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]
