SPAKE Pre-Authentication

SPAKE Pre-Authentication Red Hat, Inc.

npmccallum@redhat.com

Red Hat, Inc.

ssorce@redhat.com

Red Hat, Inc.

rharwood@redhat.com

MIT

ghudson@mit.edu

Security Internet Engineering Task Force This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without relying on FAST. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client.

When a client uses PA-ENC-TIMESTAMP (or similar schemes, or the KDC does not require preauthentication), a passive attacker that observes either the AS-REQ or AS-REP can perform an offline brute-force attack against the transferred ciphertext. When the client principal's long-term key is based on a password, offline dictionary attacks can successfuly recover the key, with only modest effort needed if the password is weak.

Password authenticated key exchange (PAKE) algorithms provide several properties which are useful to overcome this problem and make them ideal for use as a Kerberos pre-authentication mechanism. Each side of the exchange contributes entropy. Passive attackers cannot determine the shared key. Active attackers cannot perform a man-in-the-middle attack. These properties of PAKE allow us to establish high-entropy encryption keys resistant to offline brute force attack, even when the passwords used are weak (low-entropy).

The SPAKE algorithm works by encrypting the public keys of a Diffie-Hellman key exchange with a shared secret. SPAKE was selected for this pre-authentication mechanism for the following properties: Because SPAKE's encryption method ensures that the result is a member of the underlying group, it can be used with elliptic curve cryptography, which is believed to provide equivalent security levels to finite-field DH key exchange at much smaller key sizes. It can compute the shared key after just one message from each party. It requires a small number of group operations, and can therefore be implemented simply and efficiently.

Using PAKE in a pre-authentication mechanism also has another benefit when used as a component of two-factor authentication (2FA). 2FA methods often require the secure transfer of plaintext material to the KDC for verification. This includes one-time passwords, challenge/response signatures and biometric data. Attempting to encrypt this data using the long-term secret results in packets that are vulnerable to offline brute-force attack if either authenticated encryption is used or if the plaintext is distinguishable from random data. This is a problem that PAKE solves for first factor authentication. So a similar technique can be used with PAKE to encrypt second-factor data. In the OTP pre-authentication specification, this problem is mitigated by using FAST, which uses a secondary trust relationship to create a secure encryption channel within which pre-authentication data can be sent. However, the requirement for a secondary trust relationship has proven to be cumbersome to deploy and often introduces third parties into the trust chain (such as certification authorities). These requirements lead to a scenario where FAST cannot be enabled by default without sufficient configuration. SPAKE pre-authentication, in contrast, can create a secure encryption channel implicitly, using the key exchange to negotiate a high-entropy encryption key. This key can then be used to securely encrypt 2FA plaintext data without the need for a secondary trust relationship. Further, if the second factor verifiers are sent at the same time as the first factor verifier, and the KDC is careful to prevent timing attacks, then an online brute-force attack cannot be used to attack the factors separately. For these reasons, this draft departs from the advice given in Section 1 of RFC 6113 which states that "Mechanism designers should design FAST factors, instead of new pre-authentication mechanisms outside of FAST." However, this pre-authentication mechanism does not intend to replace FAST, and may be used with it to further conceal the metadata of the Kerberos messages.

The SPAKE algorithm can be broadly described in a series of four steps: Calculation and exchange of the public key Calculation of the shared secret (K) Derivation of an encryption key (K') Verification of the derived encryption key (K') Higher level protocols must define their own verification step. In the case of this mechanism, verification happens implicitly by a successful decryption of the 2FA data. This mechanism provides its own method of deriving encryption keys from the calculated shared secret K, for several reasons: to fit within the framework of , to ensure negotiation integrity using a transcript checksum, to derive different keys for each use, and to bind the KDC-REQ-BODY to the pre-authentication exchange.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . This document refers to numerous terms and protocol messages defined in . The terms "encryption type", "required checksum mechanism", and "get_mic" are defined in . The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED", "KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "pre-authentication facility", and "authentication set" are defined in . The paper defines SPAKE as a family of two key exchange algorithms differing only in derivation of the final key. This mechanism uses a derivation similar to the second algorithm (SPAKE2) with differences in detail. For simplicity, this document refers to the algorithm as "SPAKE". The normative reference for this algorithm is . The terms "ASN.1" and "DER" are defined in and respectively.

