idnits 2.17.00 (12 Aug 2021) /tmp/idnits37148/draft-sheffer-ipsecme-hush-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2011) is 4084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'BM93' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'BMP00' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'PA97' is defined on line 464, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: draft-sheffer-emu-eap-eke has been published as RFC 6124 -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Independent 4 Intended status: Informational S. Fluhrer 5 Expires: September 10, 2011 Cisco 6 March 9, 2011 8 HUSH: Using HUmanly memorable SHared secrets with IKEv2 9 draft-sheffer-ipsecme-hush-02 11 Abstract 13 This document defines a new mode for IKEv2, where both peers can 14 authenticate using a short, humanly memorable shared secret. This 15 mode is based on the EKE protocol. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 10, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. The IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . 5 56 4.2. The IKE_HUSH Exchange . . . . . . . . . . . . . . . . . . 5 57 4.2.1. Message #1 . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2.2. Message #2 . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2.3. Message #3 . . . . . . . . . . . . . . . . . . . . . . 7 60 4.2.4. Message #4 . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Protocol Formats . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Encrypt Payload . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. Protect Payload . . . . . . . . . . . . . . . . . . . . . 8 64 6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 73 A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 There is strong interest in a simple method for bootstrapping an IKE 80 [RFC4306] security association between two peers, requiring neither 81 PKI nor AAA infrastructure. Although IKEv2 supports EAP-based 82 authentication in part to provide for this capability, it has been 83 claimed that the use of an extra authentication layer/protocol adds 84 little benefit and increases complexity. 86 This protocol integrates the well known EKE protocol [BM92] into 87 IKEv2, to provide password-based authentication. Some of the 88 benefits of this protocol are: 90 o EKE is a well known protocol, which has had multiple deep 91 cryptographic analyses applied to it. 92 o EKE provides the benefit of a well known, clear IPR status. 94 This protocol is not intended for use in enterprise-scale remote 95 access. As a result, only the basic authentication capability is 96 provided. Some capabilities typically associated with the use of 97 passwords for remote access include: password change and expiry, 98 password recovery, and enforcement of password strength policy. 100 In this preliminary version of the protocol many issues are not yet 101 covered, such as: 103 o Integration with other IKE elements, e.g. optional notifications, 104 Session Resumption... 105 o Error handling. 106 o Generation of a high-quality PSK, so that the password doesn't 107 need to be used for each authentication. Secure signalling of PSK 108 possession. 109 o Security analysis. 111 2. Terminology 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 3. Overview 119 This protocol attempts to preserve the general structure of IKEv2, 120 minimizing the number of new constructs and round trips, while 121 retaining IKE's security guarantees, including identity protection. 122 The resulting protocol only adds one round trip to the shared secret 123 authentication mode of IKEv2. 125 At a high level, the message exchange is as follows: 127 Initiator Responder 128 --------- --------- 130 HDR, SAi1, KEi, Ni, N(HUSH) 132 <- HDR, SAr1, KEr, Nr, N(HUSH) 134 HDR, SK{IDi, [IDr,], SAi2, TSi, TSr, Encrypt{Yi}} -> 136 <- HDR, SK{IDr, Encrypt{Yr}, Protect{Nr2}} 138 HDR, SK{AUTH, Protect{Ni2|Nr2}} 140 <- HDR, SK{AUTH, SAr2, TSi, TSr, Protect{Ni2}} 142 The changes to IKEv2 are summarized in the following list: 144 o The regular IKE_SA_INIT exchange is followed by a new 2-round trip 145 exchange, IKE_HUSH. 146 o Negotiation of the new mode using notifications in IKE_SA_INIT. 147 o Negotiation of cryptographic algorithms: the encryption algorithm, 148 the integrity protection algorithm and the pseudo-random function 149 are the ones negotiated for the IKE SA itself, while a new Diffie- 150 Hellman group is selected for the HUSH exchange, by extending the 151 SAi1/SAr1 negotiation. 152 o A new encrypted payload type, denoted Encrypt{}, for exchanging an 153 ephemeral public key encrypted by the password. 154 o A new encrypted and integrity-protected payload type, denoted 155 Protect{}, for exchanging nonces encrypted by the EKE shared 156 secret. 157 o The IKE AUTH payloads provide cryptographic binding of the IKE 158 shared secret with the password-based authentication. 160 4. Protocol Sequence 162 The protocol consists of a slightly extended IKE_SA_INIT exchange, 163 followed by the 4-message IKE_HUSH exchange. 165 4.1. The IKE_SA_INIT Exchange 167 During this exchange, the initiator sends an empty HUSH_SUPPORTED 168 notification. If the responder understands this protocol and wishes 169 to use it, it sends back another empty HUSH_SUPPORTED notification. 171 In addition, this protocol defines a new transform type for the IKE 172 protocol, called "EKE D-H Group". Possible transforms are the EKE 173 groups defined in Section 6.1. This transform type is negotiated 174 between the initiator and responder with the usual SAi1, SAr1 175 payloads. If the initiator suspects that the responder does not 176 support this protocol, it SHOULD also include a proposal that omits 177 this transform, to allow the negotiation to revert to regular IKE. 178 During successful negotiation, an EKE D-H Group MUST be negotiated if 179 (and only if) the responder indicates support for this protocol. 181 4.2. The IKE_HUSH Exchange 183 This exchange consists of two message pairs, and includes all 184 payloads normally contained in the IKE_AUTH exchange. These latter 185 payloads are not described in this subsection, in order to focus on 186 the new HUSH payloads. 188 4.2.1. Message #1 190 The initiator computes 192 Yi = g^x mod N, 194 where x is a randomly chosen number in the range 2 .. N-1, as 195 defined by the negotiated Diffie-Hellman group. The randomly chosen 196 number is the private key, and the calculated value is the 197 corresponding public key. Each of the peers MUST use a fresh, random 198 value for x on each run of the protocol. 200 Note: If Elliptic Curve Diffie-Hellman is used in a future version of 201 this protocol, the corresponding additive group operations are to be 202 understood. 204 The initiator generates the Encrypt payload (Section 5.1), 206 Encrypt(prf+(password, "HUSH Password"), Yi), 208 where the literal string is encoded using ASCII with no zero 209 terminator. The prf+ notation is as defined in [RFC4306]. When 210 using block ciphers, it may be necessary to pad Yi on the right, to 211 fit the encryption algorithm's block size. In such cases, random 212 padding MUST be used, and this randomness is critical to the security 213 of the protocol. Randomness recommendations can be found in 214 [RFC4086]. 216 If the password needs to be stored on the server, it is RECOMMENDED 217 to store the randomized password value, i.e. prf+(password, ...), as 218 a password-equivalent, rather than the cleartext password. 220 If the password is non-ASCII, it SHOULD be normalized by the sender 221 before the message is constructed. The normalization method is 222 SASLprep, [RFC4013]. Note that the password is not null-terminated. 224 4.2.2. Message #2 226 Similarly to Message #1, the responder picks a random private key, 227 generates an ephemeral public key Yr, encrypts it by the expanded 228 password and includes the resulting Encrypt payload in the message: 230 Encrypt(prf+(password, "HUSH Password"), Yr), 232 The responder now calculates 234 EkeSharedSecret = prf(0+, g^(x*y) mod N) 236 where the first argument to "prf" is a string of zero octets whose 237 length is the output size of the base hash algorithm, e.g. 20 octets 238 for HMAC-SHA1; the result is of the same length. This extra 239 application of the pseudo-random function is the "extraction step" of 240 [RFC5869]. 242 The responder computes the encryption and authentication (integrity 243 protection) keys: 245 Ke2, Ka2 = prf+(EkeSharedSecret, "HUSH encryption and 246 authentication" | IDi | IDr) 248 Now the responder can generate the Protect payload included in the 249 message: 251 Protect(Ke2, Ka2, Nr2), 253 where Nr2 is a randomly generated binary string (nonce). Nr2 has 254 length equal to the block size of the negotiated encryption algorithm 255 for block ciphers, or 32 octets if this algorithm is a stream cipher. 256 The responder sends this value as an Encrypt payload. 258 4.2.3. Message #3 260 The initiator computes the EkeSharedSecret, Ke2 and Ka2 values as 261 above. 263 It then picks a random nonce Ni2, of the same format as Nr2, 264 concatenates the two nonces, and generates 266 Protect(Ke2, Ka2, Ni2 | Nr2), 268 In addition, it computes 270 AUTH = prf(prf(Shared Secret, Ni2 | Nr2 | IDi | IDr), 271 ) 273 where the Shared Secret is the regular IKE shared secret, created by 274 the IKE_SA_INIT exchange. 276 4.2.4. Message #4 278 The responder verifies Nr2 and the received AUTH payload, and MUST 279 terminate the protocol if either of them fails to verify. The 280 responder generates 282 Protect(Ke2, Ka2, Ni2) 284 and 286 AUTH = prf(prf(Shared Secret, Ni2 | Nr2 | IDi | IDr), 287 ) 289 The initiator MUST verify the Ni2 and AUTH values when receiving 290 Message #4. 292 5. Protocol Formats 294 5.1. Encrypt Payload 296 This payload contains encrypted, but non-integrity protected, data. 297 Unfortunately the simpler term "Encrypted Payload" is used by IKEv2 298 for a payload that contains encrypted and integrity-protected data. 300 Compared to the IKE Encrypted Payload, this payload does not contain 301 other embedded payloads. The payload is denoted Encrypt(key, data), 302 and defined thus: 304 1 2 3 305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Next Payload |C| RESERVED | Payload Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Initialization Vector | 310 | (length is block size for encryption algorithm) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Data Length | ~ 313 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Encrypted Data ~ 314 ~ ~ 315 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ | ~ 317 +-+-+-+-+-+-+-+-+ Random Padding (0-255 octets) ~ 318 ~ ~ 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 The Encrypt Payload 323 o Data Length is a 2 octet length of the encrypted data, exclusive 324 of padding. This field itself is unencrypted. 325 o Random Padding MUST indeed be random and unpredictable if it is 326 included. This randomness is critical to the security of the 327 protocol. 329 5.2. Protect Payload 331 This payload contains encrypted and integrity protected data. 333 This payload is identical to the Encrypt Payload (Section 5.1) with 334 the addition of an integrity-protection ICV field. The payload is 335 denoted by Protect(enc-key, integ-key, data) and defined as follows: 337 1 2 3 338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Next Payload |C| RESERVED | Payload Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Initialization Vector | 343 | (length is block size for encryption algorithm) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Data Length | ~ 346 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| Encrypted Data ~ 347 ~ ~ 348 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 ~ | ~ 350 +-+-+-+-+-+-+-+-+ Random Padding (0-255 octets) ~ 351 ~ ~ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Integrity Check Value (ICV) | 354 | (length depends on integrity algorithm) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 The Protect Payload 359 o The Integrity Check Value is computed over the Initialization 360 Vector, Data Length, Encrypted Data and Random Padding (if any). 361 The length of the field is determined by the negotiated integrity 362 algorithm. 364 6. Cryptographic Details 366 6.1. Diffie-Hellman Groups 368 Many of the commonly used Diffie Hellman groups are inappropriate for 369 use in EKE. Most of these groups use a generator which is not a 370 primitive element of the group. As a result, an attacker running a 371 dictionary attack would be able to learn at least 1 bit of 372 information for each decrypted password guess. 374 Any MODP Diffie Hellman group defined for use in this protocol MUST 375 have the following properties, to ensure that it does not leak a 376 usable amount of information about the password: 377 1. The generator is a primitive element of the group. 378 2. The most significant 64 bits of the prime number are 1. 379 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 380 prime. 382 The last requirement is related to the strength of the Diffie Hellman 383 algorithm, rather than the password encryption. It also makes it 384 easy to verify that the generator is primitive. 386 We have defined the following groups. The Value column is used when 387 negotiating the group. Additional groups may be defined through IANA 388 allocation. Future non-MODP groups require a document to define 389 their interaction with this protocol. 391 +----------------+--------+---------+-------------------------------+ 392 | Name | Length | Value | Description | 393 +----------------+--------+---------+-------------------------------+ 394 | Reserved | | 0 | | 395 | DHGROUP_EKE_2 | 1024 | 1 | The prime number of Group 2 | 396 | | | | [RFC4306], with the generator | 397 | | | | 5 (decimal) | 398 | DHGROUP_EKE_5 | 1536 | 2 | The prime number of Group 5 | 399 | | | | [RFC3526], g=31 | 400 | DHGROUP_EKE_14 | 2048 | 3 | The prime number of Group 14 | 401 | | | | [RFC3526], g=11 | 402 | DHGROUP_EKE_15 | 3072 | 4 | The prime number of Group 15 | 403 | | | | [RFC3526], g=5 | 404 | DHGROUP_EKE_16 | 4096 | 5 | The prime number of Group 16 | 405 | | | | [RFC3526], g=5 | 406 | Available for | | 6-127 | | 407 | allocation via | | | | 408 | IANA | | | | 409 | Reserved for | | 128-255 | | 410 | private use | | | | 411 +----------------+--------+---------+-------------------------------+ 413 7. IANA Considerations 415 TBD: one notification, one transform type, two payloads, a new 416 exchange. Also a new DH group registry. 418 8. Security Considerations 420 Will be added. 422 9. Acknowledgements 424 Much of this protocol is derived from [I-D.sheffer-emu-eap-eke], and 425 authors (and reviewers) of that draft are acknowledged. 427 10. References 429 10.1. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 435 Diffie-Hellman groups for Internet Key Exchange (IKE)", 436 RFC 3526, May 2003. 438 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 439 RFC 4306, December 2005. 441 10.2. Informative References 443 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 444 Password-Based Protocols Secure Against Dictionary 445 Attacks", Proc. IEEE Symp. on Research in Security and 446 Privacy , May 1992. 448 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 449 Exchange: A Password-Based Protocol Secure against 450 Dictionary Attacks and Password File Compromise", Proc. 451 1st ACM Conference on Computer and Communication 452 Security , 1993. 454 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 455 Password Authenticated Key Exchange Using Diffie-Hellman", 456 Advances in Cryptology, EUROCRYPT 2000 , 2000. 458 [I-D.sheffer-emu-eap-eke] 459 Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 460 EAP Authentication Method Based on the EKE Protocol", 461 draft-sheffer-emu-eap-eke-09 (work in progress), 462 October 2010. 464 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 465 Schemes", Proceedings of the 1997 IEEE Symposium on 466 Security and Privacy , 1997. 468 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 469 and Passwords", RFC 4013, February 2005. 471 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 472 Requirements for Security", BCP 106, RFC 4086, June 2005. 474 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 475 Key Derivation Function (HKDF)", RFC 5869, May 2010. 477 Appendix A. Change Log 479 Note to RFC Editor: please remove this section before publication. 481 A.1. -01 483 Reissued, changed the derivation of the payload encryption and 484 authentication keys. 486 A.2. -00 488 Initial version, a very rough draft. 490 Authors' Addresses 492 Yaron Sheffer 493 Independent 495 Email: yaronf.ietf@gmail.com 497 Scott Fluhrer 498 Cisco Systems. 499 1414 Massachusetts Ave. 500 Boxborough, MA 01719 501 USA 503 Email: sfluhrer@cisco.com