idnits 2.17.1 draft-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.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2009) is 5293 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 90, but not defined == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 729, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-07 -- 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: 2 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM G. Lebovitz 3 Internet-Draft Juniper 4 Intended status: Standards Track E. Rescorla 5 Expires: May 1, 2010 RTFM 6 October 28, 2009 8 Cryptographic Algorithms for TCP's Authentication Option, TCP-AO 9 draft-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 May 1, 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. Concrete KDFs . . . . . . . . . . . . . . . . . . . . 6 74 3.2. MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2.1. The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11 76 3.2.2. The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11 77 4. Change History (RFC Editor: Delete before publishing) . . . . 12 78 5. Needs Work in Next Draft (RFC Editor: Delete Before 79 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 This document is a companion to TCP-AO [TCP-AO] 91 [I-D.ietf-tcpm-tcp-auth-opt]. Like most modern security protocols, 92 TCP-AO allows users to chose which cryptographic algorithm(s) they 93 want to use to meet their security needs. 95 TCP-AO provides cryptographic authentication and message integrity 96 verification between to end-points. In order to accomplish this 97 function, message authentication codes (MACs) are used, which then 98 rely on shared keys. There are various ways to create MACs. The use 99 of hashed-based MACs (HMAC) in Internet protocols is defined in 100 [RFC2104]. The use of cipher-based MACs (CMAC) in Internet protocols 101 is defined in [RFC4493]. 103 This RFC defines the general requirements for MACs used in TCP-AO, 104 both for currently specified MACs and for any future specified MACs. 105 It then specifies two MAC algorithms required in all TCP-AO 106 implementations. It also specifies two key derivations functions 107 (KDFs) used to create the traffic keys used by the MACs. These KDFs 108 are also required by all TCP-AO implementations. 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 When used in lower case, these words convey their typical use in 119 common language, and are not to be interpreted as described in 120 [RFC2119]. 122 2.2. Algorithm Requirements 124 This is the initial specification of required cryptography for 125 TCP-AO, and indicates two MAC algorithms and two KDFs. All four 126 components MUST be implemented in order for the implementation to be 127 fully compliant with this RFC. 129 The following table indicates the required MAC algorithms and KDFs 130 for TCP-AO: 132 Requirement Authentication Algorithm 133 ------------ ------------------------ 134 MUST HMAC-SHA-1-96 [RFC2404] 135 MUST AES-128-CMAC-96 [RFC4493] 137 Requirement Key Derivation Function (KDF) 138 ------------- ------------------------ 139 MUST KDF_HMAC_SHA1 140 MUST KDF_AES_128_CMAC 142 NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED: 144 Two MAC algorithms and two corresponding KDFs are mandated as a 145 result of discussion in the TCPM WG, and in consultation with the 146 Security Area Directors. SHA-1 was selected because it is widely 147 deployed and currently has sufficient strength and reasonable 148 computational cost, so it is a "MUST" for TCP-AO today. The security 149 strength of SHA-1 HMACs should be sufficient for the foreseeable 150 future, especially given that the tags are truncated to 96 bits. 152 Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC 153 MD5) aren't practical on SHA-1, but these types of analyses are 154 mounting and could potentially pose a concern for HMAC forgery if 155 they were significantly improved, over time. The security issues 156 driving the migration from SHA-1 to SHA-256 for digital signatures 157 [HMAC-ATTACK] do not immediately render SHA-1 weak for this 158 application of SHA-1 in HMAC mode. 160 AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but 161 may not yet have very wide implementation. AES-128 CMAC is also a 162 "MUST" to implement, in order to drive vendors toward its use, and to 163 allow for another MAC option, if SHA-1 were to be compromised. 165 2.3. Requirements for Future MAC Algorithms 167 TCP-AO is intended to support cryptographic agility. As a result, 168 this document includes recommendations in various places for future 169 MAC and KDF algorithms when used for TCP-AO. For future MAC 170 algorithms specifically, they SHOULD protect at least 2**48 messages 171 with a collision probability of less than one in 10**9. 173 [Reviewers: Are there any other requirements we want/need to place in 174 here? RFC EDITOR: Please delete this note before publishing as RFC] 176 3. Algorithms Specified 178 TCP-AO requires two classes of cryptographic algorithms used on a 179 particular connection, and refers to this document to define them 180 both: 182 (1) Key Derivation Functions (KDFs) which name a pseudorandom 183 function (PRF) and use a Master_Key and some connection- 184 specific input with that PRF to produce Traffic_Keys, the 185 keys suitable for authenticating and integrity checking 186 individual TCP segments, as described in TCP-AO. 187 (2) Message Authentication Code (MAC) algorithms which take a 188 key and a message and produce an authentication tag which 189 can be used to verify the integrity and authenticity of 190 those messages. 192 In TCP-AO, these algorithms are always used in pairs. Each MAC 193 algorithm MUST specify the KDF to be used with that MAC algorithm. 194 However, a KDF MAY be used with more than one MAC algorithm. 196 3.1. Key Derivation Functions (KDFs) 198 TCP-AO's Traffic_Keys are derived using KDFs. The KDFs used in TCP- 199 AO's current manual keying have the following interface: 201 Traffic_Key = KDF_alg(Master_Key, Context, Output_Length) 203 where: 205 - KDF_alg: the specific pseudorandom function (PRF) that is 206 the basic building block used in constructing the 207 given Traffic_Key. 209 - Master_Key: In TCP-AO's manual key mode, this is a key shared 210 by both peers, entered via some interface to their 211 respective configurations. The Master_Key is used 212 as the seed for the KDF. We assume that this is a 213 human-readable pre-shared key (PSK), thus we assume 214 it is of variable length. Master_Keys SHOULD be 215 random, but might not be (e.g., badly chosen by the 216 user). 218 - Context : A binary string containing information related to 219 the specific connection for this derived keying 220 material, as defined in 221 [I-D.ietf-tcpm-tcp-auth-opt], Section 7.2] 223 - Output_Length: The length in bits of the key that the KDF will 224 produce. This length must be the size required for 225 the MAC algorithm that will use the PRF result as a 226 seed. 228 When invoked, a KDF generates a string of length Output_Length bits 229 based on Master_Key and context value. This result may then be used 230 as a cryptographic key for any algorithm which takes an Output_Length 231 length key. A KDF MAY specify a maximum Output_Length parameter. 233 3.1.1. Concrete KDFs 235 This document defines two KDF algorithms, each paired with a 236 corresponding PRF algorithm as explained below: 238 * KDF_HMAC_SHA1 based on PRF-HMAC-SHA1 [RFC2404] 239 * KDF_AES_128_CMAC based on AES-CMAC-PRF-128 [RFC4615] 241 Each 243 Both of these KDFs are based on the iteration mode KDFs specified in 244 [NIST-SP800-108]. This means that they use an underlying 245 pseudorandom function (PRF) with a fixed-length output lengths, 128 246 bits in the case of the AES-CMAC, and 160 bits in the case of HMAC- 247 SHA1. The KDF generates an arbitrary number of output bits by 248 operating the PRF in a "counter mode", where each invocation of the 249 PRF uses a different input block differentiated by a block counter. 251 Each input block is constructed as follows: 253 ( i || Label || Context || Output_Length) 255 Where 257 - "||": For any X || Y, "||" represents a concatonation 258 operation of the binary strings X and Y. 260 - i: A counter, a binary string that is an input to each 261 iteration of the PRF in counter mode. The number of 262 iterations will depend on the specific size of the 263 Output_Length desired for a given MAC. 265 - Label: A binary string that clearly identifies the purpose 266 of this KDF's derived keying material. For TCP-AO we 267 use the ASCII string "TCP-AO", where the last 268 character is the capital letter "O", not to be 269 confused with a zero. While this may seem like 270 overkill in this specification since TCP-AO only 271 describes one call to the KDF, it is included in 272 order to comply with FIPS 140 certifications. 274 - Context : The context argument provided to the KDF interface, 275 as described above in Section 3.1 . 277 - Output_Length: The length in bits of the key that the KDF will 278 produce. This length must be the size required for 279 the MAC algorithm that will use the PRF result as a 280 seed. 282 The ouput of mutiple PRF invocations is simply concatenated. For the 283 Traffic_Key, values of multiple PRF invocations are concatenated and 284 truncated as needed to create a Traffic_Key of the desired length. 285 For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit 286 internal PRF to generate 320 bits of data, one would execute the PRF 287 twice, once with i=0 and once with i=1. The result would be the 288 entire output of the first invocation concatenated with the second 289 invocation. E.g., 291 Traffic_Key = 292 KDF_alg(Master_Key, 0 || Label || Context || Output_length) || 293 KDF_alg(Master_Key, 1 || Label || Context || Output_length) 295 If the number of bits required is not an even multiple of the output 296 size of the PRF, then the output of the final invocation of the PRF 297 is truncated as necessary. 299 3.1.1.1. KDF_HMAC_SHA1 301 For KDF_HMAC_SHA1: 303 - PRF for KDF_alg: HMAC-SHA1 [RFC2404]. 305 - Use: HMAC-SHA1(Key, Input). 307 - Key: Master_Key, configured by user, and passed to the KDF. 309 - Input: ( i || Label || Context || Output_Length) 311 - Output_Length: 160 bits. 313 - Result: Traffic_Key, used in the MAC function by TCP-AO. 315 3.1.1.2. KDF_AES_128_CMAC 317 For KDF_AES_128_CMAC: 319 - PRF for KDF_alg: AES-CMAC-PRF-128 [RFC4615]. 321 - Use: AES-CMAC(Key, Input). 323 - Key: Master_Key (see usage below) 325 - Input: ( i || Label || Context || Output_Length) 327 - Output_Length: 128 bits. 329 - Result: Traffic_Key, used in the MAC function by TCP-AO 331 The Master_Key in TCP-AO's current manual keying mechanism is a 332 shared secret, entered by an administrator. It is passed via an out- 333 of-band mechanism between two devices, and often between two 334 organizations. The shared secret does not have to be 16 octets, and 335 the length may vary. However, AES_128_CMAC requires a key of exactly 336 16 octets (128 bits) in length. We could mandate that 337 implementations force administrators to input Master_Keys of exactly 338 128 bit length when using AES_128_CMAC, and with sufficient 339 randomness, but this places undue burden on the implementors and 340 deployers. This specification RECOMMENDS that deployers use a 341 randomly generated 128-bit string as the Master_Key, but acknowledges 342 that deployers may not. 344 To handle variable length Master_Keys we use the same mechanism as 345 described in [RFC4615], Sect 3. First we use AES_128_CMAC with a 346 fixed key of all zeros as a "randomness extractor", while using the 347 shared secret Master_Key, MK, as the message input, to produce a 128 348 bit key Derived_Master_Key (K). Second, we use the result as a key, 349 and run AES-128_CMAC again, this time using the result K as the Key, 350 and the true input block as the Input to yield the Traffic_Key (TK) 351 used in the MAC over the message. The description follows: 353 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 354 + KDF-AES-128-CMAC + 355 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 356 + + 357 + Input : MK (Master_Key, the variable-length shared secret) + 358 + : I (Input, i.e., the input data of the PRF) + 359 + : MKlen (length of MK in octets) + 360 + : len (length of M in octets) + 361 + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)+ 362 + + 363 +-------------------------------------------------------------------+ 364 + Variable: K (128-bit key for AES-CMAC) + 365 + + 366 + Step 1. If MKlen is equal to 16 + 367 + Step 1a. then + 368 + K := MK; + 369 + Step 1b. else + 370 + K := AES-CMAC(0^128, MK, MKlen); + 371 + Step 2. TK := AES-CMAC(K, I, len); + 372 + return TK; + 373 + + 374 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 376 Figure 1 378 In step 1, the 128-bit key, K, for AES-CMAC is derived as follows: 380 o If the Master_Key, MK, provided by the administrator is exactly 128 381 bits, then we use it as-is. 383 o If it is longer or shorter than 128 bits, then we derive the key K 384 by applying the AES-CMAC algorithm using the 128-bit all-zero string 385 as the key and MK as the input message. This step is described in 386 step 1b. 388 In step 2, we apply the AES-CMAC algorithm again, this time using K 389 as the key and I as the input message. 391 The output of this algorithm returns TK, the Traffic_Key, which is 392 128 bits suitable for use in the MAC function on each TCP segment of 393 the connection. 395 3.1.1.3. Tips for User Interfaces regarding KDFs 397 This section provides suggested representations for the KDFs in 398 implementation user interfaces. Following these guidelines across 399 common implementations will make interoperability easier and simpler 400 for deployers. 402 UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1". 404 UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply 405 "AES128". 407 The initial IANA registry values will reflect these two entries. 409 UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO 410 settings. KDF_HMAC_SHA1 is preferred at this time because it has 411 wide support, being present in most implementations in the 412 marketplace. 414 3.2. MAC Algorithms 416 Each MAC_alg defined for TCP-AO has three fixed elements as part of 417 its definition: 419 - KDF_Alg: Name of the TCP-AO KDF algorithm used to generate the 420 Traffic_Key 421 - Key_Length: Length in bits required for the Traffic_Key used in 422 this MAC 423 - Output: The final length of the bits used in the TCP-AO MAC 424 field. This value may be a truncation of the MAC 425 function's original output length. 427 MACs computed for TCP-AO have the following interface: 429 MAC = MAC_alg(Traffic_Key, Message) 431 where: 433 - MAC_alg: MAC Algorithm used 434 - Traffic_Key: Variable; the result of KDF. 435 - Message The message to be authenticated, as specified in 436 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 438 This document specifies two MAC algorithm options for generating the 439 MAC as used by TCP-AO: 441 * HMAC-SHA-1-96 based on [RFC2404] 442 * AES-128-CMAC-96 based on [RFC4493] 444 Both provide a high level of security and efficiency. The AES-128- 445 CMAC-96 is potentially more efficient, particularly in hardware, but 446 HMAC-SHA-1-96 is more widely used in Internet protocols and in most 447 cases could be supported with little or no additional code in today's 448 deployed software and devices. 450 An important aspect to note about these algorithms' definitions for 451 use in TCP-AO is the fact that the MAC outputs are truncated to 96 452 bits. AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1 453 produces a 160 bit result. The MAC output are then truncated to 96 454 bits to provide a reasonable tradeoff between security and message 455 size, for fitting into the TCP-AO header. 457 3.2.1. The Use of HMAC-SHA-1-96 459 By definition, HMAC [RFC2104] requires a cryptographic hash function. 460 SHA1 will be that has function used for authenticating and providing 461 integrity validation on TCP segments with HMAC. 463 The three fixed elements for HMAC-SHA-1-96 are: 465 - KDF_Alg: KDF_HMAC_SHA1. 466 - Key_Length: 160 bits. 467 - Output: 96 bits. 469 For: 471 MAC = MAC_alg (Traffic_Key, Message) 473 HMAC-SHA-1-96 for TCP-AO has the following values: 475 - MAC_alg: HMAC-SHA1 476 - Traffic_Key: Variable; the result of the KDF. 477 - Message: The message to be authenticated, as specified in 478 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 480 3.2.2. The Use of AES-128-CMAC-96 482 In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually 483 define a usage of AES-128 as a cipher-based MAC according to 484 [NIST-SP800-38B]. 486 The three fixed elements for AES-128-CMAC-96 are: 488 - KDF_Alg: KDF_AES_128_CMAC. 489 - Key_Length: 128 bits. 490 - Output: 96 bits. 492 For: 494 MAC = MAC_alg (Traffic_Key, Message) 496 AES-128-CMAC-96 for TCP-AO has the following values: 498 - MAC_alg: AES-128-CMAC-96 [RFC4493] 499 - Traffic_Key: Variable; the result of the KDF. 500 - Message: The message to be authenticated, as specified in 501 [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1. 503 4. Change History (RFC Editor: Delete before publishing) 505 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 506 Please remove before publishing as RFC.] 508 draft-ietf...-02 - 6th submission 510 o 3.1.1.1 & 3.1.1.2, s/PRF:/PRF for KDF_alg: for clarification 511 o 513 draft-ietf...-01 - 5th submission 515 o simplified title of document - Touch 516 o structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the 517 description of the two KDF's became 3.1.1.1 & 3.1.1.2. used a 518 template (of sorts) in both sections that can be easily re-used by 519 any future KDF definition. 520 o in 3.1, switched "Derived_Key" back to "Traffic_Key" in order to 521 sync with -auth-opt spec. 522 o in 3.1, for Traffic_Key definition, changed the name of the 523 element "Input" to "Context", and removed the hard binding to 524 NIST-SP800-108 at the generic interface level. The NIST inclusion 525 is still present in the concrete definitions of the two presented 526 KDF's, but this way, if NIST changes, or if the community wants to 527 define some other, non-NIST-like KDFs, the interface is flexible 528 enough to handle that. Changed "KDF" to "KDF-alg". 530 o in 3.2, clarified that the output of the function is called "MAC 531 =", to have a similar look and feel to sect 3.1's function. also 532 changed MAC(foo) to "MAC_alg", and dropped "Output_Length" from 533 the function parameters, as it is specified as a fixed element for 534 each MAC defined, but not passed as a parameter of the function. 535 o sect 3.2 - removed "truncation" from interface definition, and 536 placed it as a fixed element of the MAC definition. sect 3.2.1 and 537 3.2.2 - changed "truncation:" field to "Output:". Removed text 538 about RFC4493 from end of 3.2.2. 539 o sect 3.1.1.2, changed back to follow 4615 exactly (agreement with 540 polk, mcgrew, lebovitz, ekr) 541 o sect 3.1.1.3, deleted the following: "When such a time arrives as 542 KDF_AES_128_CMAC becomes widely deployed, this document should be 543 updated so that it becomes the default KDF on implementations." 544 o added the two IANA values SHA1 and AES128 to IANA section 545 o Minor text change in section 3.1 and 3.2, to the definition of 546 "Context" in both - Joe Touch 547 o minor text change in 3.1.1 clarifying that the concatenation is of 548 binary strings - Joe Touch 549 o copy edits for read-ability throughout - Touch 551 draft-ietf...-00 - 4th submission 553 o Submitting draft-lebovitz...-02 as a WG document. Added EKR as 554 co- author, and gave him credit for rewrite of sect 3.1.x . 556 draft-lebovitz...-02 - 3rd submission 558 o cleaned up explanation in 3.1.2 559 o in 3.1.2, changed the key extractor mechanism back, from using an 560 alphanumeric string for the fixed key C to use 0^128 as the key 561 (as it was in -00) (Polk & Ekr) 562 o deleted cut-and-paste error text from sect 3.1 between "label" and 563 "context" 564 o changed "conn_key" to "traffic_key" throughout, to follow auth- 565 opt-05 566 o changed "tsad" to "mkt" throughout, to follow auth-opt-05 567 o changed "conn_block" to "data_block" throughout, to follow auth- 568 opt-05 570 draft-lebovitz...-01- 2nd submission 572 o removed the whole section on labels (previously section 4), per WG 573 consensus at IETF74. Added 3.1.3 to specify that implementations 574 SHOULD make HMAC-SHA1 the default choice for the time being, and 575 to suggest common names for the KDF's universally in UI's. 577 o changed KDF = PRF... to Derived_Key = KDF... (EKR) 578 o added the text on how to deal with future KDF to end of s3.1 (EKR) 579 o removed references to TCP-AO "manual key mode". Changed to TCP- 580 AO's "current mode of manual keying". (Touch) 581 o removed the whole MUST- / SHOULD+ thing. Both KDF's are MUST now, 582 per wg consensus at ietf74. 583 o in 3.1.2, changed the mechanism to force the K to be 128bits from 584 using 0^128, to using a fixed 128-bit string of random characters 585 (Dave McGrew) 586 o sect 3.1, in Input description, dropped "0x00". Added "NOTE" 587 explaining why right after the output_length description. 588 o cleaned up all references 589 o copy editing 591 draft-lebovitz...-00 - original submission 593 5. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 595 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 596 Please remove before publishing as RFC.] 598 List of stuff that still needs work 599 o should be ready for WG LC. Any changes will come from final WG 600 review or IESG review. 602 6. Security Considerations 604 This document inherits all of the security considerations of the 605 TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents. 607 The security of cryptographic-based systems depends on both the 608 strength of the cryptographic algorithms chosen and the strength of 609 the keys used with those algorithms. The security also depends on 610 the engineering of the protocol used by the system to ensure that 611 there are no non-cryptographic ways to bypass the security of the 612 overall system. 614 Care should also be taken to ensure that the selected key is 615 unpredictable, avoiding any keys known to be weak for the algorithm 616 in use. ][RFC4086] contains helpful information on both key 617 generation techniques and cryptographic randomness. 619 Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128 620 bit / 16 byte key as the seed. However, for convenience to the 621 administrators/deployers, we did not want to force them to enter a 16 622 byte Master_Key. So we specified the sub-key routine that could 623 handle a variable length Master_Key, one that might be less than 16 624 bytes. This does NOT mean that administrators are safe to use weak 625 keys. Administrators are encouraged to follow [RFC4086] as listed 626 above. We simply attempted to "put a fence around stupidity", in as 627 much as possible. 629 This document concerns itself with the selection of cryptographic 630 algorithms for the use of TCP-AO. The algorithms identified in this 631 document as "MUST implement" or "SHOULD implement" are not known to 632 be broken at the current time, and cryptographic research so far 633 leads us to believe that they will likely remain secure into the 634 foreseeable future. Some of the algorithms may be found in the 635 future to have properties significantly weaker than those that were 636 believed at the time this document was produced. Expect that new 637 revisions of this document will be issued from time to time. Be sure 638 to search for more recent versions of this document before 639 implementing. 641 7. IANA Considerations 643 IANA has created and will maintain a registry called, "Cryptographic 644 Algorithms for TCP-AO". The registry consists of a text string and 645 an RFC number that lists the associated transform(s). New entries 646 can be added to the registry only after RFC publication and approval 647 by an expert designated by the IESG. 649 The registry has the following initial values: 651 SHA1 [This RFC when published] 652 AES128 [This RFC when published] 654 8. Acknowledgements 656 Eric "EKR" Rescorla, who provided a ton of input and feedback, 657 including a somewhat heavy re-write of section 3.1.x, earning him and 658 author slot on the document. 660 Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly 661 create a first draft here. 663 Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two 664 hash algorithms for TCP-AO is largely cut and pasted into various 665 sections of this document. 667 Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] & 668 [RFC4305] text was consulted and sometimes used in the Requirements 669 Section 2 section of this document. 671 (In other words, I was truly only an editor of others' text in 672 creating this document.) 674 Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues 675 with the inputs to PRFs for the KDFs. EKR was also of great 676 assistance in how to structure the text, as well as helping to guide 677 good cryptographic decisions. 679 The TCPM working group, who put up with all us crypto and routing 680 folks DoS'ing their WG for 2 years, and who provided reviews of this 681 document. 683 9. References 685 9.1. Normative References 687 [I-D.ietf-tcpm-tcp-auth-opt] 688 Touch, J., Mankin, A., and R. Bonica, "The TCP 689 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-07 690 (work in progress), October 2009. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 9.2. Informative References 697 [HMAC-ATTACK] 698 "On the Security of HMAC and NMAC Based on HAVAL, MD4, 699 MD5, SHA-0 and SHA-1"", 2006, 700 . 703 [I-D.narten-iana-considerations-rfc2434bis] 704 Narten, T. and H. Alvestrand, "Guidelines for Writing an 705 IANA Considerations Section in RFCs", 706 draft-narten-iana-considerations-rfc2434bis-09 (work in 707 progress), March 2008. 709 [NIST-SP800-108] 710 National Institute of Standards and Technology, 711 "Recommendation for Key Derivation Using Pseudorandom 712 Functions", SP 800-108, April 2008. 714 [NIST-SP800-38B] 715 National Institute of Standards and Technology, 716 "Recommendation for Block Cipher Modes of Operation: The 717 CMAC Mode for Authentication", SP 800-38B, May 2005. 719 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 720 Hashing for Message Authentication", RFC 2104, 721 February 1997. 723 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 724 Internet Protocol", RFC 2401, November 1998. 726 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 727 ESP and AH", RFC 2404, November 1998. 729 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 730 Payload (ESP)", RFC 2406, November 1998. 732 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 733 Requirements for Security", BCP 106, RFC 4086, June 2005. 735 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 736 Requirements for Encapsulating Security Payload (ESP) and 737 Authentication Header (AH)", RFC 4305, December 2005. 739 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 740 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 741 December 2005. 743 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 744 December 2005. 746 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 747 AES-CMAC Algorithm", RFC 4493, June 2006. 749 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 750 Advanced Encryption Standard-Cipher-based Message 751 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 752 PRF-128) Algorithm for the Internet Key Exchange Protocol 753 (IKE)", RFC 4615, August 2006. 755 Authors' Addresses 757 Gregory Lebovitz 758 Juniper Networks, Inc. 759 1194 North Mathilda Ave. 760 Sunnyvale, CA 94089-1206 761 US 763 Phone: 764 Email: gregory.ietf@gmail.com 766 Eric Rescorla 767 RTFM, Inc. 768 2064 Edgewood Drive 769 Palo Alto, CA 94303 770 US 772 Phone: 650-678-2350 773 Email: ekr@rtfm.com