This mechanism requires the initial KDC pre-authentication state to contain a singular reply key. Therefore, a KDC which offers SPAKE pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE-INFO2 value containing a single ETYPE-INFO2-ENTRY, as described in section 2.1. PA-ETYPE-INFO2 is specified in section 5.2.7.5.

KDCs which implement SPAKE pre-authentication MUST have some secure mechanism for retaining state between AS-REQs. For stateless KDC implementations, this method will most commonly be an encrypted PA-FX-COOKIE. Clients which implement SPAKE pre-authentication MUST support PA-FX-COOKIE, as described in section 5.2.

Both KDCs and clients which implement SPAKE pre-authentication MUST support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described in section 5.2.

This mechanism uses the reply key and provides the Client Authentication and Strengthening Reply Key pre-authentication facilities ( section 3). When the mechanism completes successfully, the client will have proved knowledge of the original reply key and possibly a second factor, and the reply key will be strengthened to a more uniform distribution based on the PAKE exchange. This mechanism also ensures the integrity of the KDC-REQ-BODY contents. This mechanism can be used in an authentication set; no pa-hint value is required or defined. This mechanism negotiates a choice of group for the SPAKE algorithm. Groups are defined in the IANA "Kerberos SPAKE Groups" registry created by this document. Clients and KDCs MUST implement the edwards25519 group, but MAY choose not to offer or accept it by default. This section will describe the flow of messages when performing SPAKE pre-authentication. We will begin by explaining the most verbose version of the protocol which all implementations MUST support. Then we will describe several optional optimizations to reduce round-trips. Mechanism messages are communicated using PA-DATA elements within the padata field of KDC-REQ messages or within the METHOD-DATA in the e-data field of KRB-ERROR messages. All PA-DATA elements for this mechanism MUST use the following padata-type: TBD The padata-value for all PA-SPAKE PA-DATA values MUST be empty or contain a DER encoding for the ASN.1 type PA-SPAKE.

The SPAKE pre-authentication exchange begins when the client sends an initial authentication service request (AS-REQ) without pre-authentication data. Upon receipt of this AS-REQ, a KDC which requires pre-authentication and supports SPAKE SHOULD reply with a KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty PA-SPAKE PA-DATA element (possibly in addition to other PA-DATA elements). This message indicates to the client that the KDC supports SPAKE pre-authentication.

Once the client knows that the KDC supports SPAKE pre-authentication and the client desires to use it, the client will generate a new AS-REQ message containing a PA-SPAKE PA-DATA element using the support choice. This message indicates to the KDC which groups the client prefers for the SPAKE operation. The group numbers are defined in the IANA "Kerberos SPAKE Groups" registry created by this document. The groups sequence is ordered from the most preferred group to the least preferred group.

The client and KDC initialize a transcript checksum () and update it with the DER-encoded PA-SPAKE message. Upon receipt of the support message, the KDC will select a group. The KDC SHOULD choose a group from the groups provided by the support message. However, if the support message does not contain any group that is supported by the KDC, the KDC MAY select another group in hopes that the client might support it. Once the KDC has selected a group, the KDC will reply to the client with a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error containing a PA-SPAKE PA-DATA element using the challenge choice. The client and KDC update the transcript checksum with the DER-encoded PA-SPAKE message.

The group field indicates the KDC-selected group used for all SPAKE calculations as defined in the IANA "Kerberos SPAKE Groups" registry created by this document. The pubkey field indicates the KDC's public key generated using the M constant in the SPAKE algorithm, with inputs and conversions as specified in . The factors field contains an unordered list of second factors which can be used to complete the authentication. Each second factor is represented by a SPAKESecondFactor.

The type field is a unique integer which identifies the second factor type. The factors field of SPAKEChallenge MUST NOT contain more than one SPAKESecondFactor with the same type value. The data field contains optional challenge data. The contents in this field will depend upon the second factor type chosen.

