idnits 2.17.1 draft-ietf-tcpm-tcp-ao-crypto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 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 (September 05, 2009) is 5337 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 93, but not defined == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 678, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-05 -- 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 (~~), 7 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: March 9, 2010 RTFM 6 September 05, 2009 8 Cryptographic Algorithms, Use, & Implementation Requirments for TCP 9 Authentication Option 10 draft-ietf-tcpm-tcp-ao-crypto-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 9, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The TCP Authentication Option, TCP-AO, relies on security algorithms 59 to provide authentication between two end-points. There are many 60 such algorithms available, and two TCP-AO systems cannot interoperate 61 unless they are using the same algorithm(s). This document specifies 62 the algorithms and attributes that can be used in TCP-AO's current 63 manual keying mechanism. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . . 3 71 2.3. Requirements for Future MAC Algorithms . . . . . . . . . . 4 72 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 5 74 3.1.1. The Use of KDF_HMAC_SHA1 . . . . . . . . . . . . . . . 7 75 3.1.2. The Use of KDF_AES_128_CMAC . . . . . . . . . . . . . 8 76 3.1.3. Tips for User Interfaces regarding KDFs . . . . . . . 9 77 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10 78 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11 79 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11 80 4. Change History (RFC Editor: Delete before publishing) . . . . 12 81 5. Needs Work in Next Draft (RFC Editor: Delete Before 82 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 This document is a companion to TCP-AO [TCP-AO] 94 [I-D.ietf-tcpm-tcp-auth-opt]. Like most security protocols, TCP-AO 95 allows users to chose which cryptographic algorithm(s) they want to 96 use to meet their security needs. 98 TCP-AO provides cryptographic authentication and message integrity 99 verification between to end-points. In order to accomplish this 100 function, one employs message authentication codes (MACs). There are 101 various ways to create MACs. The use of hashed-based MACs (HMAC) in 102 Internet protocols is defined in [RFC2104]. The use of cipher-based 103 MACs (CMAC) in Internet protocols is defined in [RFC4493]. 105 This RFC discusses the requirements for implementations to support 106 two MACs used in TCP-AO, both now and in the future, and includes the 107 rationale behind the present and future requirements. The document 108 then specifies the use of those two MACs with TCP-AO. 110 2. Requirements 112 2.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 2.2. Algorithm Requirements 120 In this the first RFC specifying cryptography for TCP-AO, we specify 121 two MAC algorithms. Both MUST be implemented in order for the 122 implementation to be fully compliant with this RFC. 124 This table lists authentication algorithms for the TCP-AO protocol. 126 Requirement Authentication Algorithm 127 ------------ ------------------------ 128 MUST HMAC-SHA-1-96 [RFC2404] 129 MUST AES-128-CMAC-96 [RFC4493] 131 Requirement Key Derivation Function (KDF) 132 ------------- ------------------------ 133 MUST KDF_HMAC_SHA1 134 MUST KDF_AES_128_CMAC 136 NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: 138 The security issues driving the migration from SHA-1 to SHA-256 for 139 digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately 140 render SHA-1 weak for this application of SHA-1 in HMAC mode. The 141 security strength of SHA-1 HMACs should be sufficient for the 142 foreseeable future, especially given that the tags are truncated to 143 96 bits. However, while it's clear that the attacks aren't practical 144 on SHA-1, these types of analysis are mounting and could potentially 145 pose a concern for HMAC forgery if they were significantly improved, 146 over time. In anticipation of SHA-1's growing less dependable over 147 time, but given its wide deployment and current strength, it is a 148 "MUST" for TCP-AO today. AES-128 CMAC is considered to be far 149 stronger algorithm, but may not yet have very wide implementation. 150 It is also a "MUST" to implement, in order to drive vendors toward 151 its use. 153 2.3. Requirements for Future MAC Algorithms 155 Since this document provides cryptographic agility, it is also 156 important to establish requirements for future MAC algorithms. The 157 TCPM WG should restrict any future MAC algorithms for this 158 specification to ones that can protect at least 2**48 messages with a 159 probability that a collision will occur of less than one in a 160 billion. 162 [Reviewers: Are there any other requirements we want/need to place in 163 here? RFC EDITOR: Please delete this text before publishing as RFC] 165 3. Algorithms Specified 167 TCP-AO refers to this document saying that the MAC mechanism employed 168 for a connection is listed in the TAPD entry, and is chosen from a 169 list of MACs both named and described in this document. 171 TCP-AO requires two classes of cryptographic algorithms: 173 (1) Key Derivation Functions (KDFs) which name a pseudorandom 174 function (PRF) and use a Master_Key and some connection- 175 specific Input with that PRF to produce Traffic_Keys, the 176 keys suitable for authenticating and integrity checking 177 individual TCP segments. 179 (2) Message Authentication Code (MAC) algorithms which take a 180 key and a message and produce an authentication tag which 181 can be used to verify the integrity of the messages sent 182 over the wire. 184 In TCP-AO, these algorithms are always used in pairs. Each MAC 185 algorithm MUST specify the KDF to be used with that MAC algorithm. 186 However, a KDF MAY be used with more than one MAC algorithm. 188 3.1. Key Derivation Functions (KDFs) 190 TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP- 191 AO's current manual keying have the following interface: 193 Derived_Key = KDF(Master_Key, Input, Output_Length) 195 where: 197 - KDF: the specific pseudorandom function that is the 198 basic building block used in constructing the given 199 Derived_Key. 201 - Master_Key: The Master_Key as will be stored into the 202 associated TCP-AO TAPD entry. In TPC-AO's manual 203 key mode, this is a shared key that both peers 204 enter via some user interface into their respective 205 configurations. The Master_Key is the seed for the 206 KDF. We assume that, in manual key mode, this is a 207 human readable pre-shared key (PSK), thus we assume 208 that it is of variable length. Users SHOULD chose 209 random strings for the Master_Key. However, we 210 assume that some users may not. 212 - Input: the input data for the KDF, in conformance with 213 [NIST-SP800-108], is a concatonation of: 215 ( i || Label || Context || Output_Length) 217 Where 219 - "||": Represents a concatonation operation, between two 220 values X || Y. 222 - i: A counter, a binary string that is an input to 223 each iteration of a PRF in counter mode and 224 (optionally) in feedback mode. This will depend 225 on the specific size of the Output_Length desired 226 for an given MAC. 228 - Label: A binary string that clearly identifies the 229 purpose of this KDF's derived keying material. 230 For TCP-AO we use the ASCII string "TCP-AO", where 231 the last character is the capital letter "O", not 232 to be confused with a zero. While this may seem 233 like overkill in this specification since TCP-AO 234 only describes one call to the KDF, it is included 235 in order to comply with FIPS 140 certifications. 237 - Context : A binary string containing information related to 238 the specific connection for this derived keying 239 material. In TCP-AO, this is the Data_Block, as 240 defined in [I-D.ietf-tcpm-tcp-auth-opt], Section 241 7.1] 243 - Output_Length: The length in bits of the key that the KDF 244 will produce. This length must be the size 245 required for the MAC algorithm that will use the 246 PRF result as a seed. 248 NOTE: The cited NIST document on KDFs calls for an input: (i || Label 249 || 0x00 || Context || Output_Length). That document states that the 250 "0x00" is an all zero octet and is "an optional data field used to 251 indicate a separation of different variable length data fields". In 252 our case, the "Label" is specified and fixed, thus its data field is 253 fixed, not variable, so there is no need for the 0x00 separator. 254 Thus, we have dropped it. 256 When invoked, a KDF runs a certain PRF, using the Master_Key as the 257 seed, and Input as the message input and produces a result of 258 Output_Length bits. This result may then be used as a cryptographic 259 key for any algorithm which takes an Output_Length length key as its 260 seed. A KDF MAY specify a maximum Output_Length parameter. 262 This document defines two KDFs: 264 * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] 265 * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] 267 Other KDFs may be defined in future revisions of this document, and 268 SHOULD follow this same format as described above. When doing so, 269 note: 271 1. The underlying PRFs specified in this document have fixed sized 272 output lengths, 128 bits in the case of the AES-CMAC, and 160 273 bits in the case of HMAC-SHA1. 274 2. It is possible to generate an arbitrary number of output bits 275 with some given PRF by operating it in a feedback or counter 276 mode. The KDFs described in [NIST-SP800-108] incorporate this 277 feature, hence the counter "i", which creates leading "0". 278 3. Each MAC needs a key of a specific length. 279 4. Not totally uncoincidentally, the KDFs we have chosen to use 280 with each MAC happen to generate the right key size for use with 281 the MAC, thus avoiding the need for the procedure in (2). 282 5. If one wanted to use these KDFs with a MAC requiring a longer 283 key (e.g., HMAC-SHA-256) one would need to use the procedure: 284 KDF_X = PRF_X(Master_Key, Input). 286 3.1.1. The Use of KDF_HMAC_SHA1 288 For: 290 PRF(Master_Key, Input, Output_Length) 292 KDF_HMAC_SHA1 for TCP-AO has the following values: 294 - PRF: HMAC-SHA1 [RFC2404] 295 - Master_Key: As provided in the MKT 296 - Input: 298 - i: "0" 299 - Label: "TCP-AO" 300 - Context: Data_Block 301 - Output_Length 160 302 - Result: Traffic_Key 304 The result is computed by performing HMAC-SHA1(Master_Key, Input) and 305 then taking the first (high order) Output_Length, 160 here, bits. 306 This result is the TCP-AO Traffic_Key. The Traffic_Key is then used 307 as the seed for the MAC function on each segment of the connection. 309 3.1.2. The Use of KDF_AES_128_CMAC 311 For: 313 PRF(Master_Key, Input, Output_Length) 315 KDF_AES_128_CMAC for TCP-AO has the following values: 317 - PRF: AES-CMAC-PRF-128 [RFC4615] 318 - Master_Key: As provided in the MKT 319 - Input: 321 - i: "0" 322 - Label: "TCP-AO" 323 - Context: Data_Block 324 - Output_Length 128 325 - Result: Traffic_Key 327 Whereas the KDF_SHA1 used only one round to produce the Traffic_Key, 328 the KDF_AES will take two steps. The reasoning follows: 330 The Master_Key in TCP-AO's current manual keying mechanism is a 331 shared secret, entered by an administrator. It is passed via an out- 332 of-band mechanism between two devices, and often between two 333 organizations. The shared secret does not have to be 16 octets, and 334 the length may vary. However, AES_128_CMAC requires a key of 16 335 octets (128 bits) in length. We could mandate that implementations 336 force administrators to input Master_Keys of exactly 128 bit length, 337 and with sufficient randomness, but this places undue burdon on the 338 deployers. This specification RECOMMENDS that deployers use a 339 randomly generated 128-bit string as the Master_Key, but acknowledges 340 that deployers may not. 342 To handle variable length Master_Keys we use a similar mechanism to 343 the AES-CMAC-PRF-128 mechanism represented in [RFC4615], Sect 3. We 344 do a two step process. 346 First we use AES_128_CMAC with a fixed key as a "randomness 347 extractor", while using the shared secret Master_Key, MK, as the 348 message input to produce a 128 bit key K. 350 Second, we run AES_128_CMAC again, this time using K as the key and 351 the normal Input I (as described above) as the message input to 352 produce Traffic_Key, TK. 354 Therefore this KDF is always a 2 step function, as follows (borrowing 355 the format from [RFC4615]): 357 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 358 + KDF-AES-128-CMAC + 359 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 360 + + 361 + Input : MK (Master_Key, the variable-length shared secret) + 362 + : I (Input, i.e., the input data of the PRF) + 363 + : MKlen (length of MK in octets) + 364 + : len (length of I in octets) + 365 + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + 366 + + 367 +-------------------------------------------------------------------+ 368 + Variable: K (128-bit key for AES-CMAC) + 369 + + 370 + Step 1. K := AES-CMAC(0^128, MK, MKlen); + 371 + Step 2. TK := AES-CMAC(K, I, len); + 372 + return TK; + 373 + + 374 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 376 Figure 1: The AES-CMAC-PRF-128 Algorithm for TCP-AO 378 o In Step 1, the 128-bit key, K, for AES-CMAC is derived by 379 applying the AES-CMAC algorithm using the 128-bit all-zero string 380 as the key and MK as the input message. 382 o In Step 2, we apply the AES-CMAC algorithm again, this time 383 using the output of Step 1, K, as the key. The input message is 384 now I, just as it is described at the beginning of this section. 385 The output of this algorithm returns TK, the Traffic_Key, which is 386 128 bits suitable for the seed into the AES-CMAC operation over 387 the actual TCP segment. 389 3.1.3. Tips for User Interfaces regarding KDFs 391 This section provides suggested representations for the KDFs in 392 implementation user interfaces. Following these guidelines across 393 common implementations will make interoperability easier and simpler 394 for deployers. 396 UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". 398 UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply 399 "AES128". 401 UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO 402 settings. KDF_HMAC_SHA1 is preferred at this time solely because it 403 has wide support, being present in most implementations in the 404 marketplace. When such a time arrives as KDF_AES_128_CMAC becomes 405 widely deployed, this document should be updated so that it becomes 406 the default KDF on implementations. 408 3.2. MAC Algorithms 410 MACs for TCP-AO have the following interface: 412 MAC (Traffic_Key(KDF), Message, Truncation) 414 where: 416 - MAC-algo: MAC Algorithm used 417 - Traffic_Key: Variable; Result of KDF. 419 - KDF: Name of the TCP-AO KDF used 421 - Key_Length: Length in bits required for the Traffic_Key used in 422 this MAC 423 - Truncation: Length in bits to which the final MAC result is 424 truncated before being placed into TCP-AO header 426 This document specifies two MAC algorithm options for generating the 427 MAC for TCP-AO's option header: 429 * HMAC-SHA-1-96 based on [RFC2404] 431 * AES-128-CMAC-96 based on [RFC4493] 433 Both provide a high level of security and efficiency. The AES-128- 434 CMAC-96 is potentially more efficient, particularly in hardware, but 435 HMAC-SHA-1-96 is more widely used in Internet protocols and in most 436 cases could be supported with little or no additional code in today's 437 deployed software and devices. 439 An important aspect to note about these algorithms' definitions for 440 use in TCP-AO is the fact that the MAC outputs are truncated to 96 441 bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 442 produces a 160 bit result. The MAC output are then truncated to 96 443 bits to provide a reasonable tradeoff between security and message 444 size, for fitting into the TCP-AO header. 446 3.2.1. The Use of HMAC-SHA-1-96 448 By definition, HMAC [RFC2104] requires a cryptographic hash function. 449 SHA1 will be that has function used for authenticating and providing 450 integrity validation on TCP segments with HMAC. 452 For: 454 MAC (Traffic_Key(KDF), Message, Truncation) 456 HMAC-SHA-1-96 for TCP-AO has the following values: 458 - MAC-algo: MAC Algorithm used 459 - Traffic_Key: Variable; Result of KDF. 461 - KDF: KDF_HMAC_SHA1 463 - Key_Length: 160 bits 464 - Truncation: 96 bits 466 3.2.2. The Use of AES-128-CMAC-96 468 In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually 469 define a usage of AES-128 as a cipher-based MAC according to 470 [NIST-SP800-38B]. 472 For: 474 MAC (Traffic_Key(KDF), Message, Truncation) 476 AES-128-CMAC-96 for TCP-AO has the following values: 478 - MAC-algo: AES-128-CMAC-96 [RFC4493] 479 - Traffic_Key: Variable; Result of KDF. 481 - KDF: KDF_AES_128_CMAC 483 - Key_Length: 128 bits 484 - Truncation: 96 bits 486 According to [RFC4493], by default, "the length of the output of AES- 487 128-CMAC is 128 bits. It is possible to truncate the MAC. The 488 result of the truncation is then taken in most significant bits first 489 order. The MAC length must be specified before the communication 490 starts, and it must not be changed during the lifetime of the key." 491 Therefore, we explicitly specify the employed MAC length for TCP-AO 492 to be 96 bits. 494 4. Change History (RFC Editor: Delete before publishing) 496 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 497 Please remove before publishing as RFC.] 499 draft-ietf...-00 - 4th submission 501 Submitting draft-lebovitz...-02 as a WG document. Added EKR as co- 502 author, and gave him credit for rewrite of sect 3.1.x . 504 lebovitz...-02 - 3rd submission 506 o cleaned up explanation in 3.1.2 507 o in 3.1.2, changed the key extractor mechanism back, from using an 508 alphanumeric string for the fixed key C to use 0^128 as the key 509 (as it was in -00) (Polk & Ekr) 510 o deleted cut-and-paste error text from sect 3.1 between "label" and 511 "context" 512 o changed "conn_key" to "traffic_key" throughout, to follow auth- 513 opt-05 514 o changed "tsad" to "mkt" throughout, to follow auth-opt-05 515 o changed "conn_block" to "data_block" throughout, to follow auth- 516 opt-05 518 lebovitz...-01- 2nd submission 520 o removed the whole section on labels (previously section 4), per WG 521 consensus at IETF74. Added 3.1.3 to specify that implementations 522 SHOULD make HMAC-SHA1 the default choice for the time being, and 523 to suggest common names for the KDF's universally in UI's. 524 o changed KDF = PRF... to Derived_Key = KDF... (EKR) 525 o added the text on how to deal with future KDF to end of s3.1 (EKR) 526 o removed references to TCP-AO "manual key mode". Changed to TCP- 527 AO's "current mode of manual keying". (Touch) 528 o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, 529 per wg consensus at ietf74. 531 o in 3.1.2, changed the mechanism to force the K to be 128bits from 532 using 0^128, to using a fixed 128-bit string of random characters 533 (Dave McGrew) 534 o sect 3.1, in Input description, dropped "0x00". Added "NOTE" 535 explaining why right after the output_length description. 536 o cleaned up all references 537 o copy editing 539 lebovitz...-00 - original submission 541 5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 543 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 544 Please remove before publishing as RFC.] 546 List of stuff that still needs work 547 o fix the iana registry section. Need registry entries for the KDFs 548 and all the other values? 549 o this was supposed to be named 550 draft-ietf-tcpm-tcp-ao-crypto-00.txt, but I forgot that since we 551 were moving from a personal submission to a wg sub, it had to go 552 back to a -00, thus needed to be done a week earlier. Oops. Will 553 fix as soon as the window opens for submitting -00's again. 555 6. Security Considerations 557 This document inherits all of the security considerations of the 558 TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. 560 The security of cryptographic-based systems depends on both the 561 strength of the cryptographic algorithms chosen and the strength of 562 the keys used with those algorithms. The security also depends on 563 the engineering of the protocol used by the system to ensure that 564 there are no non-cryptographic ways to bypass the security of the 565 overall system. 567 Care should also be taken to ensure that the selected key is 568 unpredictable, avoiding any keys known to be weak for the algorithm 569 in use. ][RFC4086] contains helpful information on both key 570 generation techniques and cryptographic randomness. 572 Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 573 bit / 16 byte key as the seed. However, for convenience to the 574 administrators/deployers, we did not want to force them to enter a 16 575 byte Master_Key. So we specified the sub-key routine that could 576 handle a variable length Master_Key, one that might be less than 16 577 bytes. This does NOT mean that administrators are safe to use weak 578 keys. Administrators are encouraged to follow [RFC4086] as listed 579 above. We simply attempted to "put a fence around stupidity", in as 580 much as possible. 582 This document concerns itself with the selection of cryptographic 583 algorithms for the use of TCP-AO. The algorithms identified in this 584 document as "MUST implement" or "SHOULD implement" are not known to 585 be broken at the current time, and cryptographic research so far 586 leads us to believe that they will likely remain secure into the 587 foreseeable future. Some of the algorithms may be found in the 588 future to have properties significantly weaker than those that were 589 believed at the time this document was produced. Expect that new 590 revisions of this document will be issued from time to time. Be sure 591 to search for more recent versions of this document before 592 implementing. 594 7. IANA Considerations 596 IANA has created and will maintain a registry called, "Cryptographic 597 Algorithms for TCP-AO". The registry consists of a text string and 598 an RFC number that lists the associated transform(s). New entries 599 can be added to the registry only after RFC publication and approval 600 by an expert designated by the IESG. 602 [need to finish this section] 604 8. Acknowledgements 606 Eric "EKR" Rescorla, who provided a ton of input and feedback, 607 including a somewhat heavy re-write of section 3.1.x, earning him and 608 author slot on the document. 610 Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly 611 create a first draft here. 613 Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two 614 hash algorithms for TCP-AO is largely cut and pasted into various 615 sections of this document. 617 Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] & 618 [RFC4305] text was consulted and sometimes used in the Requirements 619 Section 2 section of this document. 621 (In other words, I was truly only an editor of others' text in 622 creating this document.) 623 Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues 624 with the inputs to PRFs for the KDFs. EKR was also of great 625 assistance in how to structure the text, as well as helping to guide 626 good cryptographic decisions. 628 The TCPM working group, who put up with all us crypto and routing 629 folks DoS'ing their WG for 2 years, and who provided reviews of this 630 document. 632 9. References 634 9.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 9.2. Informative References 641 [HMAC-ATTACK] 642 "On the Security of HMAC and NMAC Based on HAVAL, MD4, 643 MD5, SHA-0 and SHA-1"", 2006, 644 . 647 [I-D.ietf-tcpm-tcp-auth-opt] 648 Touch, J., Mankin, A., and R. Bonica, "The TCP 649 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05 650 (work in progress), July 2009. 652 [I-D.narten-iana-considerations-rfc2434bis] 653 Narten, T. and H. Alvestrand, "Guidelines for Writing an 654 IANA Considerations Section in RFCs", 655 draft-narten-iana-considerations-rfc2434bis-09 (work in 656 progress), March 2008. 658 [NIST-SP800-108] 659 National Institute of Standards and Technology, 660 "Recommendation for Key Derivation Using Pseudorandom 661 Functions", SP 800-108, April 2008. 663 [NIST-SP800-38B] 664 National Institute of Standards and Technology, 665 "Recommendation for Block Cipher Modes of Operation: The 666 CMAC Mode for Authentication", SP 800-38B, May 2005. 668 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 669 Hashing for Message Authentication", RFC 2104, 670 February 1997. 672 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 673 Internet Protocol", RFC 2401, November 1998. 675 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 676 ESP and AH", RFC 2404, November 1998. 678 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 679 Payload (ESP)", RFC 2406, November 1998. 681 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 682 Requirements for Security", BCP 106, RFC 4086, June 2005. 684 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 685 Requirements for Encapsulating Security Payload (ESP) and 686 Authentication Header (AH)", RFC 4305, December 2005. 688 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 689 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 690 December 2005. 692 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 693 December 2005. 695 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 696 AES-CMAC Algorithm", RFC 4493, June 2006. 698 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 699 Advanced Encryption Standard-Cipher-based Message 700 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 701 PRF-128) Algorithm for the Internet Key Exchange Protocol 702 (IKE)", RFC 4615, August 2006. 704 Authors' Addresses 706 Gregory Lebovitz 707 Juniper Networks, Inc. 708 1194 North Mathilda Ave. 709 Sunnyvale, CA 94089-1206 710 US 712 Phone: 713 Email: gregory.ietf@gmail.com 714 Eric Rescorla 715 RTFM, Inc. 716 2064 Edgewood Drive 717 Palo Alto, CA 94303 718 US 720 Phone: 650-678-2350 721 Email: ekr@rtfm.com