idnits 2.17.1 draft-ietf-tcpm-tcp-ao-crypto-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 10, 2010) is 5186 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) == Missing Reference: 'TCP-AO' is mentioned on line 96, but not defined == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 747, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-10 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 4305 (Obsoleted by RFC 4835) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM G. Lebovitz 3 Internet-Draft Juniper 4 Intended status: Standards Track E. Rescorla 5 Expires: August 14, 2010 RTFM 6 February 10, 2010 8 Cryptographic Algorithms for TCP's Authentication Option, TCP-AO 9 draft-ietf-tcpm-tcp-ao-crypto-02 11 Abstract 13 The TCP Authentication Option, TCP-AO, relies on security algorithms 14 to provide authentication between two end-points. There are many 15 such algorithms available, and two TCP-AO systems cannot interoperate 16 unless they are using the same algorithms. This document specifies 17 the algorithms and attributes that can be used in TCP-AO's current 18 manual keying mechanism. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 14, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described 55 in Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Requirements Language . . . . . . . . . . . . . . . . . 4 75 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . 4 76 2.3. Requirements for Future MAC Algorithms . . . . . . . . 5 77 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . 5 78 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . 6 79 3.1.1. Concrete KDFs . . . . . . . . . . . . . . . . . . . 7 80 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . 11 81 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . 12 82 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . 12 83 4. Change History (RFC Editor: Delete before publishing) . . . 13 84 5. Needs Work in Next Draft (RFC Editor: Delete Before 85 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . 15 86 6. Security Considerations . . . . . . . . . . . . . . . . . . 15 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . 17 90 9.1. Normative References . . . . . . . . . . . . . . . . . 17 91 9.2. Informative References . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 This document is a companion to [TCP-AO] 97 [I-D.ietf-tcpm-tcp-auth-opt]. Like most modern security protocols, 98 TCP-AO allows users to chose which cryptographic algorithm(s) they 99 want to use to meet their security needs. 101 TCP-AO provides cryptographic authentication and message integrity 102 verification between to end-points. In order to accomplish this 103 function, message authentication codes (MACs) are used, which then 104 rely on shared keys. There are various ways to create MACs. The use 105 of hashed-based MACs (HMAC) in Internet protocols is defined in 106 [RFC2104]. The use of cipher-based MACs (CMAC) in Internet protocols 107 is defined in [RFC4493]. 109 This RFC defines the general requirements for MACs used in TCP-AO, 110 both for currently specified MACs and for any future specified MACs. 111 It then specifies two MAC algorithms required in all TCP-AO 112 implementations. It also specifies two key derivation functions 113 (KDFs) used to create the traffic keys used by the MACs. These KDFs 114 are also required by all TCP-AO implementations. 116 2. Requirements 118 2.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 When used in lower case, these words convey their typical use in 125 common language, and are not to be interpreted as described in 126 [RFC2119]. 128 2.2. Algorithm Requirements 130 This is the initial specification of required cryptography for 131 TCP-AO, and indicates two MAC algorithms and two KDFs. All four 132 components MUST be implemented in order for the implementation to be 133 fully compliant with this RFC. 135 The following table indicates the required MAC algorithms and KDFs 136 for TCP-AO: 138 Requirement Authentication Algorithm 139 ------------ ------------------------ 140 MUST HMAC-SHA-1-96 [RFC2404] 141 MUST AES-128-CMAC-96 [RFC4493] 143 Requirement Key Derivation Function (KDF) 144 ------------- ------------------------ 145 MUST KDF_HMAC_SHA1 146 MUST KDF_AES_128_CMAC 148 NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: 150 Two MAC algorithms and two corresponding KDFs are mandated as a 151 result of discussion in the TCPM WG, and in consultation with the 152 Security Area Directors. SHA-1 was selected because it is widely 153 deployed and currently has sufficient strength and reasonable 154 computational cost, so it is a "MUST" for TCP-AO today. The security 155 strength of SHA-1 HMACs should be sufficient for the foreseeable 156 future, especially given that the tags are truncated to 96 bits. 158 Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC 159 MD5) aren't practical on SHA-1, but these types of analyses are 160 mounting and could potentially pose a concern for HMAC forgery if 161 they were significantly improved, over time. The security issues 162 driving the migration from SHA-1 to SHA-256 for digital signatures 163 [HMAC-ATTACK] do not immediately render SHA-1 weak for this 164 application of SHA-1 in HMAC mode. 166 AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but 167 may not yet have very wide implementation. AES-128 CMAC is also a 168 "MUST" to implement, in order to drive vendors toward its use, and to 169 allow for another MAC option, if SHA-1 were to be compromised. 171 2.3. Requirements for Future MAC Algorithms 173 TCP-AO is intended to support cryptographic agility. As a result, 174 this document includes recommendations in various places for future 175 MAC and KDF algorithms when used for TCP-AO. For future MAC 176 algorithms specifically, they SHOULD protect at least 2**48 messages 177 with a collision probability of less than one in 10**9. 179 [Reviewers: Are there any other requirements we want/need to place in 180 here? RFC EDITOR: Please delete this note before publishing as RFC] 182 3. Algorithms Specified 184 TCP-AO requires two classes of cryptographic algorithms used on a 185 particular connection, and refers to this document to define them 186 both: 188 (1) Key Derivation Functions (KDFs) which name a pseudorandom 189 function (PRF) and use a Master_Key and some connection- 190 specific input with that PRF to produce Traffic_Keys, the 191 keys suitable for authenticating and integrity checking 192 individual TCP segments, as described in TCP-AO. 193 (2) Message Authentication Code (MAC) algorithms which take a 194 key and a message and produce an authentication tag which 195 can be used to verify the integrity and authenticity of 196 those messages. 198 In TCP-AO, these algorithms are always used in pairs. Each MAC 199 algorithm MUST specify the KDF to be used with that MAC algorithm. 200 However, a KDF MAY be used with more than one MAC algorithm. 202 3.1. Key Derivation Functions (KDFs) 204 TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP- 205 AO's current manual keying have the following interface: 207 Traffic_Key = KDF_alg(Master_Key, Context, Output_Length) 209 where: 211 - KDF_alg: the specific pseudorandom function (PRF) that is 212 the basic building block used in constructing the 213 given Traffic_Key. 215 - Master_Key: In TCP-AO's manual key mode, this is a key shared 216 by both peers, entered via some interface to their 217 respective configurations. The Master_Key is used 218 as the seed for the KDF. We assume that this is a 219 human-readable pre-shared key (PSK), thus we assume 220 it is of variable length. Master_Keys SHOULD be 221 random, but might not be (e.g., badly chosen by the 222 user). 224 - Context : A binary string containing information related to 225 the specific connection for this derived keying 226 material, as defined in 227 [I-D.ietf-tcpm-tcp-auth-opt], Section 7.2] 229 - Output_Length: The length in bits of the key that the KDF will 230 produce. This length must be the size required for 231 the MAC algorithm that will use the PRF result as a 232 seed. 234 When invoked, a KDF generates a string of length Output_Length bits 235 based on Master_Key and context value. This result may then be used 236 as a cryptographic key for any algorithm which takes an Output_Length 237 length key. A KDF MAY specify a maximum Output_Length parameter. 239 3.1.1. Concrete KDFs 241 This document defines two KDF algorithms, each paired with a 242 corresponding PRF algorithm as explained below: 244 * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] 245 * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] 247 Both of these KDFs are based on the iteration mode KDFs specified in 248 [NIST-SP800-108]. This means that they use an underlying 249 pseudorandom function (PRF) with a fixed-length output lengths, 128 250 bits in the case of the AES-CMAC, and 160 bits in the case of HMAC- 251 SHA1. The KDF generates an arbitrary number of output bits by 252 operating the PRF in a "counter mode", where each invocation of the 253 PRF uses a different input block differentiated by a block counter. 255 Each input block is constructed as follows: 257 ( i || Label || Context || Output_Length) 259 Where 261 - "||": For any X || Y, "||" represents a concatonation 262 operation of the binary strings X and Y. 264 - i: A counter, a binary string that is an input to each 265 iteration of the PRF in counter mode. The counter 266 "i" is represented in a single octet. The number of 267 iterations will depend on the specific size of the 268 Output_Length desired for a given MAC. "i" always 269 starts = 1. 271 - Label: A binary string that clearly identifies the purpose 272 of this KDF's derived keying material. For TCP-AO we 273 use the ASCII string "TCP-AO", where the last 274 character is the capital letter "O", not to be 275 confused with a zero. While this may seem like 276 overkill in this specification since TCP-AO only 277 describes one call to the KDF, it is included in 278 order to comply with FIPS 140 certifications. 280 - Context : The context argument provided to the KDF interface, 281 as described above in Section 3.1 . 283 - Output_Length: The length in bits of the key that the KDF will 284 produce. The Output_length is represented within two 285 octets. This length must be the size required for 286 the MAC algorithm that will use the PRF result as a 287 seed. 289 The ouput of mutiple PRF invocations is simply concatenated. For the 290 Traffic_Key, values of multiple PRF invocations are concatenated and 291 truncated as needed to create a Traffic_Key of the desired length. 292 For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit 293 internal PRF to generate 320 bits of data, one would execute the PRF 294 twice, once with i=1 and once with i=2. The result would be the 295 entire output of the first invocation concatenated with the second 296 invocation. E.g., 298 Traffic_Key = 299 KDF_alg(Master_Key, 1 || Label || Context || Output_length) || 300 KDF_alg(Master_Key, 2 || Label || Context || Output_length) 302 If the number of bits required is not an even multiple of the output 303 size of the PRF, then the output of the final invocation of the PRF 304 is truncated as necessary. 306 3.1.1.1. KDF_HMAC_SHA1 308 For KDF_HMAC_SHA1: 310 - PRF for KDF_alg: HMAC-SHA1 [RFC2404]. 312 - Use: HMAC-SHA1(Key, Input). 314 - Key: Master_Key, configured by user, and passed to the KDF. 316 - Input: ( i || Label || Context || Output_Length) 318 - Output_Length: 160 bits. 320 - Result: Traffic_Key, used in the MAC function by TCP-AO. 322 3.1.1.2. KDF_AES_128_CMAC 324 For KDF_AES_128_CMAC: 326 - PRF for KDF_alg: AES-CMAC-PRF-128 [RFC4615]. 328 - Use: AES-CMAC(Key, Input). 330 - Key: Master_Key (see usage below) 332 - Input: ( i || Label || Context || Output_Length) 334 - Output_Length: 128 bits. 336 - Result: Traffic_Key, used in the MAC function by TCP-AO 338 The Master_Key in TCP-AO's current manual keying mechanism is a 339 shared secret, entered by an administrator. It is passed via an out- 340 of-band mechanism between two devices, and often between two 341 organizations. The shared secret does not have to be 16 octets, and 342 the length may vary. However, AES_128_CMAC requires a key of exactly 343 16 octets (128 bits) in length. We could mandate that 344 implementations force administrators to input Master_Keys of exactly 345 128 bit length when using AES_128_CMAC, and with sufficient 346 randomness, but this places undue burden on the implementors and 347 deployers. This specification RECOMMENDS that deployers use a 348 randomly generated 128-bit string as the Master_Key, but acknowledges 349 that deployers may not. 351 To handle variable length Master_Keys we use the same mechanism as 352 described in [RFC4615], Sect 3. First we use AES_128_CMAC with a 353 fixed key of all zeros as a "randomness extractor", while using the 354 shared secret Master_Key, MK, as the message input, to produce a 128 355 bit key Derived_Master_Key (K). Second, we use the result as a key, 356 and run AES-128_CMAC again, this time using the result K as the Key, 357 and the true input block as the Input to yield the Traffic_Key (TK) 358 used in the MAC over the message. The description follows: 360 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 361 + KDF-AES-128-CMAC + 362 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 363 + + 364 + Input : MK (Master_Key, the variable-length shared secret) + 365 + : I (Input, i.e., the input data of the PRF) + 366 + : MKlen (length of MK in octets) + 367 + : len (length of M in octets) + 368 + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + 369 + + 370 +-------------------------------------------------------------------+ 371 + Variable: K (128-bit key for AES-CMAC) + 372 + + 373 + Step 1. If MKlen is equal to 16 + 374 + Step 1a. then + 375 + K := MK; + 376 + Step 1b. else + 377 + K := AES-CMAC(0^128, MK, MKlen); + 378 + Step 2. TK := AES-CMAC(K, I, len); + 379 + return TK; + 380 + + 381 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 383 Figure 1 385 In step 1, the 128-bit key, K, for AES-CMAC is derived as follows: 387 o If the Master_Key, MK, provided by the administrator is exactly 128 388 bits, then we use it as-is. 390 o If it is longer or shorter than 128 bits, then we derive the key K 391 by applying the AES-CMAC algorithm using the 128-bit all-zero string 392 as the key and MK as the input message. This step is described in 393 step 1b. 395 In step 2, we apply the AES-CMAC algorithm again, this time using K 396 as the key and I as the input message. 398 The output of this algorithm returns TK, the Traffic_Key, which is 399 128 bits suitable for use in the MAC function on each TCP segment of 400 the connection. 402 3.1.1.3. Tips for User Interfaces regarding KDFs 404 This section provides suggested representations for the KDFs in 405 implementation user interfaces. Following these guidelines across 406 common implementations will make interoperability easier and simpler 407 for deployers. 409 UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". 411 UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply 412 "AES128". 414 The initial IANA registry values will reflect these two entries. 416 UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO 417 settings. KDF_HMAC_SHA1 is preferred at this time because it has 418 wide support, being present in most implementations in the 419 marketplace. 421 3.2. MAC Algorithms 423 Each MAC_alg defined for TCP-AO has three fixed elements as part of 424 its definition: 426 - KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the 427 Traffic_Key 428 - Key_Length: Length in bits required for the Traffic_Key used in 429 this MAC 430 - MAC_Length: The final length of the bits used in the TCP-AO MAC 431 field. This value may be a truncation of the MAC 432 function's original output length. 434 MACs computed for TCP-AO have the following interface: 436 MAC = MAC_alg(Traffic_Key, Message) 438 where: 440 - MAC_alg: MAC Algorithm used 441 - Traffic_Key: Variable; the result of KDF. 442 - Message The message to be authenticated, as specified in 443 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 445 This document specifies two MAC algorithm options for generating the 446 MAC as used by TCP-AO: 448 * HMAC-SHA-1-96 based on [RFC2404] 449 * AES-128-CMAC-96 based on [RFC4493] 451 Both provide a high level of security and efficiency. The AES-128- 452 CMAC-96 is potentially more efficient, particularly in hardware, but 453 HMAC-SHA-1-96 is more widely used in Internet protocols and in most 454 cases could be supported with little or no additional code in today's 455 deployed software and devices. 457 An important aspect to note about these algorithms' definitions for 458 use in TCP-AO is the fact that the MAC outputs are truncated to 96 459 bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 460 produces a 160 bit result. The MAC output are then truncated to 96 461 bits to provide a reasonable tradeoff between security and message 462 size, for fitting into the TCP-AO header. 464 3.2.1. The Use of HMAC-SHA-1-96 466 By definition, HMAC [RFC2104] requires a cryptographic hash function. 467 SHA1 will be that has function used for authenticating and providing 468 integrity validation on TCP segments with HMAC. 470 The three fixed elements for HMAC-SHA-1-96 are: 472 - KDF_Alg: KDF_HMAC_SHA1. 473 - Key_Length: 160 bits. 474 - MAC_Length: 96 bits. 476 For: 478 MAC = MAC_alg (Traffic_Key, Message) 480 HMAC-SHA-1-96 for TCP-AO has the following values: 482 - MAC_alg: HMAC-SHA1 483 - Traffic_Key: Variable; the result of the KDF. 484 - Message: The message to be authenticated, as specified in 485 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 487 3.2.2. The Use of AES-128-CMAC-96 489 In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually 490 define a usage of AES-128 as a cipher-based MAC according to 491 [NIST-SP800-38B]. 493 The three fixed elements for AES-128-CMAC-96 are: 495 - KDF_Alg: KDF_AES_128_CMAC. 496 - Key_Length: 128 bits. 497 - MAC_Length: 96 bits. 499 For: 501 MAC = MAC_alg (Traffic_Key, Message) 503 AES-128-CMAC-96 for TCP-AO has the following values: 505 - MAC_alg: AES-128-CMAC-96 [RFC4493] 506 - Traffic_Key: Variable; the result of the KDF. 507 - Message: The message to be authenticated, as specified in 508 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 510 4. Change History (RFC Editor: Delete before publishing) 512 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 513 Please remove before publishing as RFC.] 515 draft-ietf...-02 - 6th submission 517 o 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg: for clarification 518 o editorial touch ups - Wes 519 o in 3.2 s/Output/MAC_length , because -auth-opt-10 used "Output" in 520 a more generic way in 7.1, so the same term had two different 521 meanings, one in each doc. Changing -ao-crypto to use MAC_length 522 seemed most expedient. 523 o in 3.1.1, changed "i" to always start = 1, and changed the 524 concatonation example accordingly (it was starting = 0, which did 525 not match NIST SP 800-108 - Brian Weis 526 o in 3.1.1, added to definition of "i", "The counter "i" is 527 represented in a single octet. ", and to the definition of 528 "Output_Length" "The Output_length is represented within two 529 octets." - Brian Weis 531 draft-ietf...-01 - 5th submission 533 o simplified title of document - Touch 534 o structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the 535 description of the two KDF's became 3.1.1.1 & 3.1.1.2. used a 536 template (of sorts) in both sections that can be easily re-used by 537 any future KDF definition. 538 o in 3.1, switched "Derived_Key" back to "Traffic_Key" in order to 539 sync with -auth-opt spec. 540 o in 3.1, for Traffic_Key definition, changed the name of the 541 element "Input" to "Context", and removed the hard binding to 542 NIST-SP800-108 at the generic interface level. The NIST inclusion 543 is still present in the concrete definitions of the two presented 544 KDF's, but this way, if NIST changes, or if the community wants to 545 define some other, non-NIST-like KDFs, the interface is flexible 546 enough to handle that. Changed "KDF" to "KDF-alg". 547 o in 3.2, clarified that the output of the function is called "MAC 548 =", to have a similar look and feel to sect 3.1's function. also 549 changed MAC(foo) to "MAC_alg", and dropped "Output_Length" from 550 the function parameters, as it is specified as a fixed element for 551 each MAC defined, but not passed as a parameter of the function. 552 o sect 3.2 - removed "truncation" from interface definition, and 553 placed it as a fixed element of the MAC definition. sect 3.2.1 and 554 3.2.2 - changed "truncation:" field to "Output:". Removed text 555 about RFC4493 from end of 3.2.2. 556 o sect 3.1.1.2, changed back to follow 4615 exactly (agreement with 557 polk, mcgrew, lebovitz, ekr) 558 o sect 3.1.1.3, deleted the following: "When such a time arrives as 559 KDF_AES_128_CMAC becomes widely deployed, this document should be 560 updated so that it becomes the default KDF on implementations." 561 o added the two IANA values SHA1 and AES128 to IANA section 562 o Minor text change in section 3.1 and 3.2, to the definition of 563 "Context" in both - Joe Touch 564 o minor text change in 3.1.1 clarifying that the concatenation is of 565 binary strings - Joe Touch 566 o copy edits for read-ability throughout - Touch 568 draft-ietf...-00 - 4th submission 570 o Submitting draft-lebovitz...-02 as a WG document. Added EKR as 571 co- author, and gave him credit for rewrite of sect 3.1.x . 573 draft-lebovitz...-02 - 3rd submission 575 o cleaned up explanation in 3.1.2 576 o in 3.1.2, changed the key extractor mechanism back, from using an 577 alphanumeric string for the fixed key C to use 0^128 as the key 578 (as it was in -00) (Polk & Ekr) 579 o deleted cut-and-paste error text from sect 3.1 between "label" and 580 "context" 582 o changed "conn_key" to "traffic_key" throughout, to follow auth- 583 opt-05 584 o changed "tsad" to "mkt" throughout, to follow auth-opt-05 585 o changed "conn_block" to "data_block" throughout, to follow auth- 586 opt-05 588 draft-lebovitz...-01- 2nd submission 590 o removed the whole section on labels (previously section 4), per WG 591 consensus at IETF74. Added 3.1.3 to specify that implementations 592 SHOULD make HMAC-SHA1 the default choice for the time being, and 593 to suggest common names for the KDF's universally in UI's. 594 o changed KDF = PRF... to Derived_Key = KDF... (EKR) 595 o added the text on how to deal with future KDF to end of s3.1 (EKR) 596 o removed references to TCP-AO "manual key mode". Changed to TCP- 597 AO's "current mode of manual keying". (Touch) 598 o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, 599 per wg consensus at ietf74. 600 o in 3.1.2, changed the mechanism to force the K to be 128bits from 601 using 0^128, to using a fixed 128-bit string of random characters 602 (Dave McGrew) 603 o sect 3.1, in Input description, dropped "0x00". Added "NOTE" 604 explaining why right after the output_length description. 605 o cleaned up all references 606 o copy editing 608 draft-lebovitz...-00 - original submission 610 5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 612 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 613 Please remove before publishing as RFC.] 615 List of stuff that still needs work 616 o None. ready IESG review. 617 o Could use a bit broader security area review. Will ask a few 618 folks to review. 620 6. Security Considerations 622 This document inherits all of the security considerations of the 623 TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. 625 The security of cryptographic-based systems depends on both the 626 strength of the cryptographic algorithms chosen and the strength of 627 the keys used with those algorithms. The security also depends on 628 the engineering of the protocol used by the system to ensure that 629 there are no non-cryptographic ways to bypass the security of the 630 overall system. 632 Care should also be taken to ensure that the selected key is 633 unpredictable, avoiding any keys known to be weak for the algorithm 634 in use. ][RFC4086] contains helpful information on both key 635 generation techniques and cryptographic randomness. 637 Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 638 bit / 16 byte key as the seed. However, for convenience to the 639 administrators/deployers, we did not want to force them to enter a 16 640 byte Master_Key. So we specified the sub-key routine that could 641 handle a variable length Master_Key, one that might be less than 16 642 bytes. This does NOT mean that administrators are safe to use weak 643 keys. Administrators are encouraged to follow [RFC4086] as listed 644 above. We simply attempted to "put a fence around stupidity", in as 645 much as possible. 647 This document concerns itself with the selection of cryptographic 648 algorithms for the use of TCP-AO. The algorithms identified in this 649 document as "MUST implement" or "SHOULD implement" are not known to 650 be broken at the current time, and cryptographic research so far 651 leads us to believe that they will likely remain secure into the 652 foreseeable future. Some of the algorithms may be found in the 653 future to have properties significantly weaker than those that were 654 believed at the time this document was produced. Expect that new 655 revisions of this document will be issued from time to time. Be sure 656 to search for more recent versions of this document before 657 implementing. 659 7. IANA Considerations 661 IANA has created and will maintain a registry called, "Cryptographic 662 Algorithms for TCP-AO". The registry consists of a text string and 663 an RFC number that lists the associated transform(s). New entries 664 can be added to the registry only after RFC publication and approval 665 by an expert designated by the IESG. 667 The registry has the following initial values: 669 SHA1 [This RFC when published] 670 AES128 [This RFC when published] 672 8. Acknowledgements 674 Eric "EKR" Rescorla, who provided a ton of input and feedback, 675 including a somewhat heavy re-write of section 3.1.x, earning him and 676 author slot on the document. 678 Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly 679 create a first draft here. 681 Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two 682 hash algorithms for TCP-AO is largely cut and pasted into various 683 sections of this document. 685 Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] & 686 [RFC4305] text was consulted and sometimes used in the Requirements 687 Section 2 section of this document. 689 (In other words, I was truly only an editor of others' text in 690 creating this document.) 692 Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues 693 with the inputs to PRFs for the KDFs. EKR was also of great 694 assistance in how to structure the text, as well as helping to guide 695 good cryptographic decisions. 697 The TCPM working group, who put up with all us crypto and routing 698 folks DoS'ing their WG for 2 years, and who provided reviews of this 699 document. 701 9. References 703 9.1. Normative References 705 [I-D.ietf-tcpm-tcp-auth-opt] 706 Touch, J., Mankin, A., and R. Bonica, "The TCP 707 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-10 708 (work in progress), January 2010. 710 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 711 Requirement Levels", BCP 14, RFC 2119, March 1997. 713 9.2. Informative References 715 [HMAC-ATTACK] 716 "On the Security of HMAC and NMAC Based on HAVAL, MD4, 717 MD5, SHA-0 and SHA-1"", 2006, 718 . 721 [I-D.narten-iana-considerations-rfc2434bis] 722 Narten, T. and H. Alvestrand, "Guidelines for Writing an 723 IANA Considerations Section in RFCs", 724 draft-narten-iana-considerations-rfc2434bis-09 (work in 725 progress), March 2008. 727 [NIST-SP800-108] 728 National Institute of Standards and Technology, 729 "Recommendation for Key Derivation Using Pseudorandom 730 Functions", SP 800-108, April 2008. 732 [NIST-SP800-38B] 733 National Institute of Standards and Technology, 734 "Recommendation for Block Cipher Modes of Operation: The 735 CMAC Mode for Authentication", SP 800-38B, May 2005. 737 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 738 Hashing for Message Authentication", RFC 2104, 739 February 1997. 741 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 742 Internet Protocol", RFC 2401, November 1998. 744 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 745 ESP and AH", RFC 2404, November 1998. 747 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 748 Payload (ESP)", RFC 2406, November 1998. 750 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 751 Requirements for Security", BCP 106, RFC 4086, June 2005. 753 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 754 Requirements for Encapsulating Security Payload (ESP) and 755 Authentication Header (AH)", RFC 4305, December 2005. 757 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 758 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 759 December 2005. 761 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 762 December 2005. 764 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 765 AES-CMAC Algorithm", RFC 4493, June 2006. 767 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 768 Advanced Encryption Standard-Cipher-based Message 769 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 770 PRF-128) Algorithm for the Internet Key Exchange Protocol 771 (IKE)", RFC 4615, August 2006. 773 Authors' Addresses 775 Gregory Lebovitz 776 Juniper Networks, Inc. 777 1194 North Mathilda Ave. 778 Sunnyvale, CA 94089-1206 779 US 781 Phone: 782 Email: gregory.ietf@gmail.com 784 Eric Rescorla 785 RTFM, Inc. 786 2064 Edgewood Drive 787 Palo Alto, CA 94303 788 US 790 Phone: 650-678-2350 791 Email: ekr@rtfm.com