idnits 2.17.1 draft-mcgrew-dtls-aero-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-mcgrew-aero-00 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft J. Foley 4 Intended status: Standards Track J. Salowey 5 Expires: April 24, 2014 Cisco Systems 6 October 21, 2013 8 Using Authenticated Encryption with Replay prOtection (AERO) in Datagram 9 Transport Layer Security (DTLS) 10 draft-mcgrew-dtls-aero-00.txt 12 Abstract 14 Datagram Transport Layer Security (DTLS) is a communication security 15 protocol that is attractive for use in constrained environments, in 16 which it is important to minimize the data expansion added by the 17 security protocol, and to support multicast security . Authenticated 18 Encryption with Replay prOtection (AERO) is a cryptographic technique 19 that is well suited for use in DTLS, especially in these scenarios: 20 it has minimal data expansion, avoids the need to manage implicit 21 state, works well with multiple receivers and multiple senders, and 22 provides strong misuse resistance. This document describes how AERO 23 can be used in DTLS. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions used in this document . . . . . . . . . . . . 3 61 1.2. Document History . . . . . . . . . . . . . . . . . . . . . 3 62 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Using AERO in DTLS . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Normative references . . . . . . . . . . . . . . . . . . . 10 69 6.2. Informative references . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 It is challenging to provide communication security in constrained 75 environments. Datagram Transport Layer Security (DTLS) [RFC6347] has 76 emerged as a communication security protocol of choice for such 77 environments; for instance, a binding of DTLS to the Constrained 78 Application Protocol (CoAP) [I-D.ietf-core-coap] has been defined, 79 and it appears that a profile of DTLS will be "reasonably 80 implementable" on constrained devices [DICE]. One important 81 constraint is bandwidth, which is often a scarce resource in wireless 82 environments, most especially when the transmitter or receiver is 83 battery-powered. This motivates the use of cryptographic transforms 84 that minimize the size of the data overhead, that is, the additional 85 bytes that must be communicated in order to add confidentiality, 86 message authentication, and replay protection to each message. 88 There is also interest in using DTLS for protecting multicast 89 messages, which are commonplace in the Internet of Things 90 environments [I-D.keoh-tls-multicast-security]. Standards work is 91 underway to consider the use of DTLS record layer for this purpose 92 [DICE] (though work on key management has not yet been chartered). 93 For multicast applications, it is important to use cryptographic 94 mechanisms that can easily and securely work with multiple receivers 95 and with multiple senders. 97 In addition to meeting the needs identified above, cryptographic 98 transforms should be robust against implementation failure and 99 misuse, and should not rely on implicit state, which is problematic 100 to synchronize, especially when there are multiple senders and 101 receivers. 103 1.1. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 1.2. Document History 111 This section describes the evolution of this document as an Internet 112 Draft, and it should be removed by the RFC Editor prior to 113 publication as an RFC. 115 This is the initial version of this note. As it uses a cryptographic 116 technique that was published recently, it may evolve over time as 117 that technique is reviewed and experience is gained in its usage. 118 Thus, while we encourage the implementation of this note as the best 119 way to obtain experience with these techniques, also expect that 120 there may be changes to this specification over time. 122 2. Background 124 Authenticated Encryption with Replay prOtection (AERO) 125 [I-D.mcgrew-aero] is a cryptographic technique that provides all of 126 the essential security services needed by a communication security 127 protocol. It is a stateful and self-synchronizing authenticated 128 encryption method that provides protection from replay attacks as a 129 side benefit. Replay protection and authentication are provided 130 through a single mechanism, in which a sequence number is encrypted 131 along with a plaintext message. If the ciphertext message is not 132 tampered with, then this sequence number will be recovered by the 133 decrypter, and verified to be valid. If the ciphertext message is a 134 replay of an earlier message, then the decrypter will detect this 135 fact from the recovered sequence number. If the ciphertext message 136 is tampered with, or is crafted as a forgery, this fact will be 137 apparent to the decrypter because the value that should be a valid 138 sequence number is instead a pseudorandom value. 140 3. Using AERO in DTLS 142 AERO is an authenticated encryption mechanism, and it can be used 143 through the standard AEAD interface [RFC5116], as defined in Section 144 3.6 of [I-D.mcgrew-aero]. TLS version 1.2 defines how to use an AEAD 145 method through the that interface, via the TLS GenericAEADCipher (see 146 Section 6.2.3.3. of [RFC5246]). This note follows these earlier 147 specifications, except where otherwise noted. 149 When AERO is used in DTLS, SecurityParameters.record_iv_length is 150 equal to zero, since AERO algorithms do not require the use of a 151 nonce or initialization vector. Thus, the nonce_explicit field in 152 the GenericAEADCipher structure has a length of zero. 154 The AEAD key and plaintext are as specified in Section 6.2.3.3. of 155 [RFC5246]. 157 The AEAD associated data is denoted as additional_data and is 158 computed as 160 additional_data = TLSCompressed.type + TLSCompressed.version + 161 TLSCompressed.length; 163 where "+" denotes concatenation. The seq_num field is omitted from 164 the additional_data because its authentication is not needed, since 165 AERO detects replay attacks. 167 In DTLS version 1.3, the epoch and sequence_number fields MUST be 168 omitted from the DTLSPlaintext. In DTLS version 1.2, those fields 169 MUST be present. 171 Rationale: With AERO, the epoch and sequence_number fields are not 172 needed. Omitting those fields enables each message sent to save 173 eight bytes of overhead, a value that is significant for some 174 applications, and it makes the on-the-wire data format identical 175 to that of TLS does, which could simplify implementations. We 176 specify this omission for version 1.3, but not the earlier 177 version, in order to avoid overloading the earlier version with 178 complexity. By omitting the seq_num from the additional_data 179 computation, we enable an AERO implementation to work the same way 180 for both versions 1.2 and 1.3 of DTLS, providing compatibility. 182 3.1. Multicast 184 DTLS-AERO is suitable for use in one-to-many scenarios such as those 185 described in [I-D.keoh-tls-multicast-security]. In order to use 186 DTLS-AERO it for many-to-many scenarios, in which more than one 187 entity is using a single key for encryption, it would be necessary to 188 modify the definition of DTLS in such a way that each receiver could 189 unambiguously identify each sender. This could be done by having a 190 receiver use the source IP address and source port of the packet that 191 carried the DTLS record, or by adding a new field to DTLS that works 192 like the Synchronization Source (SSRC) identifier field in the Real- 193 time Transport Protocol [RFC3550]. In either case, the fields that 194 are used to identify the sender should be part of the authenticated 195 data. We emphasize that the change needs to be made to DTLS, and not 196 to AERO, which is inherently capable of handling scenarios in which 197 there are multiple devices performing encryption with a single key. 199 4. IANA Considerations 201 There are no requests to IANA at this time. 203 A future version of this note will specify DTLS ciphersuites that 204 make use of AERO. 206 5. Security considerations 208 The security considerations of AERO are discussed in Section 11 of 209 [I-D.mcgrew-aero]. 211 AERO works well in multiple-receiver scenarios, and it provides 212 automatic (re)synchronization of replay protection state between the 213 sender and receivers, including "late joiners" to the secure session. 214 It also works well for multiple-sender scenarios. These topics are 215 discussed in Sections 3.5, 6, and 11.4 of [I-D.mcgrew-aero]. 217 AERO is robust against misuse, which is especially valuable in 218 virtual machine environments and in devices that may be subject to 219 tampering. 221 6. References 223 6.1. Normative references 225 [I-D.keoh-tls-multicast-security] 226 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 227 Security for Low-Power and Lossy Networks (LLNs)", 228 draft-keoh-tls-multicast-security-00 (work in progress), 229 October 2012. 231 [I-D.mcgrew-aero] 232 McGrew, D. and J. Foley, "Authenticated Encryption with 233 Replay prOtection (AERO)", draft-mcgrew-aero-00 (work in 234 progress), October 2013. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 240 Encryption", RFC 5116, January 2008. 242 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 243 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 245 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 246 Security Version 1.2", RFC 6347, January 2012. 248 6.2. Informative references 250 [DICE] IETF DICE Working Group, "Datagram TLS in Constrained 251 Environments (DICE) Charter", WG Charter, 252 2013 http://www.ietf.org/proceedings/87/dice.html. 254 [I-D.ietf-core-coap] 255 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 256 Application Protocol (CoAP)", draft-ietf-core-coap-18 257 (work in progress), June 2013. 259 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 260 Jacobson, "RTP: A Transport Protocol for Real-Time 261 Applications", STD 64, RFC 3550, July 2003. 263 Authors' Addresses 265 David McGrew 266 Cisco Systems 267 13600 Dulles Technology Drive 268 Herndon, VA 20171 269 US 271 Email: mcgrew@cisco.com 272 URI: http://www.mindspring.com/~dmcgrew/dam.htm 274 John Foley 275 Cisco Systems 276 7025-2 Kit Creek Road 277 Research Triangle Park, NC 14987 278 US 280 Email: foleyj@cisco.com 282 Joe Salowey 283 Cisco Systems 285 Email: jsalowey@cisco.com