idnits 2.17.1 draft-ietf-kitten-krb-spake-preauth-03.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3961, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3961, updated by this document, for RFC5378 checks: 2002-01-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2017) is 2332 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 1044 -- Looks like a reference, but probably isn't: '1' on line 1045 -- Looks like a reference, but probably isn't: '2' on line 1046 -- Looks like a reference, but probably isn't: '3' on line 1047 == 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) ** 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 Updates: 3961 (if approved) R. Harwood 5 Intended status: Standards Track Red Hat, Inc. 6 Expires: June 3, 2018 G. Hudson 7 MIT 8 November 30, 2017 10 SPAKE Pre-Authentication 11 draft-ietf-kitten-krb-spake-preauth-03 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 relying on FAST. This is achieved 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 June 3, 2018. 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. 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. Update to Checksum Specifications . . . . . . . . . . . . . . 6 71 5. SPAKE Pre-Authentication Message Protocol . . . . . . . . . . 7 72 5.1. First Pass . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.2. Second Pass . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.3. Third Pass . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.4. Subsequent Passes . . . . . . . . . . . . . . . . . . . . 10 76 5.5. Reply Key Strengthening . . . . . . . . . . . . . . . . . 10 77 5.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 11 78 6. SPAKE Parameters and Conversions . . . . . . . . . . . . . . 11 79 7. Transcript Checksum . . . . . . . . . . . . . . . . . . . . . 12 80 8. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. Second Factor Types . . . . . . . . . . . . . . . . . . . . . 14 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 10.1. Unauthenticated Plaintext . . . . . . . . . . . . . . . 14 84 10.2. Side Channels . . . . . . . . . . . . . . . . . . . . . 14 85 10.3. KDC State . . . . . . . . . . . . . . . . . . . . . . . 15 86 10.4. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 16 87 10.5. Brute Force Attacks . . . . . . . . . . . . . . . . . . 16 88 10.6. Denial of Service Attacks . . . . . . . . . . . . . . . 17 89 10.7. Reply-Key Encryption Type . . . . . . . . . . . . . . . 17 90 10.8. KDC Authentication . . . . . . . . . . . . . . . . . . . 17 91 11. Assigned Constants . . . . . . . . . . . . . . . . . . . . . 17 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 12.1. Kerberos Second Factor Types . . . . . . . . . . . . . . 18 94 12.1.1. Registration Template . . . . . . . . . . . . . . . 18 95 12.1.2. Initial Registry Contents . . . . . . . . . . . . . 18 97 12.2. Kerberos SPAKE Groups . . . . . . . . . . . . . . . . . 18 98 12.2.1. Registration Template . . . . . . . . . . . . . . . 19 99 12.2.2. Initial Registry Contents . . . . . . . . . . . . . 19 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 13.2. Non-normative References . . . . . . . . . . . . . . . . 22 103 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 23 104 Appendix B. SPAKE M and N Value Selection . . . . . . . . . . . 24 105 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 24 106 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 31 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 109 1. Introduction 111 When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC 112 does not require preauthentication), a passive attacker that observes 113 either the AS-REQ or AS-REP can perform an offline brute-force attack 114 against the transferred ciphertext. When the client principal's 115 long-term key is based on a password, offline dictionary attacks can 116 successfuly recover the key, with only modest effort needed if the 117 password is weak. 119 1.1. Properties of PAKE 121 Password authenticated key exchange (PAKE) algorithms provide several 122 properties which are useful to overcome this problem and make them 123 ideal for use as a Kerberos pre-authentication mechanism. 125 1. Each side of the exchange contributes entropy. 127 2. Passive attackers cannot determine the shared key. 129 3. Active attackers cannot perform a man-in-the-middle attack. 131 These properties of PAKE allow us to establish high-entropy 132 encryption keys resistant to offline brute force attack, even when 133 the passwords used are weak (low-entropy). 135 1.2. PAKE Algorithm Selection 137 The SPAKE algorithm works by encrypting the public keys of a Diffie- 138 Hellman key exchange with a shared secret. SPAKE was selected for 139 this pre-authentication mechanism for the following properties: 141 1. Because SPAKE's encryption method ensures that the result is a 142 member of the underlying group, it can be used with elliptic 143 curve cryptography, which is believed to provide equivalent 144 security levels to finite-field DH key exchange at much smaller 145 key sizes. 147 2. It can compute the shared key after just one message from each 148 party. 150 3. It requires a small number of group operations, and can therefore 151 be implemented simply and efficiently. 153 1.3. PAKE and Two-Factor Authentication 155 Using PAKE in a pre-authentication mechanism also has another benefit 156 when used as a component of two-factor authentication (2FA). 2FA 157 methods often require the secure transfer of plaintext material to 158 the KDC for verification. This includes one-time passwords, 159 challenge/response signatures and biometric data. Attempting to 160 encrypt this data using the long-term secret results in packets that 161 are vulnerable to offline brute-force attack if either authenticated 162 encryption is used or if the plaintext is distinguishable from random 163 data. This is a problem that PAKE solves for first factor 164 authentication. So a similar technique can be used with PAKE to 165 encrypt second-factor data. 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 lead to a scenario where FAST 174 cannot be enabled by default without sufficient configuration. SPAKE 175 pre-authentication, in contrast, can create a secure encryption 176 channel implicitly, using the key exchange to negotiate a high- 177 entropy encryption key. This key can then be used to securely 178 encrypt 2FA plaintext data without the need for a secondary trust 179 relationship. Further, if the second factor verifiers are sent at 180 the same time as the first factor verifier, and the KDC is careful to 181 prevent timing attacks, then an online brute-force attack cannot be 182 used to attack the factors separately. 184 For these reasons, this draft 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 Higher level protocols must define their own verification step. In 206 the case of this mechanism, verification happens implicitly by a 207 successful decryption of the 2FA data. 209 This mechanism provides its own method of deriving encryption keys 210 from the calculated shared secret K, for several reasons: to fit 211 within the framework of [RFC3961], to ensure negotiation integrity 212 using a transcript checksum, to derive different keys for each use, 213 and to bind the KDC-REQ-BODY to the pre-authentication exchange. 215 2. Document Conventions 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in [RFC2119]. 221 This document refers to numerous terms and protocol messages defined 222 in [RFC4120]. 224 The terms "encryption type", "required checksum mechanism", and 225 "get_mic" are defined in [RFC3961]. 227 The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED", 228 "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED", "pre- 229 authentication facility", and "authentication set" are defined in 230 [RFC6113]. 232 The [SPAKE] paper defines SPAKE as a family of two key exchange 233 algorithms differing only in derivation of the final key. This 234 mechanism uses a derivation similar to the second algorithm (SPAKE2) 235 with differences in detail. For simplicity, this document refers to 236 the algorithm as "SPAKE". The normative reference for this algorithm 237 is [I-D.irtf-cfrg-spake2]. 239 The terms "ASN.1" and "DER" are defined in [CCITT.X680.2002] and 240 [CCITT.X690.2002] respectively. 242 3. Prerequisites 244 3.1. PA-ETYPE-INFO2 246 This mechanism requires the initial KDC pre-authentication state to 247 contain a singular reply key. Therefore, a KDC which offers SPAKE 248 pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE- 249 INFO2 value containing a single ETYPE-INFO2-ENTRY, as described in 250 [RFC6113] section 2.1. PA-ETYPE-INFO2 is specified in [RFC4120] 251 section 5.2.7.5. 253 3.2. Cookie Support 255 KDCs which implement SPAKE pre-authentication MUST have some secure 256 mechanism for retaining state between AS-REQs. For stateless KDC 257 implementations, this method will most commonly be an encrypted PA- 258 FX-COOKIE. Clients which implement SPAKE pre-authentication MUST 259 support PA-FX-COOKIE, as described in [RFC6113] section 5.2. 261 3.3. More Pre-Authentication Data Required 263 Both KDCs and clients which implement SPAKE pre-authentication MUST 264 support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described 265 in [RFC6113] section 5.2. 267 4. Update to Checksum Specifications 269 [RFC3961] section 4 specifies the Kerberos checksum algorithm 270 profile. It does not require checksums to be deterministic. In 271 practice, DES-based checksum types (deprecated by [RFC6649]) use a 272 random confounder; all other current checksum types are 273 deterministic. 275 Future checksum types required by an encryption type MUST be 276 deterministic. All future checksum types SHOULD be deterministic. 278 This mechanism requires a deterministic checksum type for the 279 transcript checksum. Therefore, a KDC MUST NOT offer this mechanism 280 if the initial reply key is of type des-cbc-crc, des-cbc-md4, or des- 281 cbc-md5. 283 5. SPAKE Pre-Authentication Message Protocol 285 This mechanism uses the reply key and provides the Client 286 Authentication and Strengthening Reply Key pre-authentication 287 facilities ([RFC6113] section 3). When the mechanism completes 288 successfully, the client will have proved knowledge of the original 289 reply key and possibly a second factor, and the reply key will be 290 strengthened to a more uniform distribution based on the PAKE 291 exchange. This mechanism also ensures the integrity of the KDC-REQ- 292 BODY contents. This mechanism can be used in an authentication set; 293 no pa-hint value is required or defined. 295 This mechanism negotiates a choice of group for the SPAKE algorithm. 296 Groups are defined in the IANA "Kerberos SPAKE Groups" registry 297 created by this document. Clients and KDCs MUST implement the 298 edwards25519 group, but MAY choose not to offer or accept it by 299 default. 301 This section will describe the flow of messages when performing SPAKE 302 pre-authentication. We will begin by explaining the most verbose 303 version of the protocol which all implementations MUST support. Then 304 we will describe several optional optimizations to reduce round- 305 trips. 307 Mechanism messages are communicated using PA-DATA elements within the 308 padata field of KDC-REQ messages or within the METHOD-DATA in the 309 e-data field of KRB-ERROR messages. All PA-DATA elements for this 310 mechanism MUST use the following padata-type: 312 PA-SPAKE TBD 314 The padata-value for all PA-SPAKE PA-DATA values MUST be empty or 315 contain a DER encoding for the ASN.1 type PA-SPAKE. 317 PA-SPAKE ::= CHOICE { 318 support [0] SPAKESupport, 319 challenge [1] SPAKEChallenge, 320 response [2] SPAKEResponse, 321 encdata [3] EncryptedData, 322 ... 323 } 325 5.1. First Pass 327 The SPAKE pre-authentication exchange begins when the client sends an 328 initial authentication service request (AS-REQ) without pre- 329 authentication data. Upon receipt of this AS-REQ, a KDC which 330 requires pre-authentication and supports SPAKE SHOULD reply with a 331 KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty 332 PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA 333 elements). This message indicates to the client that the KDC 334 supports SPAKE pre-authentication. 336 5.2. Second Pass 338 Once the client knows that the KDC supports SPAKE pre-authentication 339 and the client desires to use it, the client will generate a new AS- 340 REQ message containing a PA-SPAKE PA-DATA element using the support 341 choice. This message indicates to the KDC which groups the client 342 prefers for the SPAKE operation. The group numbers are defined in 343 the IANA "Kerberos SPAKE Groups" registry created by this document. 344 The groups sequence is ordered from the most preferred group to the 345 least preferred group. 347 SPAKESupport ::= SEQUENCE { 348 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 349 ... 350 } 352 The client and KDC initialize a transcript checksum (Section 7) and 353 update it with the DER-encoded PA-SPAKE message. 355 Upon receipt of the support message, the KDC will select a group. 356 The KDC SHOULD choose a group from the groups provided by the support 357 message. However, if the support message does not contain any group 358 that is supported by the KDC, the KDC MAY select another group in 359 hopes that the client might support it. Otherwise, the KDC MUST 360 respond with a KDC_ERR_PREAUTH_FAILED error. 362 Once the KDC has selected a group, the KDC will reply to the client 363 with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE 364 PA-DATA element using the challenge choice. The client and KDC 365 update the transcript checksum with the DER-encoded PA-SPAKE message. 367 SPAKEChallenge ::= SEQUENCE { 368 group [0] Int32, 369 pubkey [1] OCTET STRING, 370 factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, 371 ... 372 } 374 The group field indicates the KDC-selected group used for all SPAKE 375 calculations as defined in the IANA "Kerberos SPAKE Groups" registry 376 created by this document. 378 The pubkey field indicates the KDC's public key generated using the M 379 constant in the SPAKE algorithm, with inputs and conversions as 380 specified in Section 6. 382 The factors field contains an unordered list of second factors which 383 can be used to complete the authentication. Each second factor is 384 represented by a SPAKESecondFactor. 386 SPAKESecondFactor ::= SEQUENCE { 387 type [0] Int32, 388 data [1] OCTET STRING OPTIONAL 389 } 391 The type field is a unique integer which identifies the second factor 392 type. The factors field of SPAKEChallenge MUST NOT contain more than 393 one SPAKESecondFactor with the same type value. 395 The data field contains optional challenge data. The contents in 396 this field will depend upon the second factor type chosen. 398 5.3. Third Pass 400 Upon receipt of the challenge message, the client will complete its 401 part of of the SPAKE algorithm, generating a public key and computing 402 the shared secret K. The client will then choose one of the second 403 factor types listed in the factors field of the challenge message and 404 gather whatever data is required for the chosen second factor type, 405 possibly using the associated challenge data. Finally, the client 406 will send an AS-REQ containing a PA-SPAKE PA-DATA element using the 407 response choice. 409 SPAKEResponse ::= SEQUENCE { 410 pubkey [0] OCTET STRING, 411 factor [1] EncryptedData, -- SPAKESecondFactor 412 ... 413 } 415 The client and KDC will update the transcript checksum with the 416 pubkey value, and use the resulting checksum for all encryption key 417 derivations. 419 The pubkey field indicates the client's public key generated using 420 the N constant in the SPAKE algorithm, with inputs and conversions as 421 specified in Section 6. 423 The factor field indicates the client's chosen second factor data. 424 The key for this field is K'[1] as specified in Section 8. The key 425 usage number for the encryption is KEY_USAGE_SPAKE_FACTOR. The plain 426 text inside the EncryptedData is an encoding of SPAKESecondFactor. 427 Once decoded, the SPAKESecondFactor contains the type of the second 428 factor and any optional data used. The contents of the data field 429 will depend on the second factor type chosen. The client MUST NOT 430 send a response containing a second factor type which was not listed 431 in the factors field of the challenge message. 433 When the KDC receives the response message from the client, it will 434 use the pubkey to compute the SPAKE result, derive K'[1], and decrypt 435 the factors field. If decryption is successful, the first factor is 436 successfully validated. The KDC then validates the second factor. 437 If either factor fails to validate, the KDC SHOULD respond with a 438 KDC_ERR_PREAUTH_FAILED error. 440 If validation of the second factor requires further round-trips, the 441 KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 442 containing a PA-SPAKE PA-DATA element using the encdata choice. The 443 key for the EncryptedData value is K'[2] as specified in Section 8, 444 and the key usage number is KEY_USAGE_SPAKE_FACTOR. The plain text 445 of this message contains a DER-encoded SPAKESecondFactor message. As 446 before, the type field of this message will contain the second factor 447 type, and the data field will optionally contain second factor type 448 specific data. 450 KEY_USAGE_SPAKE_FACTOR 65 452 5.4. Subsequent Passes 454 Any number of additional round trips may occur using the encdata 455 choice. The contents of the plaintexts are specific to the second 456 factor type. If a client receives a PA-SPAKE PA-DATA element using 457 the encdata choice from the KDC, it MUST reply with a subsequent AS- 458 REQ with a PA-SPAKE PA-DATA using the encdata choice, or abort the AS 459 exchange. 461 The key for client-originated encdata messages in subsequent passes 462 is K'[3] as specified in Section 8 for the first subsequent pass, 463 K'[5] for the second, and so on. The key for KDC-originated encdata 464 messages is K'[4] for the first subsequent pass, K'[6] for the 465 second, and so on. 467 5.5. Reply Key Strengthening 469 When the KDC has successfully validated both factors, the reply key 470 is strengthened and the mechanism is complete. To strengthen the 471 reply key, the client and KDC replace it with K'[0] as specified in 472 Section 8. The KDC then replies with a KDC-REP message, or continues 473 on to the next mechanism in the authentication set. There is no 474 final PA-SPAKE PA-DATA message from the KDC to the client. 476 Reply key strengthening occurs only once at the end of the exchange. 477 The client and KDC MUST use the initial reply key as the base key for 478 all K'[n] derivations. 480 5.6. Optimizations 482 The full protocol has two possible optimizations. 484 First, the KDC MAY reply to the initial AS-REQ (containing no pre- 485 authentication data) with a PA-SPAKE PA-DATA element using the 486 challenge choice, instead of an empty padata-value. In this case, 487 the KDC optimistically selects a group which the client may not 488 support. If the group chosen by the challenge message is supported 489 by the client, the client MUST skip to the third pass by issuing an 490 AS-REQ with a PA-SPAKE message using the response choice. If the 491 KDC's chosen group is not supported by the client, the client MUST 492 initialize and update the transcript checksum with the KDC's 493 challenge message, and then continue to the second pass. Clients 494 MUST support this optimization. 496 Second, clients MAY skip the first pass and send an AS-REQ with a PA- 497 SPAKE PA-DATA element using the support choice. If the KDC accepts 498 the support message and generates a challenge, it MUST include a PA- 499 ETYPE-INFO2 value within the METHOD-DATA of the 500 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may 501 not otherwise be able to compute the initial reply key. If the KDC 502 cannot continue with SPAKE (either because initial reply key type is 503 incompatible with SPAKE or because it does not support any of the 504 client's groups) but can offer other pre-authentication mechanisms, 505 it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing 506 METHOD-DATA. A client supporting this optimization MUST continue 507 after a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113] 508 section 2. KDCs MUST support this optimization. 510 6. SPAKE Parameters and Conversions 512 Group elements are converted to octet strings using the serialization 513 method defined in the IANA "Kerberos SPAKE Groups" registry created 514 by this document. 516 The SPAKE algorithm requires constants M and N for each group. These 517 constants are defined in the IANA "Kerberos SPAKE Groups" registry 518 created by this document. 520 The SPAKE algorithm requires a shared secret input w to be used as a 521 scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2). This value 522 MUST be produced from the initial reply key as follows: 524 1. Determine the length of the multiplier octet string as defined in 525 the IANA "Kerberos SPAKE Groups" registry created by this 526 document. 528 2. Compose a pepper string by concatenating the string "SPAKEsecret" 529 and the group number as a big-endian four-byte unsigned binary 530 number. 532 3. Produce an octet string of the required length using PRF+(K, 533 pepper), where K is the initial reply key and PRF+ is defined in 534 [RFC6113] section 5.1. 536 4. Convert the octet string to a multiplier scalar using the 537 multiplier conversion method defined in the IANA "Kerberos SPAKE 538 Groups" registry created by this document. 540 The KDC chooses a secret scalar value x and the client chooses a 541 secret scalar value y. As required by the SPAKE algorithm, these 542 values are chosen randomly and uniformly. The KDC and client MUST 543 NOT reuse x or y values for authentications involving different 544 initial reply keys (see Section 10.3). 546 7. Transcript Checksum 548 The transcript checksum is an octet string of length equal to the 549 output length of the required checksum type of the encryption type of 550 the initial reply key. The initial value consists of all bits set to 551 zero. 553 When the transcript checksum is updated with an octet string input, 554 the new value is the get_mic result computed over the concatenation 555 of the old value and the input, for the required checksum type of the 556 initial reply key's encryption type, using the initial reply key and 557 the key usage number KEY_USAGE_SPAKE_TRANSCRIPT. 559 In the normal message flow or with the second optimization described 560 in Section 5.6, the transcript checksum is first updated with the 561 client's support message, then the KDC's challenge message, and 562 finally with the client's pubkey value. It therefore incorporates 563 the client's supported groups, the KDC's chosen group, the KDC's 564 initial second-factor messages, and the client and KDC public values. 565 Once the transcript checksum is finalized, it is used without change 566 for all key derivations (Section 8). 568 If the first optimization described in Section 5.6 is used 569 successfully, the transcript checksum is updated only with the KDC's 570 challenge message and the client's pubkey value. 572 If first optimization is used unsuccessfully (i.e. the client does 573 not accept the KDC's selected group), the transcript checksum is 574 updated with the KDC's optimistic challenge message, then with the 575 client's support message, then the KDC's second challenge message, 576 and finally with the client's pubkey value. 578 KEY_USAGE_SPAKE_TRANSCRIPT 66 580 8. Key Derivation 582 Implementations MUST NOT use the SPAKE result (denoted by K in 583 Section 2 of SPAKE [I-D.irtf-cfrg-spake2]) directly for any 584 cryptographic operation. Instead, the SPAKE result is used to derive 585 keys K'[n] as defined in this section. This method differs slightly 586 from the method used to generate K' in Section 3 of SPAKE 587 [I-D.irtf-cfrg-spake2]. 589 An input string is assembled by concatenating the following values: 591 o The fixed string "SPAKEkey". 593 o The group number as a big-endian four-byte unsigned binary number. 595 o The encryption type of the initial reply key as a big-endian four- 596 byte unsigned binary number. 598 o The SPAKE result K, converted to an octet string as specified in 599 Section 6. 601 o The transcript checksum. 603 o The KDC-REQ-BODY encoding for the request being sent or responded 604 to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST 605 be used. 607 o The value n as a big-endian four-byte unsigned binary number. 609 The derived key K'[n] has the same encryption type as the initial 610 reply key, and has the value random-to-key(PRF+(initial-reply-key, 611 input-string)). PRF+ is defined in [RFC6113] section 5.1. 613 9. Second Factor Types 615 This document defines one second factor type: 617 SF-NONE 1 619 This second factor type indicates that no second factor is used. 620 Whenever a SPAKESecondFactor is used with SF-NONE, the data field 621 MUST be omitted. The SF-NONE second factor always successfully 622 validates. 624 10. Security Considerations 626 All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2] 627 apply here as well. 629 10.1. Unauthenticated Plaintext 631 This mechanism includes unauthenticated plaintext in the support and 632 challenge messages. Beginning with the third pass, the integrity of 633 this plaintext is ensured by incorporating the transcript checksum 634 into the derivation of the final reply key and second factor 635 encryption keys. Downgrade attacks on support and challenge messages 636 will result in the client and KDC deriving different reply keys and 637 EncryptedData keys. The KDC-REQ-BODY contents are also incorporated 638 into key derivation, ensuring their integrity. The unauthenticated 639 plaintext in the KDC-REP message is not protected by this mechanism. 641 Unless FAST is used, the factors field of a challenge message is not 642 integrity-protected until the response is verified. Second factor 643 types MUST account for this when specifying the semantics of the data 644 field. Second factor data in the challenge should not be included in 645 user prompts, as it could be modified by an attacker to contain 646 misleading or offensive information. 648 Subsequent factor data, including the data in the response, are 649 encrypted in a derivative of the shared secret K. Therefore, it is 650 not possible to exploit the untrustworthiness of the challenge to 651 turn the client into an encryption or signing oracle, unless the 652 attacker knows the client's long-term key. 654 10.2. Side Channels 656 An implementation of this pre-authentication mechanism can have the 657 property of indistinguishability, meaning that an attacker who 658 guesses a long-term key and a second factor value cannot determine 659 whether one of the factors was correct unless both are correct. 660 Indistinguishability is only maintained if the second factor can be 661 validated solely based on the data in the response; the use of 662 additional round trips will reveal to the attacker whether the long- 663 term key is correct. Indistinguishability also requires that there 664 are no side channels. When processing a response message, whether or 665 not the KDC successfully decrypts the factor field, it must reply 666 with the same error fields, take the same amount of time, and make 667 the same observable communications to other servers. 669 Both the size of the EncryptedData and the number of EncryptedData 670 messages used for second-factor data (including the factor field of 671 the SPAKEResponse message and messages using the encdata PA-SPAKE 672 choice) may reveal information about the second factor used in an 673 authentication. Care should be taken to keep second factor messages 674 as small and as few as possible. 676 Any side channels in the creation of the shared secret input w, or in 677 the multiplications wM and wN, could allow an attacker to recover the 678 client long-term key. Implementations MUST take care to avoid side 679 channels, particularly timing channels. Generation of the secret 680 scalar values x and y need not take constant time, but the amount of 681 time taken MUST NOT provide information about the resulting value. 683 The conversion of the scalar multiplier for the SPAKE w parameter may 684 produce a multiplier that is larger than the order of the group. 685 Some group implementations may be unable to handle such a multiplier. 686 Others may silently accept such a multiplier, but proceed to perform 687 multiplication that is not constant time. This is a minor risk in 688 all known groups, but is a major risk for P-521 due to the extra 689 seven high bits in the input octet string. A common solution to this 690 problem is achieved by reducing the multiplier modulo the group 691 order, taking care to ensure constant time operation. 693 10.3. KDC State 695 A stateless KDC implementation generally must use a PA-FX-COOKIE 696 value to remember its private scalar value x and the transcript 697 checksum. The KDC MUST maintain confidentiality and integrity of the 698 cookie value, perhaps by encrypting it in a key known only to the 699 realm's KDCs. Cookie values may be replayed by attackers. The KDC 700 SHOULD limit the time window of replays using a timestamp, and SHOULD 701 prevent cookie values from being applied to other pre-authentication 702 mechanisms or other client principals. Within the validity period of 703 a cookie, an attacker can replay the final message of a pre- 704 authentication exchange to any of the realm's KDCs and make it appear 705 that the client has authenticated. 707 If an x or y value is reused for pre-authentications involving two 708 different client long-term keys, an attacker who observes both 709 authentications and knows one of the long-term keys can conduct an 710 offline dictionary attack to recover the other one. 712 This pre-authentication mechanism is not designed to provide forward 713 secrecy. Nevertheless, some measure of forward secrecy may result 714 depending on implementation choices. A passive attacker who 715 determines the client long-term key after the exchange generally will 716 not be able to recover the ticket session key; however, an attacker 717 who also determines the PA-FX-COOKIE encryption key (if the KDC uses 718 an encrypted cookie) will be able to recover the ticket session key. 719 The KDC can mitigate this risk by periodically rotating the cookie 720 encryption key. If the KDC or client retains the x or y value for 721 reuse with the same client long-term key, an attacker who recovers 722 the x or y value and the long-term key will be able to recover the 723 ticket session key. 725 10.4. Dictionary Attacks 727 Although this pre-authentication mechanism is designed to prevent an 728 offline dictionary attack by an active attacker posing as the KDC, 729 such an attacker can attempt to downgrade the client to encrypted 730 timestamp. Client implementations SHOULD provide a configuration 731 option to disable encrypted timestamp on a per-realm basis to 732 mitigate this attack. 734 If the user enters the wrong password, the client might fall back to 735 encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error 736 from the KDC, if encrypted timestamp is offered by the KDC and not 737 disabled by client configuration. This fallback will enable a 738 passive attacker to mount an offline dictionary attack against the 739 incorrect password, which may be similar to the correct password. 740 Client implementations SHOULD assume that encrypted timestamp and 741 encrypted challenge are unlikely to succeed if SPAKE pre- 742 authentication fails in the second pass and no second factor was 743 used. 745 Like any other pre-authentication mechanism using the client long- 746 term key, this pre-authentication mechanism does not prevent online 747 password guessing attacks. The KDC is made aware of unsuccessful 748 guesses, and can apply facilities such as password lockout to 749 mitigate the risk of online attacks. 751 10.5. Brute Force Attacks 753 The selected group's resistance to offline brute-force attacks may 754 not correspond to the size of the reply key. For performance 755 reasons, a KDC MAY select a group whose brute-force work factor is 756 less than the reply key length. A passive attacker who solves the 757 group discrete logarithm problem after the exchange will be able to 758 conduct an offline attack against the client long-term key. Although 759 the use of password policies and costly, salted string-to-key 760 functions may increase the cost of such an attack, the resulting cost 761 will likely not be higher than the cost of solving the group discrete 762 logarithm. 764 10.6. Denial of Service Attacks 766 Elliptic curve group operations are more computationally expensive 767 than secret-key operations. As a result, the use of this mechanism 768 may affect the KDC's performance under normal load and its resistance 769 to denial of service attacks. 771 10.7. Reply-Key Encryption Type 773 This mechanism does not upgrade the encryption type of the initial 774 reply key, and relies on that encryption type for confidentiality, 775 integrity, and pseudo-random functions. If the client long-term key 776 uses a weak encryption type, an attacker might be able to subvert the 777 exchange, and the replaced reply key will also be of the same weak 778 encryption type. 780 10.8. KDC Authentication 782 This mechanism does not directly provide the KDC Authentication pre- 783 authentication facility, because it does not send a key confirmation 784 from the KDC to the client. When used as a stand-alone mechanism, 785 the traditional KDC authentication provided by the KDC-REP enc-part 786 still applies. 788 11. Assigned Constants 790 The following key usage values are assigned for this mechanism: 792 KEY_USAGE_SPAKE_TRANSCRIPT 65 793 KEY_USAGE_SPAKE_FACTOR 66 795 12. IANA Considerations 797 The notes for the "Kerberos Checksum Type Numbers" registry should be 798 updated with the following addition: "If the checksum algorithm is 799 non-deterministic, see [this document] Section 4." 801 This document establishes two registries with the following 802 procedure, in accordance with [RFC5226]: 804 Registry entries are to be evaluated using the Specification Required 805 method. All specifications must be be published prior to entry 806 inclusion in the registry. There will be a three-week review period 807 by Designated Experts on the krb5-spake-review@ietf.org mailing list. 808 Prior to the end of the review period, the Designated Experts must 809 approve or deny the request. This decision is to be conveyed to both 810 the IANA and the list, and should include reasonably detailed 811 explanation in the case of a denial as well as whether the request 812 can be resubmitted. 814 12.1. Kerberos Second Factor Types 816 This section species the IANA "Kerberos Second Factor Types" 817 registry. This registry records the number, name, and reference for 818 each second factor protocol. 820 12.1.1. Registration Template 822 ID Number: This is a value that uniquely identifies this entry. It 823 is a signed integer in range -2147483648 to 2147483647, inclusive. 824 Positive values must be assigned only for algorithms specified in 825 accordance with these rules for use with Kerberos and related 826 protocols. Negative values should be used for private and 827 experimental algorithms only. Zero is reserved and must not be 828 assigned. 830 Name: Brief, unique, human-readable name for this algorithm. 832 Reference: URI or otherwise unique identifier for where the details 833 of this algorithm can be found. It should be as specific as 834 reasonably possible. 836 12.1.2. Initial Registry Contents 838 o ID Number: 1 839 o Name: NONE 840 o Reference: this draft. 842 12.2. Kerberos SPAKE Groups 844 This section specifies the IANA "Kerberos SPAKE Groups" registry. 845 This registry records the number, name, specification, serialization, 846 multiplier length, multiplier conversion, SPAKE M constant and SPAKE 847 N constant. 849 12.2.1. Registration Template 851 ID Number: This is a value that uniquely identifies this entry. It 852 is a signed integer in range -2147483648 to 2147483647, inclusive. 853 Positive values must be assigned only for algorithms specified in 854 accordance with these rules for use with Kerberos and related 855 protocols. Negative values should be used for private and 856 experimental use only. Zero is reserved and must not be assigned. 857 Values should be assigned in increasing order. 859 Name: Brief, unique, human readable name for this entry. 861 Specification: Reference to the definition of the group parameters 862 and operations. 864 Serialization: Reference to the definition of the method used to 865 serialize group elements. 867 Multiplier Length: The length of the input octet string to 868 multiplication operations. 870 Multiplier Conversion: Reference to the definition of the method 871 used to convert an octet string to a multiplier scalar. 873 SPAKE M Constant: The serialized value of the SPAKE M constant in 874 hexadecimal notation. 876 SPAKE N Constant: The serialized value of the SPAKE N constant in 877 hexadecimal notation. 879 12.2.2. Initial Registry Contents 881 o ID Number: 1 882 o Name: edwards25519 883 o Specification: [RFC7748] section 4.1 (edwards25519) 884 o Serialization: [RFC8032] section 3.1 885 o Multiplier Length: 32 886 o Multiplier Conversion: [RFC8032] section 3.1 887 o SPAKE M Constant: 888 d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf 889 o SPAKE N Constant: 890 d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab 892 o ID Number: 2 893 o Name: P-256 894 o Specification: [SEC2] section 2.4.2 895 o Serialization: [SEC1] section 2.3.3 (compressed). 896 o Multiplier Length: 32 897 o Multiplier Conversion: [SEC1] section 2.3.8. 898 o SPAKE M Constant: 899 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 900 o SPAKE N Constant: 901 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 903 o ID Number: 3 904 o Name: P-384 905 o Specification: [SEC2] section 2.5.1 906 o Serialization: [SEC1] section 2.3.3 (compressed). 907 o Multiplier Length: 48 908 o Multiplier Conversion: [SEC1] section 2.3.8. 909 o SPAKE M Constant: 910 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664 911 34b363d3dc36f15314739074d2eb8613fceec2853 912 o SPAKE N Constant: 913 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215 914 18f9c543bb252c5490214cf9aa3f0baab4b665c10 916 o ID Number: 4 917 o Name: P-521 918 o Specification: [SEC2] section 2.6.1 919 o Serialization: [SEC1] section 2.3.3 (compressed). 920 o Multiplier Length: 66 921 o Multiplier Conversion: [SEC1] section 2.3.8. 922 o SPAKE M Constant: 923 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1 924 8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5 925 6979962d7aa 926 o SPAKE N Constant: 927 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b 928 c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 929 9d95575cd25 931 13. References 933 13.1. Normative References 935 [CCITT.X680.2002] 936 International Telephone and Telegraph Consultative 937 Committee, "Abstract Syntax Notation One (ASN.1): 938 Specification of basic notation", CCITT Recommendation 939 X.680, July 2002. 941 [CCITT.X690.2002] 942 International Telephone and Telegraph Consultative 943 Committee, "ASN.1 encoding rules: Specification of basic 944 encoding Rules (BER), Canonical encoding rules (CER) and 945 Distinguished encoding rules (DER)", CCITT Recommendation 946 X.690, July 2002. 948 [I-D.irtf-cfrg-spake2] 949 Ladd, W., "SPAKE2, a PAKE", draft-irtf-cfrg-spake2-01 950 (work in progress), February 2015. 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 954 RFC2119, March 1997, . 957 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 958 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 959 2005, . 961 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 962 Kerberos Network Authentication Service (V5)", RFC 4120, 963 DOI 10.17487/RFC4120, July 2005, . 966 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 967 IANA Considerations Section in RFCs", RFC 5226, DOI 968 10.17487/RFC5226, May 2008, . 971 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 972 Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/ 973 RFC6113, April 2011, . 976 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 977 for Security", RFC 7748, DOI 10.17487/RFC7748, January 978 2016, . 980 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 981 Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/ 982 RFC8032, January 2017, . 985 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 986 Elliptic Curve Cryptography", May 2009. 988 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 989 Recommended Elliptic Curve Domain Parameters", January 990 2010. 992 13.2. Non-normative References 994 [RFC6560] Richards, G., "One-Time Password (OTP) Pre- 995 Authentication", RFC 6560, DOI 10.17487/RFC6560, April 996 2012, . 998 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- 999 EXP, and Other Weak Cryptographic Algorithms in Kerberos", 1000 BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012, 1001 . 1003 [SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based 1004 Encrypted Key Exchange Protocols", February 2005. 1006 Appendix A. ASN.1 Module 1008 KerberosV5SPAKE { 1009 iso(1) identified-organization(3) dod(6) internet(1) 1010 security(5) kerberosV5(2) modules(4) spake(8) 1011 } DEFINITIONS EXPLICIT TAGS ::= BEGIN 1013 IMPORTS 1014 EncryptedData, Int32 1015 FROM KerberosV5Spec2 { iso(1) identified-organization(3) 1016 dod(6) internet(1) security(5) kerberosV5(2) modules(4) 1017 krb5spec2(2) }; 1018 -- as defined in RFC 4120. 1020 SPAKESupport ::= SEQUENCE { 1021 groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, 1022 ... 1023 } 1025 SPAKEChallenge ::= SEQUENCE { 1026 group [0] Int32, 1027 pubkey [1] OCTET STRING, 1028 factors [2] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor, 1029 ... 1030 } 1032 SPAKESecondFactor ::= SEQUENCE { 1033 type [0] Int32, 1034 data [1] OCTET STRING OPTIONAL 1035 } 1037 SPAKEResponse ::= SEQUENCE { 1038 pubkey [0] OCTET STRING, 1039 factor [1] EncryptedData, -- SPAKESecondFactor 1040 ... 1041 } 1043 PA-SPAKE ::= CHOICE { 1044 support [0] SPAKESupport, 1045 challenge [1] SPAKEChallenge, 1046 response [2] SPAKEResponse, 1047 encdata [3] EncryptedData, 1048 ... 1049 } 1051 END 1053 Appendix B. SPAKE M and N Value Selection 1055 The M and N constants for the NIST groups are from 1056 [I-D.irtf-cfrg-spake2] section 3. 1058 The M and N constants for the edwards25519 group were generated using 1059 the algorithm from [I-D.irtf-cfrg-spake2] section 3 and the seed 1060 strings "edwards25519 point generation seed (M)" and "edwards25519 1061 point generation seed (N)". 1063 Appendix C. Test Vectors 1065 For the following text vectors: 1067 o The key is the string-to-key of "password" with the salt 1068 "ATHENA.MIT.EDUraeburn" for the designated initial reply key 1069 encryption type. 1071 o x and y were chosen randomly within the order of the designated 1072 group, then multiplied by the cofactor.. 1074 o The SPAKESupport message contains only the designated group's 1075 number. 1077 o The SPAKEChallenge message offers only the SF-NONE second factor 1078 type. 1080 o The KDC-REQ-BODY message contains no KDC options, the client 1081 principal name "raeburn@ATHENA.MIT.EDU", the server principal name 1082 "krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till 1083 field "19700101000000Z", the nonce zero, and an etype list 1084 containing only the designated encryption type. 1086 DES3 edwards25519 1087 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1088 w: a1f1a25cbd8e3092667e2fddba8ecd24f2c9cef124f7a3371ae81e11cad42a07 1089 x: 201012d07bfd48ddfa33c4aac4fb1e229fb0d043cfe65ebfb14399091c71a723 1090 y: 500b294797b8b042aca1bedc0f5931a4f52c537b3608b2d05cc8a2372f439f25 1091 X: ec274df1920dc0f690c8741b794127233745444161016ef950ad75c51db58c3e 1092 Y: d90974f1c42dac1cd4454561ac2d49af762f2ac87bf02436d461e7b661b43028 1093 T: 18f511e750c97b592acd30db7d9e5fca660389102e6bf610c1bfbed4616c8362 1094 S: 5d10705e0d1e43d5dbf30240ccfbde4a0230c70d4c79147ab0b317edad2f8ae7 1095 K: 25bde0d875f0feb5755f45ba5e857889d916ecf7476f116aa31dc3e037ec4292 1096 SPAKESupport: a0093007a0053003020101 1097 Checksum after SPAKESupport: 9037756a58a060f80c13354b1a743a66837f1d4d 1098 SPAKEChallenge: a1363034a003020101a122042018f511e750c97b592acd30 1099 db7d9e5fca660389102e6bf610c1bfbed4616c8362a20930 1100 073005a003020101 1102 Checksum after SPAKEChallenge: 145fbe58e8bd6bf84627 1103 df10ee9954b7849fdc8c 1104 Final checksum after pubkey: f08091064aa5cc32c5660d9a04efb84a1948381b 1105 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1106 1b077261656275726ea2101b0e415448454e412e4d49542e 1107 454455a3233021a003020102a11a30181b066b7262746774 1108 1b0e415448454e412e4d49542e454455a511180f31393730 1109 303130313030303030305aa703020100a8053003020110 1110 K'[0]: 8fcdad5da81f0b4962e91a67d598a2d9c84fc83b0104c868 1111 K'[1]: abf286ce894523013ba89e3413f7c4ef43c1eca8efa7dadf 1112 K'[2]: 6897524c86b5dc5ec7ecc1944cbc1aae7cbcc1643dcd989e 1113 K'[3]: b0a22c32e37902e023192cefada1869b08e69429e9fe0243 1115 RC4 edwards25519 1116 key: 8846f7eaee8fb117ad06bdd830b7586c 1117 w: 2713c1583c53861520b849bfef0525cd4fe82215b3ea6fcd896561d48048f40c 1118 x: c8a62e7b626f44cad807b2d695450697e020d230a738c5cd5691cc781dce8754 1119 y: 18fe7c1512708c7fd06db270361f04593775bc634ceaf45347e5c11c38aae017 1120 X: b0bcbbdd25aa031f4608d0442dd4924be7731d49c089a8301859d77343ffb567 1121 Y: 7d1ab8aeda1a2b1f9eab8d11c0fda60b616005d0f37d1224c5f12b8649f579a5 1122 T: 7db465f1c08c64983a19f560bce966fe5306c4b447f70a5bca14612a92da1d63 1123 S: 38f8d4568090148ebc9fd17c241b4cc2769505a7ca6f3f7104417b72b5b5cf54 1124 K: 03e75edd2cd7e7677642dd68736e91700953ac55dc650e3c2a1b3b4acdb800f8 1125 SPAKESupport: a0093007a0053003020101 1126 Checksum after SPAKESupport: c8bb7fb72f6b142557fd5de9b1b8bb4c 1127 SPAKEChallenge: a1363034a003020101a12204207db465f1c08c64983a19f5 1128 60bce966fe5306c4b447f70a5bca14612a92da1d63a20930 1129 073005a003020101 1130 Checksum after SPAKEChallenge: 318afd9874400fffa744bc602615cde8 1131 Final checksum after pubkey: 0853678dff8b9e5eb855c5e05420790c 1132 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1133 1b077261656275726ea2101b0e415448454e412e4d49542e 1134 454455a3233021a003020102a11a30181b066b7262746774 1135 1b0e415448454e412e4d49542e454455a511180f31393730 1136 303130313030303030305aa703020100a8053003020117 1137 K'[0]: 87a50a15f0dbd7c958e5bf1bbffee4f2 1138 K'[1]: 1b4a484d4ac7dd18acf5ebc42d8e1b14 1139 K'[2]: 8d6b89f491be1b532be6c6e8482328fe 1140 K'[3]: 425c47073edd4a6f0067f08166d44c7a 1142 AES128 edwards25519 1143 key: fca822951813fb252154c883f5ee1cf4 1144 w: 17c2a9030afb7c37839bd4ae7fdfeb179e99e710e464e62f1fb7c9b67936f30b 1145 x: 50be049a5a570fa1459fb9f666e6fd80602e4e87790a0e567f12438a2c96c138 1146 y: b877afe8612b406d96be85bd9f19d423e95be96c0e1e0b5824127195c3ed5917 1147 X: e73a443c678913eb4a0cad5cbd3086cf82f65a5a91b611e01e949f5c52efd6dd 1148 Y: 473c5b44ed2be9cb50afe1762b535b3930530489816ea6bd962622cccf39f6e8 1149 T: 9e9311d985c1355e022d7c3c694ad8d6f7ad6d647b68a90b0fe46992818002da 1150 S: fbe08f7f96cd5d4139e7c9eccb95e79b8ace41e270a60198c007df18525b628e 1151 K: c2f7f99997c585e6b686ceb62db42f17cc70932def3bb4cf009e36f22ea5473d 1152 SPAKESupport: a0093007a0053003020101 1153 Checksum after SPAKESupport: ce5052873534f00424e38897 1154 SPAKEChallenge: a1363034a003020101a12204209e9311d985c1355e022d7c 1155 3c694ad8d6f7ad6d647b68a90b0fe46992818002daa20930 1156 073005a003020101 1157 Checksum after SPAKEChallenge: 9c46dbbaa67fe262585e68f4 1158 Final checksum after pubkey: 9eb1f4db71208adad0d6d9f1 1159 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1160 1b077261656275726ea2101b0e415448454e412e4d49542e 1161 454455a3233021a003020102a11a30181b066b7262746774 1162 1b0e415448454e412e4d49542e454455a511180f31393730 1163 303130313030303030305aa703020100a8053003020111 1164 K'[0]: 50de22f3b9cd6cd283b23396870ca246 1165 K'[1]: b8e433cef3a84fff59f683b5206d3c86 1166 K'[2]: 3c96a2da9575a297c4e831fe2ae625d8 1167 K'[3]: 54ef2f63b25f66aed65f3d6c77030c6a 1169 AES256 edwards25519 1170 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1171 w: 35b35ca126156b5bf4ec8b90e9545060f2108f1b6aa97b381012b9400c9e3f0e 1172 x: 88c6c0a4f0241ef217c9788f02c32d00b72e4310748cd8fb5f94717607e6417d 1173 y: 88b859df58ef5c69bacdfe681c582754eaab09a74dc29cff50b328613c232f55 1174 X: 23c48eaff2721051946313840723b38f563c59b92043d6ffd752f95781af0327 1175 Y: 3d51486ec1d9be69bc45386bb675c013db87fd0488f6a9cacf6b43e8c81a0641 1176 T: 6f301aacae1220e91be42868c163c5009aeea1e9d9e28afcfc339cda5e7105b5 1177 S: 9e2cc32908fc46273279ec75354b4aeafa70c3d99a4d507175ed70d80b255dda 1178 K: cf57f58f6e60169d2ecc8f20bb923a8e4c16e5bc95b9e64b5dc870da7026321b 1179 SPAKESupport: a0093007a0053003020101 1180 Checksum after SPAKESupport: 14b16e16da078fab9830a66c 1181 SPAKEChallenge: a1363034a003020101a12204206f301aacae1220e91be428 1182 68c163c5009aeea1e9d9e28afcfc339cda5e7105b5a20930 1183 073005a003020101 1184 Checksum after SPAKEChallenge: 667e82727168d0fef248c926 1185 Final checksum after pubkey: 32bf15d0606762b6411a0f68 1186 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1187 1b077261656275726ea2101b0e415448454e412e4d49542e 1188 454455a3233021a003020102a11a30181b066b7262746774 1189 1b0e415448454e412e4d49542e454455a511180f31393730 1190 303130313030303030305aa703020100a8053003020112 1191 K'[0]: 9463038f091c0aed6f8186224b7da5cf 1192 24557bf5c7fd6fe35526ce34a9eb5b05 1193 K'[1]: 1900e226176d6730e9e4c1bf342fd954 1194 df3fc65790f8c267c89b4a3026d0d164 1195 K'[2]: b025fb4103dc29f233640540627331e1 1196 b567c1a7f5a3a00d800c70f0ef213804 1197 K'[3]: 840e2280e4d4c61c44c057e2c7c92207 1198 041dd205bd76b6dc50c9add16cc76c7b 1200 AES256 P-256 1201 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1202 w: eb2984af18703f94dd5288b8596cd36988d0d4e83bfb2b44de14d0e95e2090bd 1203 x: 935ddd725129fb7c6288e1a5cc45782198a6416d1775336d71eacd0549a3e80e 1204 y: e07405eb215663abc1f254b8adc0da7a16febaa011af923d79fdef7c42930b33 1205 X: 03bc802165aea7dbd98cc155056249fe0a37a9c203a7c0f7e872d5bf687bd105e2 1206 Y: 0340b8d91ce3852d0a12ae1f3e82c791fc86df6b346006431e968a1b869af7c735 1207 T: 024f62078ceb53840d02612195494d0d0d88de21feeb81187c71cbf3d01e71788d 1208 S: 021d07dc31266fc7cfd904ce2632111a169b7ec730e5f74a7e79700f86638e13c8 1209 K: 0268489d7a9983f2fde69c6e6a1307e9d252259264f5f2dfc32f58cca19671e79b 1210 SPAKESupport: a0093007a0053003020102 1211 Checksum after SPAKESupport: 61f93e7f998dec5f54cac55c 1212 SPAKEChallenge: a1373035a003020102a1230421024f62078ceb53840d0261 1213 2195494d0d0d88de21feeb81187c71cbf3d01e71788da209 1214 30073005a003020101 1215 Checksum after SPAKEChallenge: 949916036d3c524608533206 1216 Final checksum after pubkey: 1024bfe60a1e22b5bf2838c3 1217 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1218 1b077261656275726ea2101b0e415448454e412e4d49542e 1219 454455a3233021a003020102a11a30181b066b7262746774 1220 1b0e415448454e412e4d49542e454455a511180f31393730 1221 303130313030303030305aa703020100a8053003020112 1222 K'[0]: b3a882eccd2f31df46880f6235522a4d 1223 87523a34442547778c46780f5b35800a 1224 K'[1]: 6e18ebfd20a9a05af11b320eaab15870 1225 93f3e21a5efcb261307786661330344d 1226 K'[2]: 11e1a36e87c729a89bbda12cfa15652f 1227 a1848c0ba9b72cb3e69562648744fb09 1228 K'[3]: 9875d491c6d0bb7cbe6d374c368e1242 1229 97e506becbf8ec6aa539a0d70b9e430a 1231 AES256 P-384 1232 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1233 w: 0304cfc55151c6bbe889653db96dbfe0ba4acafc024c1e8840cb3a486f6d80c1 1234 6e1b8974016aa4b7fa43042a9b3825b1 1235 x: f323ca74d344749096fd35d0adf20806e521460637176e84d977e9933c49d76f 1236 cfc6e62585940927468ff53d864a7a50 1237 y: 5b7c709acb175a5afb82860deabca8d0b341facdff0ac0f1a425799aa905d750 1238 7e1ea9c573581a81467437419466e472 1239 X: 0211e3334f117b76635dd802d4022f601680a1fd066a56606b7f246493a10351 1240 7797b81789b225bd5bb1d9ae1da2962250 1241 Y: 0383dfa413496e5e7599fc8c6430f8d6910d37cf326d81421bc92c0939b555c4 1242 ca2ef6a993f6d3db8cb7407655ef60866e 1243 T: 02a1524603ef14f184696f854229d3397507a66c63f841ba748451056be07879 1244 ac298912387b1c5cdff6381c264701be57 1245 S: 020d5adfdb92bc377041cf5837412574c5d13e0f4739208a4f0c859a0a302bc6 1246 a533440a245b9d97a0d34af5016a20053d 1247 K: 0264aa8c61da9600dfb0beb5e46550d63740e4ef29e73f1a30d543eb43c25499 1248 037ad16538586552761b093cf0e37c703a 1249 SPAKESupport: a0093007a0053003020103 1250 Checksum after SPAKESupport: a0024c7b5ff667ae074a9988 1251 SPAKEChallenge: a1473045a003020103a133043102a1524603ef14f184696f 1252 854229d3397507a66c63f841ba748451056be07879ac2989 1253 12387b1c5cdff6381c264701be57a20930073005a003020101 1254 Checksum after SPAKEChallenge: ecd0f64ed7c0d4e18fa4c5b4 1255 Final checksum after pubkey: a238108c88afd856f04d3aa5 1256 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1257 1b077261656275726ea2101b0e415448454e412e4d49542e 1258 454455a3233021a003020102a11a30181b066b7262746774 1259 1b0e415448454e412e4d49542e454455a511180f31393730 1260 303130313030303030305aa703020100a8053003020112 1261 K'[0]: ff59fb5fb83c7bafe197b62c853eb7c3 1262 a2902301dfe8326851626a0e9c714c47 1263 K'[1]: e3c741ac7041feed0f0b5c36cb74c179 1264 cb565e509b6d65594d0badafe318c4dc 1265 K'[2]: 9c7a73087f22b52db38a14eb8292df61 1266 54516eaadb7149b14d35864bdb85aa22 1267 K'[3]: 75ea14f0f53ee8dbabd78f446462cfda 1268 590d4ace0fa93708a00f26f26c565e56 1270 AES256 P-521 1271 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1272 w: 003a095a2b2386eff3eb15b735398da1caf95bc8425665d82370aff58b0471f3 1273 4cce63791cfed967f0c94c16054b3e1703133681bece1e05219f5426bc944b0f 1274 bfb3 1275 x: 017c38701a14b490b6081dfc83524562be7fbb42e0b20426465e3e37952d30bc 1276 ab0ed857010255d44936a1515607964a870c7c879b741d878f9f9cdf5a865306 1277 f3f5 1278 y: 003e2e2950656fa231e959acdd984d125e7fa59cec98126cbc8f3888447911eb 1279 cd49428a1c22d5fdb76a19fbeb1d9edfa3da6cf55b158b53031d05d51433ade9 1280 b2b4 1281 X: 03003e95272223b210b48cfd908b956a36add04a7ff443511432f94ddd87e064 1282 1d680ba3b3d532c21fa6046192f6bfae7af81c4b803aa154e12459d1428f8f2f 1283 56e9f2 1284 Y: 030064916687960df496557ecab08298bf075429eca268c6dabbae24e258d568 1285 c62841664dc8ecf545369f573ea84548faa22f118128c0a87e1d47315afabb77 1286 3bb082 1287 T: 02017d3de19a3ec53d0174905665ef37947d142535102cd9809c0dfbd0dfe007 1288 353d54cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc275adbd9675 1289 6696ec 1290 S: 02004d142d87477841f6ba053c8f651f3395ad264b7405ca5911fb9a55abd454 1291 fef658a5f9ed97d1efac68764e9092fa15b9e0050880d78e95fd03abf5931791 1292 6822b5 1293 K: 03007c303f62f09282cc849490805bd4457a6793a832cbeb55df427db6a31e99 1294 b055d5dc99756d24d47b70ad8b6015b0fb8742a718462ed423b90fa3fe631ac1 1295 3fa916 1296 SPAKESupport: a0093007a0053003020104 1297 Checksum after SPAKESupport: 1b69d116036e141e45d4f7d7 1298 SPAKEChallenge: a1593057a003020104a145044302017d3de19a3ec53d0174 1299 905665ef37947d142535102cd9809c0dfbd0dfe007353d54 1300 cf406ce2a59950f2bb540df6fbe75f8bbbef811c9ba06cc2 1301 75adbd96756696eca20930073005a003020101 1302 Checksum after SPAKEChallenge: cac3da1e9ab1261723ece823 1303 Final checksum after pubkey: 654493ca7e47f3c5200f4b84 1304 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1305 1b077261656275726ea2101b0e415448454e412e4d49542e 1306 454455a3233021a003020102a11a30181b066b7262746774 1307 1b0e415448454e412e4d49542e454455a511180f31393730 1308 303130313030303030305aa703020100a8053003020112 1309 K'[0]: c91635dfd1de3884b635b58b30d3cfd5 1310 26fe78f8dade6f19e4eb2fb23ef594ca 1311 K'[1]: 03d38e139bb3f66cc76c5da720f3bf11 1312 4280f64ed708e69e96094bb62aa28f32 1313 K'[2]: 515eaa3c45b08bc9d77468059e64a8e1 1314 96cfcd15db92ad431cae5edbe721d07e 1315 K'[3]: 898ae786e58391d8a00eb7a7cbddd005 1316 3aff9147b42a3076d934608e70a6f0ff 1318 AES256 edwards25519 with accepted optimistic challenge 1319 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1320 w: 35b35ca126156b5bf4ec8b90e9545060f2108f1b6aa97b381012b9400c9e3f0e 1321 x: 70937207344cafbc53c8a55070e399c584cbafce00b836980dd4e7e74fad2a64 1322 y: 785d6801a2490df028903ac6449b105f2ff0db895b252953cdc2076649526103 1323 X: 13841224ea50438c1d9457159d05f2b7cd9d05daf154888eeed223e79008b47c 1324 Y: d01fc81d5ce20d6ea0939a6bb3e40ccd049f821baaf95e323a3657309ef75d61 1325 T: 83523b35f1565006cbfc4f159885467c2fb9bc6fe23d36cb1da43d199f1a3118 1326 S: 2a8f70f46cee9030700037b77f22cec7970dcc238e3e066d9d726baf183992c6 1327 K: d3c5e4266aa6d1b2873a97ce8af91c7e4d7a7ac456acced7908d34c561ad8fa6 1328 SPAKEChallenge: a1363034a003020101a122042083523b35f1565006cbfc4f 1329 159885467c2fb9bc6fe23d36cb1da43d199f1a3118a20930 1330 073005a003020101 1331 Checksum after SPAKEChallenge: 0b1dc2059f7411b639295982 1332 Final checksum after pubkey: 3990d78eb0abc055d1f69fcb 1333 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1334 1b077261656275726ea2101b0e415448454e412e4d49542e 1335 454455a3233021a003020102a11a30181b066b7262746774 1336 1b0e415448454e412e4d49542e454455a511180f31393730 1337 303130313030303030305aa703020100a8053003020112 1338 K'[0]: 1e9b04bdbdaaffb340aa09c6cdf560fa 1339 dcaadb7cb8762b22cd6e7c96753090b7 1340 K'[1]: 7b959d40bd6c517a89278b008cf314e5 1341 d947b181a3251d2832ab61a21c40d484 1343 K'[2]: 3e484bb86ab7f4ffc4b80a6f6d79692c 1344 55daf2b78654b38c7f1d37b1d688d1f3 1345 K'[3]: 23a331ddf33211859b82502295b0be4b 1346 23a56057b77356d62a13985ca573dae1 1348 AES256 P-521 with rejected optimistic edwards25519 challenge 1349 key: 01b897121d933ab44b47eb5494db15e50eb74530dbdae9b634d65020ff5d88c1 1350 w: 003a095a2b2386eff3eb15b735398da1caf95bc8425665d82370aff58b0471f3 1351 4cce63791cfed967f0c94c16054b3e1703133681bece1e05219f5426bc944b0f 1352 bfb3 1353 x: 01687b59051bf40048d7c31d5a973d792fa12284b7a447e7f5938b5885ca0bb2 1354 c3f0bd30291a55fea08e143e2e04bdd7d19b753c7c99032f06cab0d9c2aa8f83 1355 7ef7 1356 y: 01ded675ebf74fe30c9a53710f577e9cf84f09f6048fe245a4600004884cc167 1357 733f9a9e43108fb83babe8754cd37cbd7025e28bc9ff870f084c7244f536285e 1358 25b4 1359 X: 03001bed88af987101ef52db5b8876f6287eb49a72163876c2cf99deb94f4c74 1360 9bfd118f0f400833cc8daad81971fe40498e6075d8ba0a2acfac35eb9ec8530e 1361 e0edd5 1362 Y: 02007bd3bf214200795ea449852976f241c9f50f445f78ff2714fffe42983f25 1363 cd9c9094ba3f9d7adadd6c251e9dc0991fc8210547e7769336a0ac406878fb94 1364 be2f1f 1365 T: 02014cb2e5b592ece5990f0ef30d308c061de1598bc4272b4a6599bed466fd15 1366 21693642abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03fb96ef5f1e 1367 d3e645 1368 S: 02016c64995e804416f748fd5fa3aa678cbc7cbb596a4f523132dc8af7ce84e5 1369 41f484a2c74808c6b21dcf7775baefa6753398425becc7b838b210ac5daa0cb0 1370 b710e2 1371 K: 0200997f4848ae2e7a98c23d14ac662030743ab37fccc2a45f1c721114f40bcc 1372 80fe6ec6aba49868f8aea1aa994d50e81b86d3e4d3c1130c8695b68907c673d9 1373 e5886a 1374 Optimistic SPAKEChallenge: a1363034a003020102a122042047ca8c 1375 24c3a4a70b6eca228322529dadcfa85c 1376 f58faceecf5d5c02907b9e2deba20930 1377 073005a003020101 1378 Checksum after optimist SPAKEChallenge: 57eff4df899bc520010deb48 1379 SPAKESupport: a0093007a0053003020104 1380 Checksum after SPAKESupport: c2fe6c3c142c207d0bdbdd9c 1381 SPAKEChallenge: a1593057a003020104a145044302014cb2e5b592ece5990f 1382 0ef30d308c061de1598bc4272b4a6599bed466fd15216936 1383 42abcf4dbe36ce1a2d13967de45f6c4f8d0fa8e14428bf03 1384 fb96ef5f1ed3e645a20930073005a003020101 1385 Checksum after SPAKEChallenge: c78a00b2d896b73dbed4969b 1386 Final checksum after pubkey: 80a1da254a44641e0223a944 1387 KDC-REQ-BODY: 3075a00703050000000000a1143012a003020101a10b3009 1388 1b077261656275726ea2101b0e415448454e412e4d49542e 1389 454455a3233021a003020102a11a30181b066b7262746774 1390 1b0e415448454e412e4d49542e454455a511180f31393730 1391 303130313030303030305aa703020100a8053003020112 1392 K'[0]: 567cb2ee046cc10cd29cd5bbe5998e5c 1393 d4fca318075981087400c32c55299697 1394 K'[1]: 57535deb12a3bcaac8389957d9065ee5 1395 51a869148de1f457b232e12055ee9efa 1396 K'[2]: 6d18f714b69242f1e556b2819f895926 1397 9ee0da5b014785b4f1fabb3b7318b70c 1398 K'[3]: a1d86d7d091800f191884e501974fa32 1399 ca513a520197866d7c57e5c1296319e6 1401 Appendix D. Acknowledgements 1403 Nico Williams (Cryptonector) 1404 Taylor Yu (MIT) 1406 Authors' Addresses 1408 Nathaniel McCallum 1409 Red Hat, Inc. 1411 EMail: npmccallum@redhat.com 1413 Simo Sorce 1414 Red Hat, Inc. 1416 EMail: ssorce@redhat.com 1418 Robbie Harwood 1419 Red Hat, Inc. 1421 EMail: rharwood@redhat.com 1423 Greg Hudson 1424 MIT 1426 EMail: ghudson@mit.edu