Upon receipt of the challenge message, the client will complete its part of of the SPAKE algorithm, generating a public key and computing the shared secret K. The client will then choose one of the second factor types listed in the factors field of the challenge message and gather whatever data is required for the chosen second factor type, possibly using the associated challenge data. Finally, the client will send an AS-REQ containing a PA-SPAKE PA-DATA element using the response choice.

The client and KDC will update the transcript checksum with the pubkey value, and use the resulting checksum for all encryption key derivations. The pubkey field indicates the client's public key generated using the N constant in the SPAKE algorithm, with inputs and conversions as specified in . The factor field indicates the client's chosen second factor data. The key for this field is K'[1] as specified in . The key usage number for the encryption is KEY_USAGE_SPAKE_FACTOR. The plain text inside the EncryptedData is an encoding of SPAKESecondFactor. Once decoded, the SPAKESecondFactor contains the type of the second factor and any optional data used. The contents of the data field will depend on the second factor type chosen. The client MUST NOT send a response containing a second factor type which was not listed in the factors field of the challenge message. When the KDC receives the response message from the client, it will use the pubkey to compute the SPAKE result, derive K'[1], and decrypt the factors field. If decryption is successful, the first factor is successfully validated. The KDC then validates the second factor. If either factor fails to validate, the KDC SHOULD respond with an appropriate KRB-ERROR message. If validation of the second factor requires further round-trips, the KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED containing a PA-SPAKE PA-DATA element using the encdata choice. The key for the EncryptedData value is K'[2] as specified in , and the key usage number is KEY_USAGE_SPAKE_FACTOR. The plain text of this message contains a DER-encoded SPAKESecondFactor message. As before, the type field of this message will contain the second factor type, and the data field will optionally contain second factor type specific data.

Any number of additional round trips may occur using the encdata choice. The contents of the plaintexts are specific to the second factor type. If a client receives a PA-SPAKE PA-DATA element using the encdata choice from the KDC, it MUST reply with a subsequent AS-REQ with a PA-SPAKE PA-DATA using the encdata choice, or abort the AS exchange. The key for client-originated encdata messages in subsequent passes is K'[3] as specified in for the first subsequent pass, K'[5] for the second, and so on. The key for KDC-originated encdata messages is K'[4] for the first subsequent pass, K'[6] for the second, and so on.

When the KDC has successfully validated both factors, the reply key is strengthened and the mechanism is complete. To strengthen the reply key, the client and KDC replace it with K'[0] as specified in . The KDC then replies with a KDC-REP message, or continues on to the next mechanism in the authentication set. There is no final PA-SPAKE PA-DATA message from the KDC to the client. Reply key strengthening occurs only once at the end of the exchange. The client and KDC MUST use the initial reply key as the base key for all K'[n] derivations.

The full protocol has two possible optimizations. First, the KDC MAY reply to the initial AS-REQ (containing no pre-authentication data) with a PA-SPAKE PA-DATA element using the challenge choice, instead of an empty padata-value. In this case, the KDC optimistically selects a group which the client may not support. If the group chosen by the challenge message is supported by the client, the client MUST skip to the third pass by issuing an AS-REQ with a PA-SPAKE message using the response choice. If the KDC's chosen group is not supported by the client, the client MUST initialize and update the transcript checksum with the KDC's challenge message, and then continue to the second pass. Clients MUST support this optimization. Second, clients MAY skip the first pass and send an AS-REQ with a PA-SPAKE PA-DATA element using the support choice. The KDC MUST include a PA-ETYPE-INFO2 value within the METHOD-DATA of the KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may not otherwise be able to compute the initial reply key. KDCs MUST support this optimization.

Group elements are converted to octet strings using the serialization method defined in the IANA "Kerberos SPAKE Groups" registry created by this document. The SPAKE algorithm requires constants M and N for each group. These constants are defined in the IANA "Kerberos SPAKE Groups" registry created by this document. The SPAKE algorithm requires a shared secret input w to be used as a scalar multiplier (see section 2). This value MUST be produced from the initial reply key as follows: Determine the length of the multiplier octet string as defined in the IANA "Kerberos SPAKE Groups" registry created by this document. Compose a pepper string by concatenating the string "SPAKEsecret" and the group number as a big-endian four-byte unsigned binary number. Produce an octet string of the required length using PRF+(K, pepper), where K is the initial reply key and PRF+ is defined in section 5.1. Convert the octet string to a multiplier scalar using the multiplier conversion method defined in the IANA "Kerberos SPAKE Groups" registry created by this document. The KDC chooses a secret scalar value x and the client chooses a secret scalar value y. As required by the SPAKE algorithm, these values are chosen randomly and uniformly. The KDC and client MUST NOT reuse x or y values for authentications involving different initial reply keys (see ).

