Internet DRAFT - draft-mcgrew-dtls-aero

draft-mcgrew-dtls-aero






Network Working Group                                          D. McGrew
Internet-Draft                                                  J. Foley
Intended status: Standards Track                              J. Salowey
Expires: April 24, 2014                                    Cisco Systems
                                                        October 21, 2013


Using Authenticated Encryption with Replay prOtection (AERO) in Datagram
                    Transport Layer Security (DTLS)
                     draft-mcgrew-dtls-aero-00.txt

Abstract

   Datagram Transport Layer Security (DTLS) is a communication security
   protocol that is attractive for use in constrained environments, in
   which it is important to minimize the data expansion added by the
   security protocol, and to support multicast security .  Authenticated
   Encryption with Replay prOtection (AERO) is a cryptographic technique
   that is well suited for use in DTLS, especially in these scenarios:
   it has minimal data expansion, avoids the need to manage implicit
   state, works well with multiple receivers and multiple senders, and
   provides strong misuse resistance.  This document describes how AERO
   can be used in DTLS.

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 24, 2014.

Copyright Notice

   Copyright (c) 2013 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



McGrew, et al.           Expires April 24, 2014                 [Page 1]

Internet-Draft                  DTLS-AERO                   October 2013


   (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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  3
     1.2.  Document History . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Using AERO in DTLS . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative references . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative references . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11




























McGrew, et al.           Expires April 24, 2014                 [Page 2]

Internet-Draft                  DTLS-AERO                   October 2013


1.  Introduction

   It is challenging to provide communication security in constrained
   environments.  Datagram Transport Layer Security (DTLS) [RFC6347] has
   emerged as a communication security protocol of choice for such
   environments; for instance, a binding of DTLS to the Constrained
   Application Protocol (CoAP) [I-D.ietf-core-coap] has been defined,
   and it appears that a profile of DTLS will be "reasonably
   implementable" on constrained devices [DICE].  One important
   constraint is bandwidth, which is often a scarce resource in wireless
   environments, most especially when the transmitter or receiver is
   battery-powered.  This motivates the use of cryptographic transforms
   that minimize the size of the data overhead, that is, the additional
   bytes that must be communicated in order to add confidentiality,
   message authentication, and replay protection to each message.

   There is also interest in using DTLS for protecting multicast
   messages, which are commonplace in the Internet of Things
   environments [I-D.keoh-tls-multicast-security].  Standards work is
   underway to consider the use of DTLS record layer for this purpose
   [DICE] (though work on key management has not yet been chartered).
   For multicast applications, it is important to use cryptographic
   mechanisms that can easily and securely work with multiple receivers
   and with multiple senders.

   In addition to meeting the needs identified above, cryptographic
   transforms should be robust against implementation failure and
   misuse, and should not rely on implicit state, which is problematic
   to synchronize, especially when there are multiple senders and
   receivers.

1.1.  Conventions used in this document

   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].

1.2.  Document History

   This section describes the evolution of this document as an Internet
   Draft, and it should be removed by the RFC Editor prior to
   publication as an RFC.

   This is the initial version of this note.  As it uses a cryptographic
   technique that was published recently, it may evolve over time as
   that technique is reviewed and experience is gained in its usage.
   Thus, while we encourage the implementation of this note as the best
   way to obtain experience with these techniques, also expect that



McGrew, et al.           Expires April 24, 2014                 [Page 3]

Internet-Draft                  DTLS-AERO                   October 2013


   there may be changes to this specification over time.


















































McGrew, et al.           Expires April 24, 2014                 [Page 4]

Internet-Draft                  DTLS-AERO                   October 2013


2.  Background

   Authenticated Encryption with Replay prOtection (AERO)
   [I-D.mcgrew-aero] is a cryptographic technique that provides all of
   the essential security services needed by a communication security
   protocol.  It is a stateful and self-synchronizing authenticated
   encryption method that provides protection from replay attacks as a
   side benefit.  Replay protection and authentication are provided
   through a single mechanism, in which a sequence number is encrypted
   along with a plaintext message.  If the ciphertext message is not
   tampered with, then this sequence number will be recovered by the
   decrypter, and verified to be valid.  If the ciphertext message is a
   replay of an earlier message, then the decrypter will detect this
   fact from the recovered sequence number.  If the ciphertext message
   is tampered with, or is crafted as a forgery, this fact will be
   apparent to the decrypter because the value that should be a valid
   sequence number is instead a pseudorandom value.


































McGrew, et al.           Expires April 24, 2014                 [Page 5]

Internet-Draft                  DTLS-AERO                   October 2013


