Internet DRAFT - draft-yegin-coap-security-options
draft-yegin-coap-security-options
Network Working Group A. Yegin
Internet-Draft Samsung
Intended status: Standards Track Z. Shelby
Expires: April 16, 2012 Sensinode
October 14, 2011
CoAP Security Options
draft-yegin-coap-security-options-00
Abstract
This document specifies a set of Constrained Application Protocol
(CoAP) options that are used for providing data origin
authentication, integrity and replay protection, and encryption for
the CoAP messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Yegin & Shelby Expires April 16, 2012 [Page 1]
Internet-Draft CoAP Security Options October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. CryptoInitiate Option . . . . . . . . . . . . . . . . . . . 3
2.2. CryptoTerminate Option . . . . . . . . . . . . . . . . . . 5
2.3. CryptoEncap Option . . . . . . . . . . . . . . . . . . . . 6
2.3.1. AES-CCM (Counter with Cipher Block Chaining
Message Authentication Code) . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Yegin & Shelby Expires April 16, 2012 [Page 2]
Internet-Draft CoAP Security Options October 2011
1. Introduction
The CoAP base specifications identifies DTLS [RFC4347] and IPsec
[RFC4303] as two of the methods that can be used for providing data
origin authentication, integrity and replay protection, and
encryption for the CoAP messages. This document defines an
alternative method that operates at the CoAP layer. It is expected
that a solution defined within the same layer as the base
specification would provide an efficient alternative to DTLS and
IPsec in terms of crypto context setup, packet size, and
implementation overhead. How the CoAP client and server decide which
one(s) of the DTLS, IPsec, and this method to use is outside the
scope of this document.
Three new CoAP options are defined in this document. The
CryptoInitiate Option is used for initializing a crypto context
between the two end-points. It is used for setting up the crypto
parameters that can be used with the subsequent CoAP messages. The
CryptoEncap Option is used for securely delivering the CoAP messages
using the crypto context between the end-points. This option can
provide either data origin authentication, replay and integrity
protection for the whole CoAP message, or encryption for the options
and the payload of the message, or both depending on the crypto
algorithm used by the crypto context. The CryptoTerminate Option is
used for deleting the crypto context that is no longer needed by the
end-points.
The crypto context is based on a symmetric secret key shared between
the end-points. It is assumed that such a key is established a
priori. Methods used for establishing such keys are outside the
scope of this document.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
2. Details
2.1. CryptoInitiate Option
The CryptoInitiate Option (option no. TBD) is a Critical option that
is used for setting up a crypto context between the CoAP client and
server. Use of this option is not mandatory, as an out-of scope
Yegin & Shelby Expires April 16, 2012 [Page 3]
Internet-Draft CoAP Security Options October 2011
method may substitute for its functionality.
When a CoAP client wants to setup a security context to be used with
the CryptoEncap Option, it SHALL send a confirmable request message
that includes a CryptoInitiate Option. This message MAY include
other options and payload (i.e., piggybacked). The Code field of the
message SHALL be set to 0 if no other options or payload are
included.
The Option Value field of the CryptoInitiate Option contains a
Context ID. This is an identifier value assigned to the context by
the client. The Context ID space is shared between the client and
the server. If an identifier is used for the initialization of a
context by one of the end-points, the other end-point SHALL not use
the same identifier for initializing another context. If the client
re-uses an identifier that is already used with a context that was
initialized by the same client, then the new request is used for re-
initialization of that context. Otherwise, a new context with the
provided identifier is be created. Note that these actions are
executed only when the option is considered valid by the server as
outlined below.
The Key Name parameter in the Option Value field contains an
identifier for the shared secret key that will be used in the
context. For example, "Device1-Device2-key#5".
The CryptoAlgos parameter in the Options Value field contains a list
of one or more proposed crypto algorithms supported by the client.
For example, AES-CCM, AES-CTR, etc.
When the server receives the request, it SHALL check the Option Value
fields. If the Context ID is not already used for a context that was
initialized by the server, and at least one of the proposed crypto
algorithms is supported by the server, and the Key Name is
recognized, then the server SHALL send back an acknowledgement
message that contains CryptoInitiate Option whose Context ID is
copied from the request, CryptoAlgos includes the selected crypto
algorithm from the proposed list, and Key Name copied from the
request.
If at least one of these checks fails, the server SHALL still send
back a response with a CryptoInitiate Option. But this time the
problematic parameters will include special reserved values to
indicate the issue. If the Context ID is already used by the server,
then the server's response SHALL carry the value of 0 in the Context
ID field. If none of the proposed crypto algorithms are supported by
the server, the CryptoAlgos field SHALL contain no algorithms. If
the Key Name is not recognized by the server, the Key Name field
Yegin & Shelby Expires April 16, 2012 [Page 4]
Internet-Draft CoAP Security Options October 2011
SHALL be set to "Unknown!".
A client MAY have more than one crypto context with the same server.
It MAY negotiate them around the same time, or at different times.
Each negotiation SHALL be carried over a dedicated request-response.
In other words, there SHALL be at most one CryptoInitiate Option in a
CoAP message.
The same context MAY be used by the both end-points whenever they are
sending request and response messages. On the other hand, each end-
point MAY also choose to initialize dedicated contexts to be used for
the request-responses initiated by themselves.
Option Value field of the CryptoIntiate Option SHALL include the
following parameters in the given order:
- Context ID: One-octet unsigned integer value. Value 0 is
reserved to indicate invalid context ID, values 1-255 are valid.
- Key Name Length: One-octet unsigned integer value. Indicates
the length of the Key Name field.
- Key Name: A non-NULL-terminated string. Value OUnknown!O is
reserved for the server to indicate an unknown key name.
- CryptoAlgos: Zero or more one-octet unsigned integer values.
Value 0, and 2-255 are reserved for future use. Value 1 indicates
AES-CCM [NIST_SP800_38C]. Number of crypto algorithms carried in
the option is determined by the difference between the option
length and the space already consumed by the Context ID, Key Name
Length, and Key Name parameters.
2.2. CryptoTerminate Option
CryptoTerminate Option (option no. TBD) is a Critical option that is
used for deleting a crypto context shared between the CoAP client and
server. Use of this option is not mandatory, as an out-of scope
method may substitute for its functionality.
When a CoAP client wants to delete a security context with a server,
it SHALL send a confirmable request message that includes a
CryptoTerminate Option. This message MAY include other options and
payload (i.e., piggybacked). The Code field of the message SHALL be
set to 0 if no other options or payload are included.
Option Value field of the CryptoInitiate Option contains a Context ID
identifying the context to be deleted. A client SHALL NOT attempt to
delete a context that was not initialized by itself.
Yegin & Shelby Expires April 16, 2012 [Page 5]
Internet-Draft CoAP Security Options October 2011
When the server receives a request carrying a CryptoTerminate Option,
it SHALL check the Context ID. If the Context ID carries an
identifier value for a context that was initialized by the client,
then the server SHALL send an acknowledgment message carrying the
exact same Option. Subsequently, the server SHALL delete the crypto
context. The server MAY delay the deletion for handling the
possibility of re-transmitted requests. If the Context ID does not
match any context that was initialized by the client, then the server
SHALL send the option with Context ID set to 0.
Option Value field of the CryptoTerminate Option SHALL include the
following parameter:
- Context ID: One-octet unsigned integer value. Value 0 is
reserved to indicate invalid context ID, values 1-255 are valid.
2.3. CryptoEncap Option
The CryptoEncap Option (option no. TBD) is a Critical option that is
used for providing security for the messages carrying this option.
It is used with a crypto context that is already initialized by the
client. It is up-to the client to decide which CoAP messages would
carry this option, and which crypto context is used with it. When
this option is used with a request, the server SHALL also use this
option and with the same crypto context in its response.
An appropriate crypto algorithm SHALL be negotiated for the crypto
context whether this option is used for data origin authentication,
integrity and replay protection, or for encryption, or both (e.g.,
AES-CCM).
Option Value of a CryptoEncap Option in a request message SHALL start
with a Context ID parameter. Client SHALL include the desired crypto
contextOs identifier value in this parameter.
If the CryptoEncap Option is used for data origin authentication,
integrity and replay protection as indicated by the crypto algorithm,
then it SHALL also include a Nonce value for freshness and a MAC
(Message Authentication Code) value. Client SHALL ensure the same
Nonce value is never re-used with the same crypto context. The exact
format/content of the Nonce and MAC depends on the crypto algorithm
being used. MAC value is computed using the complete CoAP message
(including the CryptoEncap Option with its MAC value set to all
zeroes), shared secret key associated with the crypto context, and
the keyed hashed function indicated by the crypto algorithm.
If the CryptoEncap Option is used for encryption as indicated by the
crypto algorithm, then it SHALL include OptionCount and EncryptedData
Yegin & Shelby Expires April 16, 2012 [Page 6]
Internet-Draft CoAP Security Options October 2011
parameters. All other Options and the Payload SHALL be carried in
EncryptedData parameter in encrypted form. The algorithm used for
encryption is determined by the crypto algorithm. OptionCount
indicates the number of Options carried in the EncryptedData.
When a server receives a CoAP message that includes a CryptoEncap
Option, it SHALL first process this option. Server SHALL silently
drop the message if the Context ID is unknown.
If a MAC parameter is used as indicated by the crypto algorithm, then
the server SHALL compute its own MAC value using the complete CoAP
message (including the CryptoEncap Option with its MAC value set to
all zeroes), shared secret key associated with the crypto context,
and the keyed hashed function indicated by the crypto algorithm. If
the computed and received MAC values do not match, then the server
SHALL silently drop the message.
If an EncryptedData parameter is used as indicated by the crypto
algorithm, then the server SHALL decrypt the Options and the Payload
using that parameter, the shared secret key associated with the
crypto context, and the crypto algorithm. Following these procedures
the server SHALL continue processing the CoAP message as usual
[I-D.ietf-core-coap].
2.3.1. AES-CCM (Counter with Cipher Block Chaining Message
Authentication Code)
When the negotiated crypto algorithm is AES-CCM (code 1), then the
CryptoEncap Option is used for data origin authentication, integrity
and replay protection, and encryption.
The formatting and counter generation function of AES-CCM as
specified in Appendix A of [NIST_SP800_38C] is used with the
following parameters:
n, octet length of Nonce, is 12.
t, octet length of MAC, is 16.
q, octet length of message length field is 3.
When the crypto algorithm is AES-CCM, then the Option Value field in
CryptoEncap Option SHALL include the following parameters in the
given order:
- Context ID: One-octet unsigned integer value.
Yegin & Shelby Expires April 16, 2012 [Page 7]
Internet-Draft CoAP Security Options October 2011
- Nonce: 12-octet value.
- MAC: 16-octet value.
- OptionCount: One-octet unsigned integer value.
- EncryptedData: Variable-length value.
3. Security Considerations
It is possible to use this security methon in conjunction with the
others, such as DTLS and IPsec.
Future specification can define support for additional crypto
algorithms.
4. IANA Considerations
The following IANA actions are required by this specification:
- Assignment of a standard CoAP Option code TBD for CryptoInitiate
Option
- Assignment of a standard CoAP Option code TBD for
CryptoTerminate Option
- Assignment of a standard CoAP Option code TBD for CryptoEncap
Option
- Creation of crypto algorithm identifier space for CryptoAlgos
parameter.
- Assignment of an crypto algorithm identifier 1 for AES_CCM.
5. Acknowledgments
TBD
6. Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-07 (work in progress), July 2011.
Yegin & Shelby Expires April 16, 2012 [Page 8]
Internet-Draft CoAP Security Options October 2011
[NIST_SP800_38C]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: The CCM Mode for Authentication and
Confidentiality", May 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
Authors' Addresses
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@yegin.org
Zach Shelby
Sensinode
Kidekuja 2
Vuokatti 88600
Finland
Email: zach@sensinode.com
Yegin & Shelby Expires April 16, 2012 [Page 9]
