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. The mechanism uses a
password-authenticated key exchange to prevent brute-force
password attacks, and may optionally incorporate a second factor.
Introduction
The Kerberos protocol commonly uses
password-derived long-term keys to secure the initial authentication
exchange between a Kerberos client and a Key Distribution Center (KDC).
As noted in Section 10 of , an attacker can
perform an offline dictionary attack against the password, either by
initiating an authentication exchange to a principal for which the KDC
does not require pre-authentication, or after eavesdropping on a
legitimate authentication exchange that uses encrypted timestamp
pre-authentication (Section 5.2.7.2 of ).
This document defines a pre-authentication mechanism that
authenticates using long-term keys but is resistant to offline dictionary
attacks. The mechanism additionally enables the use of second factor
authentication without the need for a separately-established secure
channel, by leveraging the trust relationship established by the shared
long-term key.
Properties of PAKE
Password authenticated key exchange (PAKE) algorithms provide several properties which defend against
offline dictionary attacks and make them ideal for use in 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).
PAKE Algorithm Selection
The SPAKE algorithm (defined in ) 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, minimizing the need for additional round trips and state.
- It requires a small number of group operations, and can therefore
be implemented simply and efficiently.
PAKE and Two-Factor Authentication
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. Encrypting this data
using the long-term secret results in packets that are vulnerable to
offline brute-force attack on the password, using either an
authentication tag or statistical properties of the 2FA credentials to
determine whether a password guess is correct.
In the OTP pre-authentication
specification, this problem is mitigated by using flexible
authentication secure tunneling (FAST) (Section 5.4 of ), 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 make it difficult to enable FAST
without manual configuration of client hosts. 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 document 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.
SPAKE Overview
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')
In this mechanism, key verification happens implicitly by a
successful decryption of the 2FA data, or of a placeholder value when
no second factor is required. This mechanism uses a tailored 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
hash, to derive different keys for each use, and to bind the
KDC-REQ-BODY to the pre-authentication exchange.
Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.
This document refers to numerous terms and protocol messages defined
in .
The terms "encryption type", "key generation seed length", and
"random-to-key" are defined in .
The terms "FAST", "PA-FX-COOKIE", "KDC_ERR_PREAUTH_EXPIRED",
"KDC_ERR_MORE_PREAUTH_DATA_REQUIRED", "KDC_ERR_PREAUTH_FAILED",
"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 terms "ASN.1" and "DER" are defined in and
respectively.
When discussing operations within algebraic groups, this document uses
additive notation (as described in Section 2.2 of ). Group elements are denoted with uppercase letters,
while scalar multiplier values are denoted with lowercase letters.
Prerequisites
PA-ETYPE-INFO2
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, following
the guidance in Section 2.1 of . PA-ETYPE-INFO2
is specified in Section 5.2.7.5 of .
Cookie Support
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 of .
More Pre-Authentication Data Required
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 of .
SPAKE Pre-Authentication Message Protocol
This mechanism uses the reply key and provides the Client
Authentication and Strengthening Reply Key pre-authentication facilities
(Section 3 of ). 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. Each group definition specifies an associated hash
function, which will be used for transcript protection and key
derivation. 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:
- PA-SPAKE
- 151
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.
First Pass
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.
Second Pass
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.
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. Otherwise, the KDC MUST respond
with a KDC_ERR_PREAUTH_FAILED error.
The group selection determines the group order, which shall be a
large prime p multiplied by a small cofactor h (possibly 1), as well as
a generator P of a prime-order subgroup and two masking points M and
N. The KDC selects a random integer x in the range 0 <= x < h*p,
which MUST be divisible by h. The KDC computes a public key T=x*P+w*M,
where w is computed from the initial reply key according to .
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 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 T, serialized
according to .
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. Note that
this challenge is initially transmitted as unauthenticated plaintext;
see .
The client and KDC will each initialize a transcript hash () using the hash function associated with the
chosen group, and update it with the concatenation of the DER-encoded
PA-SPAKE messages sent by the client and the KDC.
Third Pass
Upon receipt of the challenge message, the client observes which
group was selected by the KDC and deserializes the KDC's public key
T. The client selects a random integer y in the range 0 <= x <
h*p, which MUST be divisible by h. The client computes a public key
S=y*P+w*N, where w is computed from the initial reply key according to
. The client computes a shared group
element K=y*(T-w*M).
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 hash with the pubkey
value, and use the resulting hash for all encryption key
derivations.
The pubkey field indicates the client's public key S, serialized
according to .
The factor field indicates the client's chosen second factor data.
The key for this field is K'[1] as specified in . The kvno field of the EncryptedData sequence is
omitted. The key usage number for the encryption is
KEY_USAGE_SPAKE. 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
deserializes the client's public key S, and computes the shared group
element K=x*(S-w*N). The KDC derives K'[1] and decrypts 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 a KDC_ERR_PREAUTH_FAILED
error.
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
kvno field of the EncryptedData sequence is omitted. The key for the
EncryptedData value is K'[2] as specified in ,
and the key usage number is KEY_USAGE_SPAKE. 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.
- KEY_USAGE_SPAKE
- 65
Subsequent Passes
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.
Reply Key Strengthening
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.
Optimizations
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. In this case
no SPAKESupport message is sent by the client, so the first update to
the transcript hash contains only the KDC's optimistic challenge. If
the KDC's chosen group is not supported by the client, the client MUST
continue to the second pass. In this case both the client and KDC MUST
reinitialize the transcript hash for the client's support message.
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. If the KDC accepts
the support message and generates a challenge, it 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. If the KDC
cannot continue with SPAKE (either because initial reply key type is
incompatible with SPAKE or because it does not support any of the
client's groups) but can offer other pre-authentication mechanisms, it
MUST respond with a KDC_ERR_PREAUTH_FAILED error containing METHOD-DATA
for the available mechanisms. A client supporting this optimization
MUST continue after a KDC_ERR_PREAUTH_FAILED error as described in
Section 2 of . KDCs MUST support this
optimization.
SPAKE Parameters and Conversions
Group elements are converted to and from 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. 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 two's complement 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 of .
- 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 ).
Transcript Hash
The transcript hash is an octet string of length equal to the output
length of the hash function associated with the selected group. The
initial value consists of all bits set to zero.
When the transcript hash is updated with an octet string input, the
new value is the hash function computed over the concatenation of the
old value and the input.
In the normal message flow or with the second optimization described
in , the transcript hash is first updated
with the concatenation of the client's support message and the KDC's
challenge, and then updated a second time 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 hash is finalized, it
is used without change for all key derivations (). In particular, encrypted second-factor messages are
not included in the transcript hash.
If the first optimization described in
is used successfully, the transcript hash is updated first with the
KDC's challenge message, and second with 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 hash is computed as
in the normal message flow, without including the KDC's optimistic
challenge.
Key Derivation
Implementations MUST NOT use the shared group element (denoted by K)
directly for any cryptographic operation. Instead, the SPAKE result is
used to derive keys K'[n] as defined in this section.
First, compute the hash function associated with the selected group
over the concatenation of the following values:
- The fixed string "SPAKEkey".
- The group number as a big-endian four-byte two's complement binary
number.
- The encryption type of the initial reply key as a big-endian
four-byte two's complement binary number.
- The PRF+ output used to compute the initial secret input w as
specified in .
- The SPAKE result K, converted to an octet string as specified in
.
- The transcript hash.
- 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.
- A single-byte block counter, with the initial value 0x01.
If the hash output is too small for the encryption type's key generation
seed length, the block counter value is incremented and the hash
function re-computed to produce as many blocks as are required. The
result is truncated to the key generation seed length, and the
random-to-key function is used to produce an intermediate key with the
same encryption type as the initial reply key.
The key K'[n] has the same encryption type as the initial reply key,
and has the value KRB-FX-CF2(initial-reply-key, intermediate-key,
"SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in Section 5.1 of .
Second Factor Types
This document defines one second factor type:
- SF-NONE
- 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.
Hint for Authentication Sets
If a KDC offers SPAKE pre-authentication as part of an authentication
set (Section 5.3 of ), it MAY provide a pa-hint
value containing the DER encoding of the ASN.1 type PA-SPAKE-HINT, to
help the client determine whether SPAKE pre-authentication is likely to
succeed if the authentication set is chosen.
The groups field indicates the KDC's supported groups. The factors
field indicates the KDC's supported second factors. The KDC MAY omit the
data field of values in the factors list.
A KDC MUST NOT include a PA-SPAKE-HINT message directly in a pa-value
field; hints must only be provided within authentication sets. A KDC
SHOULD include a hint if SPAKE pre-authentication is offered as the
second or later element of an authentication set.
The PA-SPAKE-HINT message is not part of the transcript, and does not
replace any part of the SPAKE message flow.
Security Considerations
SPAKE Computations
The deserialized public keys S and T MUST be verified to be elements
of the group, to prevent invalid curve attacks. It is not necessary to
verify that they are members of the prime-order subgroup, as the
computation of K by both parties involves a multiplication by the
cofactor h.
The aforementioned cofactor multiplication is accomplished by
choosing private scalars x and y which are divisible by the
cofactor. If the client or KDC chooses a scalar which might not be
divisible by the cofactor, an attacker might be able to coerce values
of K which are not members of the prime-order subgroup, and deduce a
limited amount of information about w from the order of K.
The scalars x and y MUST be chosen uniformly, and must not be reused
for different initial reply keys. If an x or y value is reused for
pre-authentications involving two different initial reply keys, an
attacker who observes both authentications and knows one of the initial
reply keys can conduct an offline dictionary attack to recover the
other one.
The M and N values for a group MUST NOT have known discrete logs. An
attacker who knows the discrete log of M or N can perform an offline
dictionary attack on passwords. It is therefore important to
demonstrate that the M and N values for each group were computed
without multiplying a known value by the generator P.
Unauthenticated Plaintext
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 hash 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.
Unless FAST is used, the factors field of a challenge message is
visible to an attacker, who can use it to determine whether a second
factor is required for the client.
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 for the second factor
credentials, unless the attacker knows the client's long-term key.
Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE
is advertised in authentication sets are unauthenticated, and are not
protected by the transcript hash. Since hints do not replace any part
of the message flow, manipulation of hint messages can only affect the
client's decision to use or not use an authentication set, which could
more easily be accomplished by removing authentication sets
entirely.
Side Channels
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 only a minor risk in
most commonly-used groups, but is a more serious 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.
KDC State
A stateless KDC implementation generally must use a PA-FX-COOKIE
value to remember its private scalar value x and the transcript hash.
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, perhaps splicing them
into different SPAKE exchanges. 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.
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.
Dictionary Attacks
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 enable or disable encrypted timestamp on a per-realm basis to
mitigate this attack.
If the user enters the wrong password, the client might fall back to
encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error from
the KDC, if encrypted timestamp is offered by the KDC and not disabled
by client configuration. This fallback will enable a passive attacker
to mount an offline dictionary attack against the incorrect password,
which may be similar to the correct password. Client implementations
SHOULD assume that encrypted timestamp and encrypted challenge are
unlikely to succeed if SPAKE pre-authentication fails in the second
pass and SF-NONE was used.
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 rate limiting to mitigate the
risk of online attacks.
Brute Force 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.
Denial of Service Attacks
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.
Reflection Attacks
The encdata choice of PA-SPAKE can be used in either direction, and
the factor-specific plaintext does not necessarily indicate a
direction. However, each encdata message is encrypted using a derived
key K'[n], with client-originated messages using only odd values of n
and KDC-originated messages using only even values. An attempted
reflection attack would therefore result in a failed decryption.
Reply-Key Encryption Type
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.
KDC Authentication
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.
Assigned Constants
The following key usage values are assigned for this mechanism:
- KEY_USAGE_SPAKE
- 65
IANA Considerations
IANA has assigned the following number for PA-SPAKE in the
"Pre-authentication and Typed Data" registry:
Type | Value | Reference |
PA-SPAKE | 151 | [this document] |
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. Once published, they can be
submitted directly to the krb5-spake-review@ietf.org mailing
list, where there will be a three-week long review period by
Designated Experts.
The Designated Experts ensure that the specification is publicly
available. It is sufficient to have an Internet-Draft (that is posted
and never published as an RFC) or a document from another standards
body, industry consortium, university site, etc. The Designated Experts
may provide additional in-depth reviews, but their approval should not
be taken as endorsement of the specification.
Prior to the end of the review period, the Designated Experts
must approve or deny the request. This decision is conveyed to
both IANA and the submitter. Since the mailing list archives are
not public, it should include both a reasonably detailed
explanation in the case of a denial as well as whether the
request can be resubmitted.
IANA must only accept registry updates from the designated experts
and should direct all requests for registration to the review mailing
list.
Kerberos Second Factor Types
This section species the IANA "Kerberos Second Factor Types"
registry. This registry records the number, name, and reference for
each second factor protocol.
Registration Template
- ID Number:
-
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 algorithms only. Zero is reserved and must
not be assigned. Values should be assigned in increasing
order.
- Name:
- Brief, unique, human-readable name for this algorithm.
- Reference:
-
URI or otherwise unique identifier for where the details of
this algorithm can be found. It should be as specific as
reasonably possible.
Initial Registry Contents
- ID Number:
- 1
- Name:
- SF-NONE
- Reference:
- [this document]
Kerberos SPAKE Groups
This section specifies the IANA "Kerberos SPAKE Groups" registry.
This registry records the number, name, specification, serialization,
multiplier length, multiplier conversion, SPAKE M and N constants, and
associated hash function.
Registration Template
- ID Number:
-
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.
- Name:
-
Brief, unique, human readable name for this entry.
- Specification:
-
Reference to the definition of the group parameters and operations.
- Serialization:
-
Reference to the definition of the method used to serialize
and deserialize group elements.
- Multiplier Length:
-
The length of the input octet string to multiplication operations.
- Multiplier Conversion:
-
Reference to the definition of the method used to convert an
octet string to a multiplier scalar.
- SPAKE M Constant:
-
The serialized value of the SPAKE M constant in hexadecimal notation.
- SPAKE N Constant:
-
The serialized value of the SPAKE N constant in hexadecimal notation.
- Hash Function:
-
The group's associated hash function.
Initial Registry Contents
- ID Number:
- 1
- Name:
- edwards25519
- Specification:
- Section 4.1 of (edwards25519)
- Serialization:
- Section 3.1 of
- Multiplier Length:
- 32
- Multiplier Conversion:
- Section 3.1 of
- SPAKE M Constant:
- d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
- SPAKE N Constant:
- d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
- Hash function:
- SHA-256 ()
- ID Number:
- 2
- Name:
- P-256
- Specification:
- Section 2.4.2 of
- Serialization:
- Section 2.3.3 of (compressed format)
- Multiplier Length:
- 32
- Multiplier Conversion:
- Section 2.3.8 of
- SPAKE M Constant:
- 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
- SPAKE N Constant:
- 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
- Hash function:
- SHA-256 ()
- ID Number:
- 3
- Name:
- P-384
- Specification:
- Section 2.5.1 of
- Serialization:
- Section 2.3.3 of (compressed format)
- Multiplier Length:
- 48
- Multiplier Conversion:
- Section 2.3.8 of
- SPAKE M Constant:
- 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc36f15314739074d2eb8613fceec2853
- SPAKE N Constant:
- 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb252c5490214cf9aa3f0baab4b665c10
- Hash function:
- SHA-384 ()
- ID Number:
- 4
- Name:
- P-521
- Specification:
- Section 2.6.1 of
- Serialization:
- Section 2.3.3 of (compressed format)
- Multiplier Length:
- 48
- Multiplier Conversion:
- Section 2.3.8 of
- SPAKE M Constant:
- 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa
- SPAKE N Constant:
- 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25
- Hash function:
- SHA-512 ()
Normative References
SEC 1: Elliptic Curve Cryptography
Standards for Efficient Cryptography
Group
SEC 2: Recommended Elliptic Curve Domain Parameters
Standards for Efficient Cryptography
Group
Informative References
Simple Password-Based Encrypted Key Exchange Protocols
SPAKE M and N Value Selection
The M and N values for the initial contents of the SPAKE group
registry were generated using the following Python snippet, which assumes
an elliptic curve implementation following the interface of
Edwards25519Point.stdbase() and Edwards448Point.stdbase() in Appendix A
of :
The seed initial seed strings are:
- For group 1 M: edwards25519 point generation seed (M)
- For group 1 N: edwards25519 point generation seed (N)
- For group 2 M: 1.2.840.10045.3.1.7 point generation seed (M)
- For group 2 N: 1.2.840.10045.3.1.7 point generation seed (N)
- For group 3 M: 1.3.132.0.34 point generation seed (M)
- For group 3 N: 1.3.132.0.34 point generation seed (N)
- For group 4 M: 1.3.132.0.35 point generation seed (M)
- For group 4 N: 1.3.132.0.35 point generation seed (N)
Test Vectors
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, then multiplied by the cofactor..
- 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.
There are currently no encryption types with a seed size large enough
to require multiple hash blocks during key derivation with any of the
assigned hash functions. To exercise this possibility, the following
test vector illustrates what keys would be derived if there were a copy
of the edwards25519 group with group number -1 and associated hash
function SHA-1: