idnits 2.17.1 draft-salowey-eap-protectedtlv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '...ntains a MAC-TLV SHOULD contain a SeqN...' RFC 2119 keyword, line 142: '... that contains an Encrypted TLV SHOULD...' RFC 2119 keyword, line 143: '...LV and SeqNo-TLV MAY be omitted if the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 130 has weird spacing: '...on code that ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7614 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-hiller-eap-tlv-00 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-04 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-02) exists of draft-salowey-eap-key-deriv-01 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft J. Salowey 4 Document:draft-salowey-eap-protectedtlv-02.txt Cisco Systems 5 Expires: December 2003 June 2003 7 Protected EAP TLV 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [i]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 EAP type-length-value (TLV) message types provide a mechanism for 32 encapsulating additional information in an EAP conversation. In some 33 cases it is useful to cryptographically protect this information to 34 maintain the integrity and/or privacy of the communication. This 35 document defines TLV types that provide message authentication to 36 maintain the integrity of the data, encryption to protect the privacy 37 of the data and sequence numbers to protect replays or re-sequencing 38 of the data. Although protected TLVs must be chained after an 39 authentication mechanism that generates key material the protection 40 mechanism is independent of any particular authentication mechanism. 41 This makes them useful for adding generic extensions to EAP methods. 43 Table of Contents 45 1. Introduction...................................................2 46 1.1 Terminology................................................2 47 1.2 Uses.......................................................3 48 2. Message protection and validation..............................3 49 2.1 AES-128-CBC with HMAC-SHA1-128.............................4 50 3. Protected TLV formats..........................................4 51 In the following formats bits are transmitted from left to right..4 52 3.1 SeqNo-TLV..................................................4 53 3.2 MAC-TLV....................................................5 54 3.3 Encrypted-TLV..............................................6 55 3.4 Format of Encrypted Data...................................7 56 4. Key Derivation.................................................8 57 Security Considerations...........................................9 58 References........................................................9 59 Acknowledgments..................................................10 60 Author's Addresses...............................................10 62 1. Introduction 64 The EAP-TLV [1] mechanism provides a way to carry various types of 65 information in an EAP [2] conversation. For example it may be used 66 to carry protected result indications, secret credential information, 67 or channel binding information. It is often desirable to protect the 68 integrity and privacy of this information. This method must be 69 chained after a previous EAP Authentication exchange that established 70 an extended master session key, defined in [6] which can be used to 71 derive a key hierarchy of additional keys. This document describes 72 the derivation of a portion of the key hierarchy to protect 73 additional messages, the format of a protected TLV and the 74 cryptographic operations used to protect and verify the TLV. 76 Protected TLVs must be chained after an authentication mechanism that 77 generates key material. A mechanism for the generic chaining of EAP- 78 TLVs after EAP methods is yet to be defined. Protected TLVs are an 79 important part of this framework. 81 1.1 Terminology 83 EAP Application 85 A consumer of EAP keying material. Examples include link layer 86 encryption or a protected EAP-TLV. 88 Master Session Key (MSK) 90 Keying material exported by an EAP method for the purpose of link 91 layer ciphering. 93 Extended Master Session Key (EMSK) 95 Keying material separate from the MSK that is not used for any 96 other purpose than the derivation of keys for various EAP 97 applications. It is defined in [6]. 99 Application Master Session Key (AMSK) 101 Keying material used to derive ciphering keys (encryption and MAC) 102 for the application in an application specific way. 104 1.2 Uses 106 Protected TLVs can be used to add the following features to a wide 107 variety of EAP mechanisms: 109 . Protected Acknowledged Success and Failure 111 An EAP-TLV message with a MAC-TLV can be used to authenticate 112 the success and in some cases the failure of a mechanism. 114 . Channel Binding 116 An EAP-TLV message with a MAC-TLV can be used to communicate 117 channel binding information such as the MAC addresses of the 118 802.1x supplicant and authenticator. 120 . Credential Distribution 122 An Encrypted TLV main contain credentials that can optimize re- 123 authentication. 125 2. Message protection and validation 127 EAP TLV message authentication is provided by the MAC-TLV, encryption 128 is provided in the Encrypted-TLV and sequencing is protected by the 129 SeqNo-TLV. This document defines one cipher and one message 130 authentication code that must be supported by all implementations: 131 AES-128 and HMAC-SHA1-128. 133 Verification involves verifying a sequence number, verifying a MAC 134 covering the entire protected TLV packet and decrypting the data. 135 The sequence number is incremented for each message. The exception 136 to this is re-transmissions in which case the sequence number is not 137 incremented. If a duplicate or out of order sequence number is 138 received verification fails and the message is dropped. If the 139 message MAC validation fails it is also silently dropped. 141 Every EAP-TLV message that contains a MAC-TLV SHOULD contain a SeqNo- 142 TLV and every EAP-TLV message that contains an Encrypted TLV SHOULD 143 contain a MAC-TLV. The MAC-TLV and SeqNo-TLV MAY be omitted if the 144 Encrypted-TLV uses a mode that provides both message authentication 145 and sequence protection. 147 2.1 AES-128-CBC with HMAC-SHA1-128 149 First a 128 bit initialization vector (IV) is generated. The IV is 150 used to along with the encryption key to initialize the AES 128 [4] 151 cipher in CBC [5]. The encryption key is derived as described in 152 section 4. The encapsulated TLVs are padded with 0 to a 16 byte 153 boundary and then encrypted using the cipher. The MAC is calculated 154 use HMAC-SHA1-128 [3] over the entire EAP-TLV message including 155 header, unencrypted TLVs such as seqNo-TLV and the encrypted TLV and 156 the MAC field set to 0. 158 During validation first the sequence number is checked. If it is a 159 duplicate or out of sequence message the receiver drops it. Next the 160 MAC is verified, if the verification fails then the message is 161 dropped. Finally the TLV is decrypted and the unencrypted TLV 162 processed. 164 3. Protected TLV formats 166 In the following formats bits are transmitted from left to right. 168 3.1 SeqNo-TLV 170 The format of a MAC-TLV is as follows: 172 0 1 2 3 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |M|R| SeqNo-TLV | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Sequence Number | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 M 182 The mandatory bit is always set since the receiver must be able to 183 verify and decode the packet in order to find out the actual 184 contents, which may in fact be optional. 186 R 187 Reserved, set to 0 189 Type 191 (TBD) SeqNo-TLV 192 Length 194 4 196 Sequence Number 198 The sequence number starts at 0 for the first protected TLV sent 199 and is incremented for each subsequent protected TLV. Sequence 200 numbers must not be repeated. 202 3.2 MAC-TLV 204 The format of a MAC-TLV is as follows: 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |M|R| MAC-TLV | Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | MAC Type | Reserved | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 | MAC | 215 | | 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 M 221 The mandatory bit is always set since the receiver must be able to 222 verify and decode the packet in order to find out the actual 223 contents, which may in fact be optional. 225 R 226 Reserved, set to 0 228 Type 230 (TBD) MAC TLV 232 Length 234 4 + MAC Length 236 MAC Type 237 Message authentication algorithm in use. 239 (0x0001) HMAC-SHA1-128 241 Reserved 243 Set to 0 245 MAC Data 247 MAC of fixed length depending on the MAC Type. The MAC is 248 calculated over the entire EAP-TLV message with a zeroed out MAC 249 field. This includes the header, unencrypted TLVs such as sequence 250 number, and the encrypted TLV. The MAC is treated as a bit string, 251 most significant bit first. 253 For HMAC-SHA1-128 the MAC is 16 bytes (128 bits). 255 3.3 Encrypted-TLV 257 The format of a Encrypted-TLV is as follows: 259 0 1 2 3 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |M|R| Protected TLV | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Cipher | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 | IV | 268 | | 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 | Encrypted Data... . 273 . | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 M 278 The mandatory bit is always set since the receiver must be able to 279 verify and decode the packet in order to find out the actual 280 contents, which may in fact be optional. 282 R 283 Reserved, set to 0 285 Type 287 (TBD) Encrypted TLV 289 Length 291 4 + IV Length + Encrypted Data Length 293 Cipher 295 Encryption algorithm in use 297 (0x0001) AES-128-CBC 299 Reserved 301 Set to 0 303 IV 305 The IV is an Octet string of random bits, most significant bit 306 first. For AES-128 the IV is 16 bytes (128 bits). 308 Encrypted Data 310 Encrypted TLV of variable length. The encrypted data consists of 311 one or more plaintext TLVs. The format of the encrypted data is 312 described in section 3.4. 314 3.4 Format of Encrypted Data 316 The format of the encrypted data is one or more encrypted TLVs plus 0 317 padding if required. AES-128 requires padding to a 16 byte boundary. 319 0 1 2 3 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 | TLV (First TLV) | 324 | | 325 . . 326 . . 327 . . 328 | | 329 | TLV (More TLVs) | 330 . . 331 . . 332 . . 334 | TLV (Last TLV) | 335 | | 336 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 0 Padding | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 TLV 341 One or more TLVs to be encrypted 343 0 Padding 345 0 are appended to the value to pad the TLV to cipher block size if 346 required. 348 4. Key Derivation 350 Keys are needed for cryptographic message protection. Keys are 351 obtained from EAP authentication methods completed before protected 352 TLVs are sent. A least one previous EAP method must have generated a 353 extended master session key (EMSK) for application use with the 354 required amount of entropy. The application master session key (AMSK) 355 for Protected EAP TLV is derived according to EAP Key Derivation for 356 multiple applications described in [6]. 358 The key label used for protected TLV is 360 "Protected EAP TLV Master Session Key" 362 No application specific data is used in deriving the key. For AES- 363 128-HMAC-SHA1-128 the AMSK should be 128 bits. The AMSK is then used 364 to derive the encryption and MAC keys as follows: 366 Encryption Key = HMAC-SHA1 (PMK,"protected TLV encryption key" + 367 cipher number) 369 MAC Key = HMAC-SHA1 (PMK,"protected TLV authentication key" + MAC 370 type number) 372 For AES-128 and HMAC-SHA1-128 the keys are truncated to 128 bits. 374 If more than one previous authentication method has generated a key 375 they are combined in a method described in [6]. 377 These keys are derived locally and not exported out side the EAP Peer 378 or Authenticator. 380 Security Considerations 382 The keys used in the message protection rely upon keys generated by 383 previous EAP authentication mechanism in the same session. One of 384 the mechanisms must generate a key with the required key strength. 385 For AES-128 and HMAC-SHA1-128 the required key strength is 128 bits. 386 A different key must be derived for each new EAP session. 388 The key derivation for Protected EAP-TLV makes use of the key 389 derivation in [6]. It should be noted that the keys derived for this 390 purpose should not be exported outside of the EAP Peer or 391 Authenticator as they are not needed elsewhere. In addition the 392 master session key used in deriving these keys should not be exported 393 since that would result in the same effect as exporting the keys 394 themselves. 396 References 398 [1] Hiller, Palekar, and Zorn "A Container Type for the Extensible 399 Authentication Protocol (EAP)", draft-hiller-eap-tlv-00.txt, work-in- 400 progress, October 2002 (NORMATIVE) 402 [2] L. Blunk, J. Vollbrecht, B. Aboba, "Extensible Authentication 403 Protocol (EAP)", draft-ietf-pppext-rfc2284bis-04.txt, work-in- 404 progress, June 2003 (NORMATIVE) 406 [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for 407 Message Authentication", RFC 2104, February 1997 (NORMATIVE) 409 [4] Federal Information Processing Standard (FIPS) draft standard, 410 "Advanced Encryption Standard (AES)", 411 http://csrc.nist.gov/publications/drafts/dfips-AES.pdf, September 412 2001 (NORMATIVE) 414 [5] US National Bureau of Standards, "DES Modes of Operation", 415 Federal Information Processing Standard (FIPS) Publication 81, 416 December 1980 (NORMATIVE) 418 [6] P. Eronen and J. Salowey, "EAP Key Derivation for Multiple 419 Application", draft-salowey-eap-key-deriv-01.txt, work-in-progress, 420 June 2003 (NORMATIVE) 422 Acknowledgments 424 Thanks to Glen Zorn for several helpful comments. 426 Author's Addresses 428 Joseph Salowey 429 Cisco Systems 430 2901 Third Avenue 431 Seattle, WA 98121 432 US 433 E-mail: jsalowey@cisco.com 434 Phone: +1 206 256 3380