idnits 2.17.1 draft-ietf-tcpm-tcp-ao-crypto-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 24, 2010) is 5118 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: 'RFC-tcpm-tcp-ao-crypto' is mentioned on line 553, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS197' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP800-108' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP800-38B' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: September 25, 2010 RTFM 6 March 24, 2010 8 Cryptographic Algorithms for TCP's Authentication Option, TCP-AO 9 draft-ietf-tcpm-tcp-ao-crypto-03 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, and provides the interface for future MACs. 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/ietf/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 September 25, 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 respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . ancho 61 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . Requi 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . ReqLa 63 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . ancho 64 2.3. Requirements for Future MAC Algorithms . . . . . . . . ReqFu 65 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . Algos 66 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . KDFs 67 3.1.1. Concrete KDFs . . . . . . . . . . . . . . . . . . . ancho 68 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . MACs 69 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . HMAC- 70 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . AES-1 71 4. Security Considerations . . . . . . . . . . . . . . . . . . Secur 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . ancho 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . ancho 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . ancho 75 7.1. Normative References . . . . . . . . . . . . . . . . . ancho 76 7.2. Informative References . . . . . . . . . . . . . . . . ancho 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0 79 1. Introduction 81 This document is a companion to [I-D.ietf-tcpm-tcp-auth-opt]. Like 82 most modern security protocols, TCP-AO allows users to chose which 83 cryptographic algorithm(s) they want to use to meet their security 84 needs. 86 TCP-AO provides cryptographic authentication and message integrity 87 verification between two end-points. In order to accomplish this 88 function, message authentication codes (MACs) are used, which then 89 rely on shared keys. There are various ways to create MACs. The use 90 of hashed-based MACs (HMAC) is defined in [RFC2104]. The use of 91 cipher-based MACs (CMAC) is defined in [NIST-SP800-38B]. 93 This RFC defines the general requirements for MACs used in TCP-AO, 94 both for currently specified MACs and for any future specified MACs. 95 It specifies two MAC algorithms required in all TCP-AO 96 implementations. It also specifies two key derivation functions 97 (KDFs) used to create the traffic keys used by the MACs. These KDFs 98 are also required by all TCP-AO implementations. 100 2. Requirements 102 2.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 When used in lower case, these words convey their typical use in 109 common language, and are not to be interpreted as described in 110 [RFC2119]. 112 2.2. Algorithm Requirements 114 This is the initial specification of required cryptography for 115 TCP-AO, and indicates two MAC algorithms and two KDFs. All four 116 components MUST be implemented in order for the implementation to be 117 fully compliant with this RFC. 119 The following table indicates the required MAC algorithms and KDFs 120 for TCP-AO: 122 Requirement Authentication Algorithm 123 ------------ ------------------------ 124 MUST HMAC-SHA-1-96 [RFC2104][FIPS-180-3] 125 MUST AES-128-CMAC-96 [NIST-SP800-38B][FIPS197] 127 Requirement Key Derivation Function (KDF) 128 ------------- ------------------------ 129 MUST KDF_HMAC_SHA1 130 MUST KDF_AES_128_CMAC 132 For an explanation fo why two MAC algorthims were mandated, see the 133 Section 4 section. 135 2.3. Requirements for Future MAC Algorithms 137 TCP-AO is intended to support cryptographic agility. As a result, 138 this document includes recommendations in various places for future 139 MAC and KDF algorithms when used for TCP-AO. For future MAC 140 algorithms specifically, they SHOULD protect at least 2**48 messages 141 with a collision probability of less than one in 10**9. 143 3. Algorithms Specified 145 TCP-AO requires two classes of cryptographic algorithms used on a 146 particular connection, and refers to this document to define them 147 both: 149 (1) Key Derivation Functions (KDFs) which name a pseudorandom 150 function (PRF) and use a Master_Key and some connection- 151 specific input with that PRF to produce Traffic_Keys, the 152 keys suitable for authenticating and integrity checking 153 individual TCP segments, as described in TCP-AO. 154 (2) Message Authentication Code (MAC) algorithms which take a 155 key and a message and produce an authentication tag which 156 can be used to verify the integrity and authenticity of 157 those messages. 159 In TCP-AO, these algorithms are always used in pairs. Each MAC 160 algorithm MUST specify the KDF to be used with that MAC algorithm. 161 However, a KDF MAY be used with more than one MAC algorithm. 163 3.1. Key Derivation Functions (KDFs) 165 TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP- 166 AO's current manual keying have the following interface: 168 Traffic_Key = KDF_alg(Master_Key, Context, Output_Length) 170 where: 172 - KDF_alg: the specific pseudorandom function (PRF) that is 173 the basic building block used in constructing the 174 given Traffic_Key. 176 - Master_Key: In TCP-AO's manual key mode, this is a key shared 177 by both peers, entered via some interface to their 178 respective configurations. The Master_Key is used 179 as the seed for the KDF. We assume that this is a 180 human-readable pre-shared key (PSK), thus we assume 181 it is of variable length. Master_Keys SHOULD be 182 random, but might not be (e.g., badly chosen by the 183 user). For interoperability, the management 184 interface by which the PSK is configured MUST 185 accept ASCII strings, and SHOULD also allow for the 186 configuration of any arbitrary binary string in 187 hexadecimal form. Other configuration methods MAY 188 be supported. 190 - Context: A binary string containing information related to 191 the specific connection for this derived keying 192 material, as defined in 193 [I-D.ietf-tcpm-tcp-auth-opt], Section 7.2. 195 - Output_Length: The length in bits of the key that the KDF will 196 produce. This length must be the size required for 197 the MAC algorithm that will use the PRF result as a 198 seed. 200 When invoked, a KDF generates a string of length Output_Length bits 201 based on Master_Key and context value. This result may then be used 202 as a cryptographic key for any algorithm which takes an Output_Length 203 length key. A KDF MAY specify a maximum Output_Length parameter. 205 3.1.1. Concrete KDFs 207 This document defines two KDF algorithms, each paired with a 208 corresponding PRF algorithm as explained below: 210 * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2104][FIPS-180-3] 211 * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 212 [NIST-SP800-38B][FIPS197] 214 Both of these KDFs are based on the iteration mode KDFs specified in 215 [NIST-SP800-108]. This means that they use an underlying 216 pseudorandom function (PRF) with a fixed-length output, 128 bits in 217 the case of the AES-CMAC, and 160 bits in the case of HMAC-SHA1. The 218 KDF generates an arbitrary number of output bits by operating the PRF 219 in a "counter mode", where each invocation of the PRF uses a 220 different input block differentiated by a block counter. 222 Each input block is constructed as follows: 224 ( i || Label || Context || Output_Length ) 226 Where 228 - "||": For any X || Y, "||" represents a concatonation 229 operation of the binary strings X and Y. 231 - i: A counter, a binary string that is an input to each 232 iteration of the PRF in counter mode. The counter 233 "i" is represented in a single octet. The number of 234 iterations will depend on the specific size of the 235 Output_Length desired for a given MAC. "i" always 236 starts = 1. 238 - Label: A binary string that clearly identifies the purpose 239 of this KDF's derived keying material. For TCP-AO we 240 use the ASCII string "TCP-AO", where the last 241 character is the capital letter "O", not to be 242 confused with a zero. While this may seem like 243 overkill in this specification since TCP-AO only 244 describes one call to the KDF, it is included in 245 order to comply with FIPS 140 certifications. 247 - Context: The context argument provided to the KDF interface, 248 as described above in Section 3.1 . 250 - Output_Length: The length in bits of the key that the KDF will 251 produce. The Output_length is represented within two 252 octets. This length must be the size required for 253 the MAC algorithm that will use the PRF result as a 254 seed. 256 The ouput of multiple PRF invocations is simply concatenated. For 257 the Traffic_Key, values of multiple PRF invocations are concatenated 258 and truncated as needed to create a Traffic_Key of the desired 259 length. For instance, if one were using KDF_HMAC_SHA1, which uses a 260 160-bit internal PRF to generate 320 bits of data, one would execute 261 the PRF twice, once with i=1 and once with i=2. The result would be 262 the entire output of the first invocation concatenated with the 263 second invocation. E.g., 265 Traffic_Key = 266 KDF_alg(Master_Key, 1 || Label || Context || Output_length) || 267 KDF_alg(Master_Key, 2 || Label || Context || Output_length) 269 If the number of bits required is not an exact multiple of the output 270 size of the PRF, then the output of the final invocation of the PRF 271 is truncated as necessary. 273 3.1.1.1. KDF_HMAC_SHA1 275 For KDF_HMAC_SHA1: 277 - PRF for KDF_alg: HMAC-SHA1 [RFC2104][FIPS-180-3]. 279 - Use: HMAC-SHA1(Key, Input). 281 - Key: Master_Key, configured by user, and passed to the KDF. 283 - Input: ( i || Label || Context || Output_Length) 285 - Output_Length: 160 bits. 287 - Result: Traffic_Key, used in the MAC function by TCP-AO. 289 3.1.1.2. KDF_AES_128_CMAC 291 For KDF_AES_128_CMAC: 293 - PRF for KDF_alg: AES-CMAC-PRF-128 [NIST-SP800-38B][FIPS197]. 295 - Use: AES-CMAC(Key, Input). 297 - Key: Master_Key (see usage below) 299 - Input: ( i || Label || Context || Output_Length) 300 - Output_Length: 128 bits. 302 - Result: Traffic_Key, used in the MAC function by TCP-AO 304 The Master_Key in TCP-AO's current manual keying mechanism is a 305 shared secret, entered by an administrator. It is passed via an out- 306 of-band mechanism between two devices, and often between two 307 organizations. The shared secret does not have to be 16 octets, and 308 the length may vary. However, AES_128_CMAC requires a key of exactly 309 16 octets (128 bits) in length. We could mandate that 310 implementations force administrators to input Master_Keys of exactly 311 128 bit length when using AES_128_CMAC, and with sufficient 312 randomness, but this places undue burden on the implementors and 313 deployers. This specification RECOMMENDS that deployers use a 314 randomly generated 128-bit string as the Master_Key, but acknowledges 315 that deployers may not. 317 To handle variable length Master_Keys we use the same mechanism as 318 described in [RFC4615], Sect 3. First we use AES_128_CMAC with a 319 fixed key of all zeros as a "randomness extractor", while using the 320 shared secret Master_Key, MK, as the message input, to produce a 128 321 bit key Derived_Master_Key (K). Second, we use the result as a key, 322 and run AES-128_CMAC again, this time using the result K as the Key, 323 and the true input block as the Input to yield the Traffic_Key (TK) 324 used in the MAC over the message. The description follows: 326 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 327 + KDF-AES-128-CMAC + 328 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 329 + + 330 + Input : MK (Master_Key, the variable-length shared secret) + 331 + : I (Input, i.e., the input data of the PRF) + 332 + : MKlen (length of MK in octets) + 333 + : len (length of M in octets) + 334 + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + 335 + + 336 +-------------------------------------------------------------------+ 337 + Variable: K (128-bit key for AES-CMAC) + 338 + + 339 + Step 1. If MKlen is equal to 16 + 340 + Step 1a. then + 341 + K := MK; + 342 + Step 1b. else + 343 + K := AES-CMAC(0^128, MK, MKlen); + 344 + Step 2. TK := AES-CMAC(K, I, len); + 345 + return TK; + 346 + + 347 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 349 Figure 1 351 In step 1, the 128-bit key, K, for AES-CMAC is derived as follows: 353 o If the Master_Key, MK, provided by the administrator is exactly 128 354 bits, then we use it as-is. 356 o If it is longer or shorter than 128 bits, then we derive the key K 357 by applying the AES-CMAC algorithm using the 128-bit all-zero string 358 as the key and MK as the input message. This step is described in 359 step 1b. 361 In step 2, we apply the AES-CMAC algorithm again, this time using K 362 as the key and I as the input message. 364 The output of this algorithm returns TK, the Traffic_Key, which is 365 128 bits suitable for use in the MAC function on each TCP segment of 366 the connection. 368 3.1.1.3. Tips for User Interfaces regarding KDFs 370 This section provides suggested representations for the KDFs in 371 implementation user interfaces. Following these guidelines across 372 common implementations will make interoperability easier and simpler 373 for deployers. 375 UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". 377 UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply 378 "AES128". 380 The initial IANA registry values will reflect these two entries. 382 UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO 383 settings. KDF_HMAC_SHA1 is preferred at this time because it has 384 wide support, being present in most implementations in the 385 marketplace. 387 3.2. MAC Algorithms 389 Each MAC_alg defined for TCP-AO has three fixed elements as part of 390 its definition: 392 - KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the 393 Traffic_Key 394 - Key_Length: Length in bits required for the Traffic_Key used in 395 this MAC 396 - MAC_Length: The final length of the bits used in the TCP-AO MAC 397 field. This value may be a truncation of the MAC 398 function's original output length. 400 MACs computed for TCP-AO have the following interface: 402 MAC = MAC_alg(Traffic_Key, Message) 404 where: 406 - MAC_alg: MAC Algorithm used 407 - Traffic_Key: Variable; the result of KDF. 408 - Message The message to be authenticated, as specified in 409 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 411 This document specifies two MAC algorithm options for generating the 412 MAC as used by TCP-AO: 414 * HMAC-SHA-1-96 based on [RFC2104] and [FIPS-180-3]. 416 * AES-128-CMAC-96 based on [NIST-SP800-38B][FIPS197] 418 Both provide a high level of security and efficiency. The AES-128- 419 CMAC-96 is potentially more efficient, particularly in hardware, but 420 HMAC-SHA-1-96 is more widely used in Internet protocols and in most 421 cases could be supported with little or no additional code in today's 422 deployed software and devices. 424 An important aspect to note about these algorithms' definitions for 425 use in TCP-AO is the fact that the MAC outputs are truncated to 96 426 bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 427 produces a 160 bit result. The MAC output are then truncated to 96 428 bits to provide a reasonable tradeoff between security and message 429 size, for fitting into the TCP-AO option field. 431 3.2.1. The Use of HMAC-SHA-1-96 433 By definition, HMAC [RFC2104] requires a cryptographic hash function. 434 SHA1 will be that hash function used for authenticating and providing 435 integrity validation on TCP segments with HMAC. 437 The three fixed elements for HMAC-SHA-1-96 are: 439 - KDF_Alg: KDF_HMAC_SHA1. 440 - Key_Length: 160 bits. 441 - MAC_Length: 96 bits. 443 For: 445 MAC = MAC_alg (Traffic_Key, Message) 447 HMAC-SHA-1-96 for TCP-AO has the following values: 449 - MAC_alg: HMAC-SHA1 450 - Traffic_Key: Variable; the result of the KDF. 451 - Message: The message to be authenticated, as specified in 452 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 454 3.2.2. The Use of AES-128-CMAC-96 456 In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually 457 define a usage of AES-128 as a cipher-based MAC according to 458 [NIST-SP800-38B]. 460 The three fixed elements for AES-128-CMAC-96 are: 462 - KDF_Alg: KDF_AES_128_CMAC. 463 - Key_Length: 128 bits. 464 - MAC_Length: 96 bits. 466 For: 468 MAC = MAC_alg (Traffic_Key, Message) 470 AES-128-CMAC-96 for TCP-AO has the following values: 472 - MAC_alg: AES-128-CMAC-96 [NIST-SP800-38B] 473 - Traffic_Key: Variable; the result of the KDF. 474 - Message: The message to be authenticated, as specified in 475 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 477 4. Security Considerations 479 This document inherits all of the security considerations of the 480 TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. 482 The security of cryptography-based systems depends on both the 483 strength of the cryptographic algorithms chosen and the strength of 484 the keys used with those algorithms. The security also depends on 485 the engineering of the protocol used by the system to ensure that 486 there are no non-cryptographic ways to bypass the security of the 487 overall system. 489 Care should also be taken to ensure that the selected key is 490 unpredictable, avoiding any keys known to be weak for the algorithm 491 in use. [RFC4086] contains helpful information on both key 492 generation techniques and cryptographic randomness. 494 Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 495 bit / 16 byte key as the seed. However, for convenience to the 496 administrators/deployers, we did not want to force them to enter a 16 497 byte Master_Key. So we specified the sub-key routine that could 498 handle a variable length Master_Key, one that might be less than 16 499 bytes. This does NOT mean that administrators are safe to use weak 500 keys. Administrators are encouraged to follow [RFC4086] as listed 501 above. We simply attempted to "put a fence around foolishness", in 502 as much as possible. 504 This document concerns itself with the selection of cryptographic 505 algorithms for the use of TCP-AO. The algorithms identified in this 506 document as "MUST implement" are not known to be broken at the 507 current time, and cryptographic research so far leads us to believe 508 that they will likely remain secure into the foreseeable future. 509 Some of the algorithms may be found in the future to have properties 510 significantly weaker than those that were believed at the time this 511 document was produced. Expect that new revisions of this document 512 will be issued from time to time. Be sure to search for more recent 513 versions of this document before implementing. 515 NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: 517 Two MAC algorithms and two corresponding KDFs are mandated as a 518 result of discussion in the TCPM WG, and in consultation with the 519 Security Area Directors. SHA-1 was selected because it is widely 520 deployed and currently has sufficient strength and reasonable 521 computational cost, so it is a "MUST" for TCP-AO today. The security 522 strength of SHA-1 HMACs should be sufficient for the foreseeable 523 future, especially given that the tags are truncated to 96 bits. 525 Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC 526 MD5) aren't practical on SHA-1, but these types of analyses are 527 mounting and could potentially pose a concern for HMAC forgery if 528 they were significantly improved, over time. The security issues 529 driving the migration from SHA-1 to SHA-256 for digital signatures 530 [HMAC-ATTACK] do not immediately render SHA-1 weak for this 531 application of SHA-1 in HMAC mode. 533 AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but 534 may not yet have very wide implementation. AES-128 CMAC is also a 535 "MUST" to implement, in order to drive vendors toward its use, and to 536 allow for another MAC option, if SHA-1 were to be compromised. 538 5. IANA Considerations 540 Upon approval of this document, IANA will create the following 541 registry at http://www.iana.org/assignments/TBD 543 Registry Name: Cryptographic Algorithms for TCP-AO Registration 544 Procedure: RFC Publication after Expert Review 546 Initial contents of this registry will be: 548 Algorithm | Reference 550 ----------------|----------- 551 SHA1 | [RFC-tcpm-tcp-ao-crypto] 553 AES128 | [RFC-tcpm-tcp-ao-crypto] 555 6. Acknowledgements 557 Eric "EKR" Rescorla, who provided a ton of input and feedback, 558 including a somewhat heavy re-write of section 3.1.x, earning him an 559 author slot on the document. 561 Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly 562 create a first draft here. 564 Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two 565 hash algorithms for TCP-AO is largely cut and pasted into various 566 sections of this document. 568 Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] & 569 [RFC4835] text was consulted and sometimes used in the Requirements 570 Section 2 section of this document. 572 (In other words, I was truly only an editor of others' text in 573 creating this document.) 575 Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues 576 with the inputs to PRFs for the KDFs. EKR was also of great 577 assistance in how to structure the text, as well as helping to guide 578 good cryptographic decisions. 580 The TCPM working group, who put up with all us crypto and routing 581 folks DoS'ing their WG for 2 years, and who provided reviews of this 582 document. 584 7. References 586 7.1. Normative References 588 [FIPS-180-3] 589 FIPS Publication 180-3, "Secured Hash Standard", 590 FIPS 180-3, October 2008. 592 [FIPS197] FIPS Publications 197, "Advanced Encryption Standard 593 (AES)", FIPS 197, November 2001. 595 [I-D.ietf-tcpm-tcp-auth-opt] 596 Touch, J., Mankin, A., and R. Bonica, "The TCP 597 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11 598 (work in progress), March 2010. 600 [NIST-SP800-108] 601 National Institute of Standards and Technology, 602 "Recommendation for Key Derivation Using Pseudorandom 603 Functions, NIST SP800-108", SP 800-108, October 2009. 605 [NIST-SP800-38B] 606 National Institute of Standards and Technology, 607 "Recommendation for Block Cipher Modes of Operation: The 608 CMAC Mode for Authentication", SP 800-38B, May 2005. 610 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 611 Hashing for Message Authentication", RFC 2104, 612 February 1997. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 7.2. Informative References 619 [HMAC-ATTACK] 620 "On the Security of HMAC and NMAC Based on HAVAL, MD4, 621 MD5, SHA-0 and SHA-1"", 2006, 622 . 625 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 626 Requirements for Security", BCP 106, RFC 4086, June 2005. 628 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 629 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 630 December 2005. 632 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 633 December 2005. 635 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 636 Advanced Encryption Standard-Cipher-based Message 637 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 638 PRF-128) Algorithm for the Internet Key Exchange Protocol 639 (IKE)", RFC 4615, August 2006. 641 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 642 Requirements for Encapsulating Security Payload (ESP) and 643 Authentication Header (AH)", RFC 4835, April 2007. 645 Authors' Addresses 647 Gregory Lebovitz 648 Juniper Networks, Inc. 649 1194 North Mathilda Ave. 650 Sunnyvale, CA 94089-1206 651 US 653 Phone: 654 Email: gregory.ietf@gmail.com 656 Eric Rescorla 657 RTFM, Inc. 658 2064 Edgewood Drive 659 Palo Alto, CA 94303 660 US 662 Phone: 650-678-2350 663 Email: ekr@rtfm.com