3.  Using AERO in DTLS

   AERO is an authenticated encryption mechanism, and it can be used
   through the standard AEAD interface [RFC5116], as defined in Section
   3.6 of [I-D.mcgrew-aero].  TLS version 1.2 defines how to use an AEAD
   method through the that interface, via the TLS GenericAEADCipher (see
   Section 6.2.3.3. of [RFC5246]).  This note follows these earlier
   specifications, except where otherwise noted.

   When AERO is used in DTLS, SecurityParameters.record_iv_length is
   equal to zero, since AERO algorithms do not require the use of a
   nonce or initialization vector.  Thus, the nonce_explicit field in
   the GenericAEADCipher structure has a length of zero.

   The AEAD key and plaintext are as specified in Section 6.2.3.3. of
   [RFC5246].

   The AEAD associated data is denoted as additional_data and is
   computed as

      additional_data = TLSCompressed.type + TLSCompressed.version +
      TLSCompressed.length;

   where "+" denotes concatenation.  The seq_num field is omitted from
   the additional_data because its authentication is not needed, since
   AERO detects replay attacks.

   In DTLS version 1.3, the epoch and sequence_number fields MUST be
   omitted from the DTLSPlaintext.  In DTLS version 1.2, those fields
   MUST be present.

      Rationale: With AERO, the epoch and sequence_number fields are not
      needed.  Omitting those fields enables each message sent to save
      eight bytes of overhead, a value that is significant for some
      applications, and it makes the on-the-wire data format identical
      to that of TLS does, which could simplify implementations.  We
      specify this omission for version 1.3, but not the earlier
      version, in order to avoid overloading the earlier version with
      complexity.  By omitting the seq_num from the additional_data
      computation, we enable an AERO implementation to work the same way
      for both versions 1.2 and 1.3 of DTLS, providing compatibility.

3.1.  Multicast

   DTLS-AERO is suitable for use in one-to-many scenarios such as those
   described in [I-D.keoh-tls-multicast-security].  In order to use
   DTLS-AERO it for many-to-many scenarios, in which more than one
   entity is using a single key for encryption, it would be necessary to



McGrew, et al.           Expires April 24, 2014                 [Page 6]

Internet-Draft                  DTLS-AERO                   October 2013


   modify the definition of DTLS in such a way that each receiver could
   unambiguously identify each sender.  This could be done by having a
   receiver use the source IP address and source port of the packet that
   carried the DTLS record, or by adding a new field to DTLS that works
   like the Synchronization Source (SSRC) identifier field in the Real-
   time Transport Protocol [RFC3550].  In either case, the fields that
   are used to identify the sender should be part of the authenticated
   data.  We emphasize that the change needs to be made to DTLS, and not
   to AERO, which is inherently capable of handling scenarios in which
   there are multiple devices performing encryption with a single key.









































McGrew, et al.           Expires April 24, 2014                 [Page 7]

Internet-Draft                  DTLS-AERO                   October 2013


4.  IANA Considerations

   There are no requests to IANA at this time.

   A future version of this note will specify DTLS ciphersuites that
   make use of AERO.













































McGrew, et al.           Expires April 24, 2014                 [Page 8]

Internet-Draft                  DTLS-AERO                   October 2013


5.  Security considerations

   The security considerations of AERO are discussed in Section 11 of
   [I-D.mcgrew-aero].

   AERO works well in multiple-receiver scenarios, and it provides
   automatic (re)synchronization of replay protection state between the
   sender and receivers, including "late joiners" to the secure session.
   It also works well for multiple-sender scenarios.  These topics are
   discussed in Sections 3.5, 6, and 11.4 of [I-D.mcgrew-aero].

   AERO is robust against misuse, which is especially valuable in
   virtual machine environments and in devices that may be subject to
   tampering.





































McGrew, et al.           Expires April 24, 2014                 [Page 9]

Internet-Draft                  DTLS-AERO                   October 2013


6.  References

6.1.  Normative references

   [I-D.keoh-tls-multicast-security]
              Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast
              Security for Low-Power and Lossy Networks (LLNs)",
              draft-keoh-tls-multicast-security-00 (work in progress),
              October 2012.

   [I-D.mcgrew-aero]
              McGrew, D. and J. Foley, "Authenticated Encryption with
              Replay prOtection (AERO)", draft-mcgrew-aero-00 (work in
              progress), October 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, January 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

6.2.  Informative references

   [DICE]     IETF DICE Working Group, "Datagram TLS in Constrained
              Environments (DICE) Charter", WG Charter,
              2013 http://www.ietf.org/proceedings/87/dice.html.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., and C. Bormann, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-18
              (work in progress), June 2013.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.










McGrew, et al.           Expires April 24, 2014                [Page 10]

Internet-Draft                  DTLS-AERO                   October 2013


Authors' Addresses

   David McGrew
   Cisco Systems
   13600 Dulles Technology Drive
   Herndon, VA  20171
   US

   Email: mcgrew@cisco.com
   URI:   http://www.mindspring.com/~dmcgrew/dam.htm


   John Foley
   Cisco Systems
   7025-2 Kit Creek Road
   Research Triangle Park, NC  14987
   US

   Email: foleyj@cisco.com


   Joe Salowey
   Cisco Systems

   Email: jsalowey@cisco.com


























McGrew, et al.           Expires April 24, 2014                [Page 11]