Network Working Group G. Richards Internet-Draft RSA, The Security Division of EMC Intended status: Standards Track October 9, 2009 Expires: April 12, 2010 OTP Pre-authentication draft-ietf-krb-wg-otp-preauth-11 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 12, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Richards Expires April 12, 2010 [Page 1] Internet-Draft OTP Pre-authentication October 2009 (OTP) authentication. 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. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 6 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 7 3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 7 3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 9 3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 11 3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 13 3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 13 4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 15 4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 15 4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 18 4.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 21 4.4. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 24 6.2. Reflection . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 25 6.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.5. Brute Force Attack . . . . . . . . . . . . . . . . . . . . 26 6.6. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Examples of OTP Pre-Authentication Exchanges . . . . 31 B.1. Four Pass Authentication . . . . . . . . . . . . . . . . . 31 B.2. Two Pass Authentication . . . . . . . . . . . . . . . . . 34 B.3. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 35 B.4. Resynchronization . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Richards Expires April 12, 2010 [Page 2] Internet-Draft OTP Pre-authentication October 2009 1. Introduction 1.1. Scope This document describes a FAST [ZhHa09] 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 [ZhHa09]): 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 [HoReNeZo04]. 1.2. Overall Design This proposal supports 4-pass and 2-pass variants. In the 4-pass system, the client sends the KDC an initial AS-REQ and the KDC responds with a KRB-ERROR containing padata that includes a random nonce. The client then encrypts the nonce and returns it, along with its own random value, to the KDC in a second AS-REQ. Finally, the KDC returns the client's random value encrypted within the padata of the AS-REP. Note that this variant can only be used for users that require pre-authentication. In the 2-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. This variant 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 standard 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 also 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 Richards Expires April 12, 2010 [Page 3] Internet-Draft OTP Pre-authentication October 2009 supports the use of hashed OTP values in the key derivation. The preauth data sent from the client to the KDC is sent within the encrypted data provided by the FAST padata 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 returning the client's nonce encrypted under one the generated Reply Key within the encrypted part of the FAST padata of 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 [ZhHa09] and so freely uses terminology and notation from this 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 4-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, an optional list of hash algorithm identifiers, an optional iteration count and optional information on how the OTP should be generated by the Richards Expires April 12, 2010 [Page 4] Internet-Draft OTP Pre-authentication October 2009 client. The client will then generate the OTP value, its own nonce and two keys: a Client Key to encrypt the KDC's nonce and a Reply Key used to decrypt the KDC's reply. As described in section 6.5.1 of [ZhHa09], 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, a random nonce generated by the client 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 2-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 encrypting the client's nonce under the Reply Key and returning the encrypted value in the encData of a PA-OTP-CONFIRM (see Section 4.3). The PA-OTP- CONFIRM is encrypted within the armored-data of a PA-FX-FAST-REPLY PA-DATA element of the AS-REP as described in [ZhHa09]. 2.3. PIN Change Most OTP tokens involve the use of a PIN in the generation of the OTP value. This PIN value will be entered by the user on the client and combined with the value produced by the token in a manner specific to the algorithm to generate the final OTP value that will be used in this protocol. If, following successful validation of a PA-OTP-REQUEST in a AS-REQ, the KDC determines that the user needs to change their PIN, that the Richards Expires April 12, 2010 [Page 5] Internet-Draft OTP Pre-authentication October 2009 PIN has been changed for the user or is about to expire then it MAY include a PA-OTP-PIN-CHANGE (see Section 4.4) encrypted within the armored data of the PA-FX-FAST-REPLY PA-DATA element of the AS-REP. This data can be used to return a new PIN to the user if the PIN has been updated, to indicate to the user that they must change their PIN, to inform the user of the PIN's expiration time and to carry formatting information about that PIN. If PIN change is to be handled by a PIN-change service that requires a Kerberos service ticket then the KDC MUST NOT return a TGT when the user is authenticated and user PIN change is required, the KDC SHOULD instead return a service ticket to the PIN-change service, in order for the client to compute an AP-REQ. In order to complicate stealing service tickets intended for the PIN-change service (and the corresponding session keys), the lifetime of the PIN-change service tickets should be just long enough to complete the PIN change, regardless whether the existing PIN needs to be changed or not. A 1-minute lifetime is RECOMMENDED. If the user's PIN has not expired but has been changed and the KDC is returning the new value to the user in a PA-OTP-PIN-CHANGE or PIN change is not required and the PA-OTP-PIN-CHANGE is being used to inform the client of the current PIN's expiration time then no such restrictions are required and the KDC SHOULD return the originally requested ticket. If the KDC is returning a ticket for a PIN-change service then it is RECOMMENDED that any context information, such as key and vendor identifiers be, that is required by the service be added to the ticket as authorization data elements. 2.4. Re-Synchronization 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. 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-keyInfo representing the token used in the initial authentiation attempt but with "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 Richards Expires April 12, 2010 [Page 6] Internet-Draft OTP Pre-authentication October 2009 interval or counter value. 3. Pre-Authentication Protocol Details 3.1. Initial Client Request In the 4-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. If the client has all the necessary information, it MAY use the 2-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 of type KDC_ERR_PREAUTH_REQUIRED 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 [ZhHa09]. 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 6.4 of [ZhHa09]. The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned encrypted in the client's PA-OTP-REQUEST. This nonce string MUST be as long as the longest key length of the symmetric key types that the KDC supports and MUST be chosen randomly. In order to allow it to maintain any state necessary to verify the returned nonce, the KDC SHOULD use the mechanism described in section 6.3 of [ZhHa09]. Since the OTP mechanism described in this document is replacing the Reply Key, the standard shared-key system cannot be relied upon to allow the client to verify the KDC. Therefore, as described in section 4.4 of [ZhHa09], 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 PA-OTP-CONFIRM. 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. Richards Expires April 12, 2010 [Page 7] Internet-Draft OTP Pre-authentication October 2009 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 host key armor) then the KDC MUST set the "must-encrypt- nonce" flag in the PA-OTP-CHALLENGE. In order to support cases where the KDC cannot obtain plaintext values for the OTPs, the KDC MAY include in the supportedHashAlg and iterationCount elements of the PA-OTP-REQUEST a sequence of one way hash function algorithm identifiers and a minimum value of the iteration count. If these elements are included 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 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 from that are used for different purposes. Finally, the KDC MAY also include a sequence of otp-keyInfo 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-keyInfo element is included then the client MUST generate the OTP value according to the information contained within that element. If more than one otp-keyInfo element is included then the client MUST generate the OTP value according to the information contained within one of those elements. If no otp- keyInfo elements are included then the KDC is imposing no restrictions on token usage. The KDC MAY include the otp-vendor field in an otp-keyInfo to assist the client in locating the OTP token to be used by identifying the vendor of the token. 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-keyInfo for that token. If 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-keyInfo containing the challenge. 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-keyID field MAY be included in the otp-keyInfo to pass that value to the client. The otp-algID field MAY be included in an otp-keyInfo to identify the algorithm that should be used in the OTP calculation for that token. Richards Expires April 12, 2010 [Page 8] Internet-Draft OTP Pre-authentication October 2009 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 a PIN as part of the OTP generation then it MAY set the "pin-not-required" flag in the otp-keyInfo representing that token. If the token requires a PIN then it MAY set the "pin- required" flag. If the KDC is unable to determine whether the token requires a PIN then the "pin-required" and "pin-not-required" flags MUST NOT be set. Finally, in order to support connected tokens that can generate OTP values of varying length, the KDC MAY include the desired length of the OTP in the otp-length field of an otp-keyInfo. 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 [ZhHa09]. In order to generate its response, the client must generate an OTP value. If the PA-OTP-CHALLENGE contained one or more otp-keyInfo elements then the OTP value MUST be based on the information contained within one of those elements. The PA-OTP-REQUEST returned by the client SHOULD include any information on the generated OTP value reported by the OTP token. If the "nextOTP" flag is set in the otp-keyInfo from the PA-OTP- CHALLENGE, then the OTP value MUST be generated from the next token state 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 "pin-not-required" flag is set in the otp-keyInfo from the PA- OTP-CHALLENGE, then the token represented by the otp-keyInfo does not require a PIN to be collected as part of the OTP value. If the "pin- required" flag is set then the token requires a PIN to be collected. If neither flag is set then PIN requirements of the token are unspecified. If both flags are set then client SHALL regard the request as invalid. The otp-time and otp-counter fields MAY be used to return the time and counter values used by the token. 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 MAY be used by the client to report the algorithm used in the OTP calculation and the otp-keyID MAY be used to report Richards Expires April 12, 2010 [Page 9] Internet-Draft OTP Pre-authentication October 2009 the identifier of the OTP token key used. If an otp-challenge is present in the otp-keyInfo 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- keyInfo 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 the flag is set but otp-challenge is not present then the client SHALL regard the request as invalid. 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. The client MUST derive the Client Key and Reply Key as described in Section 3.6. In order to support OTP algorithms where the KDC cannot obtain the OTP value, the client MAY include the generated value in the otp-value field of the PA-OTP-REQUEST. However, the client MUST NOT include the OTP value if the "must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE or if it is not allowed by the algorithm profile. If the OTP value is included in the PA-OTP-REQUEST then it MUST NOT be used in the key derivation. If the client used hashed OTP values in the key derivation process then it MUST include the hash algorithm and iteration count used 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 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. If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained hash algorithm identifiers and the OTP value is to be used in the key derivation then the client MUST use hashed OTP values and MUST select the first algorithm from the list that it supports. However, if the algorithm identifiers do not conform to local policy restrictions then the authentication attempt MUST NOT proceed. If the iteration count specified in the PA-OTP-CHALLENGE does not conform to local policy then the client MAY use a higher value but MUST NOT use a lower value. That is, the value in the KDC challenge Richards Expires April 12, 2010 [Page 10] Internet-Draft OTP Pre-authentication October 2009 is a minimum value. 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 2-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. Finally, the client generates a nonce value to include in the PA-OTP- REQUEST that will be returned encrypted by the KDC. This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports. This nonce MUST be chosen randomly. 3.4. Verifying the pre-auth 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 and to encrypt the encData value in the PA-OTP-CONFIRM. 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 kdc-authentication is required then a PA-OTP-REQUEST containing an otp-value MUST be rejected. 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-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 acts upon the values of otp-time, otp- Richards Expires April 12, 2010 [Page 11] Internet-Draft OTP Pre-authentication October 2009 counter, otp-format, otp-algID and otp-keyID 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 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. KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 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 standard 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. 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 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. 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 Richards Expires April 12, 2010 [Page 12] Internet-Draft OTP Pre-authentication October 2009 user's PIN has expired then it MAY return a PA-OTP-PIN-CHANGE, otherwise, it SHOULD return the same response as for a non-OTP expired password. 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 including in the AS-REP, a PA-OTP-CONFIRM containing the client's nonce from PA-OTP-REQUEST encrypted under the generated Reply Key. The nonce SHALL be returned within a PA-OTP-ENC-CONFIRM encrypted within the encData of the PA-OTP-CONFIRM. The key usage SHALL be KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as used by the client in the encData of the PA-OTP-REQUEST. The PA-OTP-CONFIRM SHALL be sent to the client within the enc-fast- rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key. The client then uses its generated Reply Key to decrypt the PA-OTP- ENC-CONFIRM from the encData of the PA-OTP-CONFIRM. The client MUST NOT continue with the authentication process if the nonce value in the PA-OTP-ENC-CONFIRM is not the same as the nonce value sent in the PA-OTP-REQUEST. 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 but is also to be used by the KDC to encrypt and by the client to decrypt the encData value in the PA- OTP-CONFIRM. 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 [ZhHa09]). Richards Expires April 12, 2010 [Page 13] Internet-Draft OTP Pre-authentication October 2009 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 [ZhHa09] 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 "Combine1", "Combine2", "Combine3" and "Combine4" as shown below: {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31} {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32} {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x33} {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x34} The first input keys, K1, SHALL be the Armor Key and so, as described in section 6.1 of [ZhHa09], 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 follows. 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(sname|nonce|OTP) Where: * "|" denotes concatenation * hash is the hash algorithm selected by the client. * sname is the UTF-8 encoding of the KDC's fully qualified domain name. If the domain name is an Internationalized Domain Name then the value shall be the output of nameprep [RFC3491] as described in [RFC3490]. * nonce is the random nonce value generated by the client to be included in the PA-OTP-REQUEST. * OTP is the OTP value. 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.) Richards Expires April 12, 2010 [Page 14] Internet-Draft OTP Pre-authentication October 2009 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 OTP value is binary and 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") If the OTP value is not binary and the hash value is not used, then K2 SHALL be derived by running the OTP value once through string-to- key. K2 = string-to-key(OTP||"Krb-preAuth") The salt and any additional parameters for string-to-key will be derived as described in section 3.1.3 of [RFC4120] using preauth data or default values defined for the particular enctype. The symbol "||" denotes string concatenation. 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] [X.690] encoding of a PA-OTP-CHALLENGE containing a server generated nonce and information for the client on how to generate the OTP. Richards Expires April 12, 2010 [Page 15] Internet-Draft OTP Pre-authentication October 2009 PA-OTP-CHALLENGE 141 PA-OTP-CHALLENGE ::= SEQUENCE { flags [0] ChallengeFlags, nonce [1] OCTET STRING, supportedHashAlg [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL, iterationCount [3] Int32 OPTIONAL, otp-service [4] UTF8String OPTIONAL, otp-keyInfo [5] SEQUENCE OF OTP-KEYINFO OPTIONAL, ... } OTP-KEYINFO ::= SEQUENCE { flags [0] OTPFlags, otp-vendor [1] UTF8String OPTIONAL, otp-challenge [2] OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-length [3] Int32 OPTIONAL, otp-keyID [4] OCTET STRING OPTIONAL, otp-algID [5] AnyURI OPTIONAL, ... } ChallengeFlags ::= KerberosFlags -- reserved(0), -- must-encrypt-nonce (1) OTPFlags ::= KerberosFlags -- reserved(0), -- nextOTP(1), -- combine(2), -- pin-required(3), -- pin-not-required(4) flags 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 MUST be used in the generation of the Reply Key and Client Key as described in Section 3.6. nonce A KDC-supplied nonce value to be encrypted by the client in the PA-OTP-REQUEST. This nonce string MUST be as long as the longest key length of the symmetric key types that the KDC supports and MUST be chosen randomly. Richards Expires April 12, 2010 [Page 16] Internet-Draft OTP Pre-authentication October 2009 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 SHA1 by both the client and KDC is REQUIRED. The AlgorithmIdentifer 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 and only if supportedHashAlg is 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. 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. otp-keyInfo Use of this field is OPTIONAL, but MAY be used by the KDC to carry information on the tokens that the user may use to carry out the authentication. Each otp-keyInfo element carries information on a valid token. If this field is omitted then there are no token restrictions. 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-keyInfo 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. Richards Expires April 12, 2010 [Page 17] Internet-Draft OTP Pre-authentication October 2009 If the "pin-not-required" flag is set then the token represented by the current otp-keyInfo does not require a PIN to be collected as part of the OTP. If the "pin-required" 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 and the client MUST regard the request as invalid. 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 it is present in, and SHOULD be eight octets or longer when 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 to accept a provided OTP value or not. otp-length Use of this field is OPTIONAL, but MAY be used by the KDC to specify the desired length of the generated OTP in octets. For example, this field could be used when a token is capable of producing OTP values of different lengths. otp-keyID 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. 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. 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. Richards Expires April 12, 2010 [Page 18] Internet-Draft OTP Pre-authentication October 2009 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. PA-OTP-REQUEST 142 PA-OTP-REQUEST ::= SEQUENCE { flags [0] OTPFlags, nonce [1] OCTET STRING, 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-challenge [6] OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-time [7] KerberosTime OPTIONAL, otp-counter [8] OCTET STRING OPTIONAL, otp-format [9] OTPFormat OPTIONAL, otp-keyID [10] OCTET STRING OPTIONAL, otp-algID [11] AnyURI OPTIONAL, ... } KEY_USAGE_OTP_REQUEST 45 PA-OTP-ENC-REQUEST ::= SEQUENCE { nonce [0] OCTET STRING, ... } OTPFormat ::= INTEGER { decimal(0), hexadecimal(1), alphanumeric(2), binary(3) } flags 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. Richards Expires April 12, 2010 [Page 19] Internet-Draft OTP Pre-authentication October 2009 If the "combine" flag is set then the OTP was calculated based on a challenge and the token state. nonce A value generated by the client to be returned encrypted by the KDC in the PA-OTP-CONFIRM 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 contains 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 and only if a hash of the OTP value was used as input to string-to-key (see Section 3.6) and 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 and only if a hash of the OTP value was used as input to string-to-key (see Section 3.6) and 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 that specified in the PA-OTP- CHALLENGE. otp-value The generated OTP value. This value MUST NOT be present unless allowed by the OTP algorithm profile and if the "must-encrypt- nonce" flag was not 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 Expires April 12, 2010 [Page 20] Internet-Draft OTP Pre-authentication October 2009 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 of 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 of 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 calculation. 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-keyID 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 calculation. 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-CONFIRM The padata-type PA-OTP-CONFIRM is returned by the KDC in the enc- fast-rep of a PA-FX-FAST-REPLY in the AS-REP of the KDC. It is used to return the client's nonce encrypted under the new Reply Key in order to authenticate the KDC and confirm the Reply Key change. Richards Expires April 12, 2010 [Page 21] Internet-Draft OTP Pre-authentication October 2009 The corresponding padata-value field contains the DER encoding of a PA-OTP-CONFIRM. PA-OTP-CONFIRM 143 PA-OTP-CONFIRM ::= SEQUENCE { encData [0] EncryptedData, -- PA-OTP-ENC-CONFIRM -- Key usage of KEY_USAGE_OTP_CONFIRM ... } KEY_USAGE_OTP_CONFIRM 46 PA-OTP-ENC-CONFIRM ::= SEQUENCE { nonce [0] OCTET STRING, ... } encData An EncryptedData containing a PA-OTP-ENC-CONFIRM containing the value of the nonce from the corresponding PA-OTP-REQUEST encrypted under the current Reply Key. The key usage SHALL be KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as that used by the client in the PA-OTP-REQUEST. 4.4. 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. Richards Expires April 12, 2010 [Page 22] Internet-Draft OTP Pre-authentication October 2009 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 "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 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 this field MAY be used to carry a system generated PIN that MAY be used by the user when changing the PIN. minLength and maxLength If the "systemSetPin" flag is not set then the minLength and maxLength fields MAY be included to pass restrictions on the size of the user selected PIN. last-req The last-req element (as defined in section 5.4.2 of [RFC4120]) MAY be included with an lr-type of 6 to carry PIN expiration information. Richards Expires April 12, 2010 [Page 23] Internet-Draft OTP Pre-authentication October 2009 * 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 PIN 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 A registry will be required for the URIs to be used as otp-algID values as introduced in Section 4.1. It is currently anticipated that the registry being introduced in section 12.4 of [HoPeMa09] can be used for this purpose and no other IANA actions are anticipated. 6. Security Considerations 6.1. Man-in-the-Middle 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 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 achieve crypto-binding to the outer channel. As described in section 6.5 of [ZhHa09], FAST can use an anonymous TGT obtained using anonymous PKINIT [ZhLe08] [RFC4556] as the Armor Key. However, the current anonymous PKINIT proposal is open to man- Richards Expires April 12, 2010 [Page 24] Internet-Draft OTP Pre-authentication October 2009 in-the-middle attacks since the attacker 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. It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it 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 4-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 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. 6.4. Replay In the 4-pass version of this protocol, the client encrypts a KDC generated nonce and so replay can be detected by the KDC. The 2-pass Richards Expires April 12, 2010 [Page 25] Internet-Draft OTP Pre-authentication October 2009 version of the protocol does not involve a server nonce but the client instead encrypts a timestamp and so is not protected from replay in the same way. In the case of time or event-based tokens, a replayed OTP can be detected by the OTP server since they keep track of the last used value. However, OTP servers may not be able to detect replay of OTPs generated using only a client generated challenge and since the KDC would not be able to detect replay in 2-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 2-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. 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. 6.6. FAST Facilities The secret used to generate the OTP is known only to the client and the KDC and 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 Polansky and Boris Khoutorski. Many valuable suggestions were also made by members of the Kerberos Richards Expires April 12, 2010 [Page 26] Internet-Draft OTP Pre-authentication October 2009 Working Group but special thanks go to Larry Zhu, Jeffrey Hutzelman, Tim Alsop, Henry Hotz and Nicolas Williams. I would also like to thank Tim Alsop and Srinivas Cheruku of CyberSafe for many valuable review comments. 8. References 8.1. Normative References [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. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [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.". [X.690] ITU-T, "Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).". [ZhHa09] Zhu, L. and S. Hartman, "A generalized Framework for Kerberos Pre-Authentication", draft-ietf-krb-wg-preauth-framework-14 (work in progress), August 2009. Richards Expires April 12, 2010 [Page 27] Internet-Draft OTP Pre-authentication October 2009 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. [HoPeMa09] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container", draft-ietf-keyprov-pskc-03 (work in progress), June 2009. [HoReNeZo04] Horstein, K., Renard, K., Neuman, C., and G. Zorn, "Integrating Single-use Authentication Mechanisms with Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in progress), July 2004. [RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One- Time Password System", 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. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [ZhLe08] Zhu, L. and P. Leach, "Anonymity Support for Kerberos", draft-ietf-krb-wg-anon-10 (work in progress), October 2008. Appendix A. ASN.1 Module OTPKerberos DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS KerberosTime, KerberosFlags, EncryptionKey, Int32, EncryptedData, LastReq FROM KerberosV5Spec2 {iso(1) identified-organization(3) dod(6) internet(1) security(5) Richards Expires April 12, 2010 [Page 28] Internet-Draft OTP Pre-authentication October 2009 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 3280. PA-OTP-CHALLENGE ::= SEQUENCE { flags [0] ChallengeFlags, nonce [1] OCTET STRING, supportedHashAlg [2] SEQUENCE OF AlgorithmIdentifier OPTIONAL, iterationCount [3] Int32 OPTIONAL, otp-service [4] UTF8String OPTIONAL, otp-keyInfo [5] SEQUENCE OF OTP-KEYINFO OPTIONAL, ... } OTP-KEYINFO ::= SEQUENCE { flags [0] OTPFlags, otp-vendor [1] UTF8String OPTIONAL, otp-challenge [2] OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-length [3] Int32 OPTIONAL, otp-keyID [4] OCTET STRING OPTIONAL, otp-algID [5] AnyURI OPTIONAL, ... } ChallengeFlags ::= KerberosFlags -- reserved(0), -- must-encrypt-nonce (1) OTPFlags ::= KerberosFlags -- reserved(0), -- nextOTP(1), -- combine(2), -- pin-required(3), -- pin-not-required(4) PA-OTP-REQUEST ::= SEQUENCE { flags [0] OTPFlags, nonce [1] OCTET STRING, encData [2] EncryptedData, -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC -- Key usage of KEY_USAGE_OTP_REQUEST hashAlg [3] AlgorithmIdentifier OPTIONAL, Richards Expires April 12, 2010 [Page 29] Internet-Draft OTP Pre-authentication October 2009 iterationCount [4] Int32 OPTIONAL, otp-value [5] OCTET STRING OPTIONAL, otp-challenge [6] OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-time [7] KerberosTime OPTIONAL, otp-counter [8] OCTET STRING OPTIONAL, otp-format [9] OTPFormat OPTIONAL, otp-keyID [10] OCTET STRING OPTIONAL, otp-algID [11] AnyURI OPTIONAL, ... } PA-OTP-ENC-REQUEST ::= SEQUENCE { nonce [0] OCTET STRING, ... } OTPFormat ::= INTEGER { decimal(0), hexadecimal(1), alphanumeric(2), binary(3) } PA-OTP-CONFIRM ::= SEQUENCE { encData [0] EncryptedData, -- PA-OTP-ENC-CONFIRM -- Key usage of KEY_USAGE_OTP_CONFIRM ... } PA-OTP-ENC-CONFIRM ::= 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), Richards Expires April 12, 2010 [Page 30] Internet-Draft OTP Pre-authentication October 2009 -- mandatory(2) AnyURI ::= UTF8String (CONSTRAINED BY { /* MUST be a valid URI in accordance with IETF RFC 2396 */ }) END 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. supportedHashAlg AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1 Richards Expires April 12, 2010 [Page 31] Internet-Draft OTP Pre-authentication October 2009 iterationCount 1024 otp-service A string that can be used by the client to assist the user in locating the correct token. 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 obtains the current OTP value from the token and records the time as reported by the token. 8. The client generates Client Key and Reply Key as described in Section 3.6 using SHA-256 from the list of algorithms sent by the KDC and the iteration count of 100,000 as required by local policy. 9. The client constructs a PA-OTP-REQUEST as follows: flags 0 nonce A 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. Richards Expires April 12, 2010 [Page 32] Internet-Draft OTP Pre-authentication October 2009 10. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST. 11. The client sends an AS-REQ to the KDC containing the PA-FX-FAST- REQUEST within the padata. 12. The KDC validates the pre-authentication data in the PA-OTP- REQUEST: * 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 and hash algorithm of SHA-256 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. 13. The KDC constructs a TGT for the user. 14. The KDC constructs a PA-OTP-CONFIRM as follows: encData An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM and the same encryption type as used by the client in the PA- OTP-REQUEST. The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-REQUEST. 15. The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a PA-FX-FAST-REPLY. 16. 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. 17. The client authenticates the KDC and verifies the Reply Key change. * Uses the generated Reply Key to decrypt the PA-OTP-ENC- CONFIRM in the encData of the PA-OTP-CONFIRM. * Authenticates the KDC by comparing the nonce value from the decrypted PA-OTP-ENC-CONFIRM to that sent in the corresponding PA-OTP-REQUEST. Richards Expires April 12, 2010 [Page 33] Internet-Draft OTP Pre-authentication October 2009 B.2. Two Pass Authentication In this mode, the client includes a PA-OTP-REQUEST within a PA-FX- FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC. In this example, the user has been issued with a hand-held token and 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 encryption type of aes128-cts-hmac-sha1-96 to use to encrypt the encData. o The fact that 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. 2. The client generates 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 nonce A randomly generated value. 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 aes128-cts-hmac-sha1-96. 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 pre-authentication data: * Generates the Client Key and Reply Key from the unhashed OTP value for the user identified in the AS-REQ. Richards Expires April 12, 2010 [Page 34] Internet-Draft OTP Pre-authentication October 2009 * 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 constructs a PA-OTP-CONFIRM as follows: encData An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM and an encryption type of aes128-cts-hmac-sha1-96 (the encryption type used by the client in the PA-OTP-REQUEST). The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP- REQUEST. 9. The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a PA-FX-FAST-REPLY. 10. 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. 11. The client authenticates the KDC and verifies the key change. * Uses the generated Reply Key to decrypt the PA-OTP-ENC- CONFIRM in the encData of the PA-OTP-CONFIRM. * Authenticates the KDC by comparing the nonce value from the decrypted PA-OTP-ENC-CONFIRM to that sent in the corresponding PA-OTP-REQUEST. 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 along with the PA-OTP-CONFIRM 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. Richards Expires April 12, 2010 [Page 35] Internet-Draft OTP Pre-authentication October 2009 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. KDC constructs a ticket for a PIN change service with a one minute lifetime. 4. KDC constructs a PA-OTP-CONFIRM as in the previous examples. 5. KDC constructs a PA-OTP-PIN-CHANGE as follows: flags 0 minLength 4 maxLength 8 6. KDC encrypts the PA-OTP-PIN-CHANGE and PA-OTP-CONFIRM within the enc-fast-rep of a PA-FX-FAST-REPLY. 7. KDC returns an AS-REP to the client containing the ticket to the PIN change service and padata containing the PA-FX-FAST-REPLY. 8. The client authenticates the KDC as in the previous examples. 9. The client uses the ticket in the AS-REP to call the PIN change service and change the user's PIN. 10. The client sends a second AS-REQ to the KDC containing a PA-OTP- REQUEST constructed using the new PIN. 11. The KDC responds with an AS-REP containing a TGT and a PA-OTP- CONFRIM. 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), Richards Expires April 12, 2010 [Page 36] Internet-Draft OTP Pre-authentication October 2009 the KDC determines that the local record of the token's state needs to be re-synchronized 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 re-synchronizing. 3. KDC constructs a PA-OTP-CHALLENGE as follows: nonce A randomly generated value. supportedHashAlg AlgorithmIdentifiers for SHA-256 and SHA-1 iterationCount 1024 otp-service Set to a string that can be used by the client to assist the user in locating the correct token. otp-keyInfo Information about how the OTP should be generated from the token. flags nextOTP bit set 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. 6. The client generates Client Key Reply Key as described in Section 3.6 using SHA-256 from the list of algorithms sent by the KDC and the iteration count of 100,000 as required by local policy. Richards Expires April 12, 2010 [Page 37] Internet-Draft OTP Pre-authentication October 2009 7. The client constructs a PA-OTP-REQUEST as follows: flags nextOTP bit set nonce A 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. Authentication process now proceeds as with the standard 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 Richards Expires April 12, 2010 [Page 38]