RFC 6560
One-Time Password (OTP) Pre-Authentication
RFC 6560: One-Time Password (OTP) Pre-Authentication ✨
okay bestie, this is RFC 6560 and it's giving "log in with a one-time code in Kerberos without ever touching the user's password" 🔐🦋. It was written by G. Richards from RSA, The Security Division of EMC and published in April 2012 🌸. It's a Standards Track document, and its ISSN is 2070-1721 💜.
Abstract 💜
Kerberos gives you a framework for authenticating a client by passing pre-authentication data back and forth 💅. This document explains how to use that framework to carry out One-Time Password (OTP) authentication ✨.
Status of This Memo 📜
This is an Internet Standards Track document. 🌈
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741 🫶.
Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6560 🔍.
Copyright Notice ©️
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they are in effect on the date this document is published. Please read these documents carefully, because they explain your rights and restrictions when it comes to this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🙈.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person(s) who control the copyright in some of that material may not have given the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Overall Design .............................................3
1.3. Conventions Used in This Document ..........................4
2. Usage Overview ..................................................4
2.1. OTP Mechanism Support ......................................4
2.2. Pre-Authentication .........................................4
2.3. PIN Change .................................................5
2.4. Resynchronization ..........................................6
3. Pre-Authentication Protocol Details .............................6
3.1. Initial Client Request .....................................6
3.2. KDC Challenge ..............................................7
3.3. Client Response ............................................9
3.4. Verifying the Pre-Authentication Data .....................13
3.5. Confirming the Reply Key Change ...........................15
3.6. Reply Key Generation ......................................15
4. OTP Kerberos Message Types .....................................17
4.1. PA-OTP-CHALLENGE ..........................................17
4.2. PA-OTP-REQUEST ............................................21
4.3. PA-OTP-PIN-CHANGE .........................................25
5. IANA Considerations ............................................26
6. Security Considerations ........................................27
6.1. Man-in-the-Middle Attacks .................................27
6.2. Reflection ................................................28
6.3. Denial-of-Service Attacks .................................28
6.4. Replay ....................................................29
6.5. Brute-Force Attack ........................................29
6.6. FAST Facilities ...........................................30
8. Acknowledgments ................................................30
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. ASN.1 Module ....................................... 33
Appendix B. Examples of OTP Pre-Authentication Exchanges ........ 36
B.1. Four-Pass Authentication ................................. 36
B.2. Two-Pass Authentication ................................. 38
B.3. PIN Change ............................................... 40
B.4. Resynchronization ....................................... 411. Introduction ✨
1.1. Scope
This document describes a Flexible Authentication Secure Tunneling (FAST) [RFC6113] factor. It lets One-Time Password (OTP) values be used in Kerberos V5 [RFC4120] pre-authentication without needing the user's Kerberos password, which is honestly so iconic 💖. The system is built to work with different kinds of OTP algorithms, like time-based OTPs [RFC2808], counter-based tokens [RFC4226], and challenge-response systems such as [RFC2289] 🧚. It's also built to work with tokens that connect electronically to the user's computer, for example through a USB interface 🔌.
This FAST factor provides the following facilities (as defined in [RFC6113]): client-authentication, replacing-reply-key, and KDC-authentication. It does not provide the strengthening-reply-key facility 🙈.
This proposal is partly based on earlier work on bringing single-use authentication mechanisms into Kerberos [HORENEZ004] 🍓.
1.2. Overall Design
This proposal supports four-pass and two-pass variants 💅. In the four-pass system, the client sends the Key Distribution Center (KDC) an initial AS-REQ. The KDC responds with a KRB-ERROR that contains pre-authentication data, and that data includes a random nonce. The client then encrypts the nonce and sends it back to the KDC in a second AS-REQ. Finally, the KDC returns the AS-REP ✨.
In the two-pass variant, the client encrypts a timestamp instead of a nonce from the KDC, and the encrypted data goes to the KDC inside the initial AS-REQ 🦋. The two-pass system can be used when the client can figure out in advance that the KDC supports OTP pre-authentication, which OTP key should be used, and the encryption parameters the KDC needs 🔥.
In both systems, the client must generate the OTP value and two keys in order to create the message sent to the KDC 👑. Those two keys are the classic Reply Key, which decrypts the KDC's reply, and a key that encrypts the data sent to the KDC. In most cases the OTP value gets used in the key generation. But for algorithms where the KDC cannot obtain the value (for example, [RFC2289]), the system lets the client include the OTP value in the request along with the encrypted nonce 🫶. The system also supports hashed OTP values in the key derivation, for situations where the KDC can't get the plaintext OTP value 💜.
The pre-authentication data the client sends to the KDC travels inside the encrypted data provided by the FAST pre-authentication data type of the AS-REQ 🎀. The KDC then gets the OTP value, generates the same keys, and verifies the pre-authentication data by decrypting the nonce. If verification succeeds, the KDC proves it knows the Reply Key by using it to encrypt data in the AS-REP 🌈.
1.3. Conventions Used in This Document
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 [RFC2119] 📖.
This document assumes you already know the Kerberos pre-authentication framework [RFC6113], so it uses terminology and notation from that document freely 🧠.
The word padata is shorthand for pre-authentication data 💅.
2. Usage Overview 🌸
2.1. OTP Mechanism Support
As described above, this document describes a generic system for supporting different OTP mechanisms in Kerberos pre-authentication 🧚. To keep things interoperable, all implementations of this specification SHOULD provide a mechanism (for example, a provider interface) to add or remove support for a particular OTP mechanism ✨.
2.2. Pre-Authentication
This approach uses pre-authentication data in AS-REQ, AS-REP, and KRB-ERROR messages 💖.
In the four-pass system, the client starts by sending an initial AS-REQ to the KDC. That AS-REQ may contain pre-authentication data, such as the standard Kerberos password data. The KDC then decides, in an implementation-dependent way, whether OTP authentication is required. If it is, the KDC responds with a KRB-ERROR message that contains a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA 🔐.
The PA-OTP-CHALLENGE contains a KDC-generated nonce, a list of hash algorithm identifiers, and an iteration count if hashed OTP values are used (see Section 3.6). It can also carry OPTIONAL information about how the client should generate the OTP 🍓. The client then generates the OTP value and two keys: a Client Key, which encrypts the KDC's nonce, and a Reply Key, which decrypts the KDC's reply 🦋.
As described in Section 5.4.1 of [RFC6113], the FAST system uses an Armor Key to set up an encrypted tunnel for FAST factors 🛡️. As described in Section 3.6 of this document, the Client Key and Reply Key get generated from the Armor Key and the OTP value, unless the OTP algorithm doesn't let the KDC obtain the OTP value. If hash algorithm identifiers were included in the PA-OTP-CHALLENGE, the client uses the hash of the OTP value instead of the plaintext value in the key generation 🔥. Both keys have the same encryption type as the Armor Key 👑.
The generated Client Key encrypts the nonce received from the KDC. The encrypted value, along with optional information about how the OTP was generated, is then sent to the KDC in a PA-OTP-REQUEST (see Section 4.2). That PA-OTP-REQUEST sits inside the armored-data of a PA-FX-FAST-REQUEST PA-DATA element of a second AS-REQ 💌.
In the two-pass system, the client sends the PA-OTP-REQUEST in the initial AS-REQ, instead of sending it in response to a PA-OTP-CHALLENGE from the KDC. Since no challenge comes back from the KDC, the client puts an encrypted timestamp in the request rather than the encrypted KDC nonce ⏰.
In both cases, when the KDC receives a PA-OTP-REQUEST, it generates the keys the same way the client does. It then uses the generated Client Key to verify the pre-authentication by decrypting the encrypted data the client sent (either the nonce or the timestamp) 🌈. If validation succeeds, the KDC authenticates itself to the client and confirms that the Reply Key has been updated, by using the generated Reply Key in the AS-REP response ✨.
2.3. PIN Change
Bestie, most OTP tokens need a Personal Identification Number (PIN) 🔐 to make the OTP value. The token makes its value, the PIN gets mixed in with it, and the result is the final OTP that goes into this protocol. Main character energy, honestly 💅
If the KDC checks a PA-OTP-REQUEST in an AS-REQ 📨 and it's all valid, but the user's PIN has expired and needs changing, the KDC SHOULD send back a KRB-ERROR of type KDC_ERR_PIN_EXPIRED 🙈 It MAY also include formatting info about the PIN in a PA-OTP-PIN-CHANGE (see Section 4.3). That info gets encrypted inside the armored-data of the PA-FX-FAST-REPLY PA-DATA element.
KDC_ERR_PIN_EXPIRED 96If a separate PIN-change service handles the change, then it's assumed that authenticating to that service will succeed when the PIN has expired ✨
If the PIN hasn't expired but has been changed, the KDC MAY send the new value back to the client in a PA-OTP-PIN-CHANGE, encrypted inside the armored-data of the PA-FX-FAST-REPLY PA-DATA element of the AS-REP 🎀 Same vibe if no change is needed: the KDC MAY still send a PA-OTP-PIN-CHANGE to tell the client when the current PIN expires ⏰
2.4. Resynchronization
Okay, real talk: time-based and event-based tokens can get out of sync with the OTP server 😭 Event-based tokens drift because the token's counter goes up every time it's used, but the server's counter only goes up on an authentication. Time-based tokens can drift too, because their clocks wander.
How you recover depends on the OTP algorithm, but it can involve the client sending a sequence of OTP values so the server can narrow down the right spot in its search window (see Section 7.4 of [RFC4226] for an example) 🧚
If a PA-OTP-REQUEST fails pre-authentication for this reason, the KDC MAY return a KRB-ERROR message. That KRB-ERROR MAY contain a PA-OTP-CHALLENGE in the PA-DATA, with a single otp-tokenInfo for the token used in the first attempt, but with the "nextOTP" flag set 🦋 When that flag is set, the client SHOULD retry using an OTP generated from the token's next "state" after the one used in the failed attempt. For example, that could mean the next time interval or counter value ⏭️
3. Pre-Authentication Protocol Details
3.1. Initial Client Request
In four-pass mode 🌈, the client starts by sending an initial AS-REQ, which might include other pre-authentication data. If the KDC decides OTP pre-authentication is needed and the request doesn't include a PA-OTP-REQUEST, the KDC responds as described in Section 3.2.
If the client has everything it needs, it MAY use the two-pass system by building a PA-OTP-REQUEST as described in Section 3.3 and putting it in the initial request 🚀
3.2. KDC Challenge
If the user has to authenticate with an OTP, the KDC SHALL respond to the initial AS-REQ with a KRB-ERROR (as described in Section 2.2 of [RFC6113]). That KRB-ERROR carries a PA-OTP-CHALLENGE inside the enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY, encrypted under the current Armor Key as described in [RFC6113] 🔥
If the OTP mechanism runs as an individual mechanism, the PA-OTP-CHALLENGE SHALL be carried within the padata of the KrbFastResponse. If the OTP mechanism is required as part of an authentication set instead, the PA-OTP-CHALLENGE SHALL be carried within a PA-AUTHENTICATION-SET-ELEM (see Section 5.3 of [RFC6113]) 💖
The PA-OTP-CHALLENGE SHALL contain a nonce value, which gets sent back encrypted in the client's PA-OTP-REQUEST. This nonce string MUST include a randomly chosen component at least as long as the Armor Key length (see [RFC4086] for a deep dive on randomness) 🎲 To keep whatever state it needs for checking the returned nonce, the KDC SHOULD use the mechanism in Section 5.2 of [RFC6113] 🧠
The KDC MAY use the otp-service field to help the client find the OTP token by saying what the authentication is for 🔍 For example, otp-service could help a user pick the right token when they have several OTP tokens for different purposes. If the token is a connected device, these values SHOULD be an exact octet-level match for the values on the target token 🎯
The KDC SHALL include a sequence of one or more otp-tokenInfo elements. They describe the token or tokens the user can use to authenticate, and how the OTP value gets generated with them 🧾 If there's only one otp-tokenInfo element, then the KDC only accepts that one token, and any OTP value the client makes MUST be generated according to what's in that element. If there's more than one otp-tokenInfo element, the OTP value MUST be generated according to one of those elements 🎀
The KDC MAY include the otp-vendor field in an otp-tokenInfo to name the token's vendor, which helps the client find the token it can use for the request 🏷️
If the KDC can get the OTP values for the token, the OTP value SHOULD be used in key generation as described in Section 3.6. So the KDC SHOULD set the "must-encrypt-nonce" flag in the otp-tokenInfo. If the KDC can't get the OTP values for the token, the "must-encrypt-nonce" flag MUST NOT be set. If the flag isn't set, the client returns the OTP value in the otp-value field of the PA-OTP-REQUEST. So if sending OTP values that way doesn't fit KDC policy, the KDC SHOULD NOT include that token's otp-tokenInfo in the PA-OTP-CHALLENGE 🙅♀️
If the KDC requires hashed OTPs for key generation as described in Section 3.6 (say, it can only get hashed OTP values for the token), then it MUST include the supported hash algorithms, in order of preference, in the supportedHashAlg of the otp-KeyInfo, plus the minimum value of the iteration count in the iterationCount element 🔐
Here's the tricky part 😤 Since this OTP mechanism is replacing the Reply Key, the classic shared-key system can't be relied on for the client to verify the KDC. So, as described in Section 3.4 of [RFC6113], some other mechanism must be provided to support this. If the OTP value is used in Reply Key generation, the client and KDC share a key, and the KDC provides KDC-authentication using the Reply Key made from the OTP value. But if the OTP value is sent in the otp-value element of the PA-OTP-REQUEST, there's no shared key, and the OTP mechanism does NOT provide KDC-authentication. So if this mechanism isn't used somewhere KDC-authentication is handled another way (for example, with a host-key-based Armor Key), the KDC MUST NOT include any otp-tokenInfo elements in the PA-OTP-CHALLENGE that lack the "must-encrypt-nonce" flag 🛡️
If an OTP for a token is generated from a server-generated challenge, the challenge value SHALL be included in the otp-challenge field of that token's otp-tokenInfo. If the token is a connected device and the OTP is made by combining the challenge with the token's current state (for example, the time), the "combine" flag SHALL be set within the otp-tokenInfo that contains the challenge ⏱️
If the KDC can work out which OTP token key (the seed value on the token used to generate the OTP) should be used, the otp-tokenID field MAY be included in the otp-tokenInfo to pass that value to the client 🔑
The otp-algID field MAY be included in an otp-tokenInfo to name the algorithm the OTP calculation should use for that token. For example, it could come in handy when a user has been issued several tokens that support different algorithms 🧮
If the KDC can tell that a usable OTP token doesn't need the client to collect a PIN, it SHOULD set the "do-not-collect-pin" flag in the otp-tokenInfo for that token. If the token does need the client to collect a PIN, the KDC SHOULD set the "collect-pin" flag. If the KDC can't tell whether the client should collect a PIN, then the "collect-pin" and "do-not-collect-pin" flags MUST NOT be set 📌
If the KDC needs the token's PIN returned to it separately, it SHOULD set the "separate-pin-required" flag in the otp-KeyInfo for that token 🔒
If the KDC requires that the token's OTPs have a Luhn check digit appended (as defined in [ISOIEC7812]), then it MUST set the "check-digit" flag. This flag only applies when the OTP format is decimal, so the otp-format field, if present, MUST have the value "decimal" 🔢
Last one! 🎉 To support connected tokens that can make OTP values of different lengths or formats, the KDC MAY include the desired otp-length and the format of the OTP in the otp-length and otp-format fields of an otp-tokenInfo ✨
3.3. Client Response ✨
Okay bestie, so the client response SHALL be sent to the KDC as a PA-OTP-REQUEST tucked inside the enc-fast-req of the armored-data. That whole thing lives in a PA-FX-FAST-REQUEST and gets encrypted under the current Armor Key, as described in [RFC6113]. 🔐✨
To build its response, the client MUST generate an OTP value. If the PA-OTP-CHALLENGE had one or more otp-tokenInfo elements, then the OTP value MUST be based on the info in one of those elements. 💅
The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format, and otp-algID elements of the PA-OTP-CHALLENGE are the KDC helping the client find the right token 🦋 but how much each one matters depends on the type of token.
If the token is a disconnected device, then otp-service and otp-vendor MAY be shown to the user so they can pick the correct token, and otp-algID, otp-tokenID, otp-length, and otp-format MAY be ignored. 📱
If the token is a connected device, then these values, if present, SHOULD be used by the client to locate the correct token. When the token is connected, clients MUST support matching based on a binary comparison of the otp-vendor and otp-service strings against the values on the token. Clients MAY have other comparisons, including normalization insensitive comparisons, to try and find the right token. The values of otp-vendor and otp-service MAY be displayed to prompt the user if the correct token is not found. 🔍
If the "nextOTP" flag is set in the otp-tokenInfo from the PA-OTP-CHALLENGE, then the OTP value MUST be generated from the next token state rather than the one used in the previous PA-OTP-REQUEST for that token. The "nextOTP" flag MUST also be set in the new PA-OTP-REQUEST. ⏭️
If the "collect-pin" flag is set, then the token needs a PIN collected by the client. If the "do-not-collect-pin" flag is set in the otp-tokenInfo from the PA-OTP-CHALLENGE, then the token represented by that otp-tokenInfo does not need a PIN collected by the client as part of the OTP value. If neither of the "collect-pin" nor "do-not-collect-pin" flags are set, then the PIN requirements of the token are unspecified. If both flags are set, then the client SHALL regard the request as invalid. 🙅♀️
If the "separate-pin-required" flag is set, then any PIN collected by the client MUST be included as a UTF-8 string in the otp-pin of the PA-OTP-REQUEST. 🔢
If the token is a connected device, then how the PIN gets used to generate the OTP value depends on the type of device. If the token is disconnected, though, it depends on the "separate-pin-required" flag. If that flag is not set, then the OTP value MUST be generated by appending the PIN with the value from the token entered by the user. If the flag is set, then the OTP value MUST be the value from the token. 🧩
The clients SHOULD NOT normalize the PIN value or any OTP value collected from the user or returned by a connected token in any way. 🙅
If the "check-digit" flag is set, then any OTP values SHOULD be decimal and have a Luhn check digit appended [ISOIEC7812]. If the token is disconnected, then the Client MAY ignore this flag. If the token is connected, then the Client MUST enforce it. The Client MUST regard the request as invalid if otp-format is present and set to any value other than "decimal". 🔢
If an otp-challenge is present in the otp-tokenInfo the client selected from the PA-OTP-CHALLENGE, then the OTP value for the token MUST be generated based on a challenge, as long as the token is capable of accepting one. The client MAY ignore the provided challenge if and only if the token is not capable of including a challenge in the OTP calculation. 🧠
If the "combine" flag is not set in the otp-tokenInfo of the PA-OTP-CHALLENGE, then the OTP SHALL be calculated based only on the challenge and not on the internal state (e.g., time or counter) of the token. If the "combine" flag is set, then the OTP SHALL be calculated using both the internal state and the provided challenge, if that value is obtainable by the client. If the flag is set but otp-challenge is not present, then the client SHALL regard the request as invalid. 🤝
If the token is a connected device, then how the challenge gets used depends on the type of device. It will involve passing the challenge and the value of the "combine" flag to the token in a token-specific manner, along with a PIN if one was collected and the values of otp-length and otp-format if specified, to get the OTP value. If the token is disconnected, then the challenge MUST be displayed to the user, and the client MAY ignore the value of the "combine" flag. 📟
If the OTP value was generated using a challenge that the KDC did not send, then the challenge SHALL be included in the otp-challenge of the PA-OTP-REQUEST. If the OTP was generated by combining a challenge (either received from the KDC or generated by the client) with the token state, then the "combine" flag SHALL be set in the PA-OTP-REQUEST. 📨
If the "must-encrypt-nonce" flag is set in the otp-tokenInfo, then the OTP value MUST be used to generate the Client Key and Reply Key as described in Section 3.6, and it MUST NOT be included in the otp-value field of the PA-OTP-REQUEST. If the flag is not set, then the OTP value MUST be included in the otp-value field of the PA-OTP-REQUEST and MUST NOT be used in the key derivation. In that case, the Client Key and Reply Key SHALL be the same as the Armor Key, as described in Section 3.6. So, if returning OTP values this way doesn't conform to local policy on the client (for example, if KDC-Authentication is required and isn't being provided by other means), then the client SHOULD NOT use the token for authentication. 🔑
If the supportedHashAlg and iterationCount elements are included in the otp-tokenInfo, then the client MUST use hashed OTP values in generating the Reply Key and Client Key, as described in Section 3.6. The client MUST select the first algorithm from the list that it supports, and the AlgorithmIdentifer [RFC5280] it selects MUST be placed in the hashAlg element of the PA-OTP-REQUEST. However, if none of the algorithm identifiers conform to local policy restrictions, then the authentication attempt MUST NOT proceed using that token. If the value of iterationCount does not conform to local policy on the client, then the client MAY use a larger value, but it MUST NOT use a lower value. The value of the iteration count used by the client MUST be returned in the PA-OTP-REQUEST sent to the KDC. 🧂
If hashed OTP values are used, then the nonce generated by the client MUST be as long as the longest key length of the symmetric key types it supports, and it MUST be chosen randomly (see [RFC4086]). The nonce MUST be included in the PA-OTP-REQUEST, along with the hash algorithm and iteration count used in the nonce, in the hashAlg and iterationCount fields of the PA-OTP-REQUEST. These fields MUST NOT be included if hashed OTP values were not used. It is RECOMMENDED that the iteration count the client uses be chosen so that it is computationally infeasible or unattractive for an attacker to brute-force search for the given OTP. 🎲
The PA-OTP-REQUEST the client returns SHOULD include information on the generated OTP value reported by the OTP token, when that's available to the client. The otp-time and otp-counter fields of the PA-OTP-REQUEST SHOULD be used to return the time and counter values the token used, if available to the client. The otp-format field MAY be used to report the format of the generated OTP. This field SHOULD be used if a token can generate OTP values in multiple formats. The otp-algID field SHOULD be used by the client to report the algorithm used in the OTP calculation, and the otp-tokenID SHOULD be used to report the identifier of the OTP token key used, if the client knows that information. 📊
If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained an otp-vendor field in the selected otp-tokenInfo, then the otp-vendor field of the PA-OTP-REQUEST MUST be set to the same value. If the KDC didn't provide an otp-vendor field, then the field SHOULD be set to the vendor identifier of the token, if the client knows it. 🏷️
The generated Client Key is used by the client to encrypt the data to be included in the encData of the PA-OTP-REQUEST, which lets the KDC authenticate the user. The key usage for this encryption is KEY_USAGE_OTP_REQUEST. 🗝️
- If the
PA-OTP-REQUESTis being generated in response to aPA-OTP-CHALLENGEreturned by the KDC, then the client SHALL encrypt aPA-OTP-ENC-REQUESTcontaining the value ofnoncefrom thePA-OTP-CHALLENGE, using the same encryption type as the Armor Key. - If the
PA-OTP-REQUESTis not in response to aPA-OTP-CHALLENGE, then the client SHALL encrypt aPA-ENC-TS-ENCcontaining the current time, as in the encrypted timestamp pre-authentication mechanism [RFC4120].
If the client is working in two-pass mode and so is not responding to an initial KDC challenge, then the values of the iteration count and hash algorithms can't be obtained from that challenge. The client SHOULD use any values obtained from a previous PA-OTP-CHALLENGE, or, if no values are available, it MAY use initial configured values. 🔁
3.4. Verifying the Pre-Authentication Data ✨
okay so this is where the KDC gets to be the detective 🕵️♀️. It rebuilds the Client Key and Reply Key the same way the client did, then uses that Client Key to unlock the encData from the PA-OTP-REQUEST. The Reply Key it generated is what gets used to encrypt stuff in the AS-REP 🔐.
If the otp-value field is in the PA-OTP-REQUEST, the KDC MUST use that value, unless the OTP method is required to support KDC-authentication (see Section 3.2). If there's no otp-value, then the KDC will need to generate or obtain the OTP value itself 💅.
If the otp-pin field is present, the PIN has to be the one the client provided. The KDC SHOULD SASLPrep (Stringprep Profile for User Names and Passwords) [RFC4013] the value in lookup mode before comparing it 🎀.
It's worth noting that as better string comparison technologies get standardized, the way the KDC processes this will change too. The goal is still to stay as compatible with SASLprep as possible 🌸.
If the otp-challenge field is there, then the OTP was calculated using that challenge. If the "combine" flag is also set, then the OTP was calculated using the challenge AND the token's current state 🔥.
It is RECOMMENDED that the KDC act on the values of otp-time, otp-counter, otp-format, otp-algID, and otp-tokenID if they show up in the PA-OTP-REQUEST. If the KDC gets a request with these values but can't act on them, then they MAY be ignored 🦋.
The KDC generates the Client Key and Reply Key as described in Section 3.6, using the OTP value plus the nonce, hash algorithm, and iteration count (if they're present in the PA-OTP-REQUEST). The KDC MUST fail the request with KDC_ERR_INVALID_HASH_ALG if the KDC requires hashed OTP values and the hashAlg field wasn't present in the PA-OTP-REQUEST, or if the value of that field doesn't match local KDC policy. Similarly, the KDC MUST fail the request with KDC_ERR_INVALID_ITERATION_COUNT if the iterationCount in the PA-OTP-REQUEST doesn't match local KDC policy, or if it's less than what's specified in the PA-OTP-CHALLENGE. Also, the KDC MUST fail the authentication request with KDC_ERR_PIN_REQUIRED if it needs a separate PIN on top of the OTP value and no otp-pin was included in the PA-OTP-REQUEST 🙈. Here are the error codes:
KDC_ERR_INVALID_HASH_ALG 94
KDC_ERR_INVALID_ITERATION_COUNT 95
KDC_ERR_PIN_REQUIRED 97Next, the generated Client Key gets used to decrypt the encData from the PA-OTP-REQUEST. If the client response was sent because of a PA-OTP-CHALLENGE, then the decrypted data will be a PA-OTP-ENC-REQUEST, and the client authentication MUST fail with KDC_ERR_PREAUTH_FAILED if the nonce in the PA-OTP-ENC-REQUEST isn't the same as the nonce that was sent in the PA-OTP-CHALLENGE 😭. If the response was NOT sent because of a PA-OTP-CHALLENGE, then the decrypted value will be a PA-ENC-TS-ENC, and the authentication process works the same way as classic encrypted timestamp pre-authentication [RFC4120] 💖.
The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP if the encryption type the client used in the encData doesn't match KDC policy 💀.
If authentication fails because of the hash algorithm, the iteration count, or the encryption type the client used, then the KDC SHOULD return a PA-OTP-CHALLENGE with the required values in the error response. If authentication fails because the token state on the server is no longer in sync with the token that was used, then the KDC MAY return a PA-OTP-CHALLENGE with the "nextOTP" flag set, as described in Section 2.4 🔄.
If, during authentication, the KDC works out that the user's PIN has been changed, then it SHOULD include a PA-OTP-PIN-CHANGE in the response (see Section 2.3) containing the new PIN value 🧚. The KDC MAY also include the new PIN's expiration time and the expiration time of the OTP account within the last-req field of the PA-OTP-PIN-CHANGE. (These fields are useful when the account tied to the user's OTP token has a different expiration time than the user's Kerberos account.) If the KDC sees that the user's PIN or OTP account is about to expire, it MAY return a PA-OTP-PIN-CHANGE with that information 👑. Finally, if the KDC determines the user's PIN has expired, then it SHOULD return a KRB-ERROR of type KDC_ERR_PIN_EXPIRED, as described in Section 2.3 🫶.
3.5. Confirming the Reply Key Change
Once the pre-authentication data checks out, the KDC SHALL respond to the client's PA-OTP-REQUEST by using the generated Reply Key to encrypt the data in the AS-REP. This is what gives us mutual authentication 🤝. The client then uses its own generated Reply Key to decrypt that data, and it MUST NOT continue with the authentication process if decryption isn't successful. no cap, that's a hard stop 🛑.
3.6. Reply Key Generation
Okay, so to authenticate the user, the client and the KDC both need to generate two encryption keys 🔑:
- The Client Key, which the client uses to encrypt and the KDC uses to decrypt the encData in the PA-OTP-REQUEST.
- The Reply Key, which the KDC uses in the standard way to encrypt data in the AS-REP.
How the two keys get made depends on the OTP algorithm 🧠.
- If the OTP value is included in the otp-value of the PA-OTP-REQUEST, then the two keys SHALL be the same as the Armor Key (defined in [RFC6113]).
- If the OTP value is NOT included in the otp-value of the PA-OTP-REQUEST, then the two keys SHALL be derived from the Armor Key and the OTP value, as described below.
If the OTP value isn't in the PA-OTP-REQUEST, then the Reply Key and Client Key SHALL be generated using the KRB-FX-CF2 algorithm from [RFC6113], like this:
Client Key = KRB-FX-CF2(K1, K2, O1, O2)
Reply Key = KRB-FX-CF2(K1, K2, O3, O4)The octet string parameters, O1, O2, O3, and O4 shall be the ASCII string "OTPComb1", "OTPComb2", "OTPComb3", and "OTPComb4", as shown below 🌈:
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}The first input key, K1, SHALL be the Armor Key. As described in Section 5.1 of [RFC6113], the enctypes of the generated Client Key and Reply Key will match the enctype of the Armor Key. The second input key, K2, shall be derived from the OTP value using string-to-key (defined in [RFC3961]), as described below 💜.
If the hash of the OTP value is going to be used, then K2 SHALL be derived like this:
- An initial hash value, H, gets generated:
H = hash(realm|nonce|OTP)Where:
- "|" denotes concatenation.
- hash is the hash algorithm the client selected.
- realm is the name of the server's realm, as carried in the realm field of the AS-REQ (not including the tag and length from the DER encoding).
- nonce is the random nonce value the client generated and carried in the nonce field of the PA-OTP-REQUEST (not including the tag and length from the DER encoding).
- If the OTP format is decimal, hexadecimal, or alphanumeric, then OTP is the value of the OTP generated as described in Section 3.3, with SASLPrep [RFC4013] applied in lookup mode. Otherwise, it's the unnormalized OTP value.
- The initial hash value then gets hashed iterationCount-1 times to produce a final hash value, H' (where iterationCount is the value from the PA-OTP-REQUEST):
H' = hash(hash(...(iterationCount-1 times)...(H)))- The value of K2 is then derived from the Base64 [RFC2045] encoding of this final hash value:
K2 = string-to-key(Base64(H')|"Krb-preAuth")If the hash value isn't used, then K2 SHALL be derived from the base64 encoding of the OTP value:
K2 = string-to-key(Base64(OTP)|"Krb-preAuth")The enctype used for string-to-key SHALL be the enctype of the Armor Key. The salt and any additional parameters for string-to-key MAY be provided by the KDC in the PA-OTP-CHALLENGE. If the salt and string-to-key parameters aren't provided, then the default values defined for that particular enctype SHALL be used 🍓.
If the strengthen-key is present in KrbFastResponse, then it gets combined with the Reply Key to generate the final AS-REQ, as described in [RFC6113]. The strengthen-key does NOT influence the Client Key 🎀.
4. OTP Kerberos Message Types ✨
4.1. PA-OTP-CHALLENGE ✨
okay bestie so this is the padata-type PA-OTP-CHALLENGE 🎀 the KDC sends it back to the client inside the enc-fast-rep of a PA-FX-FAST-REPLY, which sits in the PA-DATA of a KRB-ERROR, whenever OTP pre-authentication is required 🔥 the padata-value is the Distinguished Encoding Rules (DER) [X.680] and [X.690] encoding of a PA-OTP-CHALLENGE. it holds a server-generated nonce plus everything the client needs to know to make its OTP 💅
PA-OTP-CHALLENGE 141
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)nonce
this is a KDC-supplied nonce that the client has to encrypt in the PA-OTP-REQUEST 🔐 this nonce string MUST contain a randomly chosen component at least as long as the Armor Key length 🫶
otp-service
use of this field is OPTIONAL, but MAY be used by the KDC to help the client find the right OTP tokens 🧚 for example, it could come in clutch when a user has multiple OTP tokens for different purposes 💜
otp-tokenInfo
this element MUST be included 🎀 it's a sequence of one or more OTP-TOKENINFO objects that describe the token or tokens the user can authenticate with, and how the OTP value is supposed to be generated with them. if a single OTP-TOKENINFO object is included, then only a single token is acceptable to the KDC, and any OTP value the client generates MUST be generated according to the information in that element. if more than one OTP-TOKENINFO object is included, then the OTP value MUST be generated according to the information in one of those objects 🦋
flags
if the "nextOTP" flag is set, the OTP SHALL be based on the next token "state" instead of the one used in the previous authentication ⏭️ for a time-based token, that means the next time slot, and for an event-based token it could mean the next counter value. if the "nextOTP" flag is set, then there MUST only be a single otp-tokenInfo element in the PA-OTP-CHALLENGE 🙈
the "combine" flag controls how the challenge in otp-challenge gets used 🍓 if the flag is set, the OTP SHALL be calculated using the challenge from otp-challenge and the internal token state (like the time or a counter). if the "combine" flag is not set, the OTP SHALL be calculated based only on the challenge. if the flag is set and otp-challenge is not present, then the request SHALL be regarded as invalid ❌
if the "do-not-collect-pin" flag is set, the token represented by the current otp-tokenInfo does not need a PIN collected as part of the OTP 🙅♀️ if the "collect-pin" flag is set, the token does need a PIN. if neither flag is set, whether or not a PIN is required is unspecified 🤷♀️ the flags are mutually exclusive, so both flags MUST NOT be set, or the client MUST regard the request as invalid 💀
if the "must-encrypt-nonce" flag is set, the OTP value MUST NOT be included in the otp-value field of the PA-OTP-REQUEST 🔒 instead, the OTP value MUST be used in the generation of the Reply Key and Client Key as described in Section 3.6 ✨
if the "separate-pin-required" flag is set, the PIN the client collected SHOULD NOT be used in generating the OTP value, and it SHOULD be returned in the otp-pin field of the PA-OTP-REQUEST 🌸
the "check-digit" flag controls whether the OTP values the token generates need to include a Luhn check digit [ISOIEC7812] 🔢 if the token is disconnected, the Client MAY ignore this flag. but if the flag is set and the token is connected, then the OTP MUST be a decimal with a check digit appended 👑
otp-vendor
use of this field is OPTIONAL, but MAY be used by the KDC to identify the vendor of the OTP token to be used 🏷️
otp-challenge
the otp-challenge is how the KDC sends a challenge value for the OTP calculation 🎯 the challenge is an OPTIONAL octet string that SHOULD be uniquely generated for each request it shows up in. when the challenge isn't present, the OTP is calculated on the current token state only. the client MAY ignore a provided challenge if and only if the OTP token it's talking to can't include a challenge in the OTP calculation. in that case, KDC policies decide whether a provided OTP value gets accepted 🙏
otp-length
use of this field is OPTIONAL, but MAY be used by the KDC to set the desired length of the generated OTP 📏 for example, it could be used when a token can make OTP values of different lengths. if the OTP format is 'decimal', 'hexidecimal', or 'alphanumeric', this value is the desired length in digits or characters. if the OTP format is 'binary', it's the desired length in octets. and if the OTP format is 'base64', it's the desired length of the unencoded OTP value in octets 🧮
otp-format
use of this field is OPTIONAL, but MAY be used by the KDC to set the desired format of the generated OTP value 🎨 for example, it could be used when a token can produce OTP values in different formats 💖
otp-tokenID
use of this field is OPTIONAL, but MAY be used by the KDC to identify which token key should be used for the authentication 🗝️ for example, it could be used when a user has been issued multiple token keys by the same server 🫧
otp-algID
use of this field is OPTIONAL, but MAY be used by the KDC to identify the algorithm to use when generating the OTP ⚙️ the value of this field MUST be a URI [RFC3986] and SHOULD be obtained from the Portable Symmetric Key Container (PSKC) algorithm registry [RFC6030] 📚
supportedHashAlg
if this is present, then a hash of the OTP value MUST be used in the key derivation instead of the plain text value 🌈 each AlgorithmIdentifier names a hash algorithm the KDC supports, listed in decreasing order of preference. the client MUST select the first algorithm from the list that it supports 🥇 support for SHA-256 by both the client and KDC is REQUIRED 🫶 and the AlgorithmIdentifier the client picks MUST be placed in the hashAlg element of the PA-OTP-REQUEST 💅
iterationCount
this is the minimum iteration count the client has to use when hashing the OTP value ⏱️ this value MUST be present if supportedHashAlg is present, and otherwise MUST NOT be present. if the value doesn't conform to local policy on the client, the client MAY use a larger value but MUST NOT use a lower value 🙅♀️ and the iteration count the client actually used MUST be returned in the PA-OTP-REQUEST sent to the KDC 📬
salt
this is the salt value used in string-to-key when calculating the keys as described in Section 3.6 🧂
s2kparams
these are any extra parameters string-to-key needs, as described in Section 3.6 🧪
4.2. PA-OTP-REQUEST 🎀
okay bestie, so PA-OTP-REQUEST is the padata-type the client sends to the KDC 💌 It rides inside the KrbFastReq padata of a PA-FX-FAST-REQUEST, which lives in the PA-DATA of an AS-REQ. The padata-value is the DER encoding of a PA-OTP-REQUEST ✨
The message carries pre-authentication data encrypted by the client with the generated Client Key, plus optional info on how the OTP was made. It can also, optionally, include the generated OTP value 🔐
PA-OTP-REQUEST 142
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
KEY_USAGE_OTP_REQUEST 45
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}flags 💖 This field MUST be present.
If the "nextOTP" flag is set, then the OTP was calculated based on the next token "state" rather than the current one. This flag MUST be set if and only if it was set in a corresponding PA-OTP-CHALLENGE.
If the "combine" flag is set, then the OTP was calculated based on a challenge and the token state.
No other OTPFlag bits are applicable and MUST be ignored by the KDC.
nonce 🌸 This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the nonce value generated by the client and used in the generation of hashed OTP values as described in Section 3.6. This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports and MUST be chosen randomly.
encData 🧚 This field MUST be present and MUST contain the pre-authentication data encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then this MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-CHALLENGE. If no challenge was received, then this MUST contain a PA-ENC-TS-ENC.
hashAlg 🍓 This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the AlgorithmIdentifier of the hash algorithm used. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then the AlgorithmIdentifer MUST be the first one supported by the client from the supportedHashAlg of the PA-OTP-CHALLENGE.
iterationCount 🔢 This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the iteration count used when hashing the OTP value. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then the value MUST NOT be less than what was specified in the PA-OTP-CHALLENGE.
otp-value 🙈 The generated OTP value. This value MUST NOT be present if the "must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE.
otp-pin 🔑 The OTP PIN value entered by the user. This value MUST NOT be present unless the "separate-pin-required" flag was set in the PA-OTP-CHALLENGE.
otp-challenge 🧩 The value the client used in the OTP calculation. It MUST be sent to the KDC if and only if the value would otherwise be unknown to the KDC (for example, the token- or client-modified or generated challenge).
otp-time ⏰ This field MAY be included by the client to carry the time value as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by a client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-counter 🔁 This field MAY be included by the client to carry the token counter value, as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by a client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-format 🎨 This field MAY be used by the client to send the format of the generated OTP as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-tokenID 🪪 This field MAY be used by the client to send the identifier of the token key used, as reported by the OTP token. Use of this field is OPTIONAL, but MAY be used by the client to simplify the authentication process by identifying a particular token key associated with the user. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value.
otp-algID 🧮 This field MAY be used by the client to send the identifier of the OTP algorithm used, as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value. The value of this field MUST be a URI [RFC3986] and SHOULD be obtained from the PSKC algorithm registry [RFC6030].
otp-vendor 🏷️ If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained an otp-vendor field in the selected otp-tokenInfo, then this field MUST be set to the same value; otherwise, this field SHOULD be set to the vendor identifier of the token, if known to the client. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
4.3. PA-OTP-PIN-CHANGE 🌈
the PA-OTP-PIN-CHANGE padata-type is returned by the KDC in the enc-fast-rep of a PA-FX-FAST-REPLY in the AS-REP 💅 It shows up when the user has to change their PIN, when their PIN has already been changed, or to let them know when the PIN expires ⏳
The padata-value is the DER encoding of a PA-OTP-PIN-CHANGE ✨
PA-OTP-PIN-CHANGE 144
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)flags 🔐 The "systemSetPin" flag tells you what kind of PIN change is happening. If the flag is set, then the system has changed the user's PIN for them. If the flag is not set, then the user has to change their own PIN.
If the "systemSetPin" flag is not set and the "mandatory" flag is set, then the user PIN change is required before the next authentication using the current OTP token. If the "mandatory" flag is not set, then the user PIN change is optional. If the "systemSetPin" flag is set, then the "mandatory" flag has no meaning and SHOULD be ignored by the client.
pin 🧸 The pin field carries a new PIN value. If the "systemSetPin" flag is set, then the pin field carries the new PIN value set for the user and MUST be present. If the "systemSetPin" flag is not set, then use of this field is OPTIONAL and MAY be used to carry a system-generated PIN that MAY be used by the user when changing the PIN.
minLength and maxLength 📏 Use of the minLength and maxLength fields is OPTIONAL. If the "systemSetPin" flag is not set, then these fields MAY be included to pass restrictions on the size of the user-selected PIN.
last-req 📅 Use of the last-req field (as defined in Section 5.4.2 of [RFC4120])) is OPTIONAL, but MAY be included with an lr-type of 6 to carry PIN expiration information.
- If the "systemSetPin" flag is set, then the expiration time MUST be that of the new system-set PIN.
- If the "systemSetPin" flag is not set, then the expiration time MUST be that of the current PIN of the token used in the authentication.
The element MAY also be included with an lr-type of 7 to indicate when the OTP account will expire.
format 🎀 The format element MAY be included by the KDC to carry format restrictions on the new PIN.
- If the "systemSetPin" flag is set, then the element MUST describe the format of the new system-generated PIN.
- If the "systemSetPin" flag is not set, then the element MUST describe restrictions on any new user-generated PIN.
5. IANA Considerations 🦋
The OTP algorithm identifier URIs used as otp-algID values in the PA-OTP-CHALLENGE described in Section 4.1 and the PA-OTP-REQUEST described in Section 4.2 have been registered in the "Algorithm URI Registry and Related PSKC Profiles" registry [RFC6030].
These pre-authentication types are defined in this document:
PA-OTP-CHALLENGE 141
PA-OTP-REQUEST 142
PA-OTP-PIN-CHANGE 144Note that PA-OTP-CONFIRM (143) has been marked as OBSOLETE per this document.
These values are currently registered in a registry created by [RFC6113], but the entries have been updated to refer to this document.
These error codes and key usage values are defined in this document:
KDC_ERR_INVALID_HASH_ALG 94
KDC_ERR_INVALID_ITERATION_COUNT 95
KDC_ERR_PIN_EXPIRED 96
KDC_ERR_PIN_REQUIRED 97
KEY_USAGE_OTP_REQUEST 45These values are currently not managed by IANA and have not been accounted for. There is currently work in progress [LHA10] to define IANA registries and a registration process for these values.
6. Security Considerations 🔥
6.1. Man-in-the-Middle Attacks 🕵️♀️
Okay so the OTP pre-authentication protocol gets tunneled inside the FAST Armor channel that the pre-authentication framework gives us 🎀. As [ASNINY02] explains, tunneled protocols can be vulnerable to man-in-the-middle (MITM) attacks if the outer tunnel is compromised. It's generally considered good practice in that situation to bind the inner encryption to the outer tunnel 🔒.
To block that, this system uses the outer Armor Key when deriving the inner Client and Reply keys. That gets it crypto-binding to the outer channel, and honestly it's giving security 💅.
Section 5.4 of [RFC6113] says FAST can use an anonymous Ticket-Granting Ticket (TGT) obtained through anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC6112] [RFC4556] as the Armor Key. The catch is that the current anonymous PKINIT proposal is open to MITM attacks. The attacker can pick a session key so that the session key between the MITM and the real KDC matches the session key between the client and the MITM 😭.
As Section 3.6 describes, if the OTP value isn't sent to the KDC, the Armor Key is used together with the OTP value to generate the Client Key and Reply Key. If the Armor Key is known, the only entropy left in that key generation comes from the OTP value 🧐. If the OTP algorithm needs the OTP value sent to the KDC, it's sent encrypted inside the FAST Armor tunnel. That means an attacker who has the Armor Key can see it 💀.
Therefore, unless the identity of the KDC has been verified, anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC.
Also, the security considerations should be carefully considered before anonymous PKINIT is used with other algorithms, like ones with short OTP values 🙈.
Be extra careful too if you use host key armor for the KDC-authentication facility with OTP algorithms where the OTP value is sent within the otp-value field of the PA-OTP-REQUEST. Compromised host keys would let an attacker impersonate the KDC 🚨.
6.2. Reflection 🪞
The four-pass system described above is a challenge-response protocol, and those are potentially vulnerable to reflection attacks. No such attacks are known at this point 🙌. Still, to help mitigate them, the system uses different keys to encrypt the client and server nonces.
6.3. Denial-of-Service Attacks 😬
The protocol supports an iteration count in generating the Client and Reply keys, and the client can send the number of iterations used as part of the PA-OTP-REQUEST. That could open the KDC up to a denial-of-service attack if an attacker specifies a really large iteration count.
So it's super important that, as Section 3.4 describes, the KDC rejects any authentication request where the iteration count is above a maximum value set by local policy 🛑.
6.4. Replay 🔁
In the four-pass version of this protocol, the client encrypts a KDC-generated nonce, so the KDC can detect replay. The two-pass version doesn't involve a server nonce. The client encrypts a timestamp instead, so it isn't protected from replay in that same way. It will need some other mechanism, like an OTP-server-based system or a timestamp-based replay cache on the KDC ⏰.
As Section 5.2 of [RFC6113] describes, a client can't be certain it'll use the same KDC for every message in a conversation. So the client can't assume the PA-OTP-REQUEST will go to the same KDC that issued the PA-OTP-CHALLENGE. To support this, a KDC implementing this protocol needs a way to share session state. But doing that introduces the possibility of a replay attack where the same response gets sent to multiple KDCs 👯.
For time- or event-based tokens, or server-generated challenges, protection against replay may come from the OTP server being used, if that server can keep track of the last used value. This protection relies on the OTP server being either non-redundant, or using a commit protocol to synchronize between replicas. If that doesn't hold for an OTP server being used, the system may be vulnerable to replay attacks 😱.
However, OTP servers may not be able to detect replay of OTPs generated using only a client-generated challenge. Since the KDC wouldn't be able to detect replay in two-pass mode, it is recommended that the use of OTPs generated from only a client-generated challenge (that is, not in combination with some other factor such as time) should not be supported in two-pass mode 🙅♀️.
6.5. Brute-Force Attack 🔨
A compromised or hostile KDC may be able to obtain the OTP value used by the client through a brute-force attack. If the OTP value is short, the KDC could iterate over the possible OTP values until it generates a Client Key that can decrypt the encData sent in the PA-OTP-REQUEST.
As Section 3.6 describes, an iteration count can be used in generating the Client Key, and its value can be controlled by local client policy. Using this iteration count can make it computationally infeasible/unattractive for an attacker to brute-force search for the given OTP within that OTP's lifetime 🧮.
If PINs contain international characters, similar looking or similar functioning characters may be mapped together. For example, combined and decomposed forms of accented characters will typically be treated the same. Users who try to exploit quirks of international characters to boost their PINs may get false positives, meaning PINs they meant to be distinct actually aren't. This decision was made to improve usability across the widest variety of input methods. Users can pick other methods to add strength to their PINs 💅.
6.6. FAST Facilities 👑
The secret used to generate the OTP is known only to the client and the KDC. So when the KDC successfully decrypts the encrypted nonce, that authenticates the user 🔐. If the OTP value is used in Reply Key generation, then the client successfully decrypting the encrypted nonce proves that the expected KDC replied.
The Reply Key is replaced by either a key generated from the OTP and Armor Key, or by the Armor Key. This FAST factor therefore provides these facilities: client-authentication, replacing-reply-key, and, depending on the OTP algorithm, KDC-authentication 🧚.
7. Acknowledgments 🫶
Many significant contributions were made to this document by RSA employees, but special thanks go to Magnus Nystrom, John Linn, Richard Zhang, Piers Bowness, Robert Philpott, Robert Polansky, and Boris Khoutorski 💜.
Lots of valuable suggestions also came from members of the Kerberos Working Group. Special thanks go to Larry Zhu, Jeffrey Hutzelman, Tim Alsop, Henry Hotz, Nicolas Williams, Sam Hartman, Frank Cusak, Simon Josefsson, Greg Hudson, and Linus Nordberg 🌸.
I (the author) would also like to thank Tim Alsop and Srinivas Cheruku of CyberSafe for many valuable review comments 🍓.
8. References 📚
8.1. Normative References
[ISOIEC7812] ISO, "ISO/IEC 7812-1:2006 Identification cards --
Identification of issuers -- Part 1: Numbering system",
October 2006, <http://www.iso.org/iso/iso_catalogue/
catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos (PKINIT)", RFC 4556,
June 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support
for Kerberos", RFC 6112, April 2011.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for
Kerberos Pre-Authentication", RFC 6113, April 2011.
[X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC
8824-1:2002, Information technology - Abstract Syntax
Notation One (ASN.1): Specification of basic notation.",
July 2002.
[X.690] ITU-T, "Recommendation X.690 (2008) | ISO/IEC
8825-1:2008, X.690 : Information technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", December 2008.8.2. Informative References
[ASNINY02] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication Protocols", Cryptology ePrint
Archive Report 2002/163, November 2002.
[HORENEZ004] Horstein, K., Renard, K., Neuman, C., and G. Zorn,
"Integrating Single-use Authentication Mechanisms with
Kerberos", Work in Progress, July 2004.
[LHA10] Hornquist Astrand, L., "Kerberos number registry to
IANA", Work in Progress, March 2010.
[RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A
One-Time Password System", STD 61, RFC 2289, February
1998.
[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
April 2000.
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D.,
and O. Ranen, "HOTP: An HMAC-Based One-Time Password
Algorithm", RFC 4226, December 2005.
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
Key Container (PSKC)", RFC 6030, October 2010.Appendix A. ASN.1 Module ✨
Okay bestie, the ASN.1 module is where the whole OTP pre-auth vibe gets locked into actual types 💅 Everything from the Kerberos spec and PKIX gets imported first, then the OTP structures get defined. Read it like a menu of every field that can show up in a message 🫶
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
KerberosTime, KerberosFlags, EncryptionKey, Int32,
EncryptedData, LastReq, KerberosString
FROM KerberosV5Spec2 {iso(1) identified-organization(3)
dod(6) internet(1) security(5)
kerberosV5(2) modules(4) krb5spec2(2)}
-- as defined in RFC 4120.
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1)
security (5) mechanisms (5) pkix (7)
id-mod (0) id-pkix1-explicit (18) };
-- As defined in RFC 5280.
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
AnyURI ::= UTF8String
(CONSTRAINED BY {
-- MUST be a valid URI in accordance with IETF RFC 2396
})
ENDAppendix B. Examples of OTP Pre-Authentication Exchanges
This section is non-normative. 🌸 Translation: these are just worked examples to help you picture how the pieces click together, not rules you have to follow to the letter.
B.1. Four-Pass Authentication
In this mode, the client sends an initial AS-REQ to the KDC that does not contain a PA-OTP-REQUEST, and the KDC responds with a KRB-ERROR containing a PA-OTP-CHALLENGE. Four passes, very dramatic 🎀
In this example, the user has a connected, time-based token, and the KDC wants hashed OTP values in the key generation, with SHA-384 as the preferred hash algorithm and a minimum of 1024 iterations. Meanwhile, the client's local policy supports SHA-256 and insists on 100,000 iterations of the hash of the OTP value. Two different opinions, lol 💀
Here's the basic flow:
- The client obtains the user name of the user.
- The client sends an initial AS-REQ to the KDC that does not contain a PA-OTP-REQUEST.
- The KDC determines that the user identified by the AS-REQ requires OTP authentication.
- The KDC constructs a PA-OTP-CHALLENGE as follows:
nonce: A randomly generated value.otp-service: A string that can be used by the client to assist the user in locating the correct token.otp-tokenInfo: Information about how the OTP should be generated from the token.flags:must-encrypt-nonceandcollect-pinbits set.supportedHashAlg: AlgorithmIdentifiers for SHA-384, SHA-256, and SHA-1.iterationCount: 1024.
- The KDC returns a KRB-ERROR with an error code of
KDC_ERR_PREAUTH_REQUIREDand the PA-OTP-CHALLENGE in the e-data. - The client displays the value of
otp-serviceand prompts the user to connect the token. 🔌 - The client collects a PIN from the user.
- The client obtains the current OTP value from the token using the PIN, and records the time as reported by the token.
- The client generates the Client Key and Reply Key as described in Section 3.6, using SHA-256 from the list of algorithms sent by the KDC, the iteration count of 100,000 as required by local policy, and a randomly generated nonce.
- The client constructs a PA-OTP-REQUEST as follows:
flags: 0nonce: The randomly generated value.encData: An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and the encryption type of the Armor Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-OTP-CHALLENGE.hashAlg: SHA-256iterationCount: 100,000otp-time: The time used in the OTP calculation as reported by the OTP token.
- The client encrypts the PA-OTP-REQUEST within the
enc-fast-reqof a PA-FX-FAST-REQUEST. - The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
- The KDC validates the padata in the PA-OTP-REQUEST by performing the following steps:
- It generates the Client Key and Reply Key from the OTP value for the user identified in the AS-REQ, using an iteration count of 100,000, a hash algorithm of SHA-256, and the nonce as specified in the PA-OTP-REQUEST.
- It uses the generated Client Key to decrypt the PA-OTP-ENC-REQUEST in the encData of the PA-OTP-REQUEST.
- It authenticates the user by comparing the nonce value from the decrypted PA-OTP-ENC-REQUEST to that sent in the corresponding PA-OTP-CHALLENGE.
- The KDC constructs a TGT for the user. 🎟️
- The KDC returns an AS-REP to the client, encrypted using the Reply Key, containing the TGT and padata with the PA-FX-FAST-REPLY.
- The client authenticates the KDC and verifies the Reply Key change. The client uses the generated Reply Key to decrypt the encrypted data in the AS-REP. Full circle moment ✨
B.2. Two-Pass Authentication
In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-FAST-REQUEST padata of the initial AS-REQ sent to the KDC. Only two passes, super efficient, very giving 🦋
In this example, the user has a hand-held token, so none of the OTP generation parameters (otp-length, etc.) are included in the PA-OTP-REQUEST. The KDC does not require hashed OTP values in the key generation.
It is assumed that the client has been configured with the following information, or has obtained it from a previous PA-OTP-CHALLENGE:
- The OTP value must not be carried in the otp-value.
- The hashed OTP values are not required.
Here's the basic flow:
- The client obtains the user name and OTP value from the user.
- The client generates the Client Key and Reply Key using unhashed OTP values as described in Section 3.6.
- The client constructs a PA-OTP-REQUEST as follows:
flags: 0encData: An EncryptedData containing a PA-ENC-TS-ENC encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and an encryption type of the Armor Key. The PA-ENC-TS-ENC contains the current client time.
- The client encrypts the PA-OTP-REQUEST within the
enc-fast-reqof a PA-FX-FAST-REQUEST. - The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
- The KDC validates the padata by performing the following steps:
- It generates the Client Key and Reply Key from the unhashed OTP value for the user identified in the AS-REQ.
- It uses the generated Client Key to decrypt the PA-ENC-TS-ENC in the encData of the PA-OTP-REQUEST.
- It authenticates the user using the timestamp in the standard manner.
- The KDC constructs a TGT for the user. 🎟️
- The KDC returns an AS-REP to the client, encrypted using the Reply Key, containing the TGT and padata with the PA-FX-FAST-REPLY.
- The client authenticates the KDC and verifies the key change. The client uses the generated Reply Key to decrypt the encrypted data in the AS-REP. And that's the whole glow-up 💖
B.3. PIN Change 🎀
okay so this one picks up right where the KDC gets the PA-OTP-REQUEST from the client in the examples in Appendix B.1 and Appendix B.2 💅. While it's validating the pre-authentication data (encrypted nonce or encrypted timestamp, either one), the KDC realises the user's PIN has expired and has to be changed 😭. So it includes a PA-OTP-PIN-CHANGE in the AS-REP. 🧚
In this example, the KDC doesn't make up PIN values for the user. Instead it asks the user to come up with a new PIN that's between 4 and 8 characters long 🌸. The actual PIN change is handled by a PIN change service, so that's a separate thing 🫶.
The basic sequence goes like this:
- The client constructs and sends a PA-OTP-REQUEST to the KDC as described in the previous examples.
- The KDC validates the pre-authentication data and authenticates the user as in the previous examples, but it determines that the user's PIN has expired.
- The KDC constructs a PA-OTP-PIN-CHANGE as follows:
flags
0
minLength
4
maxLength
8- The KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep of a PA-FX-FAST-REPLY 🔐.
- The KDC returns a KRB-ERROR to the client of type KDC_ERR_PIN_EXPIRED, with padata containing the PA-FX-FAST-REPLY 💀.
- The client authenticates to the PIN change service and changes the user's PIN 🔥.
- The client sends a second AS-REQ to the KDC containing a PA-OTP-REQUEST built using the new PIN ✨.
- The KDC responds with an AS-REP containing a TGT. 👑
B.4. Resynchronization 🦋
this one picks up where the KDC gets the PA-OTP-REQUEST from the client. While it's validating the pre-authentication data (encrypted nonce or encrypted timestamp), the KDC figures out that its local record of the token's state needs to be resynchronized with the token 🙈. So it sends back a KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set 💜.
The steps below are a variation of the four pass examples shown in Appendix B.1, but the same process would also work in the two-pass case ⭐.
- The client constructs and sends a PA-OTP-REQUEST to the KDC as described in the previous examples.
- The KDC validates the pre-authentication data and authenticates the user as in the previous examples, but determines that the user's token requires resynchronizing 🌈.
- The KDC constructs a PA-OTP-CHALLENGE as follows:
nonce
A randomly generated value.
otp-service
Set to a string that can be used by the client to assist the
user in locating the correct token.
otp-tokenInfo
Information about how the OTP should be generated from the
token.
flags
must-encrypt-nonce, collect-pin, and nextOTP bits set
supportedHashAlg
AlgorithmIdentifiers for SHA-256 and SHA-1
iterationCount
1024- The KDC returns a KRB-ERROR with an error code of KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data 🍓.
- The client obtains the next OTP value from the token and records the time as reported by the token ⏰.
- The client generates the Client Key and Reply Key as described in Section 3.6, using SHA-256 from the list of algorithms sent by the KDC, the iteration count of 100,000 as required by local policy, and a randomly generated nonce 🧮.
- The client constructs a PA-OTP-REQUEST as follows:
flags
nextOTP bit set
nonce
The randomly generated value.
encData
An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
under the Client Key with a key usage of
KEY_USAGE_OTP_REQUEST and the encryption type of the Armor
Key. The PA-OTP-ENC-REQUEST contains the nonce from the
PA-OTP-CHALLENGE.
hashAlg
SHA-256
iterationCount
100,000
otp-time
The time used in the OTP calculation as reported by the OTP
token.- The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST 🔒.
- The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata 📨.
- The authentication process now proceeds as with the classic sequence 🎉.
Author's Address 🌷
Gareth Richards
RSA, The Security Division of EMC
RSA House
Western Road
Bracknell, Berkshire RG12 1RT
UK
EMail: gareth.richards@rsa.com📦 where this page comes from
- ietf: rfc6560 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms