[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/