idnits 2.17.1 draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01.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.ii 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 (July 11, 2009) is 5393 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 92, but not defined == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 655, 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 July 11, 2009 5 Expires: January 12, 2010 7 Cryptographic Algorithms, Use, & Implementation Requirments for TCP 8 Authentication Option 9 draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 12, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The TCP Authentication Option, TCP-AO, relies on security algorithms 58 to provide authentication between two end-points. There are many 59 such algorithms available, and two TCP-AO systems cannot interoperate 60 unless they are using the same algorithm(s). This document specifies 61 the algorithms and attributes that can be used in TCP-AO's current 62 manual keying mechanism. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2.2. Algorithm Requirements . . . . . . . . . . . . . . . . . . 3 70 2.3. Requirements for Future MAC Algorithms . . . . . . . . . . 4 71 3. Algorithms Specified . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 5 73 3.1.1. The Use of KDF_HMAC_SHA1 . . . . . . . . . . . . . . . 7 74 3.1.2. The Use of KDF_AES_128_CMAC . . . . . . . . . . . . . 8 75 3.1.3. Tips for User Interfaces regarding KDFs . . . . . . . 9 76 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10 77 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11 78 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11 79 4. Change History (RFC Editor: Delete before publishing) . . . . 12 80 5. Needs Work in Next Draft (RFC Editor: Delete Before 81 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 This document is a companion to TCP-AO [TCP-AO] 93 [I-D.ietf-tcpm-tcp-auth-opt]. Like most security protocols, TCP-AO 94 allows users to chose which cryptographic algorithm(s) they want to 95 use to meet their security needs. 97 TCP-AO provides cryptographic authentication and message integrity 98 verification between to end-points. In order to accomplish this 99 function, one employs message authentication codes (MACs). There are 100 various ways to create MACs. The use of hashed-based MACs (HMAC) in 101 Internet protocols is defined in [RFC2104]. The use of cipher-based 102 MACs (CMAC) in Internet protocols is defined in [RFC4493]. 104 This RFC discusses the requirements for implementations to support 105 two MACs used in TCP-AO, both now and in the future, and includes the 106 rationale behind the present and future requirements. The document 107 then specifies the use of those two MACs with TCP-AO. 109 2. Requirements 111 2.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2.2. Algorithm Requirements 119 In this the first RFC specifying cryptography for TCP-AO, we specify 120 two MAC algorithms. Both MUST be implemented in order for the 121 implementation to be fully compliant with this RFC. 123 This table lists authentication algorithms for the TCP-AO protocol. 125 Requirement Authentication Algorithm 126 ------------ ------------------------ 127 MUST HMAC-SHA-1-96 [RFC2404] 128 MUST AES-128-CMAC-96 [RFC4493] 130 Requirement Key Derivation Function (KDF) 131 ------------- ------------------------ 132 MUST KDF_HMAC_SHA1 133 MUST KDF_AES_128_CMAC 135 NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: 137 The security issues driving the migration from SHA-1 to SHA-256 for 138 digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately 139 render SHA-1 weak for this application of SHA-1 in HMAC mode. The 140 security strength of SHA-1 HMACs should be sufficient for the 141 foreseeable future, especially given that the tags are truncated to 142 96 bits. However, while it's clear that the attacks aren't practical 143 on SHA-1, these types of analysis are mounting and could potentially 144 pose a concern for HMAC forgery if they were significantly improved, 145 over time. In anticipation of SHA-1's growing less dependable over 146 time, but given its wide deployment and current strength, it is a 147 "MUST" for TCP-AO today. AES-128 CMAC is considered to be far 148 stronger algorithm, but may not yet have very wide implementation. 149 It is also a "MUST" to implement, in order to drive vendors toward 150 its use. 152 2.3. Requirements for Future MAC Algorithms 154 Since this document provides cryptographic agility, it is also 155 important to establish requirements for future MAC algorithms. The 156 TCPM WG should restrict any future MAC algorithms for this 157 specification to ones that can protect at least 2**48 messages with a 158 probability that a collision will occur of less than one in a 159 billion. 161 [Reviewers: Are there any other requirements we want/need to place in 162 here? RFC EDITOR: Please delete this text before publishing as RFC] 164 3. Algorithms Specified 166 TCP-AO refers to this document saying that the MAC mechanism employed 167 for a connection is listed in the TAPD entry, and is chosen from a 168 list of MACs both named and described in this document. 170 TCP-AO requires two classes of cryptographic algorithms: 172 (1) Key Derivation Functions (KDFs) which name a pseudorandom 173 function (PRF) and use a Master_Key and some connection- 174 specific Input with that PRF to produce Conn_Keys, the keys 175 suitable for authenticating and integrity checking 176 individual TCP segments. 178 (2) Message Authentication Code (MAC) algorithms which take a 179 key and a message and produce an authentication tag which 180 can be used to verify the integrity of the messages sent 181 over the wire. 183 In TCP-AO, these algorithms are always used in pairs. Each MAC 184 algorithm MUST specify the KDF to be used with that MAC algorithm. 185 However, a KDF MAY be used with more than one MAC algorithm. 187 3.1. Key Derivation Functions (KDFs) 189 TCP-AO's Conn_Keys are derived using KDFs. The KDFs used in TCP-AO's 190 current manual keying have the following interface: 192 Derived_Key = KDF(Master_Key, Input, Output_Length) 194 where: 196 - KDF: the specific pseudorandom function that is the 197 basic building block used in constructing the given 198 Derived_Key. 200 - Master_Key: The Master_Key as will be stored into the 201 associated TCP-AO TAPD entry. In TPC-AO's manual 202 key mode, this is a shared key that both peers 203 enter via some user interface into their respective 204 configurations. The Master_Key is the seed for the 205 KDF. We assume that, in manual key mode, this is a 206 human readable pre-shared key (PSK), thus we assume 207 that it is of variable length. Users SHOULD chose 208 random strings for the Master_Key. However, we 209 assume that some users may not. 211 - Input: the input data for the KDF, in conformance with 212 [NIST-SP800-108], is a concatonation of: 214 ( i || Label || Context || Output_Length) 216 Where 218 - "||": Represents a concatonation operation, between two 219 values X || Y. 221 - i: A counter, a binary string that is an input to 222 each iteration of a PRF in counter mode and 223 (optionally) in feedback mode. This will depend 224 on the specific size of the Output_Length desired 225 for an given MAC. 227 - Label: A binary string that clearly identifies the 228 purpose of this KDF's derived keying material. 229 For TCP-AO we use the ASCII string "TCP-AO", where 230 the last character is the capital letter "O", not 231 to be confused with a zero. While this may seem 232 like overkill in this specification since TCP-AO 233 only describes one call to the KDF, it is included 234 in order to comply with FIPS 140 certifications. 236 An octet of all zeros. An optional data field 237 used to indicate a separation of different 238 variable length data fields. 240 - Context : A binary string containing information related to 241 the specific connection for this derived keying 242 material. In TCP-AO, this is the Conn_Block, as 243 defined in [I-D.ietf-tcpm-tcp-auth-opt], Section 244 X] 246 - Output_Length: The length in bits of the key that the KDF 247 will produce. This length must be the size 248 required for the MAC algorithm that will use the 249 PRF result as a seed. 251 NOTE: The cited NIST document on KDFs calls for an input: (i || Label 252 || 0x00 || Context || Output_Length). That document states that the 253 "0x00" is an all zero octet and is "an optional data field used to 254 indicate a separation of different variable length data fields". In 255 our case, the "Label" is specified and fixed, thus its data field is 256 fixed, not variable, so there is no need for the 0x00 separator. 257 Thus, we have dropped it. 259 When invoked, a KDF runs a certain PRF, using the Master_Key as the 260 seed, and Input as the message input and produces a result of 261 Output_Length bits. This result may then be used as a cryptographic 262 key for any algorithm which takes an Output_Length length key as its 263 seed. A KDF MAY specify a maximum Output_Length parameter. 265 This document defines two KDFs: 267 * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] 268 * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] 270 Other KDFs may be defined in future revisions of this document, and 271 SHOULD follow this same format as described above. When doing so, 272 note: 274 1. The underlying PRFs specified in this document have fixed sized 275 output lengths, 128 bits in the case of the AES-CMAC, and 160 276 bits in the case of HMAC-SHA1. 277 2. It is possible to generate an arbitrary number of output bits 278 with some given PRF by operating it in a feedback or counter 279 mode. The KDFs described in [NIST-SP800-108] incorporate this 280 feature, hence the counter "i", which creates leading "0". 281 3. Each MAC needs a key of a specific length. 282 4. Not totally uncoincidentally, the KDFs we have chosen to use 283 with each MAC happen to generate the right key size for use with 284 the MAC, thus avoiding the need for the procedure in (2). 285 5. If one wanted to use these KDFs with a MAC requiring a longer 286 key (e.g., HMAC-SHA-256) one would need to use the procedure: 287 KDF_X = PRF_X(Master_Key, Input). 289 3.1.1. The Use of KDF_HMAC_SHA1 291 For: 293 PRF(Master_Key, Input, Output_Length) 295 KDF_HMAC_SHA1 for TCP-AO has the following values: 297 - PRF: HMAC-SHA1 [RFC2404] 298 - Master_Key: As provided in the TSAD 299 - Input: 301 - i: "0" 302 - Label: "TCP-AO" 303 - Context: Conn_Block 304 - Output_Length 160 305 - Result: Conn_Key 306 The result is computed by performing HMAC-SHA1(Master_Key, Input) and 307 then taking the first (high order) Output_Length, 160 here, bits. 308 This result is the TCP-AO Conn_Key. The Conn_Key is then used as the 309 seed for the MAC function on each segment of the connection. 311 3.1.2. The Use of KDF_AES_128_CMAC 313 For: 315 PRF(Master_Key, Input, Output_Length) 317 KDF_AES_128_CMAC for TCP-AO has the following values: 319 - PRF: AES-CMAC-PRF-128 [RFC4615] 320 - Master_Key: As provided in the TSAD 321 - Input: 323 - i: "0" 324 - Label: "TCP-AO" 325 - Context: Conn_Block 326 - Output_Length 128 327 - Result: Conn_Key 328 The result is computed by performing AES-CMAC-PRF-128(Master_Key, 329 Input) and then taking the first (high order) Output_Length, 128, 330 bits. This result is the TCP-AO Conn_Key. The Conn_Key is then used 331 as the seed for the MAC function on each segment of the connection. 333 Since the Master_Key in TCP-AO's current manual keying mechanism is a 334 pre-shared key (PSK) passed in an out of band mechanism between two 335 devices, and often between two organizations, it is assumed to be of 336 variable length. Therefore it may not have 16 octets / 128 bits, as 337 is required as an input length to AES-128. We could mandate that 338 implementations force administrators to input only keys of such 339 length, and with sufficient randomness, but this places undue burdon 340 on the deployers. The specification does RECOMMEND that deployers 341 use a randomly generated 128-bit string as the Master_Key, but 342 acknowledges that deployers may not. Therefore we use a similar 343 mechanism to the AES-CMAC-PRF-128 mechanism represented in [RFC4615], 344 Sect 3, with two changes: (1) we never use the raw Master_Key (MK) 345 alone if K := MK. Instead, we always assume MK is variable length, 346 and we always use both the the FR, the MK, and the MKlen arguments, 347 even when K := MK; and (2) we don't use 0^128 for FR, we use an 348 alpha-numeric string. Therefore this KDF is always a 2 step 349 function, as follows (borrowing the format from [RFC4615]): 351 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 352 + KDF-AES-128-CMAC + 353 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 354 + + 355 + Input : FR (Fixed 128-bits of randomness) + 356 + : MK (Variable-length Master_Key) + 357 + : I (Input, i.e., the input data of the PRF) + 358 + : MKlen (length of MK in octets) + 359 + : len (length of I in octets) + 360 + Output : PRV (128-bit Pseudo-Random Variable) + 361 + + 362 +-------------------------------------------------------------------+ 363 + Variable: K (128-bit key for AES-CMAC) + 364 + + 365 + Step 1. K := AES-CMAC(FR, MK, MKlen); + 366 + Step 2. PRV := AES-CMAC(K, I, len); + 367 + return PRV; + 368 + + 369 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 371 where FR is always equal to: 372 CkhKR2iJzHtlQXAA 374 Figure 1: The AES-CMAC-PRF-128 Algorithm for TCP-AO 376 o In Step 1, the 128-bit key, K, for AES-CMAC is derived by 377 applying the AES-CMAC algorithm using the FR 128-bit binary 378 representation of the ASCII string "CkhKR2iJzHtlQXAA" as the key 379 and MK as the input message. 381 o In Step 2, we apply the AES-CMAC algorithm again, this time 382 using K as the key and I as the input message. The output of this 383 algorithm returns PRV, 128 bits suitable for the seed, the 384 Conn_Key, in the AES-CMAC operation over the segment. 386 3.1.3. Tips for User Interfaces regarding KDFs 388 This section provides suggested representations for the KDFs in 389 implementation user interfaces. Following these guidelines across 390 common implementations will make interoperability easier and simpler 391 for deployers. 393 UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". 395 UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply 396 "AES128". 398 UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO 399 settings. KDF_HMAC_SHA1 is preferred at this time solely because it 400 has wide support, being present in most implementations in the 401 marketplace. When such a time arrives as KDF_AES_128_CMAC becomes 402 widely deployed, this document should be updated so that it becomes 403 the default KDF on implementations. 405 3.2. MAC Algorithms 407 MACs for TCP-AO have the following interface: 409 MAC (Conn_Key(KDF), Message, Truncation) 411 where: 413 - MAC-algo: MAC Algorithm used 414 - Conn_Key: Variable; Result of KDF. 416 - KDF: Name of the TCP-AO KDF used 418 - Key_Length: Length in bits required for the Conn_Key used in 419 this MAC 420 - Truncation: Length in bits to which the final MAC result is 421 truncated before being placed into TCP-AO header 423 This document specifies two MAC algorithm options for generating the 424 MAC for TCP-AO's option header: 426 * HMAC-SHA-1-961 based on [RFC2404] 428 * AES-128-CMAC-96 based on [RFC4493] 430 Both provide a high level of security and efficiency. The AES-128- 431 CMAC-96 is potentially more efficient, particularly in hardware, but 432 HMAC-SHA-1-96 is more widely used in Internet protocols and in most 433 cases could be supported with little or no additional code in today's 434 deployed software and devices. 436 An important aspect to note about these algorithms' definitions for 437 use in TCP-AO is the fact that the MAC outputs are truncated to 96 438 bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 439 produces a 160 bit result. The MAC output are then truncated to 96 440 bits to provide a reasonable tradeoff between security and message 441 size, for fitting into the TCP-AO header. 443 3.2.1. The Use of HMAC-SHA-1-96 445 By definition, HMAC [RFC2104] requires a cryptographic hash function. 446 SHA1 will be that has function used for authenticating and providing 447 integrity validation on TCP segments with HMAC. 449 For: 451 MAC (Conn_Key(KDF), Message, Truncation) 453 HMAC-SHA-1-96 for TCP-AO has the following values: 455 - MAC-algo: MAC Algorithm used 456 - Conn_Key: Variable; Result of KDF. 458 - KDF: KDF_HMAC_SHA1 460 - Key_Length: 160 bits 461 - Truncation: 96 bits 463 3.2.2. The Use of AES-128-CMAC-96 465 In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually 466 define a usage of AES-128 as a cipher-based MAC according to 467 [NIST-SP800-38B]. 469 For: 471 MAC (Conn_Key(KDF), Message, Truncation) 473 AES-128-CMAC-96 for TCP-AO has the following values: 475 - MAC-algo: AES-128-CMAC-96 [RFC4493] 476 - Conn_Key: Variable; Result of KDF. 478 - KDF: KDF_AES_128_CMAC 480 - Key_Length: 128 bits 481 - Truncation: 96 bits 482 According to [RFC4493], by default, "the length of the output of AES- 483 128-CMAC is 128 bits. It is possible to truncate the MAC. The 484 result of the truncation is then taken in most significant bits first 485 order. The MAC length must be specified before the communication 486 starts, and it must not be changed during the lifetime of the key." 487 Therefore, we explicitly specify the employed MAC length for TCP-AO 488 to be 96 bits. 490 4. Change History (RFC Editor: Delete before publishing) 492 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 493 Please remove before publishing as RFC.] 495 lebovitz...-00 - original submission 497 lebovitz...-01- 2nd submission 499 o removed the whole section on labels (previously section 4), per WG 500 consensus at IETF74. Added 3.1.3 to specify that implementations 501 SHOULD make HMAC-SHA1 the default choice for the time being, and 502 to suggest common names for the KDF's universally in UI's. 503 o changed KDF = PRF... to Derived_Key = KDF... (EKR) 504 o added the text on how to deal with future KDF to end of s3.1 (EKR) 505 o removed references to TCP-AO "manual key mode". Changed to TCP- 506 AO's "current mode of manual keying". (Touch) 507 o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, 508 per wg consensus at ietf74. 509 o in 3.1.2, changed the mechanism to force the K to be 128bits from 510 using 0^128, to using a fixed 128-bit string of random characters 511 (Dave McGrew) 512 o sect 3.1, in Input description, dropped "0x00". Added "NOTE" 513 explaining why right after the output_length description. 514 o cleaned up all references 515 o copy editing 517 5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 519 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 520 Please remove before publishing as RFC.] 522 List of stuff that still needs work 523 o fix the iana registry section. Need registry entries for the KDFs 524 and all the other values? 526 o this was supposed to be named 527 draft-ietf-tcpm-tcp-ao-crypto-00.txt, but I forgot that since we 528 were moving from a personal submission to a wg sub, it had to go 529 back to a -00, thus needed to be done a week earlier. Oops. Will 530 fix as soon as the window opens for submitting again. 532 6. Security Considerations 534 This document inherits all of the security considerations of the 535 TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. 537 The security of cryptographic-based systems depends on both the 538 strength of the cryptographic algorithms chosen and the strength of 539 the keys used with those algorithms. The security also depends on 540 the engineering of the protocol used by the system to ensure that 541 there are no non-cryptographic ways to bypass the security of the 542 overall system. 544 Care should also be taken to ensure that the selected key is 545 unpredictable, avoiding any keys known to be weak for the algorithm 546 in use. ][RFC4086] contains helpful information on both key 547 generation techniques and cryptographic randomness. 549 Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 550 bit / 16 byte key as the seed. However, for convenience to the 551 administrators/deployers, we did not want to force them to enter a 16 552 byte Master_Key. So we specified the sub-key routine that could 553 handle a variable length Master_Key, one that might be less than 16 554 bytes. This does NOT mean that administrators are safe to use weak 555 keys. Administrators are encouraged to follow [RFC4086] as listed 556 above. We simply attempted to "put a fence around stupidity", in as 557 much as possible. 559 This document concerns itself with the selection of cryptographic 560 algorithms for the use of TCP-AO. The algorithms identified in this 561 document as "MUST implement" or "SHOULD implement" are not known to 562 be broken at the current time, and cryptographic research so far 563 leads us to believe that they will likely remain secure into the 564 foreseeable future. Some of the algorithms may be found in the 565 future to have properties significantly weaker than those that were 566 believed at the time this document was produced. Expect that new 567 revisions of this document will be issued from time to time. Be sure 568 to search for more recent versions of this document before 569 implementing. 571 7. IANA Considerations 573 IANA has created and will maintain a registry called, "Cryptographic 574 Algorithms for TCP-AO". The registry consists of a text string and 575 an RFC number that lists the associated transform(s). New entries 576 can be added to the registry only after RFC publication and approval 577 by an expert designated by the IESG. 579 [need to finish this section] 581 8. Acknowledgements 583 Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly 584 create a first draft here. 586 Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two 587 hash algorithms for TCP-AO is largely cut and pasted into various 588 sections of this document. 590 Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] & 591 [RFC4305] text was consulted and sometimes used in the Requirements 592 Section 2 section of this document. 594 (In other words, I was truly only an editor of others' text in 595 creating this document.) 597 Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues 598 with the inputs to PRFs for the KDFs, and was of great assistance in 599 how to structure the text, as well as the correct cryptographic 600 decisions. 602 David McGrew who caught an issue with the cryptography of section 603 3.1.2. Now we need to also go and fix [RFC4615]. 605 The TCPM working group, who put up with all us crypto and routing 606 folks DoS'ing their WG for 2 years, and who provided reviews of this 607 document. 609 9. References 611 9.1. Normative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 9.2. Informative References 618 [HMAC-ATTACK] 619 "On the Security of HMAC and NMAC Based on HAVAL, MD4, 620 MD5, SHA-0 and SHA-1"", 2006, 621 . 624 [I-D.ietf-tcpm-tcp-auth-opt] 625 Touch, J., Mankin, A., and R. Bonica, "The TCP 626 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05 627 (work in progress), July 2009. 629 [I-D.narten-iana-considerations-rfc2434bis] 630 Narten, T. and H. Alvestrand, "Guidelines for Writing an 631 IANA Considerations Section in RFCs", 632 draft-narten-iana-considerations-rfc2434bis-09 (work in 633 progress), March 2008. 635 [NIST-SP800-108] 636 National Institute of Standards and Technology, 637 "Recommendation for Key Derivation Using Pseudorandom 638 Functions", SP 800-108, April 2008. 640 [NIST-SP800-38B] 641 National Institute of Standards and Technology, 642 "Recommendation for Block Cipher Modes of Operation: The 643 CMAC Mode for Authentication", SP 800-38B, May 2005. 645 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 646 Hashing for Message Authentication", RFC 2104, 647 February 1997. 649 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 650 Internet Protocol", RFC 2401, November 1998. 652 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 653 ESP and AH", RFC 2404, November 1998. 655 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 656 Payload (ESP)", RFC 2406, November 1998. 658 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 659 Requirements for Security", BCP 106, RFC 4086, June 2005. 661 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 662 Requirements for Encapsulating Security Payload (ESP) and 663 Authentication Header (AH)", RFC 4305, December 2005. 665 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 666 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 667 December 2005. 669 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 670 December 2005. 672 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 673 AES-CMAC Algorithm", RFC 4493, June 2006. 675 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 676 Advanced Encryption Standard-Cipher-based Message 677 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 678 PRF-128) Algorithm for the Internet Key Exchange Protocol 679 (IKE)", RFC 4615, August 2006. 681 Author's Address 683 Gregory Lebovitz 684 Juniper Networks, Inc. 685 1194 North Mathilda Ave. 686 Sunnyvale, CA 94089-1206 687 US 689 Phone: 690 Email: gregory.ietf@gmail.com