The transcript checksum is an octet string of length equal to the output length of the required checksum type of the encryption type of the initial reply key. The initial value consists of all bits set to zero. When the transcript checksum is updated with an octet string input, the new value is the get_mic result computed over the concatenation of the old value and the input, for the required checksum type of the initial reply key's encryption type, using the initial reply key and the key usage number KEY_USAGE_SPAKE_TRANSCRIPT. In the normal message flow or with the second optimization described in , the transcript checksum is first updated with the client's support message, then the KDC's challenge message, and finally with the client's pubkey value. It therefore incorporates the client's supported groups, the KDC's chosen group, the KDC's initial second-factor messages, and the client and KDC public values. Once the transcript checksum is finalized, it is used without change for all key derivations (). If the first optimization described in is used successfully, the transcript checksum is updated only with the KDC's challenge message and the client's pubkey value. If first optimization is used unsuccessfully (i.e. the client does not accept the KDC's selected group), the transcript checksum is updated with the KDC's optimistic challenge message, then with the client's support message, then the KDC's second challenge message, and finally with the client's pubkey value.

Implementations MUST NOT use the SPAKE result (denoted by K in Section 2 of SPAKE) directly for any cryptographic operation. Instead, the SPAKE result is used to derive keys K'[n] as defined in this section. This method differs slightly from the method used to generate K' in Section 3 of SPAKE. An input string is assembled by concatenating the following values: The fixed string "SPAKEkey". The group number as a big-endian four-byte unsigned binary number. The encryption type of the initial reply key as a big-endian four-byte unsigned binary number. The SPAKE result K, converted to an octet string as specified in . The transcript checksum. The KDC-REQ-BODY encoding for the request being sent or responded to. Within a FAST channel, the inner KDC-REQ-BODY encoding MUST be used. The value n as a big-endian four-byte unsigned binary number. The derived key K'[n] has the same encryption type as the initial reply key, and has the value random-to-key(PRF+(initial-reply-key, input-string)). PRF+ is defined in section 5.1.

This document defines one second factor type: 1 This second factor type indicates that no second factor is used. Whenever a SPAKESecondFactor is used with SF-NONE, the data field MUST be omitted. The SF-NONE second factor always successfully validates.

All of the security considerations from SPAKE apply here as well.

This mechanism includes unauthenticated plaintext in the support and challenge messages. Beginning with the third pass, the integrity of this plaintext is ensured by incorporating the transcript checksum into the derivation of the final reply key and second factor encryption keys. Downgrade attacks on support and challenge messages will result in the client and KDC deriving different reply keys and EncryptedData keys. The KDC-REQ-BODY contents are also incorporated into key derivation, ensuring their integrity. The unauthenticated plaintext in the KDC-REP message is not protected by this mechanism. Unless FAST is used, the factors field of a challenge message is not integrity-protected until the response is verified. Second factor types MUST account for this when specifying the semantics of the data field. Second factor data in the challenge should not be included in user prompts, as it could be modified by an attacker to contain misleading or offensive information. Subsequent factor data, including the data in the response, are encrypted in a derivative of the shared secret K. Therefore, it is not possible to exploit the untrustworthiness of the challenge to turn the client into an encryption or signing oracle, unless the attacker knows the client's long-term key.

