idnits 2.17.1 draft-ietf-kitten-krb-spake-preauth-09.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 10, 2020) is 1415 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 1197 -- Looks like a reference, but probably isn't: '1' on line 1166 -- Looks like a reference, but probably isn't: '2' on line 1159 -- Looks like a reference, but probably isn't: '3' on line 1160 == Missing Reference: '-1' is mentioned on line 1195, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 3 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 12, 2020 Red Hat, Inc. 6 G. Hudson 7 MIT 8 June 10, 2020 10 SPAKE Pre-Authentication 11 draft-ietf-kitten-krb-spake-preauth-09 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 second factor 20 authentication without the need for a separately-established secure 21 channel. This is achieved using the existing trust relationship 22 established by the shared first factor. Third, make Kerberos pre- 23 authentication more resilient against time synchronization errors by 24 removing the need to transfer an encrypted 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 https://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 12, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 (https://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. PAKE Algorithm Selection . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10 75 4.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 11 76 4.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11 77 5. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 12 78 6. Transcript Hash . . . . . . . . . . . . . . . . . . . . . . . 12 79 7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 14 81 9. Hint for Authentication Sets . . . . . . . . . . . . . . . . 14 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 10.1. SPAKE Computations . . . . . . . . . . . . . . . . . . . 15 84 10.2. Unauthenticated Plaintext . . . . . . . . . . . . . . . 15 85 10.3. Side Channels . . . . . . . . . . . . . . . . . . . . . 16 86 10.4. KDC State . . . . . . . . . . . . . . . . . . . . . . . 17 87 10.5. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 17 88 10.6. Brute Force Attacks . . . . . . . . . . . . . . . . . . 18 89 10.7. Denial of Service Attacks . . . . . . . . . . . . . . . 18 90 10.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . 18 91 10.9. Reply-Key Encryption Type . . . . . . . . . . . . . . . 19 92 10.10. KDC Authentication . . . . . . . . . . . . . . . . . . . 19 93 11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 19 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 95 12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 20 96 12.1.1. Registration Template . . . . . . . . . . . . . . . 20 97 12.1.2. Initial Registry Contents . . . . . . . . . . . . . 20 98 12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 20 99 12.2.1. Registration Template . . . . . . . . . . . . . . . 21 100 12.2.2. Initial Registry Contents . . . . . . . . . . . . . 21 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 103 13.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 105 Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 26 106 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 107 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 110 1. Introduction 112 When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC 113 does not require pre-authentication), a passive attacker that 114 observes either the AS-REQ or AS-REP can perform an offline brute- 115 force attack against the transferred ciphertext. When the client 116 principal's long-term key is based on a password, offline dictionary 117 attacks can successfuly recover the key, with only modest effort 118 needed if the password is weak. 120 1.1. Properties of PAKE 122 Password authenticated key exchange (PAKE) algorithms provide several 123 properties which defend against offline dictionary attacks and make 124 them ideal for use as a Kerberos pre-authentication mechanism. 126 1. Each side of the exchange contributes entropy. 128 2. Passive attackers cannot determine the shared key. 130 3. Active attackers cannot perform a man-in-the-middle attack. 132 These properties of PAKE allow us to establish high-entropy 133 encryption keys resistant to offline brute force attack, even when 134 the passwords used are weak (low-entropy). 136 1.2. PAKE Algorithm Selection 138 The SPAKE algorithm (defined in Section 2) works by encrypting the 139 public keys of a Diffie-Hellman key exchange with a shared secret. 140 SPAKE was selected for this pre-authentication mechanism for the 141 following properties: 143 1. Because SPAKE's encryption method ensures that the result is a 144 member of the underlying group, it can be used with elliptic 145 curve cryptography, which is believed to provide equivalent 146 security levels to finite-field DH key exchange at much smaller 147 key sizes. 149 2. It can compute the shared key after just one message from each 150 party, minimizing the need for additional round trips and state. 152 3. It requires a small number of group operations, and can therefore 153 be implemented simply and efficiently. 155 1.3. PAKE and Two-Factor Authentication 157 Using PAKE in a pre-authentication mechanism also has another benefit 158 when used as a component of two-factor authentication (2FA). 2FA 159 methods often require the secure transfer of plaintext material to 160 the KDC for verification. This includes one-time passwords, 161 challenge/response signatures and biometric data. Encrypting this 162 data using the long-term secret results in packets that are 163 vulnerable to offline brute-force attack on the password, using 164 either an authentication tag or statistical properties of the 2FA 165 credentials to determine whether a password guess is correct. 167 In the OTP pre-authentication [RFC6560] specification, this problem 168 is mitigated by using FAST, which uses a secondary trust relationship 169 to create a secure encryption channel within which pre-authentication 170 data can be sent. However, the requirement for a secondary trust 171 relationship has proven to be cumbersome to deploy and often 172 introduces third parties into the trust chain (such as certification 173 authorities). These requirements make it difficult to enable FAST 174 without manual configuration of client hosts. SPAKE pre- 175 authentication, in contrast, can create a secure encryption channel 176 implicitly, using the key exchange to negotiate a high-entropy 177 encryption key. This key can then be used to securely encrypt 2FA 178 plaintext data without the need for a secondary trust relationship. 179 Further, if the second factor verifiers are sent at the same time as 180 the first factor verifier, and the KDC is careful to prevent timing 181 attacks, then an online brute-force attack cannot be used to attack 182 the factors separately. 184 For these reasons, this document departs from the advice given in 185 Section 1 of RFC 6113 [RFC6113] which states that "Mechanism 186 designers should design FAST factors, instead of new pre- 187 authentication mechanisms outside of FAST." However, this pre- 188 authentication mechanism does not intend to replace FAST, and may be 189 used with it to further conceal the metadata of the Kerberos 190 messages. 192 1.4. SPAKE Overview 194 The SPAKE algorithm can be broadly described in a series of four 195 steps: 197 1. Calculation and exchange of the public key 199 2. Calculation of the shared secret (K) 201 3. Derivation of an encryption key (K') 203 4. Verification of the derived encryption key (K') 205 In this mechanism, key verification happens implicitly by a 206 successful decryption of the 2FA data, or of a placeholder value when 207 no second factor is required. This mechanism uses a tailored method 208 of deriving encryption keys from the calculated shared secret K, for 209 several reasons: to fit within the framework of [RFC3961], to ensure 210 negotiation integrity using a transcript hash, to derive different 211 keys for each use, and to bind the KDC-REQ-BODY to the pre- 212 authentication exchange. 214 2. Document Conventions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 This document refers to numerous terms and protocol messages defined 223 in [RFC4120]. 225 The terms "encryption type", "key generation seed length", and 226 "random-to-key" are defined in [RFC3961]. 228 The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED", 229 "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "pre- 230 authentication facility", and "authentication set" are defined in 231 [RFC6113]. 233 The [SPAKE] paper defines SPAKE as a family of two key exchange 234 algorithms differing only in derivation of the final key. This 235 mechanism uses a derivation similar to the second algorithm (SPAKE2) 236 with differences in detail. For simplicity, this document refers to 237 the algorithm as "SPAKE". 239 The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and 240 [CCITT.X690.2002] respectively. 242 When discussing operations within algebraic groups, this document 243 uses additive notation (as described in Section 2.2 of [RFC6090]). 244 Group elements are denoted with uppercase letters, while scalar 245 multiplier values are denoted with lowercase letters. 247 3. Prerequisites 249 3.1. PA-ETYPE-INFO2 251 This mechanism requires the initial KDC pre-authentication state to 252 contain a singular reply key. Therefore, a KDC which offers SPAKE 253 pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE- 254 INFO2 value containing a single ETYPE-INFO2-ENTRY, following the 255 guidance in Section 2.1 of [RFC6113]. PA-ETYPE-INFO2 is specified in 256 Section 5.2.7.5 of [RFC4120]. 258 3.2. Cookie Support 260 KDCs which implement SPAKE pre-authentication MUST have some secure 261 mechanism for retaining state between AS-REQs. For stateless KDC 262 implementations, this method will most commonly be an encrypted PA- 263 FX-COOKIE. Clients which implement SPAKE pre-authentication MUST 264 support PA-FX-COOKIE, as described in Section 5.2 of [RFC6113]. 266 3.3. More Pre-Authentication Data Required 268 Both KDCs and clients which implement SPAKE pre-authentication MUST 269 support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described 270 in Section 5.2 of [RFC6113]. 272 4. SPAKE Pre-Authentication Message Protocol 274 This mechanism uses the reply key and provides the Client 275 Authentication and Strengthening Reply Key pre-authentication 276 facilities (Section 3 of [RFC6113]). When the mechanism completes 277 successfully, the client will have proved knowledge of the original 278 reply key and possibly a second factor, and the reply key will be 279 strengthened to a more uniform distribution based on the PAKE 280 exchange. This mechanism also ensures the integrity of the KDC-REQ- 281 BODY contents. This mechanism can be used in an authentication set; 282 no pa-hint value is required or defined. 284 This mechanism negotiates a choice of group for the SPAKE algorithm. 285 Groups are defined in the IANA "Kerberos SPAKE Groups" registry 286 created by this document. Each group definition specifies an 287 associated hash function, which will be used for transcript 288 protection and key derivation. Clients and KDCs MUST implement the 289 edwards25519 group, but MAY choose not to offer or accept it by 290 default. 292 This section will describe the flow of messages when performing SPAKE 293 pre-authentication. We will begin by explaining the most verbose 294 version of the protocol which all implementations MUST support. Then 295 we will describe several optional optimizations to reduce round- 296 trips. 298 Mechanism messages are communicated using PA-DATA elements within the 299 padata field of KDC-REQ messages or within the METHOD-DATA in the 300 e-data field of KRB-ERROR messages. All PA-DATA elements for this 301 mechanism MUST use the following padata-type: 303 PA-SPAKE 151 305 The padata-value for all PA-SPAKE PA-DATA values MUST be empty or 306 contain a DER encoding for the ASN.1 type PA-SPAKE. 308 PA-SPAKE ::= CHOICE { 309 support [0] SPAKESupport, 310 challenge [1] SPAKEChallenge, 311 response [2] SPAKEResponse, 312 encdata [3] EncryptedData, 313 ... 314 } 316 4.1. First Pass 318 The SPAKE pre-authentication exchange begins when the client sends an 319 initial authentication service request (AS-REQ) without pre- 320 authentication data. Upon receipt of this AS-REQ, a KDC which 321 requires pre-authentication and supports SPAKE SHOULD reply with a 322 KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty 323 PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA 324 elements). This message indicates to the client that the KDC 325 supports SPAKE pre-authentication. 327 4.2. Second Pass 329 Once the client knows that the KDC supports SPAKE pre-authentication 330 and the client desires to use it, the client will generate a new AS- 331 REQ message containing a PA-SPAKE PA-DATA element using the support 332 choice. This message indicates to the KDC which groups the client 333 prefers for the SPAKE operation. The group numbers are defined in 334 the IANA "Kerberos SPAKE Groups" registry created by this document. 336 The groups sequence is ordered from the most preferred group to the 337 least preferred group. 339 SPAKESupport ::= SEQUENCE { 340 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 341 ... 342 } 344 Upon receipt of the support message, the KDC will select a group. 345 The KDC SHOULD choose a group from the groups provided by the support 346 message. However, if the support message does not contain any group 347 that is supported by the KDC, the KDC MAY select another group in 348 hopes that the client might support it. Otherwise, the KDC MUST 349 respond with a KDC_ERR_PREAUTH_FAILED error. 351 The group selection determines the group order, which shall be a 352 large prime p multiplied by a small cofactor h (possibly 1), as well 353 as a generator P of a prime-order subgroup and two masking points M 354 and N. The KDC selects a random integer x in the range [0,h*p), 355 which MUST be divisible by h. The KDC computes a public key 356 T=x*P+w*M, where w is computed from the initial reply key according 357 to Section 5. 359 The KDC will reply to the client with a 360 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA- 361 DATA element using the challenge choice. 363 SPAKEChallenge ::= SEQUENCE { 364 group [0] Int32, 365 pubkey [1] OCTET STRING, 366 factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, 367 ... 368 } 370 The group field indicates the KDC-selected group used for all SPAKE 371 calculations as defined in the IANA "Kerberos SPAKE Groups" registry 372 created by this document. 374 The pubkey field indicates the KDC's public key T, serialized 375 according to Section 5. 377 The factors field contains an unordered list of second factors which 378 can be used to complete the authentication. Each second factor is 379 represented by a SPAKESecondFactor. 381 SPAKESecondFactor ::= SEQUENCE { 382 type [0] Int32, 383 data [1] OCTET STRING OPTIONAL 384 } 386 The type field is a unique integer which identifies the second factor 387 type. The factors field of SPAKEChallenge MUST NOT contain more than 388 one SPAKESecondFactor with the same type value. 390 The data field contains optional challenge data. The contents in 391 this field will depend upon the second factor type chosen. Note that 392 this challenge is initially transmitted as unauthenticated plaintext; 393 see Section 10.2. 395 The client and KDC will each initialize a transcript hash (Section 6) 396 using the hash function associated with the chosen group, and update 397 it with the concatenation of the DER-encoded PA-SPAKE messages sent 398 by the client and the KDC. 400 4.3. Third Pass 402 Upon receipt of the challenge message, the client observes which 403 group was selected by the KDC and deserializes the KDC's public key 404 T. The client selects a random integer y in the range [0,h*p), which 405 MUST be divisible by h. The client computes a public key S=y*P+w*N, 406 where w is computed from the initial reply key according to 407 Section 5. The client computes a shared group element K=y*(T-w*M). 409 The client will then choose one of the second factor types listed in 410 the factors field of the challenge message and gather whatever data 411 is required for the chosen second factor type, possibly using the 412 associated challenge data. Finally, the client will send an AS-REQ 413 containing a PA-SPAKE PA-DATA element using the response choice. 415 SPAKEResponse ::= SEQUENCE { 416 pubkey [0] OCTET STRING, 417 factor [1] EncryptedData, -- SPAKESecondFactor 418 ... 419 } 421 The client and KDC will update the transcript hash with the pubkey 422 value, and use the resulting hash for all encryption key derivations. 424 The pubkey field indicates the client's public key S, serialized 425 according to Section 5. 427 The factor field indicates the client's chosen second factor data. 428 The key for this field is K'[1] as specified in Section 7. The kvno 429 field of the EncryptedData sequence is omitted. The key usage number 430 for the encryption is KEY_USAGE_SPAKE. The plain text inside the 431 EncryptedData is an encoding of SPAKESecondFactor. Once decoded, the 432 SPAKESecondFactor contains the type of the second factor and any 433 optional data used. The contents of the data field will depend on 434 the second factor type chosen. The client MUST NOT send a response 435 containing a second factor type which was not listed in the factors 436 field of the challenge message. 438 When the KDC receives the response message from the client, it 439 deserializes the client's public key S, and computes the shared group 440 element K=x*(S-w*N). The KDC derives K'[1] and decrypts the factors 441 field. If decryption is successful, the first factor is successfully 442 validated. The KDC then validates the second factor. If either 443 factor fails to validate, the KDC SHOULD respond with a 444 KDC_ERR_PREAUTH_FAILED error. 446 If validation of the second factor requires further round-trips, the 447 KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 448 containing a PA-SPAKE PA-DATA element using the encdata choice. The 449 kvno field of the EncryptedData sequence is omitted. The key for the 450 EncryptedData value is K'[2] as specified in Section 7, and the key 451 usage number is KEY_USAGE_SPAKE. The plain text of this message 452 contains a DER-encoded SPAKESecondFactor message. As before, the 453 type field of this message will contain the second factor type, and 454 the data field will optionally contain second factor type specific 455 data. 457 KEY_USAGE_SPAKE 65 459 4.4. Subsequent Passes 461 Any number of additional round trips may occur using the encdata 462 choice. The contents of the plaintexts are specific to the second 463 factor type. If a client receives a PA-SPAKE PA-DATA element using 464 the encdata choice from the KDC, it MUST reply with a subsequent AS- 465 REQ with a PA-SPAKE PA-DATA using the encdata choice, or abort the AS 466 exchange. 468 The key for client-originated encdata messages in subsequent passes 469 is K'[3] as specified in Section 7 for the first subsequent pass, 470 K'[5] for the second, and so on. The key for KDC-originated encdata 471 messages is K'[4] for the first subsequent pass, K'[6] for the 472 second, and so on. 474 4.5. Reply Key Strengthening 476 When the KDC has successfully validated both factors, the reply key 477 is strengthened and the mechanism is complete. To strengthen the 478 reply key, the client and KDC replace it with K'[0] as specified in 479 Section 7. The KDC then replies with a KDC-REP message, or continues 480 on to the next mechanism in the authentication set. There is no 481 final PA-SPAKE PA-DATA message from the KDC to the client. 483 Reply key strengthening occurs only once at the end of the exchange. 484 The client and KDC MUST use the initial reply key as the base key for 485 all K'[n] derivations. 487 4.6. Optimizations 489 The full protocol has two possible optimizations. 491 First, the KDC MAY reply to the initial AS-REQ (containing no pre- 492 authentication data) with a PA-SPAKE PA-DATA element using the 493 challenge choice, instead of an empty padata-value. In this case, 494 the KDC optimistically selects a group which the client may not 495 support. If the group chosen by the challenge message is supported 496 by the client, the client MUST skip to the third pass by issuing an 497 AS-REQ with a PA-SPAKE message using the response choice. In this 498 case no SPAKESupport message is sent by the client, so the first 499 update to the transcript hash contains only the KDC's optimistic 500 challenge. If the KDC's chosen group is not supported by the client, 501 the client MUST continue to the second pass. In this case both the 502 client and KDC MUST reinitialize the transcript hash for the client's 503 support message. Clients MUST support this optimization. 505 Second, clients MAY skip the first pass and send an AS-REQ with a PA- 506 SPAKE PA-DATA element using the support choice. If the KDC accepts 507 the support message and generates a challenge, it MUST include a PA- 508 ETYPE-INFO2 value within the METHOD-DATA of the 509 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may 510 not otherwise be able to compute the initial reply key. If the KDC 511 cannot continue with SPAKE (either because initial reply key type is 512 incompatible with SPAKE or because it does not support any of the 513 client's groups) but can offer other pre-authentication mechanisms, 514 it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing 515 METHOD-DATA for the available mechanisms. A client supporting this 516 optimization MUST continue after a KDC_ERR_PREAUTH_FAILED error as 517 described in Section 2 of [RFC6113]. KDCs MUST support this 518 optimization. 520 5. SPAKE Parameters and Conversions 522 Group elements are converted to and from octet strings using the 523 serialization method defined in the IANA "Kerberos SPAKE Groups" 524 registry created by this document. 526 The SPAKE algorithm requires constants M and N for each group. These 527 constants are defined in the IANA "Kerberos SPAKE Groups" registry 528 created by this document. 530 The SPAKE algorithm requires a shared secret input w to be used as a 531 scalar multiplier. This value MUST be produced from the initial 532 reply key as follows: 534 1. Determine the length of the multiplier octet string as defined in 535 the IANA "Kerberos SPAKE Groups" registry created by this 536 document. 538 2. Compose a pepper string by concatenating the string "SPAKEsecret" 539 and the group number as a big-endian four-byte two's complement 540 binary number. 542 3. Produce an octet string of the required length using PRF+(K, 543 pepper), where K is the initial reply key and PRF+ is defined in 544 Section 5.1 of [RFC6113]. 546 4. Convert the octet string to a multiplier scalar using the 547 multiplier conversion method defined in the IANA "Kerberos SPAKE 548 Groups" registry created by this document. 550 The KDC chooses a secret scalar value x and the client chooses a 551 secret scalar value y. As required by the SPAKE algorithm, these 552 values are chosen randomly and uniformly. The KDC and client MUST 553 NOT reuse x or y values for authentications involving different 554 initial reply keys (see Section 10.4). 556 6. Transcript Hash 558 The transcript hash is an octet string of length equal to the output 559 length of the hash function associated with the selected group. The 560 initial value consists of all bits set to zero. 562 When the transcript hash is updated with an octet string input, the 563 new value is the hash function computed over the concatenation of the 564 old value and the input. 566 In the normal message flow or with the second optimization described 567 in Section 4.6, the transcript hash is first updated with the 568 concatenation of the client's support message and the KDC's 569 challenge, and then updated a second time with the client's pubkey 570 value. It therefore incorporates the client's supported groups, the 571 KDC's chosen group, the KDC's initial second-factor messages, and the 572 client and KDC public values. Once the transcript hash is finalized, 573 it is used without change for all key derivations (Section 7). In 574 particular, encrypted second-factor messages are not included in the 575 transcript hash. 577 If the first optimization described in Section 4.6 is used 578 successfully, the transcript hash is updated first with the KDC's 579 challenge message, and second with the client's pubkey value. 581 If first optimization is used unsuccessfully (i.e. the client does 582 not accept the KDC's selected group), the transcript hash is computed 583 as in the normal message flow, without including the KDC's optimistic 584 challenge. 586 7. Key Derivation 588 Implementations MUST NOT use the shared group element (denoted by K) 589 directly for any cryptographic operation. Instead, the SPAKE result 590 is used to derive keys K'[n] as defined in this section. 592 First, compute the hash function associated with the selected group 593 over the concatenation of the following values: 595 o The fixed string "SPAKEkey". 597 o The group number as a big-endian four-byte two's complement binary 598 number. 600 o The encryption type of the initial reply key as a big-endian four- 601 byte two's complement binary number. 603 o The PRF+ output used to compute the initial secret input w as 604 specified in Section 5. 606 o The SPAKE result K, converted to an octet string as specified in 607 Section 5. 609 o The transcript hash. 611 o The KDC-REQ-BODY encoding for the request being sent or responded 612 to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST 613 be used. 615 o The value n as a big-endian four-byte unsigned binary number. 617 o A single-byte block counter, with the initial value 0x01. 619 If the hash output is too small for the encryption type's key 620 generation seed length, the block counter value is incremented and 621 the hash function re-computed to produce as many blocks as are 622 required. The result is truncated to the key generation seed length, 623 and the random-to-key function is used to produce an intermediate key 624 with the same encryption type as the initial reply key. 626 The key K'[n] has the same encryption type as the initial reply key, 627 and has the value KRB-FX-CF2(initial-reply-key, intermediate-key, 628 "SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in Section 5.1 of 629 [RFC6113]. 631 8. Second Factor Types 633 This document defines one second factor type: 635 SF-NONE 1 637 This second factor type indicates that no second factor is used. 638 Whenever a SPAKESecondFactor is used with SF-NONE, the data field 639 MUST be omitted. The SF-NONE second factor always successfully 640 validates. 642 9. Hint for Authentication Sets 644 If a KDC offers SPAKE pre-authentication as part of an authentication 645 set (Section 5.3 of [RFC6113]), it MAY provide a pa-hint value 646 containing the DER encoding of the ASN.1 type PA-SPAKE-HINT, to help 647 the client determine whether SPAKE pre-authentication is likely to 648 succeed if the authentication set is chosen. 650 PA-SPAKE-HINT ::= SEQUENCE { 651 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 652 factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor 653 } 655 The groups field indicates the KDC's supported groups. The factors 656 field indicates the KDC's supported second factors. The KDC MAY omit 657 the data field of values in the factors list. 659 A KDC MUST NOT include a PA-SPAKE-HINT message directly in a pa-value 660 field; hints must only be provided within authentication sets. A KDC 661 SHOULD include a hint if SPAKE pre-authentication is offered as the 662 second or later element of an authentication set. 664 The PA-SPAKE-HINT message is not part of the transcript, and does not 665 replace any part of the SPAKE message flow. 667 10. Security Considerations 669 10.1. SPAKE Computations 671 The deserialized public keys S and T MUST be verified to be elements 672 of the group, to prevent invalid curve attacks. It is not necessary 673 to verify that they are members of the prime-order subgroup, as the 674 computation of K by both parties involves a multiplication by the 675 cofactor h. 677 The aforementioned cofactor multiplication is accomplished by 678 choosing private scalars x and y which are divisible by the cofactor. 679 If the client or KDC chooses a scalar which might not be divisible by 680 the cofactor, an attacker might be able to coerce values of K which 681 are not members of the prime-order subgroup, and deduce a limited 682 amount of information about w from the order of K. 684 The scalars x and y MUST be chosen uniformly, and must not be reused 685 for different initial reply keys. If an x or y value is reused for 686 pre-authentications involving two different initial reply keys, an 687 attacker who observes both authentications and knows one of the 688 initial reply keys can conduct an offline dictionary attack to 689 recover the other one. 691 The M and N values for a group MUST NOT have known discrete logs. An 692 attacker who knows the discrete log of M or N can perform an offline 693 dictionary attack on passwords. It is therefore important to 694 demonstrate that the M and N values for each group were computed 695 without multiplying a known value by the generator P. 697 10.2. Unauthenticated Plaintext 699 This mechanism includes unauthenticated plaintext in the support and 700 challenge messages. Beginning with the third pass, the integrity of 701 this plaintext is ensured by incorporating the transcript hash into 702 the derivation of the final reply key and second factor encryption 703 keys. Downgrade attacks on support and challenge messages will 704 result in the client and KDC deriving different reply keys and 705 EncryptedData keys. The KDC-REQ-BODY contents are also incorporated 706 into key derivation, ensuring their integrity. The unauthenticated 707 plaintext in the KDC-REP message is not protected by this mechanism. 709 Unless FAST is used, the factors field of a challenge message is not 710 integrity-protected until the response is verified. Second factor 711 types MUST account for this when specifying the semantics of the data 712 field. Second factor data in the challenge should not be included in 713 user prompts, as it could be modified by an attacker to contain 714 misleading or offensive information. 716 Unless FAST is used, the factors field of a challenge message is 717 visible to an attacker, who can use it to determine whether a second 718 factor is required for the client. 720 Subsequent factor data, including the data in the response, are 721 encrypted in a derivative of the shared secret K. Therefore, it is 722 not possible to exploit the untrustworthiness of the challenge to 723 turn the client into an encryption or signing oracle for the second 724 factor credentials, unless the attacker knows the client's long-term 725 key. 727 Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE 728 is advertised in authentication sets are unauthenticated, and are not 729 protected by the transcript hash. Since hints do not replace any 730 part of the message flow, manipulation of hint messages can only 731 affect the client's decision to use or not use an authentication set, 732 which could more easily be accomplished by removing authentication 733 sets entirely. 735 10.3. Side Channels 737 An implementation of this pre-authentication mechanism can have the 738 property of indistinguishability, meaning that an attacker who 739 guesses a long-term key and a second factor value cannot determine 740 whether one of the factors was correct unless both are correct. 741 Indistinguishability is only maintained if the second factor can be 742 validated solely based on the data in the response; the use of 743 additional round trips will reveal to the attacker whether the long- 744 term key is correct. Indistinguishability also requires that there 745 are no side channels. When processing a response message, whether or 746 not the KDC successfully decrypts the factor field, it must reply 747 with the same error fields, take the same amount of time, and make 748 the same observable communications to other servers. 750 Both the size of the EncryptedData and the number of EncryptedData 751 messages used for second-factor data (including the factor field of 752 the SPAKEResponse message and messages using the encdata PA-SPAKE 753 choice) may reveal information about the second factor used in an 754 authentication. Care should be taken to keep second factor messages 755 as small and as few as possible. 757 Any side channels in the creation of the shared secret input w, or in 758 the multiplications wM and wN, could allow an attacker to recover the 759 client long-term key. Implementations MUST take care to avoid side 760 channels, particularly timing channels. Generation of the secret 761 scalar values x and y need not take constant time, but the amount of 762 time taken MUST NOT provide information about the resulting value. 764 The conversion of the scalar multiplier for the SPAKE w parameter may 765 produce a multiplier that is larger than the order of the group. 766 Some group implementations may be unable to handle such a multiplier. 767 Others may silently accept such a multiplier, but proceed to perform 768 multiplication that is not constant time. This is only a minor risk 769 in most commonly-used groups, but is a more serious risk for P-521 770 due to the extra seven high bits in the input octet string. A common 771 solution to this problem is achieved by reducing the multiplier 772 modulo the group order, taking care to ensure constant time 773 operation. 775 10.4. KDC State 777 A stateless KDC implementation generally must use a PA-FX-COOKIE 778 value to remember its private scalar value x and the transcript hash. 779 The KDC MUST maintain confidentiality and integrity of the cookie 780 value, perhaps by encrypting it in a key known only to the realm's 781 KDCs. Cookie values may be replayed by attackers, perhaps splicing 782 them into different SPAKE exchanges. The KDC SHOULD limit the time 783 window of replays using a timestamp, and SHOULD prevent cookie values 784 from being applied to other pre-authentication mechanisms or other 785 client principals. Within the validity period of a cookie, an 786 attacker can replay the final message of a pre-authentication 787 exchange to any of the realm's KDCs and make it appear that the 788 client has authenticated. 790 This pre-authentication mechanism is not designed to provide forward 791 secrecy. Nevertheless, some measure of forward secrecy may result 792 depending on implementation choices. A passive attacker who 793 determines the client long-term key after the exchange generally will 794 not be able to recover the ticket session key; however, an attacker 795 who also determines the PA-FX-COOKIE encryption key (if the KDC uses 796 an encrypted cookie) will be able to recover the ticket session key. 797 The KDC can mitigate this risk by periodically rotating the cookie 798 encryption key. If the KDC or client retains the x or y value for 799 reuse with the same client long-term key, an attacker who recovers 800 the x or y value and the long-term key will be able to recover the 801 ticket session key. 803 10.5. Dictionary Attacks 805 Although this pre-authentication mechanism is designed to prevent an 806 offline dictionary attack by an active attacker posing as the KDC, 807 such an attacker can attempt to downgrade the client to encrypted 808 timestamp. Client implementations SHOULD provide a configuration 809 option to disable encrypted timestamp on a per-realm basis to 810 mitigate this attack. 812 If the user enters the wrong password, the client might fall back to 813 encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error 814 from the KDC, if encrypted timestamp is offered by the KDC and not 815 disabled by client configuration. This fallback will enable a 816 passive attacker to mount an offline dictionary attack against the 817 incorrect password, which may be similar to the correct password. 818 Client implementations SHOULD assume that encrypted timestamp and 819 encrypted challenge are unlikely to succeed if SPAKE pre- 820 authentication fails in the second pass and SF-NONE was used. 822 Like any other pre-authentication mechanism using the client long- 823 term key, this pre-authentication mechanism does not prevent online 824 password guessing attacks. The KDC is made aware of unsuccessful 825 guesses, and can apply facilities such as rate limiting to mitigate 826 the risk of online attacks. 828 10.6. Brute Force Attacks 830 The selected group's resistance to offline brute-force attacks may 831 not correspond to the size of the reply key. For performance 832 reasons, a KDC MAY select a group whose brute-force work factor is 833 less than the reply key length. A passive attacker who solves the 834 group discrete logarithm problem after the exchange will be able to 835 conduct an offline attack against the client long-term key. Although 836 the use of password policies and costly, salted string-to-key 837 functions may increase the cost of such an attack, the resulting cost 838 will likely not be higher than the cost of solving the group discrete 839 logarithm. 841 10.7. Denial of Service Attacks 843 Elliptic curve group operations are more computationally expensive 844 than secret-key operations. As a result, the use of this mechanism 845 may affect the KDC's performance under normal load and its resistance 846 to denial of service attacks. 848 10.8. Reflection Attacks 850 The encdata choice of PA-SPAKE can be used in either direction, and 851 the factor-specific plaintext does not necessarily indicate a 852 direction. However, each encdata message is encrypted using a 853 derived key K'[n], with client-originated messages using only odd 854 values of n and KDC-originated messages using only even values. An 855 attempted reflection attack would therefore result in a failed 856 decryption. 858 10.9. Reply-Key Encryption Type 860 This mechanism does not upgrade the encryption type of the initial 861 reply key, and relies on that encryption type for confidentiality, 862 integrity, and pseudo-random functions. If the client long-term key 863 uses a weak encryption type, an attacker might be able to subvert the 864 exchange, and the replaced reply key will also be of the same weak 865 encryption type. 867 10.10. KDC Authentication 869 This mechanism does not directly provide the KDC Authentication pre- 870 authentication facility, because it does not send a key confirmation 871 from the KDC to the client. When used as a stand-alone mechanism, 872 the traditional KDC authentication provided by the KDC-REP enc-part 873 still applies. 875 11. Assigned Constants 877 The following key usage values are assigned for this mechanism: 879 KEY_USAGE_SPAKE 65 881 12. IANA Considerations 883 IANA has assigned the following number for PA-SPAKE in the "Pre- 884 authentication and Typed Data" registry: 886 +----------+-------+-----------------+ 887 | Type | Value | Reference | 888 +----------+-------+-----------------+ 889 | PA-SPAKE | 151 | [this document] | 890 +----------+-------+-----------------+ 892 This document establishes two registries with the following 893 procedure, in accordance with [RFC8126]: 895 Registry entries are to be evaluated using the Specification Required 896 method. All specifications must be be published prior to entry 897 inclusion in the registry. Once published, they can be submitted 898 directly to the krb5-spake-review@ietf.org mailing list, where there 899 will be a three-week long review period by Designated Experts. 901 The Designated Experts ensure that the specification is publicly 902 available. It is sufficient to have an Internet-Draft (that is 903 posted and never published as an RFC) or a document from another 904 standards body, industry consortium, university site, etc. The 905 Designated Experts may provide additional in-depth reviews, but their 906 approval should not be taken as endorsement of the specification. 908 Prior to the end of the review period, the Designated Experts must 909 approve or deny the request. This decision is conveyed to both IANA 910 and the submitter. Since the mailing list archives are not public, 911 it should include both a reasonably detailed explanation in the case 912 of a denial as well as whether the request can be resubmitted. 914 IANA MUST only accept registry updates from the designated experts 915 and SHOULD direct all requests for registration to the review mailing 916 list. 918 12.1. Kerberos Second Factor Types 920 This section species the IANA "Kerberos Second Factor Types" 921 registry. This registry records the number, name, and reference for 922 each second factor protocol. 924 12.1.1. Registration Template 926 ID Number: This is a value that uniquely identifies this entry. It 927 is a signed integer in range -2147483648 to 2147483647, inclusive. 928 Positive values must be assigned only for algorithms specified in 929 accordance with these rules for use with Kerberos and related 930 protocols. Negative values should be used for private and 931 experimental algorithms only. Zero is reserved and must not be 932 assigned. 934 Name: Brief, unique, human-readable name for this algorithm. 936 Reference: URI or otherwise unique identifier for where the details 937 of this algorithm can be found. It should be as specific as 938 reasonably possible. 940 12.1.2. Initial Registry Contents 942 o ID Number: 1 943 o Name: SF-NONE 944 o Reference: this document. 946 12.2. Kerberos SPAKE Groups 948 This section specifies the IANA "Kerberos SPAKE Groups" registry. 949 This registry records the number, name, specification, serialization, 950 multiplier length, multiplier conversion, SPAKE M and N constants, 951 and associated hash function. 953 12.2.1. Registration Template 955 ID Number: This is a value that uniquely identifies this entry. It 956 is a signed integer in range -2147483648 to 2147483647, inclusive. 957 Positive values must be assigned only for algorithms specified in 958 accordance with these rules for use with Kerberos and related 959 protocols. Negative values should be used for private and 960 experimental use only. Zero is reserved and must not be assigned. 961 Values should be assigned in increasing order. 963 Name: Brief, unique, human readable name for this entry. 965 Specification: Reference to the definition of the group parameters 966 and operations. 968 Serialization: Reference to the definition of the method used to 969 serialize and deserialize group elements. 971 Multiplier Length: The length of the input octet string to 972 multiplication operations. 974 Multiplier Conversion: Reference to the definition of the method 975 used to convert an octet string to a multiplier scalar. 977 SPAKE M Constant: The serialized value of the SPAKE M constant in 978 hexadecimal notation. 980 SPAKE N Constant: The serialized value of the SPAKE N constant in 981 hexadecimal notation. 983 Hash Function: The group's associated hash function. 985 12.2.2. Initial Registry Contents 987 o ID Number: 1 988 o Name: edwards25519 989 o Specification: Section 4.1 of [RFC7748] (edwards25519) 990 o Serialization: Section 3.1 of [RFC8032] 991 o Multiplier Length: 32 992 o Multiplier Conversion: Section 3.1 of [RFC8032] 993 o SPAKE M Constant: 994 d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf 995 o SPAKE N Constant: 996 d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab 997 o Hash function: SHA-256 ([RFC6234]) 998 o ID Number: 2 999 o Name: P-256 1000 o Specification: Section 2.4.2 of [SEC2] 1001 o Serialization: Section 2.3.3 of [SEC1] (compressed format) 1002 o Multiplier Length: 32 1003 o Multiplier Conversion: Section 2.3.8 of [SEC1] 1004 o SPAKE M Constant: 1005 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 1006 o SPAKE N Constant: 1007 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 1008 o Hash function: SHA-256 ([RFC6234]) 1010 o ID Number: 3 1011 o Name: P-384 1012 o Specification: Section 2.5.1 of [SEC2] 1013 o Serialization: Section 2.3.3 of [SEC1] (compressed format) 1014 o Multiplier Length: 48 1015 o Multiplier Conversion: Section 2.3.8 of [SEC1] 1016 o SPAKE M Constant: 1017 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664 1018 34b363d3dc36f15314739074d2eb8613fceec2853 1019 o SPAKE N Constant: 1020 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215 1021 18f9c543bb252c5490214cf9aa3f0baab4b665c10 1022 o Hash function: SHA-384 ([RFC6234]) 1024 o ID Number: 4 1025 o Name: P-521 1026 o Specification: Section 2.6.1 of [SEC2] 1027 o Serialization: Section 2.3.3 of [SEC1] (compressed format) 1028 o Multiplier Length: 66 1029 o Multiplier Conversion: Section 2.3.8 of [SEC1] 1030 o SPAKE M Constant: 1031 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1 1032 8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5 1033 6979962d7aa 1034 o SPAKE N Constant: 1035 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b 1036 c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 1037 9d95575cd25 1038 o Hash function: SHA-512 ([RFC6234]) 1040 13. References 1041 13.1. Normative References 1043 [CCITT.X680.2002] 1044 International Telephone and Telegraph Consultative 1045 Committee, "Abstract Syntax Notation One (ASN.1): 1046 Specification of basic notation", CCITT Recommendation 1047 X.680, July 2002. 1049 [CCITT.X690.2002] 1050 International Telephone and Telegraph Consultative 1051 Committee, "ASN.1 encoding rules: Specification of basic 1052 encoding Rules (BER), Canonical encoding rules (CER) and 1053 Distinguished encoding rules (DER)", CCITT Recommendation 1054 X.690, July 2002. 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, 1058 DOI 10.17487/RFC2119, March 1997, 1059 . 1061 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 1062 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 1063 2005, . 1065 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1066 Kerberos Network Authentication Service (V5)", RFC 4120, 1067 DOI 10.17487/RFC4120, July 2005, 1068 . 1070 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 1071 Kerberos Pre-Authentication", RFC 6113, 1072 DOI 10.17487/RFC6113, April 2011, 1073 . 1075 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1076 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1077 DOI 10.17487/RFC6234, May 2011, 1078 . 1080 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1081 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1082 2016, . 1084 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1085 Signature Algorithm (EdDSA)", RFC 8032, 1086 DOI 10.17487/RFC8032, January 2017, 1087 . 1089 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1090 Writing an IANA Considerations Section in RFCs", BCP 26, 1091 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1092 . 1094 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1095 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1096 May 2017, . 1098 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 1099 Elliptic Curve Cryptography", May 2009. 1101 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 1102 Recommended Elliptic Curve Domain Parameters", January 1103 2010. 1105 13.2. Informative References 1107 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1108 Curve Cryptography Algorithms", RFC 6090, 1109 DOI 10.17487/RFC6090, February 2011, 1110 . 1112 [RFC6560] Richards, G., "One-Time Password (OTP) Pre- 1113 Authentication", RFC 6560, DOI 10.17487/RFC6560, April 1114 2012, . 1116 [SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based 1117 Encrypted Key Exchange Protocols", February 2005. 1119 Appendix A. ASN.1 Module 1121 KerberosV5SPAKE { 1122 iso(1) identified-organization(3) dod(6) internet(1) 1123 security(5) kerberosV5(2) modules(4) spake(8) 1124 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1126 IMPORTS 1127 EncryptedData, Int32 1128 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1129 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 1130 krb5spec2(2) }; 1131 -- as defined in RFC 4120. 1133 SPAKESupport ::= SEQUENCE { 1134 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 1135 ... 1136 } 1138 SPAKEChallenge ::= SEQUENCE { 1139 group [0] Int32, 1140 pubkey [1] OCTET STRING, 1141 factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, 1142 ... 1143 } 1145 SPAKESecondFactor ::= SEQUENCE { 1146 type [0] Int32, 1147 data [1] OCTET STRING OPTIONAL 1148 } 1150 SPAKEResponse ::= SEQUENCE { 1151 pubkey [0] OCTET STRING, 1152 factor [1] EncryptedData, -- SPAKESecondFactor 1153 ... 1154 } 1156 PA-SPAKE ::= CHOICE { 1157 support [0] SPAKESupport, 1158 challenge [1] SPAKEChallenge, 1159 response [2] SPAKEResponse, 1160 encdata [3] EncryptedData, 1161 ... 1162 } 1164 PA-SPAKE-HINT ::= SEQUENCE { 1165 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 1166 factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor 1168 } 1170 END 1172 Appendix B. SPAKE M and N Value Selection 1174 The M and N values for the initial contents of the SPAKE group 1175 registry were generated using the following Python snippet, which 1176 assumes an elliptic curve implementation following the interface of 1177 Edwards25519Point.stdbase() and Edwards448Point.stdbase() in 1178 Appendix A of [RFC8032]: 1180 def iterhash(seed, n): 1181 h = seed 1182 for i in range(n): 1183 h = hashlib.sha256(h).digest() 1184 return h 1186 def bighash(seed, start, sz): 1187 n = -(-sz // 32) 1188 hashes = [iterhash(seed, i) for i in range(start, start + n)] 1189 return b''.join(hashes)[:sz] 1191 def canon_pointstr(ecname, s): 1192 if ecname == 'edwards25519': 1193 return s 1194 elif ecname == 'edwards448': 1195 return s[:-1] + bytes([s[-1] & 0x80]) 1196 else: 1197 return bytes([(s[0] & 1) | 2]) + s[1:] 1199 def gen_point(seed, ecname, ec): 1200 for i in range(1, 1000): 1201 hval = bighash(seed, i, len(ec.encode())) 1202 pointstr = canon_pointstr(ecname, hval) 1203 try: 1204 p = ec.decode(pointstr) 1205 if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): 1206 return pointstr, i 1207 except Exception: 1208 pass 1210 The seed initial seed strings are: 1212 o For group 1 M: edwards25519 point generation seed (M) 1214 o For group 1 N: edwards25519 point generation seed (N) 1215 o For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M) 1217 o For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N) 1219 o For group 3 M: 1.3.132.0.34 point generation seed (M) 1221 o For group 3 N: 1.3.132.0.34 point generation seed (N) 1223 o For group 4 M: 1.3.132.0.35 point generation seed (M) 1225 o For group 4 N: 1.3.132.0.35 point generation seed (N) 1227 Appendix C. Test Vectors 1229 For the following text vectors: 1231 o The key is the string-to-key of "password" with the salt 1232 "ATHENA.MIT.EDUraeburn" for the designated initial reply key 1233 encryption type. 1235 o x and y were chosen randomly within the order of the designated 1236 group, then multiplied by the cofactor.. 1238 o The SPAKESupport message contains only the designated group's 1239 number. 1241 o The SPAKEChallenge message offers only the SF-NONE second factor 1242 type. 1244 o The KDC-REQ-BODY message contains no KDC options, the client 1245 principal name "raeburn@ATHENA.MIT.EDU", the server principal name 1246 "krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till 1247 field "19700101000000Z", the nonce zero, and an etype list 1248 containing only the designated encryption type. 1250 des3-cbc-sha1 edwards25519 1251 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1252 w (PRF+ output): 686d84730cb8679ae95416c6567c6a63 1253 f2c9cef124f7a3371ae81e11cad42a37 1254 w (reduced multiplier): a1f1a25cbd8e3092667e2fddba8ecd24 1255 f2c9cef124f7a3371ae81e11cad42a07 1256 x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723 1257 y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25 1258 X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e 1259 Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028 1260 T: 18f511e750c97b592acd30db7d9e5fca660389102e6bf610c1bfbed4616c8362 1261 S: 5d10705e0d1e43d5dbf30240ccfbde4a0230c70d4c79147ab0b317edad2f8ae7 1262 K: 25bde0d875f0feb5755f45ba5e857889d916ecf7476f116aa31dc3e037ec4292 1263 SPAKESupport: a0093007a0053003020101 1264 SPAKEChallenge: a1363034a003020101a122042018f511e750c97b592acd30 1265 db7d9e5fca660389102e6bf610c1bfbed4616c8362a20930 1266 073005a003020101 1267 Transcript hash after challenge: 22bb2271e34d329d52073c70b1d11879 1268 73181f0bc7614266bb79ee80d3335175 1269 Final transcript hash after pubkey: eaaa08807d0616026ff51c849efbf35b 1270 a0ce3c5300e7d486da46351b13d4605b 1271 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1272 1b077261656275726ea2101b0e415448454e412e4d49542e 1273 454455a3233021a003020102a11a30181b066b7262746774 1274 1b0e415448454e412e4d49542e454455a511180f31393730 1275 303130313030303030305aa703020100a8053003020110 1276 K'[0]: baf12fae7cd958cbf1a29bfbc71f89ce49e03e295d89dafd 1277 K'[1]: 64f73dd9c41908206bcec1f719026b574f9d13463d7a2520 1278 K'[2]: 0454520b086b152c455829e6baeff78a61dfe9e3d04a895d 1279 K'[3]: 4a92260b25e3ef94c125d5c24c3e5bced5b37976e67f25c4 1281 rc4-hmac edwards25519 1282 key: 8846f7eaee8fb117ad06bdd830b7586c 1283 w (PRF+ output): 7c86659d29cf2b2ea93bfe79c3cefb88 1284 50e82215b3ea6fcd896561d48048f49c 1285 w (reduced multiplier): 2713c1583c53861520b849bfef0525cd 1286 4fe82215b3ea6fcd896561d48048f40c 1287 x: c8a62e7b626f44cad807b2d695450697e020d230a738c5cd5691cc781dce8754 1288 y: 18fe7c1512708c7fd06db270361f04593775bc634ceaf45347e5c11c38aae017 1289 X: b0bcbbdd25aa031f4608d0442dd4924be7731d49c089a8301859d77343ffb567 1290 Y: 7d1ab8aeda1a2b1f9eab8d11c0fda60b616005d0f37d1224c5f12b8649f579a5 1291 T: 7db465f1c08c64983a19f560bce966fe5306c4b447f70a5bca14612a92da1d63 1292 S: 38f8d4568090148ebc9fd17c241b4cc2769505a7ca6f3f7104417b72b5b5cf54 1293 K: 03e75edd2cd7e7677642dd68736e91700953ac55dc650e3c2a1b3b4acdb800f8 1294 SPAKESupport: a0093007a0053003020101 1295 SPAKEChallenge: a1363034a003020101a12204207db465f1c08c64983a19f5 1296 60bce966fe5306c4b447f70a5bca14612a92da1d63a20930 1297 073005a003020101 1298 Transcript hash after challenge: 3cde9ed9b562a09d816885b6c225f733 1299 6d9e2674bb4df903dfc894d963a2af42 1300 Final transcript hash after pubkey: f4b208458017de6ef7f6a307d47d87db 1301 6c2af1d291b726860f68bc08bfef440a 1302 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1303 1b077261656275726ea2101b0e415448454e412e4d49542e 1304 454455a3233021a003020102a11a30181b066b7262746774 1305 1b0e415448454e412e4d49542e454455a511180f31393730 1306 303130313030303030305aa703020100a8053003020117 1307 K'[0]: 770b720c82384cbb693e85411eedecba 1308 K'[1]: 621deec88e2865837c4d3462bb50a1d5 1309 K'[2]: 1cc8f6333b9fa3b42662fd9914fbd5bb 1310 K'[3]: edb4032b7fc3806d5211a534dcbc390c 1311 aes128-cts-hmac-sha1-96 edwards25519 1312 key: fca822951813fb252154c883f5ee1cf4 1313 w (PRF+ output): 0d591b197b667e083c2f5f98ac891d3c 1314 9f99e710e464e62f1fb7c9b67936f3eb 1315 w (reduced multiplier): 17c2a9030afb7c37839bd4ae7fdfeb17 1316 9e99e710e464e62f1fb7c9b67936f30b 1317 x: 50be049a5a570fa1459fb9f666e6fd80602e4e87790a0e567f12438a2c96c138 1318 y: b877afe8612b406d96be85bd9f19d423e95be96c0e1e0b5824127195c3ed5917 1319 X: e73a443c678913eb4a0cad5cbd3086cf82f65a5a91b611e01e949f5c52efd6dd 1320 Y: 473c5b44ed2be9cb50afe1762b535b3930530489816ea6bd962622cccf39f6e8 1321 T: 9e9311d985c1355e022d7c3c694ad8d6f7ad6d647b68a90b0fe46992818002da 1322 S: fbe08f7f96cd5d4139e7c9eccb95e79b8ace41e270a60198c007df18525b628e 1323 K: c2f7f99997c585e6b686ceb62db42f17cc70932def3bb4cf009e36f22ea5473d 1324 SPAKESupport: a0093007a0053003020101 1325 SPAKEChallenge: a1363034a003020101a12204209e9311d985c1355e022d7c 1326 3c694ad8d6f7ad6d647b68a90b0fe46992818002daa20930 1327 073005a003020101 1328 Transcript hash after challenge: 4512310282c01b39dd9aebd0cc2a5e53 1329 2ed077a6c11d4c973c4593d525078797 1330 Final transcript hash after pubkey: 951285f107c87f0169b9c918a1f51f60 1331 cb1a75b9f8bb799a99f53d03add94b5f 1332 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1333 1b077261656275726ea2101b0e415448454e412e4d49542e 1334 454455a3233021a003020102a11a30181b066b7262746774 1335 1b0e415448454e412e4d49542e454455a511180f31393730 1336 303130313030303030305aa703020100a8053003020111 1337 K'[0]: 548022d58a7c47eae8c49dccf6baa407 1338 K'[1]: b2c9ba0e13fc8ab3a9d96b51b601cf4a 1339 K'[2]: 69f0ee5fdb6c237e7fcd38d9f87df1bd 1340 K'[3]: 78f91e2240b5ee528a5cc8d7cbebfba5 1342 aes256-cts-hmac-sha1-96 edwards25519 1343 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1344 w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3 1345 f2108f1b6aa97b381012b9400c9e3f4e 1346 w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060 1347 f2108f1b6aa97b381012b9400c9e3f0e 1348 x: 88c6c0a4f0241ef217c9788f02c32d00b72e4310748cd8fb5f94717607e6417d 1349 y: 88b859df58ef5c69bacdfe681c582754eaab09a74dc29cff50b328613c232f55 1350 X: 23c48eaff2721051946313840723b38f563c59b92043d6ffd752f95781af0327 1351 Y: 3d51486ec1d9be69bc45386bb675c013db87fd0488f6a9cacf6b43e8c81a0641 1352 T: 6f301aacae1220e91be42868c163c5009aeea1e9d9e28afcfc339cda5e7105b5 1353 S: 9e2cc32908fc46273279ec75354b4aeafa70c3d99a4d507175ed70d80b255dda 1354 K: cf57f58f6e60169d2ecc8f20bb923a8e4c16e5bc95b9e64b5dc870da7026321b 1355 SPAKESupport: a0093007a0053003020101 1356 SPAKEChallenge: a1363034a003020101a12204206f301aacae1220e91be428 1357 68c163c5009aeea1e9d9e28afcfc339cda5e7105b5a20930 1358 073005a003020101 1360 Transcript hash after challenge: 23a5e72eb4dedd1ca860f43736c458f0 1361 775c3bb1370a26af8a9374d521d70ec9 1362 Final transcript hash after pubkey: 1c605649d4658b58cbe79a5faf227acc 1363 16c355c58b7dade022f90c158fe5ed8e 1364 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1365 1b077261656275726ea2101b0e415448454e412e4d49542e 1366 454455a3233021a003020102a11a30181b066b7262746774 1367 1b0e415448454e412e4d49542e454455a511180f31393730 1368 303130313030303030305aa703020100a8053003020112 1369 K'[0]: a9bfa71c95c575756f922871524b6528 1370 8b3f695573ccc0633e87449568210c23 1371 K'[1]: 1865a9ee1ef0640ec28ac007391cac62 1372 4c42639c714767a974e99aa10003015f 1373 K'[2]: e57781513fefdb978e374e156b0da0c1 1374 a08148f5eb26b8e157ac3c077e28bf49 1375 K'[3]: 008e6487293c3cc9fabbbcdd8b392d6d 1376 cb88222317fd7fe52d12fbc44fa047f1 1378 aes256-cts-hmac-sha1-96 P-256 1379 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1380 w (PRF+ output): eb2984af18703f94dd5288b8596cd369 1381 88d0d4e83bfb2b44de14d0e95e2090bd 1382 w (reduced multiplier): eb2984af18703f94dd5288b8596cd369 1383 88d0d4e83bfb2b44de14d0e95e2090bd 1384 x: 935ddd725129fb7c6288e1a5cc45782198a6416d1775336d71eacd0549a3e80e 1385 y: e07405eb215663abc1f254b8adc0da7a16febaa011af923d79fdef7c42930b33 1386 X: 03bc802165aea7dbd98cc155056249fe0a37a9c203a7c0f7e872d5bf687bd105e2 1387 Y: 0340b8d91ce3852d0a12ae1f3e82c791fc86df6b346006431e968a1b869af7c735 1388 T: 024f62078ceb53840d02612195494d0d0d88de21feeb81187c71cbf3d01e71788d 1389 S: 021d07dc31266fc7cfd904ce2632111a169b7ec730e5f74a7e79700f86638e13c8 1390 K: 0268489d7a9983f2fde69c6e6a1307e9d252259264f5f2dfc32f58cca19671e79b 1391 SPAKESupport: a0093007a0053003020102 1392 SPAKEChallenge: a1373035a003020102a1230421024f62078ceb53840d0261 1393 2195494d0d0d88de21feeb81187c71cbf3d01e71788da209 1394 30073005a003020101 1395 Transcript hash after challenge: 0a142afca77c2e92b066572a90389eac 1396 40a6b1f1ed8b534d342591c0e7727e00 1397 Final transcript hash after pubkey: 20ad3c1a9a90fc037d1963a1c4bfb15a 1398 b4484d7b6cf07b12d24984f14652de60 1399 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1400 1b077261656275726ea2101b0e415448454e412e4d49542e 1401 454455a3233021a003020102a11a30181b066b7262746774 1402 1b0e415448454e412e4d49542e454455a511180f31393730 1403 303130313030303030305aa703020100a8053003020112 1404 K'[0]: 7d3b906f7be49932db22cd3463f032d0 1405 6c9c078be4b1d076d201fc6e61ef531e 1406 K'[1]: 17d74e36f8993841fbb7feb12fa4f011 1407 243d3ae4d2ace55b39379294bbc4db2c 1409 K'[2]: d192c9044081a2aa6a97a6c69e2724e8 1410 e5671c2c9ce073dd439cdbaf96d7dab0 1411 K'[3]: 41e5bad6b67f12c53ce0e2720dd6a988 1412 7f877bf9463c2d5209c74c36f8d776b7 1414 aes256-cts-hmac-sha1-96 P-384 1415 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1416 w (PRF+ output): 0304cfc55151c6bbe889653db96dbfe0ba4acafc024c1e88 1417 40cb3a486f6d80c16e1b8974016aa4b7fa43042a9b3825b1 1418 w (reduced multiplier): 0304cfc55151c6bbe889653db96dbfe0 1419 ba4acafc024c1e8840cb3a486f6d80c1 1420 6e1b8974016aa4b7fa43042a9b3825b1 1421 x: f323ca74d344749096fd35d0adf20806e521460637176e84d977e9933c49d76f 1422 cfc6e62585940927468ff53d864a7a50 1423 y: 5b7c709acb175a5afb82860deabca8d0b341facdff0ac0f1a425799aa905d750 1424 7e1ea9c573581a81467437419466e472 1425 X: 0211e3334f117b76635dd802d4022f601680a1fd066a56606b7f246493a10351 1426 7797b81789b225bd5bb1d9ae1da2962250 1427 Y: 0383dfa413496e5e7599fc8c6430f8d6910d37cf326d81421bc92c0939b555c4 1428 ca2ef6a993f6d3db8cb7407655ef60866e 1429 T: 02a1524603ef14f184696f854229d3397507a66c63f841ba748451056be07879 1430 ac298912387b1c5cdff6381c264701be57 1431 S: 020d5adfdb92bc377041cf5837412574c5d13e0f4739208a4f0c859a0a302bc6 1432 a533440a245b9d97a0d34af5016a20053d 1433 K: 0264aa8c61da9600dfb0beb5e46550d63740e4ef29e73f1a30d543eb43c25499 1434 037ad16538586552761b093cf0e37c703a 1435 SPAKESupport: a0093007a0053003020103 1436 SPAKEChallenge: a1473045a003020103a133043102a1524603ef14f184696f 1437 854229d3397507a66c63f841ba748451056be07879ac2989 1438 12387b1c5cdff6381c264701be57a20930073005a0030201 1439 01 1440 Transcript hash after challenge: 4d4095d9f94552e15015881a3f2cf458 1441 1be83217cf7ad830d2f051dba3ec8caa 1442 6e354eaa85738d7035317ac557f8c294 1443 Final transcript hash after pubkey: 5ac0d99ef9e5a73998797fe64f074673 1444 e3952dec4c7d1aacce8b75f64d2b0276 1445 a901cb8539b4e8ed69e4db0ce805b47b 1446 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1447 1b077261656275726ea2101b0e415448454e412e4d49542e 1448 454455a3233021a003020102a11a30181b066b7262746774 1449 1b0e415448454e412e4d49542e454455a511180f31393730 1450 303130313030303030305aa703020100a8053003020112 1451 K'[0]: b917d37c16dd1d8567fbe379f64e1ee3 1452 6ca3fd127aa4e60f97e4afa3d9e56d91 1453 K'[1]: 93d40079dab229b9c79366829f4e7e72 1454 82e6a4b943ac7bac69922d516673f49a 1455 K'[2]: bfc4f16f12f683e71589f9a888e23287 1456 5ef293ac9793db6c919567cd7b94bcd4 1458 K'[3]: 3630e2b5b99938e7506733141e8ec344 1459 166f6407e5fc2ef107c156e764d1bc20 1461 aes256-cts-hmac-sha1-96 P-521 1462 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1463 w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8 1464 2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45 1465 e85d1a5435d1c8c83662999722d542831f9a 1466 w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1 1467 caf95bc8425665d82370aff58b0471f3 1468 4cce63791cfed967f0c94c16054b3e17 1469 03133681bece1e05219f5426bc944b0f 1470 bfb3 1471 x: 017c38701a14b490b6081dfc83524562be7fbb42e0b20426465e3e37952d30bc 1472 ab0ed857010255d44936a1515607964a870c7c879b741d878f9f9cdf5a865306 1473 f3f5 1474 y: 003e2e2950656fa231e959acdd984d125e7fa59cec98126cbc8f3888447911eb 1475 cd49428a1c22d5fdb76a19fbeb1d9edfa3da6cf55b158b53031d05d51433ade9 1476 b2b4 1477 X: 03003e95272223b210b48cfd908b956a36add04a7ff443511432f94ddd87e064 1478 1d680ba3b3d532c21fa6046192f6bfae7af81c4b803aa154e12459d1428f8f2f 1479 56e9f2 1480 Y: 030064916687960df496557ecab08298bf075429eca268c6dabbae24e258d568 1481 c62841664dc8ecf545369f573ea84548faa22f118128c0a87e1d47315afabb77 1482 3bb082 1483 T: 02017d3de19a3ec53d0174905665ef37947d142535102cd9809c0dfbd0dfe007 1484 353d54cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc275adbd9675 1485 6696ec 1486 S: 02004d142d87477841f6ba053c8f651f3395ad264b7405ca5911fb9a55abd454 1487 fef658a5f9ed97d1efac68764e9092fa15b9e0050880d78e95fd03abf5931791 1488 6822b5 1489 K: 03007c303f62f09282cc849490805bd4457a6793a832cbeb55df427db6a31e99 1490 b055d5dc99756d24d47b70ad8b6015b0fb8742a718462ed423b90fa3fe631ac1 1491 3fa916 1492 SPAKESupport: a0093007a0053003020104 1493 SPAKEChallenge: a1593057a003020104a145044302017d3de19a3ec53d0174 1494 905665ef37947d142535102cd9809c0dfbd0dfe007353d54 1495 cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc2 1496 75adbd96756696eca20930073005a003020101 1497 Transcript hash after challenge: 554405860f8a80944228f1fa2466411d 1498 cf236162aa385e1289131b39e1fd59f2 1499 5e58b4c281ff059c28dc20f5803b87c6 1500 7571ce64cea01b39a21819d1ef1cdc7f 1501 Final transcript hash after pubkey: 8d6a89ae4d80cc4e47b6f4e48ea3e579 1502 19cc69598d0d3dc7c8bd49b6f1db1409 1503 ca0312944cd964e213aba98537041102 1504 237cff5b331e5347a0673869b412302e 1505 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1506 1b077261656275726ea2101b0e415448454e412e4d49542e 1507 454455a3233021a003020102a11a30181b066b7262746774 1508 1b0e415448454e412e4d49542e454455a511180f31393730 1509 303130313030303030305aa703020100a8053003020112 1510 K'[0]: 1eb3d10bee8fab483adcd3eb38f3ebf1 1511 f4feb8db96ecc035f563cf2e1115d276 1512 K'[1]: 482b92781ce57f49176e4c94153cc622 1513 fe247a7dbe931d1478315f856f085890 1514 K'[2]: a2c215126dd3df280aab5a27e1e0fb7e 1515 594192cbff8d6d8e1b6f1818d9bb8fac 1516 K'[3]: cc06603de984324013a01f888de6d43b 1517 410a4da2dea53509f30e433c352fb668 1519 aes256-cts-hmac-sha1-96 edwards25519, accepted optimistic challenge 1520 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1521 w (PRF+ output): e902341590a1b4bb4d606a1c643cccb3 1522 f2108f1b6aa97b381012b9400c9e3f4e 1523 w (reduced multiplier): 35b35ca126156b5bf4ec8b90e9545060 1524 f2108f1b6aa97b381012b9400c9e3f0e 1525 x: 70937207344cafbc53c8a55070e399c584cbafce00b836980dd4e7e74fad2a64 1526 y: 785d6801a2490df028903ac6449b105f2ff0db895b252953cdc2076649526103 1527 X: 13841224ea50438c1d9457159d05f2b7cd9d05daf154888eeed223e79008b47c 1528 Y: d01fc81d5ce20d6ea0939a6bb3e40ccd049f821baaf95e323a3657309ef75d61 1529 T: 83523b35f1565006cbfc4f159885467c2fb9bc6fe23d36cb1da43d199f1a3118 1530 S: 2a8f70f46cee9030700037b77f22cec7970dcc238e3e066d9d726baf183992c6 1531 K: d3c5e4266aa6d1b2873a97ce8af91c7e4d7a7ac456acced7908d34c561ad8fa6 1532 SPAKEChallenge: a1363034a003020101a122042083523b35f1565006cbfc4f 1533 159885467c2fb9bc6fe23d36cb1da43d199f1a3118a20930 1534 073005a003020101 1535 Transcript hash after challenge: 0332da8ba3095ccd127c51740cb905ba 1536 c76e90725e769570b9d8338e6d62a7f2 1537 Final transcript hash after pubkey: 26f07f9f8965307434d11ea855461d41 1538 e0cbabcc0a1bab48ecee0c6c1a4292b7 1539 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1540 1b077261656275726ea2101b0e415448454e412e4d49542e 1541 454455a3233021a003020102a11a30181b066b7262746774 1542 1b0e415448454e412e4d49542e454455a511180f31393730 1543 303130313030303030305aa703020100a8053003020112 1544 K'[0]: 4569ec08b5de5c3cc19d941725913ace 1545 8d74524b521a341dc746acd5c3784d92 1546 K'[1]: 0d96ce1a4ac0f2e280a0cfc31742b064 1547 61d83d04ae45433db2d80478dd882a4c 1548 K'[2]: 58018c19315a1ba5d5bb9813b58029f0 1549 aec18a6f9ca59e0847de1c60bc25945c 1550 K'[3]: ed7e9bffd68c54d86fb19cd3c03f317f 1551 88a71ad9a5e94c28581d93fc4ec72b6a 1553 aes256-cts-hmac-sha1-96 P-521, rejected edwards25519 challenge 1554 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1555 w (PRF+ output): de3a095a2b2386eff3eb15b735398da1caf95bc8425665d8 1556 2370aff58b0471f34a57bccddf1ebf0a2965b58a93ee5b45 1557 e85d1a5435d1c8c83662999722d542831f9a 1558 w (reduced multiplier): 003a095a2b2386eff3eb15b735398da1 1559 caf95bc8425665d82370aff58b0471f3 1560 4cce63791cfed967f0c94c16054b3e17 1561 03133681bece1e05219f5426bc944b0f 1562 bfb3 1563 x: 01687b59051bf40048d7c31d5a973d792fa12284b7a447e7f5938b5885ca0bb2 1564 c3f0bd30291a55fea08e143e2e04bdd7d19b753c7c99032f06cab0d9c2aa8f83 1565 7ef7 1566 y: 01ded675ebf74fe30c9a53710f577e9cf84f09f6048fe245a4600004884cc167 1567 733f9a9e43108fb83babe8754cd37cbd7025e28bc9ff870f084c7244f536285e 1568 25b4 1569 X: 03001bed88af987101ef52db5b8876f6287eb49a72163876c2cf99deb94f4c74 1570 9bfd118f0f400833cc8daad81971fe40498e6075d8ba0a2acfac35eb9ec8530e 1571 e0edd5 1572 Y: 02007bd3bf214200795ea449852976f241c9f50f445f78ff2714fffe42983f25 1573 cd9c9094ba3f9d7adadd6c251e9dc0991fc8210547e7769336a0ac406878fb94 1574 be2f1f 1575 T: 02014cb2e5b592ece5990f0ef30d308c061de1598bc4272b4a6599bed466fd15 1576 21693642abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03fb96ef5f1e 1577 d3e645 1578 S: 02016c64995e804416f748fd5fa3aa678cbc7cbb596a4f523132dc8af7ce84e5 1579 41f484a2c74808c6b21dcf7775baefa6753398425becc7b838b210ac5daa0cb0 1580 b710e2 1581 K: 0200997f4848ae2e7a98c23d14ac662030743ab37fccc2a45f1c721114f40bcc 1582 80fe6ec6aba49868f8aea1aa994d50e81b86d3e4d3c1130c8695b68907c673d9 1583 e5886a 1584 Optimistic SPAKEChallenge: a1363034a003020102a122042047ca8c 1585 24c3a4a70b6eca228322529dadcfa85c 1586 f58faceecf5d5c02907b9e2deba20930 1587 073005a003020101 1588 SPAKESupport: a0093007a0053003020104 1589 SPAKEChallenge: a1593057a003020104a145044302014cb2e5b592ece5990f 1590 0ef30d308c061de1598bc4272b4a6599bed466fd15216936 1591 42abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03 1592 fb96ef5f1ed3e645a20930073005a003020101 1593 Transcript hash after challenge: cb925b8baeae5e2867ab5b10ae1c941c 1594 4ff4b58a4812c1f7bd1c862ad480a8e1 1595 c6fcd5e88d846a2045e385841c91a75a 1596 d2035f0ff692717608e2a5a90842eff2 1597 Final transcript hash after pubkey: d0efed5e3e2c39c26034756d92a66fec 1598 3082ad793d0197f3f89ad36026f146a3 1599 996e548aa3fc49e2e82f8cac5d132c50 1600 5aa475b39e7be79cded22c26c41aa777 1601 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1602 1b077261656275726ea2101b0e415448454e412e4d49542e 1603 454455a3233021a003020102a11a30181b066b7262746774 1604 1b0e415448454e412e4d49542e454455a511180f31393730 1605 303130313030303030305aa703020100a8053003020112 1606 K'[0]: 631fcc8596e7f40e59045950d72aa0b7 1607 bac2810a07b767050e983841cf3a2d4c 1608 K'[1]: 881464920117074dbc67155a8f3341d1 1609 121ef65f78ea0380bfa81a134c1c47b1 1610 K'[2]: 377b72ac3af2caad582d73ae4682fd56 1611 b531ee56706200dd6c38c42b8219837a 1612 K'[3]: 35ad8e4d580ed3f0d15ad928329773c0 1613 81bd19f9a56363f3a5f77c7e66108c26 1615 There are currently no encryption types with a seed size large enough 1616 to require multiple hash blocks during key derivation with any of the 1617 assigned hash functions. To exercise this possibility, the following 1618 test vector illustrates what keys would be derived if there were a 1619 copy of the edwards25519 group with group number -1 and associated 1620 hash function SHA-1: 1622 AES256 edwards25519 SHA-1 group number -1 1623 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1624 w (PRF+ output): 26da6b118cee6fa5ea795ed32d61490d 1625 82b2f11102312f3f2fc04fb01c93df91 1626 w (reduced multiplier): d166c7cc9e72ca8c61f6a9185a987251 1627 81b2f11102312f3f2fc04fb01c93df01 1628 x: 606c1b668008ed78fe2eee942e8f08007f3f1dcbef66d37fd69033525bda2030 1629 y: 10fc4e0bb1a902e58f632a1ea0bceb366360ac985f46996d956a02572bfcf050 1630 X: 389621509665abad35eaab26eab3a0f593c7b4380562aa5513c1140fd78ce048 1631 Y: de3ed05986eeac518958b566f9bad065b321402025cd188f3d198dc55c6d6b8d 1632 T: 2289a4f3c613e6e1df95e94aaa3c127dc062b9fceec3f9b62378dc729d61d0e3 1633 S: f9a7fa352930dedb422d567700bfcd39ba221e7f9ac3e6b36f2b63b68b88642c 1634 K: 6f61d6b18323b6c3ddaac7c56712845335384f095d3e116f69feb926a04f1340 1635 SPAKESupport: a0093007a00530030201ff 1636 SPAKEChallenge: a1363034a0030201ffa12204202289a4f3c613e6e1df95e9 1637 4aaa3c127dc062b9fceec3f9b62378dc729d61d0e3a20930 1638 073005a003020101 1639 Transcript hash after challenge: f5c051eb75290f92142c 1640 bbe80557ec2c85902c94 1641 Final transcript hash after pubkey: 9e26a3b148400c8f9cb8 1642 545331e4e7dcab399cc0 1643 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1644 1b077261656275726ea2101b0e415448454e412e4d49542e 1645 454455a3233021a003020102a11a30181b066b7262746774 1646 1b0e415448454e412e4d49542e454455a511180f31393730 1647 303130313030303030305aa703020100a8053003020112 1648 K'[0]: 40bceb51bba474fd29ae65950022b704 1649 17b80d973fa8d8d6cd39833ff89964ad 1650 K'[1]: c29a7315453dc1cce938fa12a9e5c0db 1651 2894b2194da14c9cd4f7bc3a6a37223d 1652 K'[2]: f261984dba3c230fad99d324f871514e 1653 5aad670e44f00daef3264870b0851c25 1654 K'[3]: d24b2b46bab7c4d1790017d9116a7eeb 1655 ca88b0562a5ad8989c826cb7dab715c7 1657 Appendix D. Acknowledgements 1659 Nico Williams (Cryptonector) 1660 Taylor Yu (MIT) 1662 Authors' Addresses 1664 Nathaniel McCallum 1665 Red Hat, Inc. 1667 EMail: npmccallum@redhat.com 1668 Simo Sorce 1669 Red Hat, Inc. 1671 EMail: ssorce@redhat.com 1673 Robbie Harwood 1674 Red Hat, Inc. 1676 EMail: rharwood@redhat.com 1678 Greg Hudson 1679 MIT 1681 EMail: ghudson@mit.edu