Network Working Group G. Richards Internet-Draft RSA, The Security Division of EMC Intended status: Standards Track October 11, 2006 Expires: April 14, 2007 OTP Kerberos draft-richards-otp-kerberos-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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. Richards Expires April 14, 2007 [Page 1] Internet-Draft OTP Kerberos October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 3 2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 4 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 4 3.1. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Client Request . . . . . . . . . . . . . . . . . . . . . . 5 3.3. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Client Response . . . . . . . . . . . . . . . . . . . . . 7 3.5. Verifying the pre-auth Data . . . . . . . . . . . . . . . 7 3.6. Updating the Secret . . . . . . . . . . . . . . . . . . . 9 4. Reply Key Generation Algorithms . . . . . . . . . . . . . . . 9 4.1. Using the OTP Value Directly . . . . . . . . . . . . . . . 9 4.2. Hardening the OTP Value . . . . . . . . . . . . . . . . . 9 4.2.1. Using an Iteration Count . . . . . . . . . . . . . . . 10 4.2.2. Using a Shared Secret and OTP . . . . . . . . . . . . 10 4.2.3. Using a Password and OTP . . . . . . . . . . . . . . . 11 4.3. Generating the Key without the OTP . . . . . . . . . . . . 11 4.3.1. Using the Password . . . . . . . . . . . . . . . . . . 11 4.3.2. Using a Shared Secret . . . . . . . . . . . . . . . . 11 5. OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12 5.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12 5.2. PA-OTP-RESPONSE . . . . . . . . . . . . . . . . . . . . . 13 5.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16 5.4. PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5. OTPChalKeyParam . . . . . . . . . . . . . . . . . . . . . 17 5.6. OTPRespKeyParam . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Denial of service attacks . . . . . . . . . . . . . . . . 19 7.3. Use of a Shared Secret Value . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Richards Expires April 14, 2007 [Page 2] Internet-Draft OTP Kerberos October 2006 1. Introduction A One-Time Password (OTP) token may be a handheld hardware device, a hardware device connected to a personal computer through an electronic interface such as USB or a software module resident on a personal computer. All these devices generate one-time passwords that may be used to authenticate a user towards some service. This document describes extensions to Kerberos V5 [RFC4120] to support pre-authentication using an OTP. In this proposal, the KDC sends the client a random nonce, information on which OTP token is to be used, how the OTP is to be generated using that token and how the Reply Key is to be generated. The Reply Key is then used to encrypt the nonce value and the encrypted value is returned to the KDC as the pre-authentication data. Depending on whether the KDC can obtain the OTP value, the OTP value is either used in the generation of the Reply Key or is encrypted using the key and returned to the KDC along with the encrypted nonce. The encrypted nonce, an optional encrypted OTP value and information on how the Reply Key and OTP value were generated are sent to the KDC and used by the KDC to generate the same Reply Key and decrypt and verify the nonce. This proposal is partially based upon previous work on integrating single-use authentication mechanisms into Kerberos [HoReNeZo04] and uses the existing password-change extensions to handle PIN change as described in [RFC3244]. 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 is an early draft of this document and so is liable to change significantly. >> 2. Usage Overview 2.1. Pre-Authentication The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP and KRB_ERROR. The client begins by sending an initial KRB_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 in the PA-DATA. Richards Expires April 14, 2007 [Page 3] Internet-Draft OTP Kerberos October 2006 The PA-OTP-CHALLENGE contains information on how the OTP should be generated, how the Reply Key should be generated and a nonce. The client uses this information to locate the token and generate the OTP, generate the Reply Key and then encrypt the nonce using the generated key. Depending on the type of OTP, the Reply Key may be generated using the OTP value or alternatively, the generated OTP will instead be encrypted along with the nonce using the key. The encrypted nonce along with information on how the OTP and Reply Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA- DATA element. The KDC then uses this information to generate the same key as the client, allowing it to verify the pre-authentication by decrypting the nonce. If the validation succeeds then the KDC returns the TGT in a KRB_AS_REP. 2.2. PIN Change If, following successful validation of a PA-OTP-RESPONSE in a KRB_AS_REQ, the KDC requires that the user changes their PIN then it will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP. This pre-auth data can be used to return a new PIN to the user if the KDC has updated the PIN or to indicate to the user that they must change their PIN. In the latter case, user PIN change shall be handled by a PIN change service supporting the ChangePasswdData in a KRB_AP_REQ as described in [RFC3244]. If such a user PIN change is required then the KDC SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it only issues tickets for the PIN change service until the PIN has been changed. 2.3. Re-Synchronization It is possible with time and event-based tokens, that the client and OTP server will loose synchronization. If, when processing a PA-OTP- RESPONSE, the pre-authentication validation fails for this reason then the KDC SHALL return a KRB_ERROR message containing a PA-OTP- CHALLENGE in the PA-DATA with the "nextOTP" flag set. The setting of this flag will cause the client to re-try the authentication using the OTP for the next token "state". 3. Pre-Authentication Protocol Details 3.1. Shared Secret The method of deriving the Reply Key shall depend upon: Richards Expires April 14, 2007 [Page 4] Internet-Draft OTP Kerberos October 2006 o Whether the OTP is of sufficiently high entropy to generate the key alone. o Whether the OTP has insufficient entropy and so must be strengthened. o Whether the OTP value used can be obtained by the KDC. If the OTP value is of low entropy then it is important to slow down an attacker sufficiently to make it economically unattractive to brute-force search for an OTP given an observed OTP-Kerberos exchange. If the OTP value cannot be obtained by the KDC then it cannot be used in the derivation of the Reply Key but shall be encrypted using the generated key rather than used to derive the key and so the Reply Key must be derived from some other value. Both of these issues can be solved using shared secret value known by the client and KDC but unknown to the attacker. This protocol supports the following types of secret: o A pre-shared secret can be established between the client and KDC and stored on the client. o Diffie-Hellman key agreement (as defined in [RFC2631]) can be used to establish a shared secret value ZZ. The server's public key, and the base and prime are stored on the client. The pre-shared secret value or the Diffie-Hellman shared secret value, ZZ, are converted to a value of the required length for the encryption scheme's random-to-key function using the n-fold function (both defined in [RFC3961]). 3.2. Client Request The client begins by sending an initial KRB_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-RESPONSE then it will respond as described in Section 3.3. Alternatively, if the client has all the necessary information, it MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and include it in the initial request. 3.3. KDC Challenge If the user is required to authenticate using an OTP then the KDC SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing: Richards Expires April 14, 2007 [Page 5] Internet-Draft OTP Kerberos October 2006 o An error code of KDC_ERR_PREAUTH_REQUIRED o An e-data field containing PA-DATA with a PA-OTP-CHALLENGE. The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by the generated Reply Key and it MAY also contain information on how the OTP value is to be generated and information on how the Reply Key is to be generated in an otp-keyParam element. Use of the otp-keyParam element is OPTIONAL. If it is not present the Reply Key SHALL be generated directly from the OTP value as specified in Section 4.1 and the OTP value SHALL NOT be included in the client response. If the otp-keyParam element is present and the "sendOTP" flag is set then the OTP value MUST NOT be used in the generation of the Reply Key but it must instead be returned to the KDC encrypted using the key. The Reply Key MUST be derived using one of the methods described in Section 4.3. If the "sendOTP" flag is not set then the OTP value is to be used in the key derivation then the client MUST use one of the methods described in Section 4.2. The otp-keyParam element will control the use of a shared secret in the key derivation. If the "noSecret" flag is set the the client MUST NOT use a secret value in the key derivation. If the "noSecret" flag is not set and secret identifier is present then the client MUST NOT use any other secret value. If the "noSecret" flag is not set and a secret identifier is not present then the client MAY still use a value if there is a value associated with the KDC. If the "noSecret" flag is not set and the client can locate a secret value for the KDC then the Reply Key will be generated using one of the following methods: o If the OTP is to be included in the key derivation then the key SHALL be derived as specified in Section 4.2.2. o If the OTP is to be sent encrypted in the response then the key SHALL be derived as specified in Section 4.3.2. If the client fails to find a shared secret for the KDC or the "noSecret" flag was set in the challenge then the Reply Key will be generated using one of the following methods: o If the OTP is to be used in the key derivation then the KDC MAY specify an iteration count. If such a value is specified then the key SHALL be derived from the OTP as described in Section 4.2.1. Richards Expires April 14, 2007 [Page 6] Internet-Draft OTP Kerberos October 2006 o If the OTP is to be used in the key derivation but an iteration count was not specified then the key SHALL be derived from the OTP value and the user's Kerberos password as described in Section 4.2.3. o If the OTP is to be sent encrypted then the key SHALL be derived from the user's Kerberos password as described in section Section 4.3.1. 3.4. Client Response The client will use the generated Reply Key to encrypt the nonce from the KDC challenge and, if required, to encrypt the OTP value. This encrypted data SHALL be sent to the KDC in the otp-encData of a PA- OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ. This response MAY also include information on how the Reply Key was generated in an optional otp-keyParam element. The client MUST NOT include this element if the Reply Key was generated directly from the OTP value. The element MUST be included if the Reply Key was generated using either a secret value or an iteration count and contain the secret identifier and iteration count value. If the Reply Key was generated using a password then the element MUST be present and MUST be empty. The response SHOULD also include information on the generated OTP value. 3.5. Verifying the pre-auth Data If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use the information in the otp-keyParam to generate the same Reply Key and decrypt the encrypted nonce contained in the otp-encData. If the encrypted OTP value is not included in the otp-encData then the Reply Key was generated using the OTP value. The KDC SHALL therefore use the OTP information in the PA-OTP-RESPONSE to obtain the OTP value for the user and use the value along with the information in the otp-keyParam to generate the Reply Key. This information SHALL be used as follows: o If the otp-keyParam is not present then the Reply Key SHALL be generated directly from the OTP value as described in Section 4.1. o If the otp-keyParam is present but empty then the Reply Key SHALL be generated using the OTP value and the user's Kerberos Password as described in Section 4.2.3. Richards Expires April 14, 2007 [Page 7] Internet-Draft OTP Kerberos October 2006 o If the otp-keyParam is present and contains a secret identifier then the Reply Key SHALL be generated using the OTP value and the secret value as described in Section 4.2.2. If the identified secret value can not be found then the KDC SHALL respond with a KDC_ERR_PREAUTH_REQUIRED error as described above but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE. o if the otp-keyParam is present and contains an iteration count then the Reply Key shall be generated from the OTP value using the iteration count value as described in Section 4.2.1. If the encrypted OTP value is included in the otp-encData then the Reply Key was not generated using the OTP value but was instead used to encrypt the OTP value. The KDC SHALL therefore use the information in the otp-keyParam to generate the Reply Key and decrypt the OTP value. It SHALL then validate the decrypted value using the OTP information included in the response and fail the authentication if the value is not valid. This Reply Key SHALL be generated as follows: o If the otp-keyParam is not present the the KDC SHALL fail the pre- authentication with an error of KDC_ERR_PREAUTH_FAILED. If the otp-keyParam is omitted then the Reply Key was generated directly from the OTP value and so is an error if the OTP value is encrypted using the key. o If the otp-keyParam is present but empty then the Reply Key SHALL be generated using the user's Kerberos Password as described in Section 4.3.1. o If the otp-keyParam is present and contains a secret identifier then the Reply Key SHALL be generated using the secret value as described in Section 4.3.2. If the identified secret value can not be found then the KDC SHALL respond with a KDC_ERR_PREAUTH_REQUIRED error as described above but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE. o If the otp-keyParam is present and contains an iteration count then the KDC SHALL fail the authentication with an error of KDC_ERR_PREAUTH_FAILED. Richards Expires April 14, 2007 [Page 8] Internet-Draft OTP Kerberos October 2006 3.6. Updating the Secret The secret value can be pre-configured on the client but MAY also be transferred from the KDC to the client in encrypted form in the PA- OTP-CONFIRM of the KRB_AS_REP. If a client receives a new secret value in this way then it MUST update any stored value associated with the KDC. 4. Reply Key Generation Algorithms 4.1. Using the OTP Value Directly If only the OTP value is to be used then the Reply Key SHALL be generated by passing the OTP value through string-to-key (defined in [RFC3961]). K = string-to-key(OTP) The salt and additional parameters for string-to-key will be as defined in section 3.1.3 of [RFC4120]. 4.2. Hardening the OTP Value If the OTP value requires strengthening then several methods shall be supported. o The OTP can be used on its own in the key derivation but run through an iteration process many times as described in Section 4.2.1. o A secret value, shared between the KDC and client can be used along with the OTP value to derive the key as described in Section 4.2.2. o The user's Kerberos password can be used along with the OTP value in the key derivation as described in Section 4.2.3. A shared secret can only be used if the client supports the storing of persistent values and has such a value stored. The other two methods could be used to establish a secret value or when client are not capable of storing such values. <> Richards Expires April 14, 2007 [Page 9] Internet-Draft OTP Kerberos October 2006 4.2.1. Using an Iteration Count An initial key is generated by running the OTP value through string- to-key. K = string-to-key(OTP) The following key generation process is then repeated iteration count times with the resulting key being used as the protocol key for the next iteration. A sequence of octets, R, is produced from K by iterating over calls to the function pseudo-random (defined in [RFC3961]) and appending the results until at least the number of bits required by random-to- key have been produced. If the result of the iteration is longer than the required length then the result shall be truncated. The octet string parameter for pseudo-random shall be the ASCII string "CombineA" with the loop number appended. This string has the following byte value: {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41} A new key is then generated by running R through random-to-key. K = random-to-key(R) 4.2.2. Using a Shared Secret and OTP Two intermediate keys, K1 and K2, shall be generated by running the OTP value once through string-to-key and the shared secret through random-to-key. K1 = random-to-key(shared secret) K2 = string-to-key(OTP) Two sequences of octets, R1 and R2, are then produced from K1 and K2 by iterating over calls to pseudo-random and appending the results until the required number of bits have been generated for random-to- key. If the result of the iteration is longer than the required length then the result shall be truncated. The octet string parameter for pseudo-random shall be the ASCII string "CombineA" for K1 and "CombineB" for K2 with the loop number appended. These have the following byte values: Richards Expires April 14, 2007 [Page 10] Internet-Draft OTP Kerberos October 2006 {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41} {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42} The final key is then generated by combining R1 and R2 using exclusive-OR and running the result through random-to-key. K = random-to-key(R1 ^ R2) << Check on issue around combining DES keys. >> 4.2.3. Using a Password and OTP Two intermediate keys, K1 and K2, shall be generated by running the OTP and password through string-to-key. K1 = string-to-key(Password) K2 = string-to-key(OTP) The same process as described in Section 4.2.2 is then used to derive the final reply key. 4.3. Generating the Key without the OTP If the OTP value cannot be used in the derivation of the reply key then this protocol supports the following options: o A secret value, shared between the KDC and client can be used to derive the key as described in Section 4.3.2. o The user's Kerberos password can be used in the key derivation as described in Section 4.3.1. A shared secret can only be used if the client supports the storing of persistent values and has such a value stored. The password-only method could be used to establish a secret value or when clients are not capable of storing such values. 4.3.1. Using the Password The Reply Key SHALL be generated by passing the password value through string-to-key (defined in [RFC3961]). 4.3.2. Using a Shared Secret The reply key shall be generated by running the shared secret value through random-to-key. K = random-to-key(shared secret) Richards Expires April 14, 2007 [Page 11] Internet-Draft OTP Kerberos October 2006 5. OTP Kerberos Types 5.1. PA-OTP-CHALLENGE This is a pre-authentication type sent by the KDC to the client in a KRB_ERROR. It contains information for the client on how to generate the OTP and reply key. PA-OTP-CHALLENGE ::= SEQUENCE { otp-flags OTPFlags, otp-nonce UInt32, otp-etype INTEGER, otp-track-id [0] OCTET STRING OPTIONAL, otp-challenge [1] OCTET STRING OPTIONAL, otp-length [2] INTEGER OPTIONAL, otp-service [3] UTF8String OPTIONAL, otp-keyID [4] OCTET STRING OPTIONAL, otp-algID [5] INTEGER OPTIONAL, otp-keyParam [6] OTPChalKeyParam OPTIONAL } OTPFlags ::= KerberosFlags -- nextOTP (0) otp-flags If the "nextOTP" flag is set then the OTP calculated SHALL be based on the next token "state" rather than the current one. As an example, for a time-based token, this means the next time slot. For an event-based token, this could mean the next counter value, if counter values are used. otp-nonce A KDC-supplied nonce value to be encrypted by the client in the PA-OTP-RESPONSE. otp-etype The encryption type to be used by the client for all encrypted fields in the PA-OTP-RESPONSE. otp-track-id This optional element is used by the KDC to link a client response to the corresponding KDC challenge. If present, this element MUST be copied by the client to the corresponding element in the PA- OTP-RESPONSE. Richards Expires April 14, 2007 [Page 12] Internet-Draft OTP Kerberos October 2006 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 The otp-length is used by the KDC to specify the desired length of the generated OTP. otp-service An identifier of the service supported by the KDC. This value can be used by the client to locate information such as the shared secret value and OTP key to use. otp-keyID The identifier of the OTP key to be used in the OTP calculation. If this value is not present then the client SHOULD use other values such as the otp-service and otp-algID to locate the appropriate key. otp-algID The identifier of the algorithm to use when generating the OTP. otp-keyParam Information on how the Reply Key should be generated from the OTP and shared secret. If the value is not present then the reply key MUST be generated directly from the OTP value. <> 5.2. PA-OTP-RESPONSE This is a pre-authentication type sent by the client to the KDC in a KRB_AS_REQ containing the encrypted pre-authentication data. It contains information on the OTP used and how the key was generated that encrypts the pre-authentication data. This information will then allow the KDC to generate the same key and validate the pre- authentication data. Richards Expires April 14, 2007 [Page 13] Internet-Draft OTP Kerberos October 2006 PA-OTP-RESPONSE ::= SEQUENCE { otp-flags OTPFlags, otp-nonce UInt32, otp-encData EncryptedData, -- PA-ENC-RESPONSE -- Key usage of <> otp-track-id [0] OCTET STRING OPTIONAL, otp-challenge [1] OCTET STRING OPTIONAL, otp-time [2] KerberosTime OPTIONAL, otp-counter [3] OCTET STRING OPTIONAL, otp-format [4] OTPFormat OPTIONAL, otp-keyID [5] OCTET STRING OPTIONAL, otp-keyParam [6] OTPRespKeyParam OPTIONAL } OTPFormat ::= INTEGER { decimal(0), hexadecimal(1), alphanumeric(2), binary(3) } PA-ENC-RESPONSE ::= SEQUENCE { nonce OCTET STRING OPTIONAL, otp [0] OCTET STRING OPTIONAL } otp-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. otp-nonce The nonce value encrypted in the otp-encData. If the PA-OTP- RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value MUST be a copy of the corresponding value in the challenge. If no challenge was received then the nonce value MUST be generated by the client. Richards Expires April 14, 2007 [Page 14] Internet-Draft OTP Kerberos October 2006 otp-track-id This element MUST be included if and only if an otp-track-id was included in the corresponding PA-OTP-CHALLENGE. If included, then the value MUST be copied from the PA-OTP-CHALLENGE. otp-challenge Value used by the client to send the challenge used in the OTP calculation. It MUST be sent to the KDC if and only if the value would otherwise be unknown to the KDC. For example, the token or client modified or generated challenge. otp-time Value used by the client to send the time used in the OTP calculation. otp-counter The counter value used in the OTP calculation. Use of this element is OPTIONAL but it MAY be used by a client to simplify the OTP calculations of the KDC to contain the counter value as reported by the OTP token. otp-format The format of the generated OTP. otp-keyID The identifier of the OTP key used. otp-keyParam Information on how the reply key was generated from the OTP and shared secret. If the value is not present then the reply key was generated directly from the OTP value. otp-encData The otp-encData field contains the result of the pre- authentication process and is encrypted using the generated Reply Key. The fields of this element are populated as follows: nonce The value of otp-nonce. otp The generated OTP value. Present if the "sendOTP" flag is set in the challenge. <> Richards Expires April 14, 2007 [Page 15] Internet-Draft OTP Kerberos October 2006 5.3. PA-OTP-CONFIRM This is a pre-authentication type returned by the KDC in a KRB_AS_REP if the client requires a new shared secret value. The value is encrypted as described in section 5.2.9 of [RFC4120] using the current reply key as derived by the KDC from the OTP. PA-OTP-CONFIRM ::= SEQUENCE { identifier OCTET STRING, newSecretValue EncryptedData -- OTPNewSecret -- Key usage of <> } OTPNewSecret ::= CHOICE { sharedSecret [0] OCTET STRING, dhParams [1] DHParam } DHParam ::= SEQUENCE { dhParameter DHParameter, dhPublic INTEGER } identifier An octet string identifying the new secret value. newSecretValue The new secret data encrypted using the current Reply Key. The encrypted data can be of one of the following types: sharedSecret A random bit string. dhParams A Diffie-Hellman public value, prime and modulus. 5.4. PA-ENC-PIN Pre-authentication type returned by the KDC in a KRB_AS_REP if the user must change their PIN or if the user's PIN has been changed. Richards Expires April 14, 2007 [Page 16] Internet-Draft OTP Kerberos October 2006 PA-ENC-PIN ::= EncryptedData -- PA-ENC-PIN-ENC -- Key usage of <> PA-ENC-PIN-ENC ::= SEQUENCE { flags PinFlags, pin [0] UTF8String OPTIONAL, minLength [1] INTEGER OPTIONAL, maxLength [2] INTEGER OPTIONAL } PinFlags ::= KerberosFlags -- systemSetPin (0) If the "systemSetPin" flag is set then the user's PIN has been changed and the new PIN value is contained in the pin field. The PIN field MUST therefore be present. If the "systemSetPin" flag is not set then the user's PIN has not been changed by the server but it MUST instead be changed by the user using the PIN change service. Restrictions on the size of the PIN MAY be given by the minLength and maxLength fields. If the pin field is present then it contains a PIN value that MAY be used by the user when changing the PIN. The KDC MAY only issue tickets for the PIN change service until the PIN has been changed. 5.5. OTPChalKeyParam This data type can optionally be included by the KDC in a PA-OTP- CHALLENGE to instruct the client on how to generate the reply key. This value is included in the challenge if the OTP generated by the token is too weak to be used alone in the generation of the key. OTPChalKeyParam ::= SEQUENCE { flags ChallengeFlags, identifer [0] OCTET STRING OPTIONAL, iterationCount [1] INTEGER OPTIONAL } ChallengeFlags ::= KerberosFlags -- sendOTP (0) -- noSecret (1) flags Flags controlling the generation of the Reply Key. Richards Expires April 14, 2007 [Page 17] Internet-Draft OTP Kerberos October 2006 sendOTP If the "sendOTP" flag is set then the client MUST NOT use the OTP value to generate the reply key. It must instead use the generated key to encrypt the OTP value and include the encrypted value in the PA-OTP-RESPONSE. noSecret If the "noSecret" flag is set then the client MUST NOT use any stored secret value in the derivation of the Reply Key. If the "sendOTP" flag is also set then the Kerberos password MUST be used. If the "sendOTP" flag is not set then the iteration count MUST be used if it is present or the Kerberos password MUST be used if the iteration count is not specified. identifier Name of the secret that the client SHOULD use to generate the reply key. If a secret is specified but cannot be located by the client and an iteration count is specified then the client should generate the key using the iteration count. If a secret value is specified and cannot be located and an iteration count is not specified then the reply key MUST be generated using the user's Kerberos password. iterationCount This value contains the iteration count to use when the generated OTP value is used in the derivation of the reply key. This value is used by the client if a shared secret is not specified or is specified but cannot be found. The value has no meaning if the "sendOTP" flag is set. 5.6. OTPRespKeyParam This data type can optionally be included by the client in a PA-OTP- RESPONSE to inform the KDC of how the reply key was generated. OTPRespKeyParam ::= SEQUENCE { iterationCount [0] INTEGER OPTIONAL, secret SEQUENCE { identifier OCTET STRING, dhPublic [1] INTEGER OPTIONAL } } Richards Expires April 14, 2007 [Page 18] Internet-Draft OTP Kerberos October 2006 iterationCount The actual value of the iteration count used by the client in the key derivation. If omitted then no iteration was used in the derivation of the reply key. secret Information on the secret used in the key derivation. If this value is omitted then no shared secret was used. identifier An octet string identifying the shared secret value used by the client in the key derivation. dhPublic The client's Diffie-Hellman public key. Present only if a Diffie-Hellman secret was used. 6. IANA Considerations A registry may be required for the otp-AlgID values as introduced in Section 5.1. No other IANA actions are anticipated. 7. Security Considerations 7.1. Active attacks <> 7.2. Denial of service attacks An active attacker may replace the iteration count value in the PA- OTP-RESPONSE sent by the client to slow down an authentication server. Authentication servers SHOULD protect against this, e.g. by disregarding PA-OTP-RESPONSE elements with an iteration count value higher than some pre- or dynamically- (depending on load) set number. 7.3. Use of a Shared Secret Value As described in Section 3.1, the use of a shared secret value will slow down an attacker's search for a matching OTP. The ability to transfer such a value in encrypted form from the KDC to the client means that, even though there may be an initial computational cost for the KDC to authenticate the user if an iteration count is used, subsequent authentications will be efficient, while at the same time more secure, since a pre-shared, value will not be easily found by an attacker. Richards Expires April 14, 2007 [Page 19] Internet-Draft OTP Kerberos October 2006 If a client does not have a pre-configured secret value for a KDC then it will have to generate the Reply Key using an iteration count or the Kerberos password. If an iteration count is used then an attacker observing such a KRB_AS_REQ may, depending on available resources, be able to successfully attack that request. Once the correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM will potentially give the attacker access to the server-provided secret value. For this reason, initial exchanges with KDC servers SHOULD occur in a secure environment and the lifetime of this value must also be calculated with this in mind. Finally, the value MUST be securely stored by the client and the KDC, associated with the user. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols", RFC 3244, February 2002. [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. 8.2. Informative References [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. Richards Expires April 14, 2007 [Page 20] Internet-Draft OTP Kerberos October 2006 Author's Address Gareth Richards RSA, The Security Division of EMC RSA House Western Road Bracknell, Berkshire RG12 1RT UK Email: grichards@rsa.com Richards Expires April 14, 2007 [Page 21] Internet-Draft OTP Kerberos October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Richards Expires April 14, 2007 [Page 22]