diff options
Diffstat (limited to 'doc/rfc/rfc6560.txt')
| -rw-r--r-- | doc/rfc/rfc6560.txt | 2411 |
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc6560.txt b/doc/rfc/rfc6560.txt new file mode 100644 index 0000000..8c5e132 --- /dev/null +++ b/doc/rfc/rfc6560.txt @@ -0,0 +1,2411 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Richards +Request for Comments: 6560 RSA, The Security Division of EMC +Category: Standards Track April 2012 +ISSN: 2070-1721 + + + One-Time Password (OTP) Pre-Authentication + +Abstract + + The Kerberos protocol provides a framework authenticating a client + using the exchange of pre-authentication data. This document + describes the use of this 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 provide feedback on it may be obtained 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + + + +Richards Standards Track [Page 1] + +RFC 6560 OTP Pre-Authentication April 2012 + + + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such 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, except to format + it for publication as an RFC or to translate 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 ....................................... 41 + + + +Richards Standards Track [Page 2] + +RFC 6560 OTP Pre-Authentication April 2012 + + +1. Introduction + +1.1. Scope + + This document describes a Flexible Authentication Secure Tunneling + (FAST) [RFC6113] factor that allows One-Time Password (OTP) values to + be used in the Kerberos V5 [RFC4120] pre-authentication in a manner + that does not require use of the user's Kerberos password. The + system is designed to work with different types of OTP algorithms + such as time-based OTPs [RFC2808], counter-based tokens [RFC4226] and + challenge-response systems such as [RFC2289]. It is also designed to + work with tokens that are electronically connected to the user's + computer via means such as 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 partially based upon previous work on integrating + single-use authentication mechanisms into Kerberos [HORENEZ004]. + +1.2. Overall Design + + This proposal supports four- and two-pass variants. In the four-pass + system, the client sends the Key Distribution Center (KDC) an initial + AS-REQ, and the KDC responds with a KRB-ERROR containing pre- + authentication data that includes a random nonce. The client then + encrypts the nonce and returns it 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 rather than a nonce from the KDC, and the + encrypted data is sent to the KDC in the initial AS-REQ. The two- + pass system can be used in cases where the client can determine in + advance that OTP pre-authentication is supported by the KDC, which + OTP key should be used and the encryption parameters required by the + KDC. + + In both systems, in order to create the message sent to the KDC, the + client must generate the OTP value and two keys: the classic Reply + Key used to decrypt the KDC's reply and a key to encrypt the data + sent to the KDC. In most cases, the OTP value will be used in the + key generation, but in order to support algorithms where the KDC + cannot obtain the value (e.g., [RFC2289]), the system supports the + option of including the OTP value in the request along with the + encrypted nonce. In addition, in order to support situations where + the KDC is unable to obtain the plaintext OTP value, the system also + supports the use of hashed OTP values in the key derivation. + + + + +Richards Standards Track [Page 3] + +RFC 6560 OTP Pre-Authentication April 2012 + + + The pre-authentication data sent from the client to the KDC is sent + within the encrypted data provided by the FAST pre-authentication + data type of the AS-REQ. The KDC then obtains the OTP value, + generates the same keys, and verifies the pre-authentication data by + decrypting the nonce. If the verification succeeds, then it confirms + knowledge of 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 familiarity with the Kerberos + pre-authentication framework [RFC6113] and so freely uses terminology + and notation from that document. + + The word padata is used as 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 ensure interoperability, all implementations of this specification + SHOULD provide a mechanism (e.g., a provider interface) to add or + remove support for a particular OTP mechanism. + +2.2. Pre-Authentication + + The approach uses pre-authentication data in AS-REQ, AS-REP, and + KRB-ERROR messages. + + In the four-pass system, the client begins by sending an initial + AS-REQ to the KDC that may contain pre-authentication data such as + the standard Kerberos password data. The KDC will then determine, in + an implementation dependent fashion, whether OTP authentication is + required and if it is, it will respond with a KRB-ERROR message + containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA. + + The PA-OTP-CHALLENGE will contain a KDC-generated nonce, a list of + hash algorithm identifiers, and an iteration count if hashed OTP + values are used (see Section 3.6) and OPTIONAL information on how the + OTP should be generated by the client. The client will then generate + the OTP value and two keys: a Client Key to encrypt the KDC's nonce + and a Reply Key used to decrypt the KDC's reply. + + + + +Richards Standards Track [Page 4] + +RFC 6560 OTP Pre-Authentication April 2012 + + + As described in Section 5.4.1 of [RFC6113], the FAST system uses an + Armor Key to set up an encrypted tunnel for use by FAST factors. As + described in Section 3.6 of this document, the Client Key and Reply + Key will be generated from the Armor Key and the OTP value, unless + the OTP algorithm does not allow the KDC to obtain the OTP value. If + hash algorithm identifiers were included in the PA-OTP-CHALLENGE, + then the client will use the hash of the OTP value rather than the + plaintext value in the key generation. Both keys will have the same + encryption type as the Armor Key. + + The generated Client Key will be used to encrypt the nonce received + from the KDC. The encrypted value along with optional information on + how the OTP was generated are then sent to the KDC in a + PA-OTP-REQUEST (see Section 4.2) encrypted within 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 returned by the KDC. Since no challenge is received + from the KDC, the client includes an encrypted timestamp in the + request rather than the encrypted KDC nonce. + + In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the + keys in the same way as the client, and uses the generated Client Key + to verify the pre-authentication by decrypting the encrypted data + sent by the client (either nonce or timestamp). If the validation + succeeds, then the KDC will authenticate itself to the client and + confirm that the Reply Key has been updated by using the generated + Reply Key in the AS-REP response. + +2.3. PIN Change + + Most OTP tokens involve the use of a Personal Identification Number + (PIN) in the generation of the OTP value. This PIN value will be + combined with the value generated by the token to produce the final + OTP value that will be used in this protocol. + + If, following successful validation of a PA-OTP-REQUEST in an AS-REQ, + the KDC determines that the user's PIN has expired and needs to + change, then it SHOULD respond with a KRB-ERROR of type + KDC_ERR_PIN_EXPIRED. It MAY include formatting information on the + PIN in a PA-OTP-PIN-CHANGE (see Section 4.3) encrypted within the + armored-data of the PA-FX-FAST-REPLY PA-DATA element. + + KDC_ERR_PIN_EXPIRED 96 + + + + + + +Richards Standards Track [Page 5] + +RFC 6560 OTP Pre-Authentication April 2012 + + + If the PIN change is to be handled by a PIN-change service, then it + is assumed that authentication to that service will succeed if the + PIN has expired. + + If the user's PIN has not expired but has been changed, then the KDC + MAY return the new value to the client in a PA-OTP-PIN-CHANGE + encrypted within the armored-data of the PA-FX-FAST-REPLY PA-DATA + element of the AS-REP. Similarly, if a PIN change is not required, + then the KDC MAY return a PA-OTP-PIN-CHANGE to inform the client of + the current PIN's expiration time. + +2.4. Resynchronization + + It is possible with time- and event-based tokens that the OTP server + will lose synchronization with the current token state. For example, + event-based tokens may drift since the counter on the token is + incremented every time the token is used, but the counter on the + server is only incremented on an authentication. Similarly, the + clocks on time-based tokens may drift. + + Methods to recover from this type of situation are OTP + algorithm-specific but may involve the client sending a sequence of + OTP values to allow the server to further validate the correct + position in its search window (see Section 7.4 of [RFC4226] for an + example). + + If, when processing a PA-OTP-REQUEST, the pre-authentication + validation fails for this reason, then the KDC MAY return a KRB-ERROR + message. The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the + PA-DATA with a single otp-tokenInfo representing the token used in + the initial authentication attempt but with the "nextOTP" flag set. + If this flag is set, then the client SHOULD re-try the authentication + using an OTP value generated using the token in the "state" after + that used in the failed authentication attempt, for example, using + the next time interval or counter value. + +3. Pre-Authentication Protocol Details + +3.1. Initial Client Request + + In the four-pass mode, the client begins by sending an initial + AS-REQ, possibly containing other pre-authentication data. If the + KDC determines that OTP-based pre-authentication is required and the + request does not contain a PA-OTP-REQUEST, then it will respond as + described in Section 3.2. + + + + + + +Richards Standards Track [Page 6] + +RFC 6560 OTP Pre-Authentication April 2012 + + + If the client has all the necessary information, it MAY use the + two-pass system by constructing a PA-OTP-REQUEST as described in + Section 3.3 and including it in the initial request. + +3.2. KDC Challenge + + If the user is required to authenticate using an OTP, then the KDC + SHALL respond to the initial AS-REQ with a KRB-ERROR (as described in + Section 2.2 of [RFC6113]), with a PA-OTP-CHALLENGE contained within + 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 is to be carried out as an individual mechanism, + then the PA-OTP-CHALLENGE SHALL be carried within the padata of the + KrbFastResponse. Alternatively, if the OTP mechanism is required as + part of an authentication set, then the PA-OTP-CHALLENGE SHALL be + carried within a PA-AUTHENTICATION-SET-ELEM as described in Section + 5.3 of [RFC6113]. + + The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned + encrypted in the client's PA-OTP-REQUEST. This nonce string MUST + contain a randomly chosen component at least as long as the Armor Key + length (see [RFC4086] for an in-depth discussion of randomness). In + order to allow it to maintain any state necessary to verify the + returned nonce, the KDC SHOULD use the mechanism described in Section + 5.2 of [RFC6113]. + + The KDC MAY use the otp-service field to assist the client in + locating the OTP token to be used by identifying the purpose of the + authentication. For example, the otp-service field could assist a + user in identifying the token to be used when a user has multiple OTP + tokens that are used for different purposes. If the token is a + connected device, then these values SHOULD be an exact octet-level + match for the values present on the target token. + + The KDC SHALL include a sequence of one or more otp-tokenInfo + elements containing information on the token or tokens that the user + can use for the authentication and how the OTP value is to be + generated using those tokens. If a single otp-tokenInfo element is + included, then only a single token is acceptable by the KDC, and any + OTP value generated by the client MUST be generated according to the + information contained within that element. If more than one + otp-tokenInfo element is included, then the OTP value MUST be + generated according to the information contained within one of those + elements. + + + + + + +Richards Standards Track [Page 7] + +RFC 6560 OTP Pre-Authentication April 2012 + + + The KDC MAY include the otp-vendor field in an otp-tokenInfo to + identify the vendor of the token that can be used in the + authentication request in order to assist the client in locating that + token. + + If the KDC is able to obtain the OTP values for the token, then the + OTP value SHOULD be used in the key generation as described in + Section 3.6; therefore, the KDC SHOULD set the "must-encrypt-nonce" + flag in the otp-tokenInfo. If the KDC is unable to obtain the OTP + values for the token, then the "must-encrypt-nonce" flag MUST NOT be + set. If the flag is not set, then the OTP value will be returned by + the client in the otp-value field of the PA-OTP-REQUEST and so, if + returning of OTP values in this way does not conform to KDC policy, + then the KDC SHOULD NOT include the otp-tokenInfo for that token in + the PA-OTP-CHALLENGE. + + If the KDC requires that hashed OTPs be used in the key generation as + described in Section 3.6 (for example, it is only able to obtain + 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 and the minimum value of the iteration count in the + iterationCount element. + + Since the OTP mechanism described in this document is replacing the + Reply Key, the classic shared-key system cannot be relied upon to + allow the client to verify the KDC. Therefore, as described in + Section 3.4 of [RFC6113], some other mechanism must be provided to + support this. If the OTP value is used in the Reply Key generation, + then the client and KDC have a shared key and KDC-authentication is + provided by the KDC using the Reply Key generated from the OTP value. + However, if the OTP value is sent in the otp-value element of the + PA-OTP-REQUEST, then there is no such shared key and the OTP + mechanism does not provide KDC-authentication. Therefore, if the OTP + mechanism is not being used in an environment where + KDC-authentication is being provided by other means (e.g., by the use + of a host-key-based Armor Key), then the KDC MUST NOT include any + otp-tokenInfo elements in the PA-OTP-CHALLENGE that do not have the + "must-encrypt-nonce" flag set. + + If the OTP for a token is to be generated using a server-generated + challenge, then the value of the challenge SHALL be included in the + otp-challenge field of the otp-tokenInfo for that token. If the + token is a connected device and the OTP is to be generated by + combining the challenge with the token's current state (e.g., time), + then the "combine" flag SHALL be set within the otp-tokenInfo + containing the challenge. + + + + + +Richards Standards Track [Page 8] + +RFC 6560 OTP Pre-Authentication April 2012 + + + If the KDC can determine which OTP token key (the seed value on the + token used to generate the OTP) is to be used, then 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 identify + the algorithm that should be used in the OTP calculation for that + token. For example, it could be used when a user has been issued + with multiple tokens that support different algorithms. + + If the KDC can determine that an OTP token that can be used by the + user does not require the client to collect a PIN, then it SHOULD set + the "do-not-collect-pin" flag in the otp-tokenInfo representing that + token. If the KDC can determine that the token requires the client + to collect a PIN, then it SHOULD set the "collect-pin" flag. If the + KDC is unable to determine whether or not the client should collect a + PIN, then the "collect-pin" and "do-not-collect-pin" flags MUST NOT + be set. + + If the KDC requires the PIN of an OTP token to be returned to it + separately, then it SHOULD set the "separate-pin-required" flag in + the otp-KeyInfo representing that token. + + If the KDC requires that the OTPs generated by the token have a Luhn + check digit appended, as defined in [ISOIEC7812], then it MUST set + the "check-digit" flag. This flag only applies if the format of the + OTP is decimal; therefore, the otp-format field, if present, MUST + have the value of "decimal". + + Finally, in order to support connected tokens that can generate OTP + values of varying lengths or formats, the KDC MAY include the desired + otp-length and format of the OTP in the otp-length and otp-format + fields of an otp-tokenInfo. + +3.3. Client Response + + The client response SHALL be sent to the KDC as a PA-OTP-REQUEST + included within the enc-fast-req of the armored-data within a + PA-FX-FAST-REQUEST encrypted under the current Armor Key as described + in [RFC6113]. + + In order to generate its response, the client MUST generate an OTP + value. If the PA-OTP-CHALLENGE contained one or more otp-tokenInfo + elements, then the OTP value MUST be based on the information + contained within one of those elements. + + + + + + +Richards Standards Track [Page 9] + +RFC 6560 OTP Pre-Authentication April 2012 + + + The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format, and + otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to + assist the client in locating the correct token to use, but the use + of the above fields will depend on the type of token. + + If the token is a disconnected device, then the values of otp-service + and otp-vendor MAY be displayed to the user in order to help the user + select the correct token, and the values of 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 when comparing + the values against those present 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 that 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 requires a PIN to be + 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 the otp-tokenInfo does not require a PIN to be + 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 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 is used to + generate the OTP value will depend on the type of device. However, + if the token is a disconnected device, then it will depend on the + "separate-pin-required" flag. If the 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 and, if the flag is set, then the OTP value + MUST be the value from the token. + + + + + +Richards Standards Track [Page 10] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 selected by the + client from the PA-OTP-CHALLENGE, then the OTP value for the token + MUST be generated based on a challenge, if the token is capable of + accepting a challenge. 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 the + challenge and not 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 token is a connected device, then the use of the challenge will + depend on the type of device but will involve passing the challenge + and the value of the "combine" flag in a token-specific manner to the + token, along with a PIN if collected and the values of otp-length and + otp-format if specified, in order to obtain the OTP value. If the + token is disconnected, then the challenge MUST be displayed to the + user and the value of the "combine" flag MAY be ignored by the + client. + + If the OTP value was generated using a challenge that was not sent by + the KDC, 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. + + + + + + + + + + +Richards Standards Track [Page 11] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 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 this case, the Client + Key and Reply Key SHALL be the same as the Armor Key as described in + Section 3.6; so, if the returning of OTP values in this way does not + conform to local policy on the client (for example, if + KDC-Authentication is required and is not being provided by other + means), then it 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 the + generation of 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] selected 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 + 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 + that it supports and 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, 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 used by the client be chosen in such a way + that it is computationally infeasible/unattractive for an attacker to + brute-force search for the given OTP. + + The PA-OTP-REQUEST returned by the client SHOULD include information + on the generated OTP value reported by the OTP token when 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 + used by the token 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 + information is known to the client. + + + + +Richards Standards Track [Page 12] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 no otp-vendor field was provided by the KDC, then the + field SHOULD be set to the vendor identifier of the token if known to + the client. + + The generated Client Key is used by the client to encrypt data to be + included in the encData of the PA-OTP-REQUEST to allow the KDC to + authenticate the user. The key usage for this encryption is + KEY_USAGE_OTP_REQUEST. + + o If the PA-OTP-REQUEST is being generated in response to a + PA-OTP-CHALLENGE returned by the KDC, then the client SHALL + encrypt a PA-OTP-ENC-REQUEST containing the value of nonce from + the PA-OTP-CHALLENGE using the same encryption type as the Armor + Key. + + o If the PA-OTP-REQUEST is not in response to a PA-OTP-CHALLENGE, + then the client SHALL encrypt a PA-ENC-TS-ENC containing 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 cannot 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 + + The KDC validates the pre-authentication data by generating the + Client Key and Reply Key in the same way as the client and using the + generated Client Key to decrypt the value of encData from the + PA-OTP-REQUEST. The generated Reply Key is used to encrypt data in + the AS-REP. + + If the otp-value field is included in the PA-OTP-REQUEST, then the + KDC MUST use that value unless the OTP method is required to support + KDC-authentication (see Section 3.2). If the otp-value is not + included in the PA-OTP-REQUEST, then the KDC will need to generate or + obtain the OTP value. + + If the otp-pin field is present in the PA-OTP-REQUEST, then the PIN + value has to be value provided by the client. The KDC SHOULD + SASLPrep (Stringprep Profile for User Names and Passwords) [RFC4013] + the value in lookup mode before comparison. + + + +Richards Standards Track [Page 13] + +RFC 6560 OTP Pre-Authentication April 2012 + + + It should be noted that it is anticipated that, as improved string + comparison technologies are standardized, the processing done by the + KDC will change, but efforts will be made to maintain as much + compatibility with SASLprep as possible. + + If the otp-challenge field is present, 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 upon the values of otp-time, + otp-counter, otp-format, otp-algID, and otp-tokenID if they are + present in the PA-OTP-REQUEST. If the KDC receives a request + containing these values, but cannot act upon them, then they MAY be + ignored. + + The KDC generates the Client Key and Reply Key as described in + Section 3.6 from the OTP value using the nonce, hash algorithm, and + iteration count if 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 was not present in the + PA-OTP-REQUEST or if the value of this field does not conform to + local KDC policy. Similarly, the KDC MUST fail the request with + KDC_ERR_INVALID_ITERATION_COUNT, if the value of the iterationCount + included in the PA-OTP-REQUEST does not conform to local KDC policy + or is less than that specified in the PA-OTP-CHALLENGE. In addition, + the KDC MUST fail the authentication request with + KDC_ERR_PIN_REQUIRED, if it requires a separate PIN to the OTP value + and an otp-pin was not included in the PA-OTP-REQUEST. The above + error codes are defined as follows: + + KDC_ERR_INVALID_HASH_ALG 94 + KDC_ERR_INVALID_ITERATION_COUNT 95 + KDC_ERR_PIN_REQUIRED 97 + + The generated Client Key is then used to decrypt the encData from the + PA-OTP-REQUEST. If the client response was sent as a result 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 value from the PA-OTP-ENC-REQUEST + is not the same as the nonce value sent in the PA-OTP-CHALLENGE. If + the response was not sent as a result of a PA-OTP-CHALLENGE, then the + decrypted value will be a PA-ENC-TS-ENC, and the authentication + process will be the same as with classic encrypted timestamp + pre-authentication [RFC4120]. + + The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP, if the + encryption type used by the client in the encData does not conform to + KDC policy. + + + +Richards Standards Track [Page 14] + +RFC 6560 OTP Pre-Authentication April 2012 + + + If authentication fails due to the hash algorithm, iteration count, + or encryption type used by the client, then the KDC SHOULD return a + PA-OTP-CHALLENGE with the required values in the error response. If + the authentication fails due to the token state on the server is no + longer being synchronized with the token used, then the KDC MAY + return a PA-OTP-CHALLENGE with the "nextOTP" flag set as described in + Section 2.4. + + If, during the authentication process, the KDC determines that the + user's PIN has been changed, then it SHOULD include a + PA-OTP-PIN-CHANGE in the response, as described in 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 can be used + by the KDC to handle cases where the account related to the user's + OTP token has a different expiration time to the user's Kerberos + account.) If the KDC determines that the user's PIN or OTP account + are about to expire, it MAY return a PA-OTP-PIN-CHANGE with that + information. Finally, if the KDC determines that 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 + + If the pre-authentication data was successfully verified, then, in + order to support mutual authentication, 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. The client then uses its generated Reply Key + to decrypt the encrypted data and MUST NOT continue with the + authentication process, if decryption is not successful. + +3.6. Reply Key Generation + + In order to authenticate the user, the client and KDC need to + generate two encryption keys: + + o The Client Key to be used by the client to encrypt and by the KDC + to decrypt the encData in the PA-OTP-REQUEST. + + o The Reply Key to be used in the standard manner by the KDC to + encrypt data in the AS-REP. + + The method used to generate the two keys will depend on the OTP + algorithm. + + o 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]). + + + +Richards Standards Track [Page 15] + +RFC 6560 OTP Pre-Authentication April 2012 + + + o 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 is not included in the PA-OTP-REQUEST, then the + Reply Key and Client Key SHALL be generated using the KRB-FX-CF2 + algorithm from [RFC6113] as follows: + + 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 and so, as described + in Section 5.1 of [RFC6113], the enctypes of the generated Client Key + and Reply Key will be the same as the enctype of 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 to be used, then K2 SHALL be derived + as follows: + + o An initial hash value, H, is generated: + + H = hash(realm|nonce|OTP) + + Where: + + * "|" denotes concatenation. + * hash is the hash algorithm selected by the client. + * 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 value of the random nonce value generated by the + client 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 is the unnormalized OTP value. + + + + +Richards Standards Track [Page 16] + +RFC 6560 OTP Pre-Authentication April 2012 + + + o The initial hash value is then 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))) + + o 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 is not 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 that of the Armor Key and + 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 are not provided, then the default values + defined for the particular enctype SHALL be used. + + If the strengthen-key is present in KrbFastResponse, then it is + 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 + + The padata-type PA-OTP-CHALLENGE is returned by the KDC to the client + in the enc-fast-rep of a PA-FX-FAST-REPLY in the PA-DATA of a + KRB-ERROR when OTP pre-authentication is required. The corresponding + padata-value field contains the Distinguished Encoding Rules (DER) + [X.680] and [X.690] encoding of a PA-OTP-CHALLENGE containing a + server-generated nonce and information for the client on how to + generate the 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, + ... + + + +Richards Standards Track [Page 17] + +RFC 6560 OTP Pre-Authentication April 2012 + + + } + + 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 + A KDC-supplied nonce value to be encrypted by the client 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 + assist the client to locate the appropriate OTP tokens to be used. + For example, this field could be used when a user has multiple OTP + tokens for different purposes. + + + + + + +Richards Standards Track [Page 18] + +RFC 6560 OTP Pre-Authentication April 2012 + + + otp-tokenInfo + This element MUST be included, and it is a sequence of one or more + OTP-TOKENINFO objects containing information on the token or + tokens that the user can use for the authentication and how the + OTP value is to be generated using those tokens. If a single + OTP-TOKENINFO object is included, then only a single token is + acceptable by the KDC and any OTP value generated by the client + MUST be generated according to the information contained within + that element. If more than one OTP-TOKENINFO object is included, + then the OTP value MUST be generated according to the information + contained within one of those objects. + + flags + If the "nextOTP" flag is set, then the OTP SHALL be based on + the next token "state" rather than the one used in the previous + authentication. As an example, for a time-based token, this + means the next time slot and for an event-based token, this + 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 included in + otp-challenge shall be used. If the flag is set, then OTP + SHALL be calculated using the challenge from otp-challenge and + the internal token state (e.g., time or counter). If the + "combine" flag is not set, then 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, then the token + represented by the current otp-tokenInfo does not require a PIN + to be collected as part of the OTP. If the "collect-pin" flag + is set, then the token requires a PIN. If neither flag is set, + then whether or not a PIN is required is unspecified. The + flags are mutually exclusive and so both flags MUST NOT be set, + or the client MUST regard the request as invalid. + + If the "must-encrypt-nonce" flag is set, then the OTP value + MUST NOT be included in the otp-value field of the + PA-OTP-REQUEST, but 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, then the PIN + collected by the client SHOULD NOT be used in the generation of + the OTP value and SHOULD be returned in the otp-pin field of + the PA-OTP-REQUEST. + + + +Richards Standards Track [Page 19] + +RFC 6560 OTP Pre-Authentication April 2012 + + + The "check-digit" flag controls whether or not the OTP values + generated by the token need to include a Luhn check digit + [ISOIEC7812]. If the token is disconnected, then the Client + MAY ignore this flag; if this 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 used by the KDC to send a challenge value + for use in the OTP calculation. The challenge is an OPTIONAL + octet string that SHOULD be uniquely generated for each request + in which it is present. When the challenge is not present, the + OTP will be calculated on the current token state only. The + client MAY ignore a provided challenge if and only if the OTP + token the client is interacting with is not capable of + including a challenge in the OTP calculation. In this case, + KDC policies will determine whether or not to accept a provided + OTP value. + + otp-length + Use of this field is OPTIONAL, but MAY be used by the KDC to + specify the desired length of the generated OTP. For example, + this field could be used when a token is capable of producing + OTP values of different lengths. If the format of the OTP is + 'decimal', 'hexidecimal', or 'alphanumeric', then this value + indicates the desired length in digits/characters; if the OTP + format is 'binary', then this value indicates the desired + length in octets; and if the OTP format is 'base64', then this + value indicates 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 + specify the desired format of the generated OTP value. For + example, this field could be used when a token is capable of + producing OTP values of 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, this field could be used when a user has been + issued multiple token keys by the same server. + + + + + +Richards Standards Track [Page 20] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 present, then a hash of the OTP value MUST be used in the + key derivation rather than the plain text value. Each + AlgorithmIdentifier identifies a hash algorithm that is + supported by the KDC 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. The AlgorithmIdentifier selected by the client MUST + be placed in the hashAlg element of the PA-OTP-REQUEST. + + iterationCount + The minimum value of the iteration count to be used by the + client when hashing the OTP value. This value MUST be present + if supportedHashAlg is present and otherwise MUST NOT be + present. If the value of this element does not conform to + local policy on the client, then the client MAY use a larger + value but 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. + + salt + The salt value to be used in string-to-key when used to calculate + the keys as described in Section 3.6. + + s2kparams + Any additional parameters required by string-to-key as described + in Section 3.6. + +4.2. PA-OTP-REQUEST + + The padata-type PA-OTP-REQUEST is sent by the client to the KDC in + the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the + PA-DATA of an AS-REQ. The corresponding padata-value field contains + the DER encoding of a PA-OTP-REQUEST. + + The message contains pre-authentication data encrypted by the client + using the generated Client Key and optional information on how the + OTP was generated. It may also, optionally, contain the generated + OTP value. + + + + + +Richards Standards Track [Page 21] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 + + + +Richards Standards Track [Page 22] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 that + 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 + Value used by the client 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). + + + + + + + + +Richards Standards Track [Page 23] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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]. + + + + + + + + + +Richards Standards Track [Page 24] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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 padata-type PA-OTP-PIN-CHANGE is returned by the KDC in the + enc-fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must + change their PIN, if the user's PIN has been changed, or to notify + the user of the PIN's expiry time. + + The corresponding padata-value field contains 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 is used to indicate the type of PIN change + that is taking place. If the flag is set, then the user's PIN has + been changed for the user by the system. If the flag is not set, + then the user's PIN needs to be changed by the user. + + If the "systemSetPin" flag is not set and the "mandatory" flag is + set, then 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 + + + + +Richards Standards Track [Page 25] + +RFC 6560 OTP Pre-Authentication April 2012 + + + "systemSetPin" flag is set, then the "mandatory" flag has no + meaning and SHOULD be ignored by the client. + + pin + The pin field is used to carry a new PIN value. If the + "systemSetPin" flag is set, then the pin field is used to carry + 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]. + + + + +Richards Standards Track [Page 26] + +RFC 6560 OTP Pre-Authentication April 2012 + + + The following pre-authentication types are defined in this document: + + PA-OTP-CHALLENGE 141 + PA-OTP-REQUEST 142 + PA-OTP-PIN-CHANGE 144 + + Note 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. + + The following 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 45 + + These 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 + + In the system described in this document, the OTP pre-authentication + protocol is tunneled within the FAST Armor channel provided by the + pre-authentication framework. As described in [ASNINY02], tunneled + protocols are potentially vulnerable to man-in-the-middle (MITM) + attacks if the outer tunnel is compromised, and it is generally + considered good practice in such cases to bind the inner encryption + to the outer tunnel. + + In order to mitigate against such attacks, the proposed system uses + the outer Armor Key in the derivation of the inner Client and Reply + keys and so achieves crypto-binding to the outer channel. + + As described in Section 5.4 of [RFC6113], FAST can use an anonymous + Ticket-Granting Ticket (TGT) obtained using anonymous Public Key + Cryptography for Initial Authentication in Kerberos (PKINIT) + [RFC6112] [RFC4556] as the Armor Key. However, the current anonymous + PKINIT proposal is open to MITM attacks since the attacker + + + + +Richards Standards Track [Page 27] + +RFC 6560 OTP Pre-Authentication April 2012 + + + can choose a session key such that the session key between the MITM + and the real KDC is the same as the session key between the client + and the MITM. + + As described in Section 3.6, if the OTP value is not being sent to + the KDC, then the Armor Key is used along with the OTP value in the + generation of the Client Key and Reply Key. If the Armor Key is + known, then the only entropy remaining in the key generation is + provided by the OTP value. If the OTP algorithm requires that the + OTP value be sent to the KDC, then it is sent encrypted within the + tunnel provided by the FAST Armor and so, is exposed to the attacker + if the attacker has the Armor Key. + + 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. In addition, the security + considerations should be carefully considered before anonymous PKINIT + is used with other algorithms such as those with short OTP values. + + Careful consideration should also be made if host key armor is used + to provide the KDC-authentication facility with OTP algorithms where + the OTP value is sent within the otp-value field of the + PA-OTP-REQUEST since compromised host keys would allow an attacker to + impersonate the KDC. + +6.2. Reflection + + The four-pass system described above is a challenge-response + protocol, and such protocols are potentially vulnerable to reflection + attacks. No such attacks are known at this point, but to help + mitigate against such attacks, the system uses different keys to + encrypt the client and server nonces. + +6.3. Denial-of-Service Attacks + + The protocol supports the use of an iteration count in the generation + of the Client and Reply keys, and the client can send the number of + iterations used as part of the PA-OTP-REQUEST. This could open the + KDC up to a denial-of-service attack if a large value for the + iteration count was specified by the attacker. It is therefore, + particularly important that, as described in Section 3.4, the KDC + reject any authentication requests where the iteration count is above + a maximum value specified by local policy. + + + + + + + + +Richards Standards Track [Page 28] + +RFC 6560 OTP Pre-Authentication April 2012 + + +6.4. Replay + + In the four-pass version of this protocol, the client encrypts a + KDC-generated nonce, so replay can be detected by the KDC. The + two-pass version of the protocol does not involve a server nonce; the + client instead encrypts a timestamp, and therefore is not protected + from replay in this way, but it will instead require some other + mechanism, such as an OTP-server-based system or a timestamp-based + replay cache on the KDC. + + As described in Section 5.2 of [RFC6113], a client cannot be certain + that it will use the same KDC for all messages in a conversation. + Therefore, the client cannot assume that the PA-OTP-REQUEST will be + sent to the same KDC that issued the PA-OTP-CHALLENGE. In order to + support this, a KDC implementing this protocol requires a means of + sharing session state. However, doing this does introduce the + possibility of a replay attack where the same response is sent to + multiple KDCs. + + In the case of time- or event-based tokens or server-generated + challenges, protection against replay may be provided by the OTP + server being used if that server is capable of keeping track of the + last used value. This protection therefore relies upon the + assumption that the OTP server being used in this protocol is either + not redundant or involves a commit protocol to synchronize between + replicas. If this does not hold for an OTP server being used, then + 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 + would not 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 via a brute-force attack. If the OTP value is short, + then the KDC could iterate over the possible OTP values until a + Client Key is generated that can decrypt the encData sent in the + PA-OTP-REQUEST. + + + + + + + + + +Richards Standards Track [Page 29] + +RFC 6560 OTP Pre-Authentication April 2012 + + + As described in Section 3.6, an iteration count can be used in the + generation of the Client Key and the value of the iteration count can + be controlled by local client policy. Use of this iteration count + can make it computationally infeasible/unattractive for an attacker + to brute-force search for the given OTP within the lifetime of that + OTP. + + If PINs contain international characters, similar looking or similar + functioning characters may be mapped together. For example, the + combined and decomposed forms of accented characters will typically + be treated the same. Users who attempt to exploit artifacts of + international characters to improve the strength of their PINs may + experience false positives in the sense that PINs they intended to be + distinct are not actually distinct. This decision was made in order + to improve usability across the widest variety of input methods. + Users can choose other methods to add strength to PINs. + +6.6. FAST Facilities + + The secret used to generate the OTP is known only to the client and + the KDC, so successful decryption of the encrypted nonce by the KDC + authenticates the user. If the OTP value is used in the Reply Key + generation, then successful decryption of the encrypted nonce by the + client 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 the following + 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. + + Many valuable suggestions were also made by members of the Kerberos + Working Group, but 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 would also like to thank Tim Alsop and Srinivas Cheruku of + CyberSafe for many valuable review comments. + + + + + + + + +Richards Standards Track [Page 30] + +RFC 6560 OTP Pre-Authentication April 2012 + + +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. + + + + + + +Richards Standards Track [Page 31] + +RFC 6560 OTP Pre-Authentication April 2012 + + + [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. + + + + + + + + + + + +Richards Standards Track [Page 32] + +RFC 6560 OTP Pre-Authentication April 2012 + + +Appendix A. ASN.1 Module + + 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), + + + +Richards Standards Track [Page 33] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 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, + + + +Richards Standards Track [Page 34] + +RFC 6560 OTP Pre-Authentication April 2012 + + + ... + } + + PinFlags ::= KerberosFlags + -- reserved(0), + -- systemSetPin(1), + -- mandatory(2) + + AnyURI ::= UTF8String + (CONSTRAINED BY { + -- MUST be a valid URI in accordance with IETF RFC 2396 + }) + + END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richards Standards Track [Page 35] + +RFC 6560 OTP Pre-Authentication April 2012 + + +Appendix B. Examples of OTP Pre-Authentication Exchanges + + This section is non-normative. + +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. + + In this example, the user has been issued with a connected, + time-based token, and the KDC requires hashed OTP values in the key + generation with SHA-384 as the preferred hash algorithm and a minimum + of 1024 iterations. The local policy on the client supports SHA-256 + and requires 100,000 iterations of the hash of the OTP value. + + The basic sequence of steps involved is as follows: + + 1. The client obtains the user name of the user. + + 2. The client sends an initial AS-REQ to the KDC that does not + contain a PA-OTP-REQUEST. + + 3. The KDC determines that the user identified by the AS-REQ + requires OTP authentication. + + 4. 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-nonce and collect-pin bits set + + supportedHashAlg + AlgorithmIdentifiers for SHA-384, SHA-256, and SHA-1 + + iterationCount + 1024 + + + + +Richards Standards Track [Page 36] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 5. The KDC returns a KRB-ERROR with an error code of + KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data. + + 6. The client displays the value of otp-service and prompts the + user to connect the token. + + 7. The client collects a PIN from the user. + + 8. The client obtains the current OTP value from the token using + the PIN and records the time as reported by the token. + + 9. 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. + + 10. The client constructs a PA-OTP-REQUEST as follows: + + flags + 0 + + 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. + + 11. The client encrypts the PA-OTP-REQUEST within the enc-fast-req + of a PA-FX-FAST-REQUEST. + + 12. The client sends an AS-REQ to the KDC containing the + PA-FX-FAST-REQUEST within the padata. + + + + + +Richards Standards Track [Page 37] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 13. The KDC validates the padata in the PA-OTP-REQUEST by performing + the following steps: + + * 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. + + * Uses the generated Client Key to decrypt the + PA-OTP-ENC-REQUEST in the encData of the PA-OTP-REQUEST. + + * Authenticates the user by comparing the nonce value from the + decrypted PA-OTP-ENC-REQUEST to that sent in the + corresponding PA-OTP-CHALLENGE. + + 14. The KDC constructs a TGT for the user. + + 15. 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. + + 16. + + 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. + +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. + + In this example, the user has been issued 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. + + o The OTP value must not be carried in the otp-value. + + o The hashed OTP values are not required. + + The basic sequence of steps involved is as follows: + + 1. The client obtains the user name and OTP value from the user. + + + + +Richards Standards Track [Page 38] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 2. The client generates the Client Key and Reply Key using unhashed + OTP values as described in Section 3.6. + + 3. The client constructs a PA-OTP-REQUEST as follows: + + flags + 0 + + encData + 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. + + 4. The client encrypts the PA-OTP-REQUEST within the enc-fast-req + of a PA-FX-FAST-REQUEST. + + 5. The client sends an AS-REQ to the KDC containing the + PA-FX-FAST-REQUEST within the padata. + + 6. The KDC validates the padata by performing the following steps: + + * Generates the Client Key and Reply Key from the unhashed OTP + value for the user identified in the AS-REQ. + + * Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in + the encData of the PA-OTP-REQUEST. + + * Authenticates the user using the timestamp in the standard + manner. + + 7. The KDC constructs a TGT for the user. + + 8. 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. + + 9. 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. + + + + + + + + + + + +Richards Standards Track [Page 39] + +RFC 6560 OTP Pre-Authentication April 2012 + + +B.3. PIN Change + + This exchange follows from the point where the KDC receives the + PA-OTP-REQUEST from the client in the examples in Appendix B.1 and + Appendix B.2. During the validation of the pre-authentication data + (whether encrypted nonce or encrypted timestamp), the KDC determines + that the user's PIN has expired and so, must be changed. The KDC + therefore, includes a PA-OTP-PIN-CHANGE in the AS-REP. + + In this example, the KDC does not generate PIN values for the user + but requires that the user generate a new PIN that is between 4 and 8 + characters in length. The actual PIN change is handled by a PIN + change service. + + The basic sequence of steps involved is as follows: + + 1. The client constructs and sends a PA-OTP-REQUEST to the KDC as + described in the previous examples. + + 2. The KDC validates the pre-authentication data and authenticates + the user as in the previous examples but determines that the + user's PIN has expired. + + 3. The KDC constructs a PA-OTP-PIN-CHANGE as follows: + + flags + 0 + minLength + 4 + maxLength + 8 + + 4. The KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep + of a PA-FX-FAST-REPLY. + + 5. The KDC returns a KRB-ERROR to the client of type + KDC_ERR_PIN_EXPIRED with padata containing the PA-FX-FAST-REPLY. + + 6. The client authenticates to the PIN change service and changes + the user's PIN. + + 7. The client sends a second AS-REQ to the KDC containing a PA-OTP- + REQUEST constructed using the new PIN. + + 8. The KDC responds with an AS-REP containing a TGT. + + + + + + +Richards Standards Track [Page 40] + +RFC 6560 OTP Pre-Authentication April 2012 + + +B.4. Resynchronization + + This exchange follows from the point where the KDC receives the + PA-OTP-REQUEST from the client. During the validation of the + pre-authentication data (whether encrypted nonce or encrypted + timestamp), the KDC determines that the local record of the token's + state needs to be resynchronized with the token. The KDC therefore, + includes a KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" + flag set. + + The sequence of steps below follows is a variation of the four pass + examples shown in Appendix B.1 but the same process would also work + in the two-pass case. + + 1. The client constructs and sends a PA-OTP-REQUEST to the KDC as + described in the previous examples. + + 2. The KDC validates the pre-authentication data and authenticates + the user as in the previous examples, but determines that user's + token requires resynchronizing. + + 3. 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 + + 4. KDC returns a KRB-ERROR with an error code of + KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data. + + 5. The client obtains the next OTP value from the token and records + the time as reported by the token. + + + +Richards Standards Track [Page 41] + +RFC 6560 OTP Pre-Authentication April 2012 + + + 6. 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. + + 7. 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. + + 8. The client encrypts the PA-OTP-REQUEST within the enc-fast-req + of a PA-FX-FAST-REQUEST. + + 9. The client sends an AS-REQ to the KDC containing the + PA-FX-FAST-REQUEST within the padata. + + 10. The authentication process now proceeds as with the classic + sequence. + + + + + + + + + + + + + +Richards Standards Track [Page 42] + +RFC 6560 OTP Pre-Authentication April 2012 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richards Standards Track [Page 43] + |