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.

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.

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 (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
• 1.1. Conventions used in this document
• 1.2. Document History
• 2. Background
• 3. Using AERO in DTLS
• 3.1. Multicast
• 4. IANA Considerations
• 5. Security considerations
• 6. References
• 6.1. Normative references
• 6.2. Informative references
• Authors' Addresses

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 there may be changes to this specification over time.

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.

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

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.

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.

6. References

6.1. Normative references

6.2. Informative references

Authors' Addresses