idnits 2.17.1 draft-ietf-kitten-krb-spake-preauth-00.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 (June 6, 2017) is 2514 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) -- Looks like a reference, but probably isn't: '0' on line 966 -- Looks like a reference, but probably isn't: '1' on line 967 -- Looks like a reference, but probably isn't: '2' on line 968 -- Looks like a reference, but probably isn't: '3' on line 969 == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-01 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-spake2 (ref. 'I-D.irtf-cfrg-spake2') ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. McCallum 3 Internet-Draft S. Sorce 4 Intended status: Standards Track R. Harwood 5 Expires: December 8, 2017 Red Hat, Inc. 6 G. Hudson 7 MIT 8 June 6, 2017 10 SPAKE Pre-Authentication 11 draft-ietf-kitten-krb-spake-preauth-00 13 Abstract 15 This document defines a new pre-authentication mechanism for the 16 Kerberos protocol that uses a password authenticated key exchange. 17 This document has three goals. First, increase the security of 18 Kerberos pre-authentication exchanges by making offline brute-force 19 attacks infeasible. Second, enable the use of secure second factor 20 authentication without relying on FAST. This is achived using the 21 existing trust relationship established by the shared first factor. 22 Third, make Kerberos pre-authentication more resilient against time 23 synchronization errors by removing the need to transfer an encrypted 24 timestamp from the client. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 8, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Properties of PAKE . . . . . . . . . . . . . . . . . . . 3 62 1.2. Which PAKE? . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.3. PAKE and Two-Factor Authentication . . . . . . . . . . . 4 64 1.4. SPAKE Overview . . . . . . . . . . . . . . . . . . . . . 5 65 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 5 66 3. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. PA-ETYPE-INFO2 . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Cookie Support . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. More Pre-Authentication Data Required . . . . . . . . . . 6 70 4. SPAKE Pre-Authentication Message Protocol . . . . . . . . . . 6 71 4.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 9 75 4.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 10 76 4.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 10 77 5. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 11 78 6. Transcript Checksum . . . . . . . . . . . . . . . . . . . . . 11 79 7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 13 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 10. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 16 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 11.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 16 85 11.1.1. Registration Template . . . . . . . . . . . . . . . 16 86 11.1.2. Initial Registry Contents . . . . . . . . . . . . . 17 87 11.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 17 88 11.2.1. Registration Template . . . . . . . . . . . . . . . 17 89 11.2.2. Initial Registry Contents . . . . . . . . . . . . . 18 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 92 12.2. Non-normative References . . . . . . . . . . . . . . . . 20 93 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21 94 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 The most widely deployed Kerberos pre-authentication method, PA-ENC- 100 TIMESTAMP, encrypts a timestamp in the client principal's long-term 101 secret. When a client uses this method, a passive attacker can 102 perform an offline brute-force attack against the transferred 103 ciphertext. When the client principal's long-term key is based on a 104 password, especially a weak password, offline dictionary attacks can 105 successfully recover the key. 107 1.1. Properties of PAKE 109 Password authenticated key exchange (PAKE) algorithms provide several 110 properties which are useful to overcome this problem and make them 111 ideal for use as a Kerberos pre-authentication mechanism. 113 1. Each side of the exchange contributes entropy. 115 2. Passive attackers cannot determine the shared key. 117 3. Active attackers cannot perform a man-in-the-middle attack. 119 4. Either side can store a password or password equivalent. 121 These properties of PAKE allow us to establish high-entropy 122 encryption keys resistant to offline brute force attack, even when 123 the passwords used are weak (low-entropy). 125 1.2. Which PAKE? 127 Diffie-Hellman Encrypted Key Exchange (DH-EKE) is the earliest widely 128 deployed PAKE. It works by encrypting the public keys of a Diffie- 129 Hellman key exchange with a shared secret. However, it requires both 130 that unauthenticated encryption be used and that the public keys be 131 indistinguishable from random data. This last requirement makes it 132 impossible to use this form of PAKE with elliptic curve cryptography. 133 For these reasons, DH-EKE is not a good fit. 135 Password authenticated key exchange by juggling (JPAKE) permits the 136 use of elliptic curve cryptography. However, it too has drawbacks. 137 First, the additional computation required for the algorithm makes it 138 resource intensive for servers under load. Second, it requires an 139 additional network round-trip, increasing latency and load on the 140 network. 142 SPAKE is a variant of the technique used by DH-EKE which ensures that 143 all public key encryption and decryption operations result in a 144 member of the underlying group. This property allows SPAKE to be 145 used with elliptic curve cryptography, permitting the use of markedly 146 smaller key sizes with equivalent security to a finite-field Diffie- 147 Hellman key exchange. Additionally, SPAKE can complete the key 148 exchange in just a single round-trip. These properties make SPAKE an 149 ideal PAKE to use for Kerberos pre-authentication. 151 1.3. PAKE and Two-Factor Authentication 153 Using PAKE in a pre-authentication mechanism also has another benefit 154 when coupled with two-factor authentication (2FA). 2FA methods often 155 require the secure transfer of plaintext material to the KDC for 156 verification. This includes one-time passwords, challenge/response 157 signatures and biometric data. Attempting to encrypt this data using 158 the long-term secret results in packets that are vulnerable to 159 offline brute-force attack if either authenticated encryption is used 160 or if the plaintext is distinguishable from random data. This is a 161 problem that PAKE solves for first factor authentication. So a 162 similar technique can be used with PAKE to encrypt second-factor 163 data. 165 In the OTP pre-authentication [RFC6560] specification, this problem 166 has been mitigated by using FAST, which uses a secondary trust 167 relationship to create a secure encryption channel within which pre- 168 authentication data can be sent. However, the requirement for a 169 secondary trust relationship has proven to be cumbersome to deploy 170 and often introduces third parties into the trust chain (such as 171 certification authorities). These requirements lead to a scenario 172 where FAST cannot be enabled by default without sufficient 173 configuration. SPAKE pre-authentication, instead, can create a 174 secure encryption channel implicitly, using the key exchange to 175 negotiate a high-entropy encryption key. This key can then be used 176 to securely encrypt 2FA plaintext data without the need for a 177 secondary trust relationship. Further, if the second factor 178 verifiers are sent at the same time as the first factor verifier, and 179 the KDC is careful to prevent timing attacks, then an online brute- 180 force attack cannot be used to attack the factors separately. 182 For these reasons, this draft departs from the advice given in 183 Section 1 of RFC 6113 [RFC6113] which states that "Mechanism 184 designers should design FAST factors, instead of new pre- 185 authentication mechanisms outside of FAST." However, this pre- 186 authentication mechanism does not intend to replace FAST, and may be 187 used with it to further conceal the metadata of the Kerberos 188 messages. 190 1.4. SPAKE Overview 192 The SPAKE algorithm can be broadly described in a series of four 193 steps: 195 1. Calculation and exchange of the public key 197 2. Calculation of the shared secret (K) 199 3. Derivation of an encryption key (K') 201 4. Verification of the derived encryption key (K') 203 Higher level protocols must define their own verification step. In 204 the case of this mechanism, verification happens implicitly by a 205 successful decryption of the 2FA data. 207 This mechanism also provides its own method of deriving encryption 208 keys from the calculated shared secret K, for several reasons: to fit 209 within the framework of [RFC3961], to ensure negotiation integrity 210 using a transcript hash, to derive different keys for each use, and 211 to bind the KDC-REQ-BODY to the pre-authentication exchange. 213 2. Document Conventions 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 This document refers to numerous terms and protocol messages defined 220 in [RFC4120]. 222 The terms "encryption type", "required checksum mechanism", and 223 "get_mic" are defined in [RFC3961]. 225 The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED", 226 "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "pre-authentication facility", 227 and "authentication set" are defined in [RFC6113]. 229 The [SPAKE] paper defines SPAKE as a family of two key exchange 230 algorithms differing only in derivation of the final key. This 231 mechanism uses a derivation similar to the second algorithm (SPAKE2) 232 with differences in detail. For simplicity, this document refers to 233 the algorithm as "SPAKE". The normative reference for this algorithm 234 is [I-D.irtf-cfrg-spake2]. 236 The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and 237 [CCITT.X690.2002]. 239 3. Prerequisites 241 3.1. PA-ETYPE-INFO2 243 This mechanism requires the initial KDC pre-authentication state to 244 contain a singular reply key. Therefore, a KDC which offers SPAKE 245 pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE- 246 INFO2 value containing a single ETYPE-INFO2-ENTRY, as described in 247 [RFC6113] section 2.1. 249 3.2. Cookie Support 251 KDCs which implement SPAKE pre-authentication MUST have some secure 252 mechanism for retaining state between AS-REQs. For stateless KDC 253 implementations, this method will most commonly be an encrypted PA- 254 FX-COOKIE. Clients which implement SPAKE pre-authentication MUST 255 support PA-FX-COOKIE. 257 3.3. More Pre-Authentication Data Required 259 Both KDCs and clients which implement SPAKE pre-authentication MUST 260 support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED. 262 4. SPAKE Pre-Authentication Message Protocol 264 This mechanism uses the reply key and provides the Client 265 Authentication and Strengthening Reply Key pre-authentication 266 facilities. When the mechanism completes successfully, the client 267 will have proved knowledge of the original reply key and possibly a 268 second factor, and the reply key will be strengthened to a more 269 uniform distribution based on the PAKE exchange. This mechanism also 270 ensures the integrity of the KDC-REQ-BODY contents. This mechanism 271 can be used in an authentication set; no pa-hint value is required or 272 defined. 274 This section will describe the flow of messages when performing SPAKE 275 pre-authentication. We will begin by explaining the most verbose 276 version of the protocol which all implementations MUST support. Then 277 we will describe several optional optimizations to reduce round- 278 trips. 280 Mechanism messages are communicated using PA-DATA elements within the 281 padata field of KDC-REQ messages or within the METHOD-DATA in the 282 e-data field of KRB-ERROR messages. All PA-DATA elements for this 283 mechanism MUST use the following padata-type: 285 PA-SPAKE TBD 286 The padata-value for all PA-SPAKE PA-DATA values MUST be empty or 287 contain a DER encoding for the ASN.1 type PA-SPAKE. 289 PA-SPAKE ::= CHOICE { 290 support [0] SPAKESupport, 291 challenge [1] SPAKEChallenge, 292 response [2] SPAKEResponse, 293 encdata [3] EncryptedData, 294 ... 295 } 297 4.1. First Pass 299 The SPAKE pre-authentication exchange begins when the client sends an 300 initial authentication service request (AS-REQ) without pre- 301 authentication data. Upon receipt of this AS-REQ, a KDC which 302 requires pre-authentication and supports SPAKE SHOULD reply with a 303 KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty 304 PA-SPAKE PA-DATA element. This message indicates to the client that 305 the KDC supports SPAKE pre-authentication. 307 4.2. Second Pass 309 Once the client knows that the KDC supports SPAKE pre-authentication 310 and the client desires to use it, the client will generate a new AS- 311 REQ message containing a PA-SPAKE PA-DATA element using the support 312 choice. This message indicates to the KDC which groups the client 313 prefers for the SPAKE operation. The group numbers are defined in 314 the IANA "Kerberos SPAKE Groups" registry created by this document. 315 The groups sequence is ordered from the most preferred group to the 316 least preferred group. 318 SPAKESupport ::= SEQUENCE { 319 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 320 ... 321 } 323 The client and KDC initialize a transcript checksum (Section 6) and 324 update it with the DER-encoded PA-SPAKE message. 326 Upon receipt of the support message, the KDC will select a group. 327 The KDC SHOULD choose a group from the groups provided by the support 328 message. However, if the support message does not contain any group 329 that is supported by the KDC, the KDC MAY select another group in 330 hopes that the client might support it. 332 Once the KDC has selected a group, the KDC will reply to the client 333 with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE 334 PA-DATA element using the challenge choice. The client and KDC 335 update the transcript checksum with the DER-encoded PA-SPAKE message. 337 SPAKEChallenge ::= SEQUENCE { 338 group [0] Int32, 339 pubkey [1] OCTET STRING, 340 factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, 341 ... 342 } 344 The group field indicates the KDC-selected group used for all SPAKE 345 calculations as defined in the IANA "Kerberos SPAKE Groups" registry 346 created by this document. 348 The pubkey field indicates the KDC's public key generated using the M 349 constant in the SPAKE algorithm, with inputs and conversions as 350 specified in Section 5. 352 The factors field contains an unordered list of second factors which 353 can be used to complete the authentication. Each second factor is 354 represented by a SPAKESecondFactor. 356 SPAKESecondFactor ::= SEQUENCE { 357 type [0] Int32, 358 data [1] OCTET STRING OPTIONAL 359 } 361 The type field is a unique integer which identifies the second factor 362 type. The factors field of SPAKEChallenge MUST NOT contain more than 363 one SPAKESecondFactor with the same type value. 365 The data field contains optional challenge data. The contents in 366 this field will depend upon the second factor type chosen. 368 4.3. Third Pass 370 Upon receipt of the challenge message, the client will complete its 371 part of of the SPAKE process, resulting in the shared secret K. 373 Next, the client chooses one of the second factor types listed in the 374 factors field of the challenge message and gathers whatever data is 375 required for this second factor type; possibly using the challenge 376 data for this second factor type. Finally, the client sends an AS- 377 REQ containing a PA-SPAKE PA-DATA element using the response choice. 379 SPAKEResponse ::= SEQUENCE { 380 pubkey [0] OCTET STRING, 381 factor [1] EncryptedData, -- SPAKESecondFactor 382 ... 383 } 385 The client and KDC update the transcript checksum with the pubkey 386 value, and use the resulting checksum for all encryption key 387 derivations. 389 The pubkey field indicates the client's public key generated using 390 the N constant in the SPAKE algorithm, with inputs and conversions as 391 specified in Section 5. 393 The factor field indicates the client's chosen second factor data. 394 The key for this field is K'[1] as specified in Section 7. The key 395 usage number for the encryption is KEY_USAGE_SPAKE_FACTOR. The plain 396 text inside the EncryptedData is an encoding of SPAKESecondFactor. 397 Once decoded, the SPAKESecondFactor contains the type of the second 398 factor and any optional data used. The contents of the data field 399 will depend on the second factor type chosen. The client MUST NOT 400 send a response containing a second factor type which was not listed 401 in the factors field of the challenge message. 403 When the KDC receives the response message from the client, it will 404 use the pubkey to compute the SPAKE result, derive K'[1], and decrypt 405 the factors field. If decryption is successful, the first factor is 406 successfully validated. The KDC then validates the second factor. 407 If either factor fails to validate, the KDC responds with an 408 appropriate KRB-ERROR message. 410 If validation of the second factor requires further round-trips, the 411 KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 412 containing a PA-SPAKE PA-DATA element using the encdata choice. The 413 key for the EncryptedData value is K'[2] as specified in Section 7, 414 and the key usage number is KEY_USAGE_SPAKE_FACTOR. The plain text 415 of this message contains a DER-encoded SPAKESecondFactor message. As 416 before, the type field of this message will contain the second factor 417 type, and the data field will optionally contain second factor type 418 specific data. 420 KEY_USAGE_SPAKE_FACTOR TBD 422 4.4. Subsequent Passes 424 Any number of additional round trips may occur using the encdata 425 choice. The contents of the plaintexts are specific to the second 426 factor type. If a client receives a PA-SPAKE PA-DATA element using 427 the encdata choice from the KDC, it MUST reply with a subsequent AS- 428 REQ with a PA-SPAKE PA-DATA using the encdata choice, or abort the AS 429 exchange. 431 The key for client-originated encdata messages in subsequent passes 432 is K'[3] as specified in Section 7 for the first subsequent pass, 433 K'[5] for the second, and so on. The key for KDC-originated encdata 434 messages is K'[4] for the first subsequent pass, K'[6] for the 435 second, and so on. 437 4.5. Reply Key Strengthening 439 When the KDC has successfully validated both factors, the reply key 440 is strengthened and the mechanism is complete. To strengthen the 441 reply key, the client and KDC replace it with K'[0] as specified in 442 Section 7. The KDC then replies with a KDC-REP message, or continues 443 on to the next mechanism in the authentication set. There is no 444 final PA-SPAKE PA-DATA message from the KDC to the client. 446 Reply key strengthening occurs only once at the end of the exchange. 447 The client and KDC MUST use the initial reply key as the base key for 448 all K'[n] derivations. 450 4.6. Optimizations 452 The full protocol has two possible optimizations. 454 First, the KDC MAY reply to the initial AS-REQ (containing no pre- 455 authentication data) with a PA-SPAKE PA-DATA element using the 456 challenge choice, instead of an empty padata-value. In this case, 457 the KDC optimistically selects a group which the client may not 458 support. If the group chosen by the challenge message is supported 459 by the client, the client MUST skip to the third pass by issuing an 460 AS-REQ with a PA-SPAKE message using the response choice. If the 461 KDC's chosen group is not supported by the client, the client MUST 462 initialize and update the transcript hash with the KDC's challenge 463 message, and then continue to the second pass. Clients MUST support 464 this optimization. 466 Second, clients MAY skip the first pass and send an AS-REQ with a PA- 467 SPAKE PA-DATA element using the support choice. The KDC MUST include 468 a PA-ETYPE-INFO2 value within the METHOD-DATA of the 469 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may 470 not otherwise be able to compute the initial reply key. KDCs MUST 471 support this optimization. 473 5. SPAKE Parameters and Conversions 475 Group elements are converted to octet strings for the SPAKEChallenge 476 and SPAKEResponse pubkey fields and for key derivation using the 477 serialization method defined in the IANA "Kerberos SPAKE Groups" 478 registry created by this document. 480 The SPAKE algorithm requires constants M and N for each group. These 481 constants are defined in the IANA "Kerberos SPAKE Groups" registry 482 created by this document. 484 The SPAKE algorithm requires a shared secret input w to be used as a 485 scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2). This value 486 MUST be produced from the initial reply key as follows: 488 1. Determine the length of the multiplier octet string defined in 489 the IANA "Kerberos SPAKE Groups" registry created by this 490 document. 492 2. Compose a pepper string by concatenating the string "SPAKEsecret" 493 and the group number a big-endian four-byte unsigned binary 494 number. 496 3. Produce an octet string of the required length using PRF+(K, 497 pepper), where K is the initial reply key and PRF+ is defined in 498 [RFC6113] section 5.1. 500 4. Convert the octet string to a multiplier scalar using the 501 multiplier conversion method defined in the IANA "Kerberos SPAKE 502 Groups" registry created by this document. 504 The KDC chooses a secret scalar value x and the client chooses a 505 secret scalar value y. As required by the SPAKE algorithm, these 506 values are chosen randomly and uniformly. The KDC and client MUST 507 NOT reuse x or y values for authentications involving different 508 initial reply keys. 510 6. Transcript Checksum 512 The transcript checksum is an octet string of length equal to the 513 output length of the required checksum type of the encryption type of 514 the initial reply key. It initially contains all zero values. 516 When the transcript checksum is updated with an octet string input, 517 the new value is the get_mic result computed over the concatenation 518 of the old value and the input, for the required checksum type of the 519 initial reply key's encryption type, using the initial reply key and 520 the key usage number KEY_USAGE_SPAKE_TRANSCRIPT. 522 In the normal message flow or with the second optimization described 523 in Section 4.6, the transcript checksum is first updated with the 524 client's support message, then the KDC's challenge message, and 525 finally with the client's pubkey value. It therefore incorporates 526 the client's supported groups, the KDC's chosen group, the KDC's 527 initial second-factor messages, and the client and KDC public values. 529 If the first optimization described in Section 4.6 is used 530 successfully, the transcript checksum is updated only with the KDC's 531 challenge message and the client's pubkey value. 533 If first optimization is used unsuccessfully (i.e. the client does 534 not accept the KDC's selected group), the transcript checksum is 535 updated with the KDC's optimistic challenge message, then with the 536 client's support message, then the KDC's second challenge message, 537 and finally with the client's pubkey value. 539 KEY_USAGE_SPAKE_TRANSCRIPT TBD 541 7. Key Derivation 543 Implementations MUST NOT use the SPAKE result (denoted by K in 544 Section 2 of SPAKE [I-D.irtf-cfrg-spake2]) directly for any 545 cryptographic operation. Instead, the SPAKE result is used to derive 546 keys K'[n] as defined in this section. This method differs slightly 547 from the method used to generate K' in Section 3 of SPAKE 548 [I-D.irtf-cfrg-spake2]. 550 A PRF+ input string is assembled by concatenating the following 551 values: 553 o The fixed string "SPAKEkey". 555 o The group number as a big-endian four-byte unsigned binary number. 557 o The encryption type of the initial reply key as a big-endian four- 558 byte unsigned binary number. 560 o The SPAKE result K, converted to an octet string as specified in 561 Section 5. 563 o The transcript checksum. 565 o The KDC-REQ-BODY encoding for the request being sent or responded 566 to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST 567 be used. 569 o The value n as a big-endian four-byte unsigned binary number. 571 The derived key K'[n] has the same encryption type as the initial 572 reply key, and has the value random-to-key(PRF+(initial-reply-key, 573 input-string)). PRF+ is defined in [RFC6113] section 5.1. 575 8. Second Factor Types 577 This document defines one second factor type: 579 SF-NONE 1 581 This second factor type indicates that no second factor is used. 582 Whenever a SPAKESecondFactor is used with SF-NONE, the data field 583 MUST be omitted. The SF-NONE second factor always successfully 584 validates. 586 9. Security Considerations 588 All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2] 589 apply here as well. 591 This mechanism includes unauthenticated plaintext in the support and 592 challenge messages. Beginning with the third pass, the integrity of 593 this plaintext is ensured by incorporating the transcript checksum 594 into the derivation of the final reply key and second factor 595 encryption keys. Downgrade attacks on support and challenge messages 596 will result in the client and KDC deriving different reply keys and 597 EncryptedData keys. The KDC-REQ-BODY contents are also incorporated 598 into key derivation, ensuring their integrity. The unauthenticated 599 plaintext in the KDC-REP message is not protected by this mechanism. 601 Unless FAST is used, the factors field of a challenge message is not 602 integrity-protected until the response is verified. Second factor 603 types MUST account for this when specifying the semantics of the data 604 field. Second factor data in the challenge should not be included in 605 user prompts, as it could be modified by an attacker to contain 606 misleading or offensive information. 608 Subsequent factor data, including the data in the response, are 609 encrypted in a derivative of the shared secret K. Therefore, it is 610 not possible to exploit the untrustworthiness of challenge to turn 611 the client into an encryption or signing oracle, unless the attacker 612 knows the client's long-term key. 614 An implementation of this pre-authentication mechanism can have the 615 property of indistinguishability, meaning that an attacker who 616 guesses a long-term key and a second factor value cannot determine 617 whether one of the factors was correct unless both are correct. 618 Indistinguishability is only maintained if the second factor can be 619 validated solely based on the data in the response; the use of 620 additional round trips will reveal to the attacker whether the long- 621 term key is correct. Indistinguishability also requires that there 622 are no side channels. When processing a response message, whether or 623 not the KDC successfully decrypts the factor field, it must reply 624 with the same error fields, take the same amount of time, and make 625 the same observable communications to other servers. 627 Given that each EncryptedData will begin a new encryption context, a 628 failure to properly derive the encryption keys will result in a 629 situation where the risk of compromise is non-negligible. 631 Weak checksums present a risk to the transcript hash. Any etype with 632 a checksum based on one of the following algorithms MUST NOT be used: 634 o CRC32 636 o MD4 638 o MD5 640 Both the size of the EncryptedData and the number of EncryptedData 641 messages may reveal information about the second factor used in an 642 authentication. Care should be taken to keep second factor messages 643 as small and as few as possible. 645 A stateless KDC implementation generally must use a PA-FX-COOKIE 646 value to remember its private scalar value x and the transcript 647 checksum. The KDC MUST maintain confidentiality and integrity of the 648 cookie value, perhaps by encrypting it in a key known only to the 649 realm's KDCs. Cookie values may be replayed by attackers. The KDC 650 SHOULD limit the time window of replays using a timestamp, and SHOULD 651 prevent cookie values from being applied to other pre-authentication 652 mechanisms or other client principals. Within the validity period of 653 a cookie, an attacker can replay the final message of a pre- 654 authentication exchange to any of the realm's KDCs and make it appear 655 that the client has authenticated. 657 Any side channels in the creation of the shared secret input w, or in 658 the multiplications wM and wN, could allow an attacker to recover the 659 client long-term key. Implementations MUST take care to avoid side 660 channels, particularly timing channels. Generation of the secret 661 scalar values x and y need not take constant time, but the amount of 662 time taken MUST NOT provide information about the resulting value. 664 If an x or y value is reused for pre-authentications involving two 665 different client long-term keys, an attacker who observes both 666 authentications and knows one of the long-term keys can conduct an 667 offline dictionary attack to recover the other one. 669 This pre-authentication mechanism is not designed to provide forward 670 secrecy. Nevertheless, some measure of forward secrecy may result 671 depending on implementation choices. A passive attacker who 672 determines the client long-term key after the exchange generally will 673 not be able to recover the ticket session key; however, an attacker 674 who also determines the PA-FX-COOKIE encryption key (if the KDC uses 675 an encrypted cookie) will be able to recover the ticket session key. 676 The KDC can mitigate this risk by periodically rotating the cookie 677 encryption key. If the KDC or client retains the x or y value for 678 reuse with the same client long-term key, an attacker who recovers 679 the x or y value and the long-term key will be able to recover the 680 ticket session key. 682 Although this pre-authentication mechanism is designed to prevent an 683 offline dictionary attack by an active attacker posing as the KDC, 684 such an attacker can attempt to downgrade the client to encrypted 685 timestamp. Client implementations SHOULD provide a configuration 686 option to disable encrypted timestamp on a per-realm basis to 687 mitigate this attack. 689 Like any other pre-authentication mechanism using the client long- 690 term key, this pre-authentication mechanism does not prevent online 691 password guessing attacks. The KDC is made aware of unsuccessful 692 guesses, and can apply facilities such as password lockout to 693 mitigate the risk of online attacks. 695 Elliptic curve group operations are more computationally expensive 696 than secret-key operations. As a result, the use of this mechanism 697 may affect the KDC's performance under normal load and its resistance 698 to denial of service attacks. 700 The selected group's resistance to offline brute-force attacks may 701 not correspond to the brute-force resistance of the secret key 702 encryption type. For performance reasons, a KDC MAY select a group 703 whose brute-force resistance is weaker than the secret key. A 704 passive attacker who solves the group discrete logarithm problem 705 after the exchange will be able to conduct an offline attack against 706 the client long-term key. Although the use of password policies and 707 costly, salted string-to-key functions may increase the cost of such 708 an attack, the resulting cost will likely not be higher than the cost 709 of solving the group discrete logarithm. 711 This mechanism does not directly provide the KDC Authentication pre- 712 authentication facility, because it does not send a key confirmation 713 from the KDC to the client. When used as a stand-alone mechanism, 714 the traditional KDC authentication provided by the KDC-REP enc-part 715 still applies. 717 The conversion of the scalar multiplier for the SPAKE w parameter may 718 produce a multiplier that is larger than the order of the group. 719 Some group implementations may be unable to handle such a multiplier. 720 Others may silently accept such a multiplier, but proceed to perform 721 multiplication that is not constant time. This is a minor risk in 722 all known groups, but is a major risk for P-521 due to the extra 723 seven high bits in the input octet string. A common solution to this 724 problem is achieved by reducing the multiplier modulo the group 725 order, taking care to ensure constant time operation. 727 10. Assigned Constants 729 The following key usage values are assigned for this mechanism: 731 KEY_USAGE_SPAKE_TRANSCRIPT TBD 732 KEY_USAGE_SPAKE_FACTOR TBD 734 11. IANA Considerations 736 This document establishes two registries with the following 737 procedure, in accordance with [RFC5226]: 739 Registry entries are to be evaluated using the Specification Required 740 method. All specifications must be be published prior to entry 741 inclusion in the registry. There will be a three-week review period 742 by Designated Experts on the krb5-spake-review@ietf.org mailing list. 743 Prior to the end of the review, the Designated Experts must approve 744 or deny the request. This decision is to be conveyed to both the 745 IANA and the list, and should include reasonably detailed explanation 746 in the case of a denial as well as whether the request can be 747 resubmitted. 749 11.1. Kerberos Second Factor Types 751 This section species the IANA "Kerberos Second Factor Types" 752 registry. This registry records the number, name, implementation 753 requirements and reference for each second factor protocol. 755 11.1.1. Registration Template 757 ID Number: This is a value that uniquely identifies this entry. It 758 is a signed integer in range -2147483648 to 2147483647, inclusive. 759 Positive values must be assigned only for algorithms specified in 760 accordance with these rules for use with Kerberos and related 761 protocols. Negative values should be used for private and 762 experimental algorithms only. Zero is reserved and must not be 763 assigned. 765 Name: Brief, unique, human-readable name for this algorithm. 767 Implementation Requirements: The second factor implementation 768 requirements, which must be one of the words Required, 769 Recommended, Optional, Deprecated, or Prohibited. 771 Reference: URI or otherwise unique identifier for where the details 772 of this algorithm can be found. It should be as specific as 773 reasonably possible. 775 11.1.2. Initial Registry Contents 777 o ID Number: 1 778 o Name: NONE 779 o Implementation Requirements: Required 780 o Reference: this draft. 782 11.2. Kerberos SPAKE Groups 784 This section specifies the IANA "Kerberos SPAKE Groups" registry. 785 This registry records the number, name, implementation requirements, 786 specification, serialization, multiplier length, multiplier 787 conversion, SPAKE M constant and SPAKE N constant. 789 11.2.1. Registration Template 791 ID Number: This is a value that uniquely identifies this entry. It 792 is a signed integer in range -2147483648 to 2147483647, inclusive. 793 Positive values must be assigned only for algorithms specified in 794 accordance with these rules for use with Kerberos and related 795 protocols. Negative values should be used for private and 796 experimental use only. Zero is reserved and must not be assigned. 797 Values should be assigned in increasing order. 799 Name: Brief, unique, human readable name for this entry. 801 Implementation Requirements: The group implementation requirements, 802 which must be one of the words Required, Recommended, Optional, 803 Deprecated, or Prohibited. 805 Specification: Reference to the definition of the group parameters 806 and operations. 808 Serialization: Reference to the definition of the method used to 809 serialize group elements. 811 Multiplier Length: The length of the input octet string to 812 multiplication operations. 814 Multiplier Conversion: Reference to the definition of the method 815 used to convert an octet string to a multiplier scalar. 817 SPAKE M Constant: The serialized value of the SPAKE M constant in 818 hexadecimal notation. 820 SPAKE N Constant: The serialized value of the SPAKE N constant in 821 hexadecimal notation. 823 11.2.2. Initial Registry Contents 825 o ID Number: 1 826 o Name: P-256 827 o Implementation Requirements: Required 828 o Specification: [SEC2] section 2.4.2 829 o Serialization: [SEC1] section 2.3.3 (compressed). 830 o Multiplier Length: 32 831 o Multiplier Conversion: [SEC1] section 2.3.8. 832 o SPAKE M Constant: 833 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 834 o SPAKE N Constant: 835 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 837 o ID Number: 2 838 o Name: P-384 839 o Implementation Requirements: Optional 840 o Specification: [SEC2] section 2.5.1 841 o Serialization: [SEC1] section 2.3.3 (compressed). 842 o Multiplier Length: 48 843 o Multiplier Conversion: [SEC1] section 2.3.8. 844 o SPAKE M Constant: 845 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664 846 34b363d3dc36f15314739074d2eb8613fceec2853 847 o SPAKE N Constant: 848 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215 849 18f9c543bb252c5490214cf9aa3f0baab4b665c10 851 o ID Number: 3 852 o Name: P-521 853 o Implementation Requirements: Optional 854 o Specification: [SEC2] section 2.6.1 855 o Serialization: [SEC1] section 2.3.3 (compressed). 856 o Multiplier Length: 66 857 o Multiplier Conversion: [SEC1] section 2.3.8. 858 o SPAKE M Constant: 859 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1 860 8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5 861 6979962d7aa 862 o SPAKE N Constant: 863 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b 864 c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 865 9d95575cd25 867 12. References 869 12.1. Normative References 871 [CCITT.X680.2002] 872 International Telephone and Telegraph Consultative 873 Committee, "Abstract Syntax Notation One (ASN.1): 874 Specification of basic notation", CCITT Recommendation 875 X.680, July 2002. 877 [CCITT.X690.2002] 878 International Telephone and Telegraph Consultative 879 Committee, "ASN.1 encoding rules: Specification of basic 880 encoding Rules (BER), Canonical encoding rules (CER) and 881 Distinguished encoding rules (DER)", CCITT Recommendation 882 X.690, July 2002. 884 [I-D.irtf-cfrg-spake2] 885 Ladd, W., "SPAKE2, a PAKE", draft-irtf-cfrg-spake2-01 886 (work in progress), February 2015. 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 890 RFC2119, March 1997, 891 . 893 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 894 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 895 2005, . 897 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 898 Kerberos Network Authentication Service (V5)", RFC 4120, 899 DOI 10.17487/RFC4120, July 2005, 900 . 902 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 903 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 904 DOI 10.17487/RFC5226, May 2008, 905 . 907 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 908 Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/ 909 RFC6113, April 2011, 910 . 912 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 913 Elliptic Curve Cryptography", May 2009. 915 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 916 Recommended Elliptic Curve Domain Parameters", January 917 2010. 919 12.2. Non-normative References 921 [RFC6560] Richards, G., "One-Time Password (OTP) Pre- 922 Authentication", RFC 6560, DOI 10.17487/RFC6560, April 923 2012, . 925 [SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based 926 Encrypted Key Exchange Protocols", February 2005. 928 Appendix A. ASN.1 Module 930 KerberosV5SPAKE { 931 iso(1) identified-organization(3) dod(6) internet(1) 932 security(5) kerberosV5(2) modules(4) spake(8) 933 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 935 IMPORTS 936 EncryptedData, Int32 937 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 938 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 939 krb5spec2(2) }; 940 -- as defined in RFC 4120. 942 SPAKESupport ::= SEQUENCE { 943 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 944 ... 945 } 947 SPAKEChallenge ::= SEQUENCE { 948 group [0] Int32, 949 pubkey [1] OCTET STRING, 950 factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, 951 ... 952 } 954 SPAKESecondFactor ::= SEQUENCE { 955 type [0] Int32, 956 data [1] OCTET STRING OPTIONAL 957 } 959 SPAKEResponse ::= SEQUENCE { 960 pubkey [0] OCTET STRING, 961 factor [1] EncryptedData, -- SPAKESecondFactor 962 ... 963 } 965 PA-SPAKE ::= CHOICE { 966 support [0] SPAKESupport, 967 challenge [1] SPAKEChallenge, 968 response [2] SPAKEResponse, 969 encdata [3] EncryptedData, 970 ... 971 } 973 END 975 Appendix B. Acknowledgements 977 Nico Williams (Cryptonector) 978 Tom Yu (MIT) 980 Authors' Addresses 982 Nathaniel McCallum 983 Red Hat, Inc. 985 EMail: npmccallum@redhat.com 987 Simo Sorce 988 Red Hat, Inc. 990 EMail: ssorce@redhat.com 992 Robbie Harwood 993 Red Hat, Inc. 995 EMail: rharwood@redhat.com 997 Greg Hudson 998 MIT 1000 EMail: ghudson@mit.edu