Network Working Group G. Richards Internet-Draft RSA, The Security Division of EMC Intended status: Standards Track June 25, 2007 Expires: December 27, 2007 OTP Kerberos draft-richards-otp-kerberos-03 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 December 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 December 27, 2007 [Page 1] Internet-Draft OTP Kerberos June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 4 2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 5 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 5 3.1. Initial Client Request . . . . . . . . . . . . . . . . . . 5 3.2. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Client Response . . . . . . . . . . . . . . . . . . . . . 5 3.4. Verifying the pre-auth Data . . . . . . . . . . . . . . . 6 3.5. Confirming the Reply Key Change . . . . . . . . . . . . . 7 3.6. Reply Key Generation . . . . . . . . . . . . . . . . . . . 7 4. OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 8 4.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 8 4.2. PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 10 4.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 11 4.4. PA-OTP-PIN-CHANGE . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Man-in-the-Middle . . . . . . . . . . . . . . . . . . 13 6.1.2. Reflection . . . . . . . . . . . . . . . . . . . . . . 13 6.1.3. Replay . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.4. Passive attacks . . . . . . . . . . . . . . . . . . . 13 6.2. FAST Facilities . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Richards Expires December 27, 2007 [Page 2] Internet-Draft OTP Kerberos June 2007 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. This FAST factor provides the following facilities: 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 response , the KDC sends with a challenge containing random nonce and details on how the OTP is to be generated as pre-auth data within a KRB-ERROR. The client generates the OTP value, the Reply Key and a Client and Server key and uses the Client Key to encrypt the nonce value. This encrypted value is then sent to the KDC along with a client generated nonce and information on the generated OTP as pre- authentication data encrypted within the armored data of a PA-FX- FAST-REQUEST contained within a second AS-REQ. The KDC then generates the same keys, verifies the pre-authentication data by decrypting the nonce and confirms knowledge of the Reply Key by sending a response to the client containing the client's nonce encrypted using the Server Key encrypted within the armored data of a PA-FX-FAST-RESPONSE contained within an AS-REP. In the 2-pass variant, the client generates the OTP and keys as in the 4-pass system but includes the PA-FX-FAST-REQUEST in the initial AS-REQ sent to the KDC. This system 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. Depending on OTP algorithm used, the OTP value is either used in the generation of the Reply Key or is sent to the KDC along with the encrypted 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]. Richards Expires December 27, 2007 [Page 3] Internet-Draft OTP Kerberos June 2007 << 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 messages. 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 and 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 key to encrypt KDC's nonce and a key to decrypt the KDC's reply. As described in Section 3.6, these keys will be generated from the Anchor Key and depending on the type of OTP, from the OTP value. The encrypted KDC nonce and the client nonce 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. The KDC then uses this information to generate the same keys as the client, allowing it to verify the pre-authentication by decrypting the encrypted nonce sent by the client. If the validation succeeds then the KDC will confirm that the Reply Key was updated by encrypting the client's nonce 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, user PIN change shall be handled by a PIN change service supporting the ChangePasswdData in a KRB_AP_REQ as described Richards Expires December 27, 2007 [Page 4] Internet-Draft OTP Kerberos June 2007 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- 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. 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. 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 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. It MAY also contain information on how the OTP value is to be generated. 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 Anchor Key. Richards Expires December 27, 2007 [Page 5] Internet-Draft OTP Kerberos June 2007 In order to generate its response, the client 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. 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. The client MUST generate three keys as described in Section 3.6. 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 SHALL use any OTP information in the PA-OTP-REQUEST to obtain the OTP value in order to generate the to generate the keys. 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] Richards Expires December 27, 2007 [Page 6] Internet-Draft OTP Kerberos June 2007 3.5. Confirming the Reply Key Change In order to support mutual authentication, the KDC SHALL respond to the clients PA-OTP-REQUEST by including in the AS-REP, the client nonce from PA-OTP-REQUEST encrypted under the 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 Anchor 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 Anchor Key. 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 Anchor 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] 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 Anchor Key, AK. The second input key, K2, shall be derived from the OTP value using string-to- key or random-to-key (both defined in [RFC3961]). Richards Expires December 27, 2007 [Page 7] Internet-Draft OTP Kerberos June 2007 o If the OTP value is binary, then K2 SHALL be derived by running the OTP value once through random-to-key. K2 = random-to-key(OTP||"Krb-preAuth") o If the OTP value is not binary, 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 additional parameters for string-to-key will be as defined in section 3.1.3 of [RFC4120]. 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} 4. OTP Kerberos Message Types 4.1. PA-OTP-CHALLENGE The padata type pa-otp-challenge sent by the KDC to the client in the PA-DATA 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, otp-challenge OCTET STRING OPTIONAL, otp-length INTEGER OPTIONAL, otp-service UTF8String OPTIONAL, otp-keyID [0] OCTET STRING OPTIONAL, otp-algID [1] INTEGER OPTIONAL, ... } OTPFlags ::= KerberosFlags -- nextOTP (0) Richards Expires December 27, 2007 [Page 8] Internet-Draft OTP Kerberos June 2007 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. 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. 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. <> Richards Expires December 27, 2007 [Page 9] Internet-Draft OTP Kerberos June 2007 4.2. PA-OTP-REQUEST The padata-type pa-otp-response sent by the client to the KDC in the KrbFastReq padata of a PA-FX-FAST-REQUEST 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-response << TBA >> PA-OTP-REQUEST ::= SEQUENCE { flags OTPFlags, nonce UInt32, encData EncryptedData, -- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP -- Key usage of << TBD >> otp-value OCTET STRING OPTIONAL, otp-challenge [0] OCTET STRING OPTIONAL, otp-time KerberosTime OPTIONAL, otp-counter [1] OCTET STRING OPTIONAL, otp-format OTPFormat OPTIONAL, otp-keyID [2] OCTET STRING OPTIONAL, otp-algID [3] INTEGER OPTIONAL, ... } PA-OTP-ENC-REQUEST ::= SEQUENCE { nonce 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 December 27, 2007 [Page 10] Internet-Draft OTP Kerberos June 2007 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. 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. 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 This pre-authentication type 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. Richards Expires December 27, 2007 [Page 11] Internet-Draft OTP Kerberos June 2007 pa-otp-confirm << TBA >> PA-OTP-CONFIRM ::= SEQUENCE { encData EncryptedData, -- PA-OTP-ENC-CONFIRM -- Key usage of << TBD >> ... } PA-OTP-ENC-CONFIRM ::= SEQUENCE { nonce OCTET STRING, ... } encData The value of nonce from the corresponding PA-OTP-REQUEST encrypted under the current Server Key. 4.4. PA-OTP-PIN-CHANGE This pre-authentication type 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. 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 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. Richards Expires December 27, 2007 [Page 12] Internet-Draft OTP Kerberos June 2007 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 6.1. Active attacks 6.1.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, Anchor, Key in the derivation of the inner Client and Server keys and so achieve crypto-binding to the outer channel. 6.1.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.1.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.1.4. Passive attacks << TBD >> 6.2. 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 Richards Expires December 27, 2007 [Page 13] Internet-Draft OTP Kerberos June 2007 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [ZhHa07] Znu, L. and S. Hartman, "A generalized Framework for Kerberos Pre-Authentication", draft-ietf-kerb-wg-preauth-framework-05 (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. Appendix A. ASN.1 Module OTPKerberos DEFINITIONS IMPLICIT TAGS ::= Richards Expires December 27, 2007 [Page 14] Internet-Draft OTP Kerberos June 2007 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. PA-OTP-CHALLENGE ::= SEQUENCE { flags OTPFlags, nonce UInt32, etype INTEGER, otp-challenge OCTET STRING OPTIONAL, otp-length INTEGER OPTIONAL, otp-service UTF8String OPTIONAL, otp-keyID [0] OCTET STRING OPTIONAL, otp-algID [1] 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 << TBD >> otp-value OCTET STRING OPTIONAL, otp-challenge [0] OCTET STRING OPTIONAL, otp-time KerberosTime OPTIONAL, otp-counter [1] OCTET STRING OPTIONAL, otp-format OTPFormat OPTIONAL, otp-keyID [2] OCTET STRING OPTIONAL, otp-algID [3] INTEGER OPTIONAL, ... } PA-OTP-ENC-REQUEST ::= SEQUENCE { nonce OCTET STRING, ... } OTPFormat ::= INTEGER { decimal(0), Richards Expires December 27, 2007 [Page 15] Internet-Draft OTP Kerberos June 2007 hexadecimal(1), alphanumeric(2), binary(3) } PA-OTP-CONFIRM ::= SEQUENCE { encData EncryptedData, -- PA-OTP-ENC-CONFIRM -- Key usage of << TBD >> ... } 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: grichards@rsa.com Richards Expires December 27, 2007 [Page 16] Internet-Draft OTP Kerberos June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 December 27, 2007 [Page 17]