An implementation of this pre-authentication mechanism can have the property of indistinguishability, meaning that an attacker who guesses a long-term key and a second factor value cannot determine whether one of the factors was correct unless both are correct. Indistinguishability is only maintained if the second factor can be validated solely based on the data in the response; the use of additional round trips will reveal to the attacker whether the long-term key is correct. Indistinguishability also requires that there are no side channels. When processing a response message, whether or not the KDC successfully decrypts the factor field, it must reply with the same error fields, take the same amount of time, and make the same observable communications to other servers. Both the size of the EncryptedData and the number of EncryptedData messages used for second-factor data (including the factor field of the SPAKEResponse message and messages using the encdata PA-SPAKE choice) may reveal information about the second factor used in an authentication. Care should be taken to keep second factor messages as small and as few as possible. Any side channels in the creation of the shared secret input w, or in the multiplications wM and wN, could allow an attacker to recover the client long-term key. Implementations MUST take care to avoid side channels, particularly timing channels. Generation of the secret scalar values x and y need not take constant time, but the amount of time taken MUST NOT provide information about the resulting value. The conversion of the scalar multiplier for the SPAKE w parameter may produce a multiplier that is larger than the order of the group. Some group implementations may be unable to handle such a multiplier. Others may silently accept such a multiplier, but proceed to perform multiplication that is not constant time. This is a minor risk in all known groups, but is a major risk for P-521 due to the extra seven high bits in the input octet string. A common solution to this problem is achieved by reducing the multiplier modulo the group order, taking care to ensure constant time operation.

A stateless KDC implementation generally must use a PA-FX-COOKIE value to remember its private scalar value x and the transcript checksum. The KDC MUST maintain confidentiality and integrity of the cookie value, perhaps by encrypting it in a key known only to the realm's KDCs. Cookie values may be replayed by attackers. The KDC SHOULD limit the time window of replays using a timestamp, and SHOULD prevent cookie values from being applied to other pre-authentication mechanisms or other client principals. Within the validity period of a cookie, an attacker can replay the final message of a pre-authentication exchange to any of the realm's KDCs and make it appear that the client has authenticated. If an x or y value is reused for pre-authentications involving two different client long-term keys, an attacker who observes both authentications and knows one of the long-term keys can conduct an offline dictionary attack to recover the other one. This pre-authentication mechanism is not designed to provide forward secrecy. Nevertheless, some measure of forward secrecy may result depending on implementation choices. A passive attacker who determines the client long-term key after the exchange generally will not be able to recover the ticket session key; however, an attacker who also determines the PA-FX-COOKIE encryption key (if the KDC uses an encrypted cookie) will be able to recover the ticket session key. The KDC can mitigate this risk by periodically rotating the cookie encryption key. If the KDC or client retains the x or y value for reuse with the same client long-term key, an attacker who recovers the x or y value and the long-term key will be able to recover the ticket session key.

Although this pre-authentication mechanism is designed to prevent an offline dictionary attack by an active attacker posing as the KDC, such an attacker can attempt to downgrade the client to encrypted timestamp. Client implementations SHOULD provide a configuration option to disable encrypted timestamp on a per-realm basis to mitigate this attack. Like any other pre-authentication mechanism using the client long-term key, this pre-authentication mechanism does not prevent online password guessing attacks. The KDC is made aware of unsuccessful guesses, and can apply facilities such as password lockout to mitigate the risk of online attacks.

The selected group's resistance to offline brute-force attacks may not correspond to the size of the reply key. For performance reasons, a KDC MAY select a group whose brute-force work factor is less than the reply key length. A passive attacker who solves the group discrete logarithm problem after the exchange will be able to conduct an offline attack against the client long-term key. Although the use of password policies and costly, salted string-to-key functions may increase the cost of such an attack, the resulting cost will likely not be higher than the cost of solving the group discrete logarithm.

Elliptic curve group operations are more computationally expensive than secret-key operations. As a result, the use of this mechanism may affect the KDC's performance under normal load and its resistance to denial of service attacks.

This mechanism does not upgrade the encryption type of the initial reply key, and relies on that encryption type for confidentiality, integrity, and pseudo-random functions. If the client long-term key uses a weak encryption type, an attacker might be able to subvert the exchange, and the replaced reply key will also be of the same weak encryption type.

This mechanism does not directly provide the KDC Authentication pre-authentication facility, because it does not send a key confirmation from the KDC to the client. When used as a stand-alone mechanism, the traditional KDC authentication provided by the KDC-REP enc-part still applies.

The following key usage values are assigned for this mechanism:

