Network Working Group G. Richards Internet-Draft RSA, The Security Division of EMC Intended status: Standards Track January 17, 2008 Expires: July 20, 2008 OTP Preauthentication draft-ietf-krb-wg-otp-preauth-02 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 July 20, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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 July 20, 2008 [Page 1] Internet-Draft OTP Preauthentication January 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 4 2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 5 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 5 3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 5 3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 6 3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 7 3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 8 3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 8 4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 10 4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 10 4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 12 4.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 14 4.4. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . . . 16 6.2. Reflection . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.4. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Richards Expires July 20, 2008 [Page 2] Internet-Draft OTP Preauthentication January 2008 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 a FAST [ZhHa07] factor that allows 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. This FAST factor provides the following facilities (as defined in [ZhHa07]): client-authentication, replacing-reply-key and KDC- authentication. It does not provide the strengthening-reply-key facility. 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. 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 and which OTP key should be used. In both systems, in order to create the message sent to the KDC, the client must generate the OTP value and three keys: the standard Reply Key, a key to encrypt the data sent to the KDC and a final key to decrypt the KDC's reply. 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, 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 supports the use of hashed OTP values in the key derivation. The message 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 of the generated keys within the encrypted part of the FAST padata of the AS-REP. This proposal is partially based upon previous work on integrating Richards Expires July 20, 2008 [Page 3] Internet-Draft OTP Preauthentication January 2008 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]. 2. Usage Overview 2.1. Pre-Authentication The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP and KRB_ERROR messages. In the 4-pass system, 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. The PA-OTP-CHALLENGE will contain a KDC generated nonce, an encryption type, an optional list of hash algorithm identifiers, an optional iteration count and optional information on how the OTP should be generated by the client. The client will then generate the OTP value, its own nonce and three keys: the Reply Key, a Client Key to encrypt the KDC's nonce and a Server Key used to decrypt the KDC's reply. As described in Section 3.6, these keys will be generated from the Armor Key (defined in [ZhHa07]) 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 request then the client will use the hash of the OTP value rather than the plaintext value in the key generation. The generated Client Key will be used to encrypt the nonce received from the KDC using the specified encryption type. The encrypted value, a random nonce generated by the client along with information on how the OTP was generated are then sent to the KDC in a PA-OTP- REQUEST element encrypted within the armored-data of a PA-FX-FAST- REQUEST PA-DATA element of a second KRB_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 Richards Expires July 20, 2008 [Page 4] Internet-Draft OTP Preauthentication January 2008 the KDC, the client includes an encrypted timestamp in the request rather than the encrypted KDC nonce. On receipt of a PA-OTP-REQUEST, the KDC generate the same keys as the client, and use 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 confirm that the Reply Key was updated by encrypting the client's nonce under the Server Key and returning the encrypted value in a PA-OTP-CONFIRM element encrypted within the armored-data of a PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP. 2.2. PIN Change If, following successful validation of a PA-OTP-REQUEST in a KRB_AS_REQ, the KDC requires that the user changes their PIN then it will include a PA-OTP-PIN-CHANGE element in the armored data of the PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP. This 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, it is recommended that user PIN change be handled by a PIN change service supporting the ChangePasswdData in a KRB_AP_REQ as described in [RFC3244]. If a user PIN change is required and such a service is used then the KDC MAY return a TGT in the KRB_AS_REP but it is RECOMMENDED that it return an INITIAL ticket 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 lose synchronization. If, when processing a PA-OTP- REQUEST, 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. If this flag is set then the client MUST re-try the authentication using the OTP for the token "state" after that used in the failed authentication attempt. 3. Pre-Authentication Protocol Details 3.1. Initial 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-REQUEST then it will respond as described in Richards Expires July 20, 2008 [Page 5] Internet-Draft OTP Preauthentication January 2008 Section 3.2. Alternatively, if the client has all the necessary information, it MAY construct a PA-OTP-REQUEST as described in Section 3.3 and include 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 KRB_AS_REQ with a KRB_ERROR containing: 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 random nonce value to be returned encrypted in the client response and the enctype to be used by the client to encrypt the nonce. In order to support situations where the KDC can determine which OTP key the client should use, the challenge MAY also contain information on how the OTP value is to be generated. In addition, in order to support cases where the KDC cannot obtain plaintext values for the OTPs, the challenge MAY also contain a sequence of one way hash function algorithm identifiers and a minimum value of the iteration count to be used by the client when hashing the OTP value. 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 a PA-FX-FAST-REQUEST encrypted under the current Armor Key. In order to generate its response, the client first generates an OTP value. The OTP value MUST be based on the parameters in the KDC challenge if present and the response SHOULD include information on the generated OTP value. The client derives three keys 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 response. However, the client MUST NOT include the OTP value in the response unless it is allowed by the algorithm profile. If it is included then the OTP value MUST NOT be used in the key derivation. If the KDC challenge contains hash algorithm identifiers and the OTP Richards Expires July 20, 2008 [Page 6] Internet-Draft OTP Preauthentication January 2008 value is to be used in the key derivation then the client MUST select one of the algorithms and MUST use the hash of the OTP value to derive the keys as described in Section 3.6. The selected algorithm identifier and the iteration count used MUST be included in the client's response. If the algorithm identifiers do not conform to local policy restrictions then the authentication attempt MUST NOT proceed. If the iteration count 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 is a minimum value. The generated Client Key is used by the client to encrypt data to be included in the encData of the response to allow the KDC to authenticate the user. o If the response is being generated in response to a KDC challenge then client encrypts the value of nonce from the corresponding challenge. o If the response is not in response to a KDC challenge then the client encrypts the current time as in the encrypted timestamp pre-authentication mechanism [RFC4120]. Finally, the client generates a random value to include in the nonce of the response. This value will then be returned encrypted by the KDC. 3.4. Verifying the pre-auth Data The KDC validates the pre-authentication data by generating the same keys as the client as described in Section 3.6. The generated Client Key is used to decrypt the value of encData from the PA-OTP-REQUEST. If the otp-value field is not included in the response, then the KDC SHOULD use any OTP information in the PA-OTP-REQUEST to obtain the OTP value in order to generate the keys. If the hashAlg field is present then the hash of the OTP value, as given by the hash algorithm identifier, was used in the key generation rather than the plaintext value. The client authentication MUST fail if the KDC requires hashed OTP values and the hashAlg field was not present or if the hash algorithm identifier or iteration count included in the PA-OTP-REQUEST do not conform to local KDC policy. In such situations, the KDC MAY return a PA-OTP-CHALLENGE with the required values in the error response. For example, this technique could be used to return required values to the client in response to a PA-OTP-REQUEST that was not the result of a PA-OTP-CHALLENGE. Richards Expires July 20, 2008 [Page 7] Internet-Draft OTP Preauthentication January 2008 If the client response was sent as a result of a PA-OTP-CHALLENGE then the client authentication MUST fail if the decrypted value is not the same as the nonce value sent in the challenge. If the response was not sent as a result of a PA-OTP-CHALLENGE then the decrypted value will be a PA-ENC-TIMESTAMP and the authentication process will be the same as with standard encrypted timestamp pre- authentication [RFC4120] 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, the client nonce from PA-OTP-REQUEST encrypted under the generated Server Key. The KDC response SHALL be sent to client as a PA-OTP-CONFIRM included within the enc-fast-rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key. 3.6. Reply Key Generation In order to authenticate the user, the client and KDC need to generate three 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 Server Key to be used by the KDC to encrypt and by the client to decrypt the encData value in the PA-OTP-CONFIRM. o The Reply Key will be used in the standard manner by the KDC to encrypt data in the AS-REP. The method used to generate the three keys will depend on the OTP algorithm. o If the OTP value is included in the otp-value of the PA-OTP- REQUEST then all three keys SHALL be the same as the Armor Key (defined in [ZhHa07]). o If the OTP value is not included in the otp-value of the PA-OTP- REQUEST then the three keys SHALL be derived from the Armor Key and the OTP value as described below. If the OTP value is not included in the client response, then the Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from [ZhHa07] Richards Expires July 20, 2008 [Page 8] Internet-Draft OTP Preauthentication January 2008 ClientKey = KRB_FX_CF2(K1, K2, O1, O2) ServerKey = KRB_FX_CF2(K1, K2, O3, O4) ReplyKey = KRB_FX_CF2(K1, K2, O5, O6) The first input keys, K1, shall be the Armor Key. The second input key, K2, shall be derived from the OTP value using string-to-key (defined in [RFC3961]). The octet string parameters, O1, O2, O3, O4, O5 and O6, shall be the ASCII string "Combine1" to "Combine6". For example, O1 and O2 have the following byte values: {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31} {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32} 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 principal name of the KDC as included in the AS- REQ. * 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.) 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 Richards Expires July 20, 2008 [Page 9] Internet-Draft OTP Preauthentication January 2008 K2 SHALL be derived by running the OTP value once through string-to- key. K2 = string-to-key(OTP||"Krb-preAuth") The salt and additional parameters for string-to-key will be as defined in section 3.1.3 of [RFC4120]. The symbol "||" denotes string concatenation. 4. OTP Kerberos Message Types 4.1. PA-OTP-CHALLENGE The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in the PA-DATA of a KRB_ERROR when pre-authentication using an OTP value is required. The corresponding padata-value field contains the DER encoding of a PA-OTP-CHALLENGE containing a server generated nonce and information for the client on how to generate the OTP. PA_OTP_CHALLENGE << TBA >> PA-OTP-CHALLENGE ::= SEQUENCE { flags OTPFlags, nonce UInt32, etype INTEGER, supportedHashAlg SEQUENCE OF AlgorithmIdentifier OPTIONAL, iterationCount INTEGER OPTIONAL, otp-challenge OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-length [0] INTEGER OPTIONAL, otp-service UTF8String OPTIONAL, otp-keyID [1] OCTET STRING OPTIONAL, otp-algID [2] INTEGER OPTIONAL, ... } OTPFlags ::= KerberosFlags -- nextOTP (0) flags If the "nextOTP" flag is set then the OTP 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. Richards Expires July 20, 2008 [Page 10] Internet-Draft OTP Preauthentication January 2008 nonce A KDC-supplied nonce value to be encrypted by the client in the PA-OTP-REQUEST. etype The encryption type to be used by the client to encrypt the nonce in the PA-OTP-REQUEST. 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-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 the OTP key to use. Richards Expires July 20, 2008 [Page 11] Internet-Draft OTP Preauthentication January 2008 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. 4.2. PA-OTP-REQUEST The padata-type PA_OTP_RESPONSE is sent by the client to the KDC in the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the PA-DATA of an AS-REQ. The corresponding padata-value field contains the DER encoding of a PA-OTP-REQUEST. The message contains pre-authentication data encrypted by the client using the generated Client Key and information on how the OTP was generated. It may also, optionally, contain the generated OTP value. PA_OTP_REQUEST << TBA >> PA-OTP-REQUEST ::= SEQUENCE { flags OTPFlags, nonce UInt32, encData EncryptedData, -- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP -- Key usage of KEY_USAGE_OTP_REQUEST hashAlg AlgorithmIdentifier OPTIONAL, iterationCount INTEGER OPTIONAL, otp-value OCTET STRING OPTIONAL, otp-challenge [0] OCTET STRING OPTIONAL, otp-time KerberosTime OPTIONAL, otp-counter [1] OCTET STRING OPTIONAL, otp-format [2] OTPFormat OPTIONAL, otp-keyID [3] OCTET STRING OPTIONAL, otp-algID [4] INTEGER OPTIONAL, ... } KEY_USAGE_OTP_REQUEST << TBA >> PA-OTP-ENC-REQUEST ::= SEQUENCE { nonce OCTET STRING, ... } Richards Expires July 20, 2008 [Page 12] Internet-Draft OTP Preauthentication January 2008 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. nonce A random nonce value generated by the client. encData If the PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE then this MUST contain the nonce from the challenge encrypted under the Client Key. If no challenge was received then this MUST contain a PA-ENC-TIMESTAMP encrypted under the Client Key. hashAlg This field MUST be present 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 one of those specified in the supportedHashAlg of the PA-OTP-CHALLENGE. iterationCount This field MUST be present 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. 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 July 20, 2008 [Page 13] Internet-Draft OTP Preauthentication January 2008 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-algID The identifier of the algorithm to used to generate the OTP. 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 KRB_AS_REP of the KDC. It is used to return the client's nonce encrypted under the new Server Key in order to confirm that the KDC has knowledge of this key. The corresponding padata-value field contains the DER encoding of a PA-OTP-CONFIRM. PA_OTP_CONFIRM << TBA >> PA-OTP-CONFIRM ::= SEQUENCE { encData EncryptedData, -- PA-OTP-ENC-CONFIRM -- Key usage of KEY_USAGE_OTP_CONFIRM ... } KEY_USAGE_OTP_CONFIRM << TBA >> PA-OTP-ENC-CONFIRM ::= SEQUENCE { nonce OCTET STRING, ... } Richards Expires July 20, 2008 [Page 14] Internet-Draft OTP Preauthentication January 2008 encData The value of nonce from the corresponding PA-OTP-REQUEST encrypted under the current Server Key. 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 KRB_AS_REP if the user must change their PIN or if the user's PIN has been changed. The corresponding padata-value field contains the DER encoding of a PA-OTP-PIN-CHANGE. PA_OTP_PIN_CHANGE << TBA >> PA-OTP-PIN-CHANGE ::= SEQUENCE { flags PinFlags, pin UTF8String OPTIONAL, minLength INTEGER OPTIONAL, maxLength [1] 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. 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. 5. IANA Considerations A registry may be required for the otp-AlgID values as introduced in Section 4.1. No other IANA actions are anticipated. 6. Security Considerations Richards Expires July 20, 2008 [Page 15] Internet-Draft OTP Preauthentication January 2008 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. Even though no such attacks are known at this point, the proposed system uses the outer Armor Key in the derivation of the inner Client and Server keys and so achieve crypto-binding to the outer channel. 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. Replay The 2-pass version of the protocol does not involve a server nonce and so the client instead encrypts a timestamp. To reduce the chance of replay attacks, the KDC must check that the client time used in such a request is later than that used in previous requests. 6.4. 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. Similarly, successful decryption of the encrypted nonce by the client proves that the expected KDC replied. The Reply Key is replaced by a key generated from the OTP and Armor Key. This FAST factor therefore provides the following facilities: client-authentication, replacing-reply-key and KDC-authentication. 7. References 7.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. Richards Expires July 20, 2008 [Page 16] Internet-Draft OTP Preauthentication January 2008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [ZhHa07] Znu, L. and S. Hartman, "A generalized Framework for Kerberos Pre-Authentication", draft-ietf-krb-wg-preauth-framework-06 (work in progress), March 2007. 7.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. [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. [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols", RFC 3244, February 2002. Appendix A. ASN.1 Module OTPKerberos DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS KerberosTime, KerberosFlags, EncryptionKey, UInt32, Int32, EncryptedData FROM KerberosV5Spec2 {iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) } -- as defined in RFC 4120. AlgorithmIdentifier FROM PKIX1Explicit88 { iso (1) identified-organization (3) Richards Expires July 20, 2008 [Page 17] Internet-Draft OTP Preauthentication January 2008 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 OTPFlags, nonce UInt32, etype INTEGER, supportedHashAlg SEQUENCE OF AlgorithmIdentifier OPTIONAL, iterationCount INTEGER OPTIONAL, otp-challenge OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-length [0] INTEGER OPTIONAL, otp-service UTF8String OPTIONAL, otp-keyID [1] OCTET STRING OPTIONAL, otp-algID [2] INTEGER OPTIONAL, ... } OTPFlags ::= KerberosFlags -- nextOTP (0) PA-OTP-REQUEST ::= SEQUENCE { flags OTPFlags, nonce UInt32, encData EncryptedData, -- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP -- Key usage of KEY_USAGE_OTP_REQUEST hashAlg AlgorithmIdentifier OPTIONAL, iterationCount INTEGER OPTIONAL, otp-value OCTET STRING OPTIONAL, otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL, otp-time KerberosTime OPTIONAL, otp-counter [1] OCTET STRING OPTIONAL, otp-format [2] OTPFormat OPTIONAL, otp-keyID [3] OCTET STRING OPTIONAL, otp-algID [4] INTEGER OPTIONAL, ... } PA-OTP-ENC-REQUEST ::= SEQUENCE { nonce OCTET STRING, ... } OTPFormat ::= INTEGER { decimal(0), Richards Expires July 20, 2008 [Page 18] Internet-Draft OTP Preauthentication January 2008 hexadecimal(1), alphanumeric(2), binary(3) } PA-OTP-CONFIRM ::= SEQUENCE { encData EncryptedData, -- PA-OTP-ENC-CONFIRM -- Key usage of KEY_USAGE_OTP_CONFIRM ... } PA-OTP-ENC-CONFIRM ::= SEQUENCE { nonce OCTET STRING, ... } PA-OTP-PIN-CHANGE ::= SEQUENCE { flags PinFlags, pin UTF8String OPTIONAL, minLength INTEGER OPTIONAL, maxLength [0] INTEGER OPTIONAL, ... } PinFlags ::= KerberosFlags -- systemSetPin (0) END 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 July 20, 2008 [Page 19] Internet-Draft OTP Preauthentication January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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 July 20, 2008 [Page 20]