This document establishes two registries with the following procedure, in accordance with : Registry entries are to be evaluated using the Specification Required method. All specifications must be be published prior to entry inclusion in the registry. There will be a three-week review period by Designated Experts on the krb5-spake-review@ietf.org mailing list. Prior to the end of the review period, the Designated Experts must approve or deny the request. This decision is to be conveyed to both the IANA and the list, and should include reasonably detailed explanation in the case of a denial as well as whether the request can be resubmitted.

This section species the IANA "Kerberos Second Factor Types" registry. This registry records the number, name, and reference for each second factor protocol.

•ID Number: 1 •Name: NONE •Reference: this draft.

This section specifies the IANA "Kerberos SPAKE Groups" registry. This registry records the number, name, specification, serialization, multiplier length, multiplier conversion, SPAKE M constant and SPAKE N constant.

This is a value that uniquely identifies this entry. It is a signed integer in range -2147483648 to 2147483647, inclusive. Positive values must be assigned only for algorithms specified in accordance with these rules for use with Kerberos and related protocols. Negative values should be used for private and experimental use only. Zero is reserved and must not be assigned. Values should be assigned in increasing order. Brief, unique, human readable name for this entry. Reference to the definition of the group parameters and operations. Reference to the definition of the method used to serialize group elements. The length of the input octet string to multiplication operations. Reference to the definition of the method used to convert an octet string to a multiplier scalar. The serialized value of the SPAKE M constant in hexadecimal notation. The serialized value of the SPAKE N constant in hexadecimal notation.

•ID Number: 1 •Name: edwards25519 •Specification: section 4.1 (edwards25519) •Serialization: section 3.1 •Multiplier Length: 32 •Multiplier Conversion: section 3.1 •SPAKE M Constant: 5ada7e4bf6ddd9adb6626d32131c6b5c51a1e347a3478f53cfcf441b88eed12e •SPAKE N Constant: 10e3df0ae37d8e7a99b5fe74b44672103dbddcbd06af680d71329a11693bc778 •ID Number: 2 •Name: P-256 •Specification: section 2.4.2 •Serialization: section 2.3.3 (compressed). •Multiplier Length: 32 •Multiplier Conversion: section 2.3.8. •SPAKE M Constant: 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f •SPAKE N Constant: 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 •ID Number: 3 •Name: P-384 •Specification: section 2.5.1 •Serialization: section 2.3.3 (compressed). •Multiplier Length: 48 •Multiplier Conversion: section 2.3.8. •SPAKE M Constant: 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664 34b363d3dc36f15314739074d2eb8613fceec2853 •SPAKE N Constant: 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215 18f9c543bb252c5490214cf9aa3f0baab4b665c10 •ID Number: 4 •Name: P-521 •Specification: section 2.6.1 •Serialization: section 2.3.3 (compressed). •Multiplier Length: 66 •Multiplier Conversion: section 2.3.8. •SPAKE M Constant: 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1 8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5 6979962d7aa •SPAKE N Constant: 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 9d95575cd25

&rfc2119; &rfc3961; &rfc4120; &rfc5226; &rfc6113; &rfc7748; &rfc8032; &spake; &CCITT.X680.2002; &CCITT.X690.2002; SEC 1: Elliptic Curve Cryptography Standards for Efficient Cryptography Group SEC 2: Recommended Elliptic Curve Domain Parameters Standards for Efficient Cryptography Group &rfc6234; &rfc6560; Simple Password-Based Encrypted Key Exchange Protocols

The M and N constants for the edwards25519 group are the SHA-256 hashes hashes of "edwards25519 point generation seed (M)" and "edwards25519 point generation seed (N)" respectively. Both hashes decode to valid curve points.

For the following text vectors: The key is the string-to-key of "password" with the salt "ATHENA.MIT.EDUraeburn" for the designated initial reply key encryption type. x and y were chosen randomly within the order of the designated group. The SPAKESupport message contains only the designated group's number. The SPAKEChallenge message offers only the SF-NONE second factor type. The KDC-REQ-BODY message contains no KDC options, the client principal name "raeburn@ATHENA.MIT.EDU", the server principal name "krbtgt/ATHENA.MIT.EDU", the realm "ATHENA.MIT.EDU", the till field "19700101000000Z", the nonce zero, and an etype list containing only the designated encryption type.