Network Working Group                                        G. Richards
Internet-Draft                         RSA, The Security Division of EMC
Intended status: Standards Track                        January 18, 2011
Expires: July 22, 2011


                         OTP Pre-authentication
                    draft-ietf-krb-wg-otp-preauth-14

Abstract

   The Kerberos protocol provides a framework authenticating a client
   using the exchange of pre-authentication data.  This document
   describes the use of this framework to carry out One Time Password
   (OTP) authentication.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 22, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Richards                  Expires July 22, 2011                 [Page 1]


Internet-Draft           OTP Pre-authentication             January 2011


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.








































Richards                  Expires July 22, 2011                 [Page 2]


Internet-Draft           OTP Pre-authentication             January 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Overall Design . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Conventions Used in this Document  . . . . . . . . . . . .  5
   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  OTP Mechanism Support  . . . . . . . . . . . . . . . . . .  5
     2.2.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  5
     2.3.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  7
   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  7
     3.1.  Initial Client Request . . . . . . . . . . . . . . . . . .  7
     3.2.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Client Response  . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Verifying the pre-auth Data  . . . . . . . . . . . . . . . 13
     3.5.  Confirming the Reply Key Change  . . . . . . . . . . . . . 14
     3.6.  Reply Key Generation . . . . . . . . . . . . . . . . . . . 15
   4.  OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 17
     4.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 17
     4.2.  PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 20
     4.3.  PA-OTP-PIN-CHANGE  . . . . . . . . . . . . . . . . . . . . 24
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     6.1.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . . . 26
     6.2.  Reflection . . . . . . . . . . . . . . . . . . . . . . . . 27
     6.3.  Denial of Service  . . . . . . . . . . . . . . . . . . . . 27
     6.4.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     6.5.  Brute Force Attack . . . . . . . . . . . . . . . . . . . . 28
     6.6.  FAST Facilities  . . . . . . . . . . . . . . . . . . . . . 28
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 30
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 30
   Appendix B.  Examples of OTP Pre-Authentication Exchanges  . . . . 32
     B.1.  Four Pass Authentication . . . . . . . . . . . . . . . . . 33
     B.2.  Two Pass Authentication  . . . . . . . . . . . . . . . . . 35
     B.3.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 36
     B.4.  Resynchronization  . . . . . . . . . . . . . . . . . . . . 37
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39










Richards                  Expires July 22, 2011                 [Page 3]


Internet-Draft           OTP Pre-authentication             January 2011


1.  Introduction

1.1.  Scope

   This document describes a FAST [ZhHa10] factor that allows One-Time
   Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-
   authentication in a manner that does not require use of the user's
   Kerberos password.  The system is designed to work with different
   types of OTP algorithms such as time-based OTPs [RFC2808], counter-
   based tokens [RFC4226] and challenge-response systems such as
   [RFC2289].  It is also designed to work with tokens that are
   electronically connected to the user's computer via means such as a
   USB interface.

   This FAST factor provides the following facilities (as defined in
   [ZhHa10]): client-authentication, replacing-reply-key and KDC-
   authentication.  It does not provide the strengthening-reply-key
   facility.

   This proposal is partially based upon previous work on integrating
   single-use authentication mechanisms into Kerberos [HoReNeZo04].

1.2.  Overall Design

   This proposal supports 4-pass and 2-pass variants.  In the 4-pass
   system, the client sends the KDC an initial AS-REQ and the KDC
   responds with a KRB-ERROR containing padata that includes a random
   nonce.  The client then encrypts the nonce and returns it to the KDC
   in a second AS-REQ.  Finally, the KDC returns the AS-REP.  Note that
   this variant can only be used for users that require pre-
   authentication.  In the 2-pass variant, the client encrypts a
   timestamp rather than a nonce from the KDC and the encrypted data is
   sent to the KDC in the initial AS-REQ.  This variant can be used in
   cases where the client can determine in advance that OTP pre-
   authentication is supported by the KDC, which OTP key should be used
   and the encryption parameters required by the KDC.

   In both systems, in order to create the message sent to the KDC, the
   client must generate the OTP value and two keys: the classic Reply
   Key used to decrypt the KDC's reply and a key to encrypt the data
   sent to the KDC.  In most cases, the OTP value will be used in the
   key generation but in order to support algorithms where the KDC
   cannot obtain the value (e.g.  [RFC2289]), the system 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.




Richards                  Expires July 22, 2011                 [Page 4]


Internet-Draft           OTP Pre-authentication             January 2011


   The preauth data sent from the client to the KDC is sent within the
   encrypted data provided by the FAST padata type of the AS-REQ.  The
   KDC then obtains the OTP value, generates the same keys and verifies
   the pre-authentication data by decrypting the nonce.  If the
   verification succeeds then it confirms knowledge of the Reply Key by
   using it to encrypt data in the AS-REP.

1.3.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document assumes familiarity with the Kerberos pre-
   authentication framework [ZhHa10] and so freely uses terminology and
   notation from this document.

   The word padata is used as shorthand for pre-authentication data.


2.  Usage Overview

2.1.  OTP Mechanism Support

   As described above, this document describes a generic system for
   supporting different OTP mechanisms in Kerberos pre-authentication.
   To ensure interoperability, all implementations of this specification
   SHOULD provide a mechanism (e.g. a provider interface) to add or
   remove support for a particular OTP mechanism.

2.2.  Pre-Authentication

   The approach uses pre-authentication data in AS-REQ, AS-REP and KRB-
   ERROR messages.

   In the 4-pass system, the client begins by sending an initial AS-REQ
   to the KDC that may contain pre-authentication data such as the
   standard Kerberos password data.  The KDC will then determine, in an
   implementation dependent fashion, whether OTP authentication is
   required and if it is, it will respond with a KRB-ERROR message
   containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA.

   The PA-OTP-CHALLENGE will contain a KDC generated nonce, an optional
   list of hash algorithm identifiers, an optional iteration count and
   optional information on how the OTP should be generated by the
   client.  The client will then generate the OTP value and two keys: a
   Client Key to encrypt the KDC's nonce and a Reply Key used to decrypt
   the KDC's reply.



Richards                  Expires July 22, 2011                 [Page 5]


Internet-Draft           OTP Pre-authentication             January 2011


   As described in section 5.4.1 of [ZhHa10], the FAST system uses an
   Armor Key to set up an encrypted tunnel for use by FAST factors.  As
   described in Section 3.6 of this document, the Client Key and Reply
   Key will be generated from the Armor Key and the OTP value unless the
   OTP algorithm does not allow the KDC to obtain the OTP value.  If
   hash algorithm identifiers were included in the PA-OTP-CHALLENGE then
   the client will use the hash of the OTP value rather than the
   plaintext value in the key generation.  Both keys will have the same
   encryption type as the Armor Key.

   The generated Client Key will be used to encrypt the nonce received
   from the KDC.  The encrypted value along with optional information on
   how the OTP was generated are then sent to the KDC in a PA-OTP-
   REQUEST (see Section 4.2) encrypted within the armored-data of a PA-
   FX-FAST-REQUEST PA-DATA element of a second AS-REQ.

   In the 2-pass system, the client sends the PA-OTP-REQUEST in the
   initial AS-REQ instead of sending it in response to a PA-OTP-
   CHALLENGE returned by the KDC.  Since no challenge is received from
   the KDC, the client includes an encrypted timestamp in the request
   rather than the encrypted KDC nonce.

   In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the
   keys in the same way as the client, and uses the generated Client Key
   to verify the pre-authentication by decrypting the encrypted data
   sent by the client (either nonce or timestamp).  If the validation
   succeeds then the KDC will authenticate itself to the client and
   confirm that the Reply Key has been updated by using the generated
   Reply Key in the AS-REP response.

2.3.  PIN Change

   Most OTP tokens involve the use of a PIN in the generation of the OTP
   value.  This PIN value will be combined with the value generated by
   the token to produce the final OTP value that will be used in this
   protocol.

   If, following successful validation of a PA-OTP-REQUEST in an AS-REQ,
   the KDC determines that the user's PIN has expired and needs to
   change then it SHOULD respond KRB-ERROR of type KDC_ERR_PIN_EXPIRED.
   It MAY include formatting information on the PIN in a PA-OTP-PIN-
   CHANGE (see Section 4.3) encrypted within the armored data of the PA-
   FX-FAST-REPLY PA-DATA element.

             KDC_ERR_PIN_EXPIRED           <TBD>

   If the PIN change is to be handled by a PIN-change service then it is
   assumed that authentication to that service will succeed if the PIN



Richards                  Expires July 22, 2011                 [Page 6]


Internet-Draft           OTP Pre-authentication             January 2011


   has expired.

   If the user's PIN has not expired but has been changed then the KDC
   MAY return the new value to the client in a PA-OTP-PIN-CHANGE
   encrypted within the armored data of the PA-FX-FAST-REPLY PA-DATA
   element of the AS-REP.  Similarly, if PIN change is not required then
   the KDC MAY return a PA-OTP-PIN-CHANGE to inform the client of the
   current PIN's expiration time.

2.4.  Re-Synchronization

   It is possible with time and event-based tokens that the OTP server
   will lose synchronization with the current token state.  For example,
   event-based tokens may drift since the counter on the token is
   incremented every time the token is used but the counter on the
   server is only incremented on an authentication.  Similarly, the
   clocks on time-based tokens may drift.

   If, when processing a PA-OTP-REQUEST, the pre-authentication
   validation fails for this reason then the KDC MAY return a KRB-ERROR
   message.  The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the
   PA-DATA with a single otp-keyInfo representing the token used in the
   initial authentication attempt but with "nextOTP" flag set.  If this
   flag is set then the client SHOULD re-try the authentication using an
   OTP value generated using the token in the "state" after that used in
   the failed authentication attempt.  For example, using the next time
   interval or counter value.


3.  Pre-Authentication Protocol Details

3.1.  Initial Client Request

   In the 4-pass mode, the client begins by sending an initial AS-REQ,
   possibly containing other pre-authentication data.  If the KDC
   determines that OTP-based pre-authentication is required and the
   request does not contain a PA-OTP-REQUEST then it will respond as
   described in Section 3.2.

   If the client has all the necessary information, it MAY use the
   2-pass system by constructing a PA-OTP-REQUEST as described in
   Section 3.3 and including it in the initial request.

3.2.  KDC Challenge

   If the user is required to authenticate using an OTP then the KDC
   SHALL respond to the initial AS-REQ with a KRB-ERROR, as described in
   section 2.2 of [ZhHa10], with a PA-OTP-CHALLENGE contained within the



Richards                  Expires July 22, 2011                 [Page 7]


Internet-Draft           OTP Pre-authentication             January 2011


   enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY encrypted
   under the current Armor Key as described in [ZhHa10].

   If the OTP mechanism is to be carried out as an individual mechanism
   then the PA-OTP-CHALLENGE SHALL be carried within the padata of the
   KrbFastResponse.  Alternatively, if the OTP mechanism is required as
   part of an authentication set then the PA-OTP-CHALLENGE SHALL be
   carried within a PA-AUTHENTICATION-SET-ELEM as described in section
   5.3 of [ZhHa10].

   The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned
   encrypted in the client's PA-OTP-REQUEST.  This nonce string MUST be
   as long as the longest key length of the symmetric key types that the
   KDC supports and MUST be chosen randomly.  In order to allow it to
   maintain any state necessary to verify the returned nonce, the KDC
   SHOULD use the mechanism described in section 5.2 of [ZhHa10].

   The KDC MAY use the otp-service field to assist the client in
   locating the OTP token to be used by identifying the purpose of the
   authentication.  For example, the otp-service field could assist a
   user in identifying the token to be used when a user has multiple OTP
   tokens from that are used for different purposes.

   The KDC SHALL include a sequence of one or more otp-keyInfo elements
   containing information on the token or tokens that the user can use
   for the authentication and how the OTP value is to be generated using
   those tokens.  If a single otp-keyInfo element is included then only
   a single token is acceptable by the KDC and any OTP value generated
   by the client MUST be generated according to the information
   contained within that element.  If more than one otp-keyInfo element
   is included then the OTP value MUST be generated according to the
   information contained within one of those elements.

   The KDC MAY include the otp-vendor field in an otp-keyInfo to
   identify the vendor of the token that can be used in the
   authentication request in order to assist the client in locating that
   token.

   If the KDC is able to obtain the OTP values for the token then the
   OTP value SHOULD be used in the key generation as described in
   Section 3.6 and so the KDC SHOULD set the "must-encrypt-nonce" flag
   in the otp-keyInfo.  If the KDC is unable to obtain the OTP values
   for the token then the "must-encrypt-nonce" flag MUST NOT be set.  If
   the flag is not set then the OTP value will be returned by the client
   in the otp-value field of the PA-OTP-REQUEST and so if returning of
   OTP values in this way does not conform to KDC policy then the KDC
   SHOULD NOT include the otp-keyInfo for that token in the PA-OTP-
   CHALLENGE.



Richards                  Expires July 22, 2011                 [Page 8]


Internet-Draft           OTP Pre-authentication             January 2011


   If the KDC requires that hashed OTPs be used in the key generation as
   described in Section 3.6 (for example, it is only able to obtain
   hashed OTP values for the token) then it MUST include the supported
   hash algorithms in order of preference in the supportedHashAlg of the
   otp-KeyInfo and the minimum value of the iteration count in the
   iterationCount element.

   Since the OTP mechanism described in this document is replacing the
   Reply Key, the classic shared-key system cannot be relied upon to
   allow the client to verify the KDC.  Therefore, as described in
   section 3.4 of [ZhHa10], some other mechanism must be provided to
   support this.  If the OTP value is used in the Reply Key generation
   then the client and KDC have a shared key and KDC-authentication is
   provided by the KDC using the Reply Key generated from the OTP value.
   However, if the OTP value is sent in the otp-value element of the PA-
   OTP-REQUEST then there is no such shared key and the OTP mechanism
   does not provide KDC-authentication.  Therefore, if the OTP mechanism
   is not being used in an environment where KDC-authentication is being
   provided by other means (e.g. by the use of host key armor) then the
   KDC MUST NOT include any otp-keyInfo elements in the PA-OTP-CHALLENGE
   that do not have the "must-encrypt-nonce" flag set.

   If the OTP for a token is to be generated using a server generated
   challenge then the value of the challenge SHALL be included in the
   otp-challenge field of the otp-keyInfo for that token.  If the token
   is a connected device and the OTP is to be generated by combining the
   challenge with the token's current state (e.g. time) then the
   "combine" flag SHALL be set within the otp-keyInfo containing the
   challenge.

   If the KDC can determine which OTP token key (the seed value on the
   token used to generate the OTP) is to be used, then the otp-keyID
   field MAY be included in the otp-keyInfo to pass that value to the
   client.

   The otp-algID field MAY be included in an otp-keyInfo to identify the
   algorithm that should be used in the OTP calculation for that token.
   For example, it could be used when a user has been issued with
   multiple tokens that support different algorithms.

   If the KDC can determine that an OTP token that can be used by the
   user does not require the client to collect a PIN then it SHOULD set
   the "pin-not-required" flag in the otp-keyInfo representing that
   token.  If the KDC can determine that the token requires the client
   to collect a PIN then it SHOULD set the "pin-required" flag.  If the
   KDC is unable to determine whether the client should collect a PIN or
   not then the "pin-required" and "pin-not-required" flags MUST NOT be
   set.



Richards                  Expires July 22, 2011                 [Page 9]


Internet-Draft           OTP Pre-authentication             January 2011


   Finally, in order to support connected tokens that can generate OTP
   values of varying length, the KDC MAY include the desired length of
   the OTP in the otp-length field of an otp-keyInfo.

3.3.  Client Response

   The client response SHALL be sent to the KDC as a PA-OTP-REQUEST
   included within the enc-fast-req of the armored-data within a PA-FX-
   FAST-REQUEST encrypted under the current Armor Key as described in
   [ZhHa10].

   In order to generate its response, the client must generate an OTP
   value.  If the PA-OTP-CHALLENGE contained one or more otp-keyInfo
   elements then the OTP value MUST be based on the information
   contained within one of those elements.

   The otp-service, otp-vendor, otp-keyID, otp-length and otp-algID
   elements of the PA-OTP-CHALLENGE are provided by the KDC to assist
   the client in locating the correct token to use but the use of the
   above fields will depend on the type of token.  If connected tokens
   are used then these values SHOULD be used by the client to locate the
   correct token if connected and otp-vendor and otp-service MAY also be
   displayed to prompt the user if the correct token is not found.  If
   the token is not a connected token, then the values of otp-service
   and otp-vendor MAY be displayed to the user in order to help the user
   select the correct token and the values of otp-algID, otp-keyID and
   otp-length MAY be ignored.

   If the "nextOTP" flag is set in the otp-keyInfo from the PA-OTP-
   CHALLENGE, then the OTP value MUST be generated from the next token
   state than that used in the previous PA-OTP-REQUEST for that token.
   The "nextOTP" flag MUST also be set in the new PA-OTP-REQUEST.

   If the "pin-not-required" flag is set in the otp-keyInfo from the PA-
   OTP-CHALLENGE, then the token represented by the otp-keyInfo does not
   require a PIN to be collected by the client as part of the OTP value.
   If the "pin-required" flag is set then the token requires a PIN to be
   collected by the client.  If neither flag is set then PIN
   requirements of the token are unspecified.  If both flags are set
   then client SHALL regard the request as invalid.

   If client collects a PIN for a connected device then its behavior
   will depend on the type of device but it will generally need to pass
   the PIN to the token in the OTP value request.  If the token is not a
   connected device then the OTP value SHALL be generated by
   concatenating the PIN and the value from the token entered by the
   user.




Richards                  Expires July 22, 2011                [Page 10]


Internet-Draft           OTP Pre-authentication             January 2011


   If an otp-challenge is present in the otp-keyInfo selected by the
   client from the PA-OTP-CHALLENGE then the OTP value for the token
   MUST be generated based on a challenge if the token is capable of
   accepting a challenge.  The client MAY ignore the provided challenge
   if and only if the token is not capable of including a challenge in
   the OTP calculation.

   If the "combine" flag is not set in the otp-keyInfo of the PA-OTP-
   CHALLENGE then the OTP SHALL be calculated based only the challenge
   and not the internal state (e.g. time or counter) of the token.  If
   the "combine" flag is set then the OTP SHALL be calculated using both
   the internal state and the provided challenge if that value is
   obtainable by the client.  If the flag is set but otp-challenge is
   not present then the client SHALL regard the request as invalid.

   If token is a connected device then the use of the challenge will
   depend on the type of device but will involve passing the challenge
   and the value of the "combine" flag in a token-specific manner to the
   token, along with a PIN if collected and the value of otp-length if
   specified, in order to obtain the OTP value.  If the token is
   disconnected then the challenge MUST be displayed to the user and the
   value of the "combine" flag MAY be ignored by the client.

   If the OTP value was generated using a challenge that was not sent by
   the KDC then the challenge SHALL be included in the otp-challenge of
   the PA-OTP-REQUEST.  If the OTP was generated by combining a
   challenge (either received from the KDC or generated by the client)
   with the token state then the "combine" flag SHALL be set in the PA-
   OTP-REQUEST.

   If the "must-encrypt-nonce" flag is set in the otp-keyInfo then the
   OTP value MUST be used to generate the Client Key and Reply Key as
   described in Section 3.6 and MUST NOT be included in the otp-value
   field of the PA-OTP-REQUEST.  If the flag is not set then the OTP
   value MUST be included in the otp-value field of the PA-OTP-REQUEST
   and MUST NOT be used in the key derivation.  In this case, the Client
   Key and Reply Key SHALL be the same as the Armor Key as described in
   Section 3.6 and so if the returning of OTP values in this way does
   not conform to local policy on the client (for example, if KDC-
   Authentication is required and is not being provided by other means)
   then it SHOULD NOT use the token for authentication.

   If the supportedHashAlg and iterationCount elements are included in
   the otp-keyInfo then the client MUST use hashed OTP values in the
   generation of the Reply Key and Client Key as described in
   Section 3.6.  The client MUST select the first algorithm from the
   list that it supports and the AlgorithmIdentifer selected MUST be
   placed in the hashAlg element of the PA-OTP-REQUEST.  However, if



Richards                  Expires July 22, 2011                [Page 11]


Internet-Draft           OTP Pre-authentication             January 2011


   none of the algorithm identifiers conform to local policy
   restrictions then the authentication attempt MUST NOT proceed using
   that token.  If the value of iterationCount does not conform to local
   policy on the client then the client MAY use a larger value but MUST
   NOT use a lower value.  The value of the iteration count used by the
   client MUST be returned in the PA-OTP-REQUEST sent to the KDC.

   If hashed OTP values are used then the nonce generated by the client
   MUST be as long as the longest key length of the symmetric key types
   that the it supports and MUST be chosen randomly.  The nonce MUST be
   included in the PA-OTP-REQUEST along with the hash algorithm and
   iteration count used in the nonce, hashAlg and iterationCount fields
   of the PA-OTP-REQUEST.  These fields MUST NOT be included if hashed
   OTP values were not used.  It is RECOMMENDED that the iteration count
   used by the client be chosen in such a way that it is computationally
   infeasible/unattractive for an attacker to brute-force search for the
   given OTP.

   The PA-OTP-REQUEST returned by the client SHOULD include information
   on the generated OTP value reported by the OTP token when available
   to the client.  The otp-time and otp-counter fields of the PA-OTP-
   REQUEST SHOULD be used to return the time and counter values used by
   the token if available to the client.  The otp-format field MAY be
   used to report the format of the generated OTP.  This field SHOULD be
   used if a token can generate OTP values in multiple formats.  The
   otp-algID field SHOULD be used by the client to report the algorithm
   used in the OTP calculation and the otp-keyID SHOULD be used to
   report the identifier of the OTP token key used if the information is
   known to the client.

   If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE
   that contained an otp-vendor field in the selected otp-keyInfo then
   the otp-vendor field of the PA-OTP-REQUEST MUST be set to the same
   value.  If no otp-vendor field was provided by the KDC then the field
   SHOULD be set to the vendor identifier of the token if known to the
   client.

   The generated Client Key is used by the client to encrypt data to be
   included in the encData of the PA-OTP-REQUEST to allow the KDC to
   authenticate the user.  The key usage for this encryption is
   KEY_USAGE_OTP_REQUEST.

   o  If the PA-OTP-REQUEST is being generated in response to a PA-OTP-
      CHALLENGE returned by the KDC then the client SHALL encrypt a PA-
      OTP-ENC-REQUEST containing the value of nonce from the PA-OTP-
      CHALLENGE using the same encryption type as the Armor Key.





Richards                  Expires July 22, 2011                [Page 12]


Internet-Draft           OTP Pre-authentication             January 2011


   o  If the PA-OTP-REQUEST is not in response to a PA-OTP-CHALLENGE
      then the client SHALL encrypt a PA-ENC-TS-ENC containing the
      current time as in the encrypted timestamp pre-authentication
      mechanism [RFC4120].

   If the client is working in 2-pass mode and so is not responding to
   an initial KDC challenge then the values of the iteration count and
   hash algorithms cannot be obtained from that challenge.  The client
   SHOULD use any values obtained from a previous PA-OTP-CHALLENGE or,
   if no values are available, it MAY use initial configured values.

3.4.  Verifying the pre-auth Data

   The KDC validates the pre-authentication data by generating the
   Client Key and Reply Key in the same way as the client and using the
   generated Client Key to decrypt the value of encData from the PA-OTP-
   REQUEST.  The generated Reply Key is used to encrypt data in the AS-
   REP.

   If the otp-value field is included in the PA-OTP-REQUEST then the KDC
   MUST use that value unless the OTP method is required to support KDC-
   authentication (see Section 3.2).  If the otp-value is not included
   in the PA-OTP-REQUEST then the KDC will need to generate or obtain
   the OTP value.

   If the otp-challenge field is present, then the OTP was calculated
   using that challenge.  If the "combine" flag is also set, then the
   OTP was calculated using the challenge and the token's current state.

   It is RECOMMENDED that the KDC acts upon the values of otp-time, otp-
   counter, otp-format, otp-algID and otp-keyID if they are present in
   the PA-OTP-REQUEST.  If the KDC receives a request containing these
   values but cannot act upon them then they MAY be ignored.

   The KDC generates the Client Key and Reply Key as described in
   Section 3.6 from the OTP value using the nonce, hash algorithm and
   iteration count if present in the PA-OTP-REQUEST.  The KDC MUST fail
   the request with KDC_ERR_INVALID_HASH_ALG if the KDC requires hashed
   OTP values and the hashAlg field was not present in the PA-OTP-
   REQUEST or if the value of this field does not conform to local KDC
   policy.  Similarly, the KDC MUST fail the request with
   KDC_ERR_INVALID_ITERATION_COUNT if the value of the iterationCount
   included in the PA-OTP-REQUEST does not conform to local KDC policy
   or is less than that specified in the PA-OTP-CHALLENGE.

               KDC_ERR_INVALID_HASH_ALG           94
               KDC_ERR_INVALID_ITERATION_COUNT    95




Richards                  Expires July 22, 2011                [Page 13]


Internet-Draft           OTP Pre-authentication             January 2011


   The generated Client Key is then used to decrypt the encData from the
   PA-OTP-REQUEST.  If the client response was sent as a result of a PA-
   OTP-CHALLENGE then the decrypted data will be a PA-OTP-ENC-REQUEST
   and the client authentication MUST fail with KDC_ERR_PREAUTH_FAILED
   if the nonce value from the PA-OTP-ENC-REQUEST is not the same as the
   nonce value sent in the PA-OTP-CHALLENGE.  If the response was not
   sent as a result of a PA-OTP-CHALLENGE then the decrypted value will
   be a PA-ENC-TS-ENC and the authentication process will be the same as
   with classic encrypted timestamp pre-authentication [RFC4120]

   The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP if the
   encryption type used by the client in the encData does not conform to
   KDC policy.

   If authentication fails due to the hash algorithm, iteration count or
   encryption type used by the client then the KDC SHOULD return a PA-
   OTP-CHALLENGE with the required values in the error response.  If the
   authentication fails due to the token state on the server no longer
   being synchronized with the token used then the KDC MAY return a PA-
   OTP-CHALLENGE with the "nextOTP" flag set as described in
   Section 2.4.

   If, during the authentication process, the KDC determines that the
   user's PIN has been changed then it SHOULD include a PA-OTP-PIN-
   CHANGE in the response as described in Section 2.3 containing the new
   PIN value.  The KDC MAY also include the new PIN's expiration time
   and the expiration time of the OTP account within the last-req field
   of the PA-OTP-PIN-CHANGE.  (These fields can be used by the KDC to
   handle cases where then account related to the user's OTP token has a
   different expiration time to the user's Kerberos account.)  If the
   KDC determines that the user's PIN or OTP account are about to
   expire, it MAY return a PA-OTP-PIN-CHANGE with that information.
   Finally, if the KDC determines that the user's PIN has expired then
   it SHOULD return a KRB-ERROR of type KDC_ERR_PIN_EXPIRED as described
   in Section 2.3

3.5.  Confirming the Reply Key Change

   If the pre-authentication data was successfully verified, then, in
   order to support mutual authentication, the KDC SHALL respond to the
   client's PA-OTP-REQUEST by using the generated Reply Key to encrypt
   the data in the AS-REP.

   The client then uses its generated Reply Key to decrypt the encrypted
   data and MUST NOT continue with the authentication process if
   decryption is not successful.





Richards                  Expires July 22, 2011                [Page 14]


Internet-Draft           OTP Pre-authentication             January 2011


3.6.  Reply Key Generation

   In order to authenticate the user, the client and KDC need to
   generate two encryption keys:

   o  The Client Key to be used by the client to encrypt and by the KDC
      to decrypt the encData in the PA-OTP-REQUEST.

   o  The Reply Key to be used in the standard manner by the KDC to
      encrypt data in the AS-REP.

   The method used to generate the two keys will depend on the OTP
   algorithm.

   o  If the OTP value is included in the otp-value of the PA-OTP-
      REQUEST then the two keys SHALL be the same as the Armor Key
      (defined in [ZhHa10]).

   o  If the OTP value is not included in the otp-value of the PA-OTP-
      REQUEST then the two keys SHALL be derived from the Armor Key and
      the OTP value as described below.

   If the OTP value is not included in the PA-OTP-REQUEST, then the
   Reply Key and Client Key SHALL be generated using the KRB-FX-CF2
   algorithm from [ZhHa10] as follows:

             Client Key = KRB-FX-CF2(K1, K2, O1, O2)
             Reply Key = KRB-FX-CF2(K1, K2, O3, O4)

   The octet string parameters, O1, O2, O3 and O4, shall be the ASCII
   string "OTPComb1", "OTPComb2", "OTPComb3" and "OTPComb4" as shown
   below:

      {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31}
      {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32}
      {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
      {0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}

   The first input keys, K1, SHALL be the Armor Key and so, as described
   in section 5.1 of [ZhHa10], the enctypes of the generated Client Key
   and Reply Key will be the same as the enctype of Armor Key. The
   second input key, K2, shall be derived from the OTP value using
   string-to-key (defined in [RFC3961]) as follows.

   If the hash of the OTP value is to be used then K2 SHALL be derived
   as follows:





Richards                  Expires July 22, 2011                [Page 15]


Internet-Draft           OTP Pre-authentication             January 2011


   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.
      *  realm is the name of the server's realm as carried in the realm
         field of the AS-REQ.  (Not including the tag and length from
         the DER encoding.)
      *  nonce is the value of the random nonce value generated by the
         client and carried in the nonce field of the PA-OTP-REQUEST.
         (Not including the tag and length from the DER encoding.)
      *  OTP is the value of the OTP generated as described in
         Section 3.3.  If the token is disconnected then the value of
         this field SHOULD be the concatenation of any PIN collected by
         the client and the token value as entered by the user without a
         terminating null character.  For connected devices, the OTP
         value SHOULD be the value as returned by the device.

   o  The initial hash value is then hashed iterationCount-1 times to
      produce a final hash value, H'.  (Where iterationCount is the
      value from the PA-OTP-REQUEST.)

             H' = hash(hash(...(iterationCount-1 times)...(H)))

   o  The value of K2 is then derived from the Base64 [RFC2045] encoding
      of this final hash value.

             K2 = string-to-key(Base64(H')||"Krb-preAuth")

   If the hash value is not used, then K2 SHALL be derived from the
   base64 encoding of the OTP value.

             K2 = string-to-key(Base64(OTP)||"Krb-preAuth")

   The symbol "||" denotes string concatenation.

   The enctype used for string-to-key SHALL be that of the Armor Key and
   the salt and any additional parameters for string-to-key MAY be
   provided by the KDC in the PA-OTP-CHALLENGE.  If the salt and string-
   to-key parameters are not provided then the default values defined
   for the particular enctype SHALL be used.

   If the strengthen-key is present in KrbFastResponse, then it is
   combined with the Reply Key to generate the final AS-REQ as described
   in [ZhHa10].  The strengthen-key does not influence the Client Key.




Richards                  Expires July 22, 2011                [Page 16]


Internet-Draft           OTP Pre-authentication             January 2011


4.  OTP Kerberos Message Types

4.1.  PA-OTP-CHALLENGE

   The padata-type PA-OTP-CHALLENGE is returned by the KDC to the client
   in the enc-fast-rep of a PA-FX-FAST-REPLY in the PA-DATA of a KRB-
   ERROR when OTP pre-authentication is required.  The corresponding
   padata-value field contains the Distinguished Encoding Rules (DER)
   [X.680] [X.690] encoding of a PA-OTP-CHALLENGE containing a server
   generated nonce and information for the client on how to generate the
   OTP.

             PA-OTP-CHALLENGE     141

             PA-OTP-CHALLENGE ::= SEQUENCE {
               nonce            [0] OCTET STRING,
               otp-service      [1] UTF8String               OPTIONAL,
               otp-keyInfo      [2] SEQUENCE (SIZE(1..MAX)) OF
                                                          OTP-KEYINFO,
               salt             [3] KerberosString           OPTIONAL,
               s2kparams        [4] OCTET STRING             OPTIONAL,
               ...
             }

             OTP-KEYINFO ::= SEQUENCE {
               flags            [0] OTPFlags,
               otp-vendor       [1] UTF8String               OPTIONAL,
               otp-challenge    [2] OCTET STRING (SIZE(8..MAX))
                                                             OPTIONAL,
               otp-length       [3] Int32                    OPTIONAL,
               otp-keyID        [4] OCTET STRING             OPTIONAL,
               otp-algID        [5] AnyURI                   OPTIONAL,
               supportedHashAlg [6] SEQUENCE OF AlgorithmIdentifier
                                                             OPTIONAL,
               iterationCount   [7] Int32                    OPTIONAL,
               ...
             }

             OTPFlags ::= KerberosFlags
             -- reserved(0),
             -- nextOTP(1),
             -- combine(2),
             -- pin-required(3),
             -- pin-not-required(4),
             -- must-encrypt-nonce (5)






Richards                  Expires July 22, 2011                [Page 17]


Internet-Draft           OTP Pre-authentication             January 2011


   nonce
      A KDC-supplied nonce value to be encrypted by the client in the
      PA-OTP-REQUEST.  This nonce string MUST be as long as the longest
      key length of the symmetric key types that the KDC supports and
      MUST be chosen randomly.

   otp-service
      Use of this field is OPTIONAL, but MAY be used by the KDC to
      assist the client to locate the appropriate OTP tokens to be used.
      For example, this field could be used when a user has multiple OTP
      tokens for different purposes.

   otp-keyInfo
      Use of this field is OPTIONAL, but MAY be used by the KDC to carry
      information on the tokens that the user may use to carry out the
      authentication.  Each otp-keyInfo element carries information on a
      valid token.  If this field is omitted then there are no token
      restrictions.

      flags
         If the "nextOTP" flag is set then the OTP SHALL be based on the
         next token "state" rather than the one used in the previous
         authentication.  As an example, for a time-based token, this
         means the next time slot and for an event-based token, this
         could mean the next counter value.  If the "nextOTP" flag is
         set then there MUST only be a single otp-keyInfo element in the
         PA-OTP-CHALLENGE.

         The "combine flag controls how the challenge included in otp-
         challenge shall be used.  If the flag is set then OTP SHALL be
         calculated using the challenge from otp-challenge and the
         internal token state (e.g. time or counter).  If the "combine"
         flag is not set then the OTP SHALL be calculated based only on
         the challenge.  If the flag is set and otp-challenge is not
         present then the request SHALL be regarded as invalid.

         If the "pin-not-required" flag is set then the token
         represented by the current otp-keyInfo does not require a PIN
         to be collected as part of the OTP.  If the "pin-required" flag
         is set then the token requires a PIN.  If neither flag is set
         then whether or not a PIN is required is unspecified.  The
         flags are mutually exclusive and so both flags MUST NOT be set,
         or the client MUST regard the request as invalid.

         If the "must-encrypt-nonce" flag is set then the OTP value MUST
         NOT be included in the otp-value field of the PA-OTP-REQUEST
         but instead MUST be used in the generation of the Reply Key and
         Client Key as described in Section 3.6.



Richards                  Expires July 22, 2011                [Page 18]


Internet-Draft           OTP Pre-authentication             January 2011


      otp-vendor
         Use of this field is OPTIONAL, but MAY be used by the KDC to
         identify the vendor of the OTP token to be used.

      otp-challenge
         The otp-challenge is used by the KDC to send a challenge value
         for use in the OTP calculation.  The challenge is an optional
         octet string that SHOULD be uniquely generated for each request
         it is present in, and SHOULD be eight octets or longer when
         present.  When the challenge is not present, the OTP will be
         calculated on the current token state only.  The client MAY
         ignore a provided challenge if and only if the OTP token the
         client is interacting with is not capable of including a
         challenge in the OTP calculation.  In this case, KDC policies
         will determine whether to accept a provided OTP value or not.

      otp-length
         Use of this field is OPTIONAL, but MAY be used by the KDC to
         specify the desired length of the generated OTP in octets.  For
         example, this field could be used when a token is capable of
         producing OTP values of different lengths.

      otp-keyID
         Use of this field is OPTIONAL, but MAY be used by the KDC to
         identify which token key should be used for the authentication.
         For example, this field could be used when a user has been
         issued multiple token keys by the same server.

      otp-algID
         Use of this field is OPTIONAL, but MAY be used by the KDC to
         identify the algorithm to use when generating the OTP.

      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 AlgorithmIdentifier selected by the client MUST
         be placed in the hashAlg element of the PA-OTP-REQUEST.

      iterationCount
         The minimum value of the iteration count to be used by the
         client when hashing the OTP value.  This value MUST be present
         if 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



Richards                  Expires July 22, 2011                [Page 19]


Internet-Draft           OTP Pre-authentication             January 2011


         value.  The value of the iteration count used by the client
         MUST be returned in the PA-OTP-REQUEST sent to the KDC.

   salt
      The salt value to be used in string-to-key when used to calculate
      the keys as described in Section 3.6.

   s2kparams
      Any additional parameters required by string-to-key as described
      in Section 3.6.

4.2.  PA-OTP-REQUEST

   The padata-type PA-OTP-REQUEST is sent by the client to the KDC in
   the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the
   PA-DATA of an AS-REQ.  The corresponding padata-value field contains
   the DER encoding of a PA-OTP-REQUEST.

   The message contains pre-authentication data encrypted by the client
   using the generated Client Key and optional information on how the
   OTP was generated.  It may also, optionally, contain the generated
   OTP value.





























Richards                  Expires July 22, 2011                [Page 20]


Internet-Draft           OTP Pre-authentication             January 2011


             PA-OTP-REQUEST     142

             PA-OTP-REQUEST ::= SEQUENCE {
               flags          [0]  OTPFlags,
               nonce          [1]  OCTET STRING                OPTIONAL,
               encData        [2]  EncryptedData,
                                  -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
                                  -- Key usage of KEY_USAGE_OTP_REQUEST
               hashAlg        [3]  AlgorithmIdentifier         OPTIONAL,
               iterationCount [4]  Int32                       OPTIONAL,
               otp-value      [5]  OCTET STRING                OPTIONAL,
               otp-challenge  [6]  OCTET STRING (SIZE(8..MAX)) OPTIONAL,
               otp-time       [7]  KerberosTime                OPTIONAL,
               otp-counter    [8]  OCTET STRING                OPTIONAL,
               otp-format     [9]  OTPFormat                   OPTIONAL,
               otp-keyID      [10] OCTET STRING                OPTIONAL,
               otp-algID      [11] AnyURI                      OPTIONAL,
               otp-vendor     [12] UTF8String                  OPTIONAL,
               ...
             }

             KEY_USAGE_OTP_REQUEST  45

             PA-OTP-ENC-REQUEST ::= SEQUENCE {
                nonce     [0] OCTET STRING,
                ...
             }

             OTPFormat ::= INTEGER {
               decimal(0),
               hexadecimal(1),
               alphanumeric(2),
               binary(3)
             }

   flags
      If the "nextOTP" flag is set then the OTP was calculated based on
      the next token "state" rather than the current one.  This flag
      MUST be set if and only if it was set in a corresponding PA-OTP-
      CHALLENGE.

      If the "combine" flag is set then the OTP was calculated based on
      a challenge and the token state.








Richards                  Expires July 22, 2011                [Page 21]


Internet-Draft           OTP Pre-authentication             January 2011


   nonce
      This field MUST be present if and only if a hash of the OTP value
      was used as input to string-to-key (see Section 3.6) and MUST
      contain nonce value generated by the client and used in the
      generation of hashed OTP values as described in Section 3.6 .
      This nonce string MUST be as long as the longest key length of the
      symmetric key types that the client supports and MUST be chosen
      randomly.

   encData
      This field contains the pre-authentication data encrypted under
      the Client Key with a key usage of KEY_USAGE_OTP_REQUEST.  If the
      PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then this
      MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-
      CHALLENGE.  If no challenge was received then this MUST contain a
      PA-ENC-TS-ENC.

   hashAlg
      This field MUST be present if and only if a hash of the OTP value
      was used as input to string-to-key (see Section 3.6) and MUST
      contain the AlgorithmIdentifier of the hash algorithm used.  If
      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then
      the AlgorithmIdentifer MUST be the first one supported by the
      client from the supportedHashAlg of the PA-OTP-CHALLENGE.

   iterationCount
      This field MUST be present if and only if a hash of the OTP value
      was used as input to string-to-key (see Section 3.6) and MUST
      contain the iteration count used when hashing the OTP value.  If
      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then
      the value MUST NOT be less that that specified in the PA-OTP-
      CHALLENGE.

   otp-value
      The generated OTP value.  This value MUST NOT be present if the
      "must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE.

   otp-challenge
      Value used by the client in the OTP calculation.  It MUST be sent
      to the KDC if and only if the value would otherwise be unknown to
      the KDC.  For example, the token or client modified or generated
      challenge.

   otp-time
      This field MAY be included by the client to carry the time value
      as reported by the OTP token.  Use of this element is OPTIONAL but
      it MAY be used by a client to simplify the OTP calculations of the
      KDC.  It is RECOMMENDED that the KDC act upon this value if it is



Richards                  Expires July 22, 2011                [Page 22]


Internet-Draft           OTP Pre-authentication             January 2011


      present in the request and it is capable of using it in the
      generation of the OTP value.

   otp-counter
      This field MAY be included by the client to carry the token
      counter value, as reported by the OTP token.  Use of this element
      is OPTIONAL but it MAY be used by a client to simplify the OTP
      calculations of the KDC.  It is RECOMMENDED that the KDC act upon
      this value if it is present in the request and it is capable of
      using it in the generation of the OTP value.

   otp-format
      This field MAY be used by the client to send the format of the
      generated OTP as reported by the OTP token.  Use of this element
      is OPTIONAL but it MAY be used by the client to simplify the OTP
      calculation.  It is RECOMMENDED that the KDC act upon this value
      if it is present in the request and it is capable of using it in
      the generation of the OTP value.

   otp-keyID
      This field MAY be used by the client to send the identifier of the
      token key used, as reported by the OTP token.  Use of this field
      is OPTIONAL but MAY be used by the client to simplify the
      authentication process by identifying a particular token key
      associated with the user.  It is RECOMMENDED that the KDC act upon
      this value if it is present in the request and it is capable of
      using it in the generation of the OTP value.

   otp-algID
      This field MAY be used by the client to send the identifier of the
      OTP algorithm used, as reported by the OTP token.  Use of this
      element is OPTIONAL but it MAY be used by the client to simplify
      the OTP calculation.  It is RECOMMENDED that the KDC act upon this
      value if it is present in the request and it is capable of using
      it in the generation of the OTP value.

   otp-vendor
      If the PA-OTP-REQUEST is being sent in response to a PA-OTP-
      CHALLENGE that contained an otp-vendor field in the selected otp-
      keyInfo then this field MUST be set to the same value otherwise,
      this filed SHOULD be set to the vendor identifier of the token if
      known to the client.  It is RECOMMENDED that the KDC act upon this
      value if it is present in the request and it is capable of using
      it in the generation of the OTP value.







Richards                  Expires July 22, 2011                [Page 23]


Internet-Draft           OTP Pre-authentication             January 2011


4.3.  PA-OTP-PIN-CHANGE

   The padata-type PA-OTP-PIN-CHANGE is returned by the KDC in the enc-
   fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change
   their PIN, if the user's PIN has been changed or to notify the user
   of the PIN's expiry time.

   The corresponding padata-value field contains the DER encoding of a
   PA-OTP-PIN-CHANGE.

             PA-OTP-PIN-CHANGE     144

             PA-OTP-PIN-CHANGE ::= SEQUENCE {
               flags     [0] PinFlags,
               pin       [1] UTF8String OPTIONAL,
               minLength [2] INTEGER    OPTIONAL,
               maxLength [3] INTEGER    OPTIONAL,
               last-req  [4] LastReq    OPTIONAL,
               format    [5] OTPFormat  OPTIONAL,
               ...
             }

             PinFlags ::= KerberosFlags
               -- reserved(0),
               -- systemSetPin(1),
               -- mandatory(2)

   flags
      The "systemSetPin" flag is used to indicate the type of PIN change
      that is taking place.  If the flag is set then the user's PIN has
      been changed for the user by the system.  If the flag is not set
      then the user's PIN needs to be changed by the user.

      If the "systemSetPin" flag is not set and the "mandatory" flag is
      set then user PIN change is required before the next
      authentication using the current OTP token.  If the "mandatory"
      flag is not set then the user PIN change is optional.  If the
      "systemSetPin" flag is set then the "mandatory" flag has no
      meaning and SHOULD be ignored by the client.

   pin
      The pin field is used to carry a new PIN value.  If the
      "systemSetPin" flag is set then field is used to carry the new PIN
      value set for the user and MUST be present.  If the "systemSetPin"
      flag is not set then this field MAY be used to carry a system
      generated PIN that MAY be used by the user when changing the PIN.





Richards                  Expires July 22, 2011                [Page 24]


Internet-Draft           OTP Pre-authentication             January 2011


   minLength and maxLength
      If the "systemSetPin" flag is not set then the minLength and
      maxLength fields MAY be included to pass restrictions on the size
      of the user selected PIN.

   last-req
      The last-req element (as defined in section 5.4.2 of [RFC4120])
      MAY be included with an lr-type of 6 to carry PIN expiration
      information.

      *  If the "systemSetPin" flag is set then the expiration time MUST
         be that of the new system-set PIN.

      *  If the "systemSetPin" flag is not set then the expiration time
         MUST be that of the current PIN of the token used in the
         authentication.

      The element MAY also be included with an lr-type of 7 to indicate
      when the OTP account will expire.

   format
      The format element MAY be included by the KDC to carry PIN format
      restrictions on the new PIN.

      *  If the "systemSetPin" flag is set then the element MUST
         describe the format of the new system-generated PIN.

      *  If the "systemSetPin" flag is not set then the element MUST
         describe restrictions on any new user generated PIN.


5.  IANA Considerations

   A registry will be required for the URIs to be used as otp-algID
   values as introduced in Section 4.1.  It is currently anticipated
   that the registry being introduced in section 12.4 of [RFC6030] can
   be used for this purpose.

   The following pre-authentication types are defined in this document:

             PA-OTP-CHALLENGE      141
             PA-OTP-REQUEST        142
             PA-OTP-PIN-CHANGE     144

   These values are currently registered in registry created by [ZhHa10]
   but the entries will need to be updated to refer to this document.

   The following error codes and key usage values are defined in this



Richards                  Expires July 22, 2011                [Page 25]


Internet-Draft           OTP Pre-authentication             January 2011


   document:

             KDC_ERR_INVALID_HASH_ALG           94
             KDC_ERR_INVALID_ITERATION_COUNT    95
             KDC_ERR_PIN_EXPIRED                <TBD>
             KEY_USAGE_OTP_REQUEST              45

   These values are not managed by IANA and have been accounted for.

   No other IANA actions are anticipated.


6.  Security Considerations

6.1.  Man-in-the-Middle

   In the system described in this document, the OTP pre-authentication
   protocol is tunneled within the FAST Armor channel provided by the
   pre-authentication framework.  As described in [AsNiNy02], tunneled
   protocols are potentially vulnerable to man-in-the-middle attacks if
   the outer tunnel is compromised and it is generally considered good
   practice in such cases to bind the inner encryption to the outer
   tunnel.

   In order to mitigate against such attacks, the proposed system uses
   the outer Armor Key in the derivation of the inner Client and Reply
   keys and so achieve crypto-binding to the outer channel.

   As described in section 5.4 of [ZhHa10], FAST can use an anonymous
   TGT obtained using anonymous PKINIT [ZhLe08] [RFC4556] as the Armor
   Key. However, the current anonymous PKINIT proposal is open to man-
   in-the-middle attacks since the attacker can choose a session key
   such that the session key between the MITM and the real KDC is the
   same as the session key between the client and the MITM.

   As described in Section 3.6, if the OTP value is not being sent to
   the KDC then the Armor Key is used along with the OTP value in the
   generation of the Client Key and Reply Key. If the Armor Key is known
   then the only entropy remaining in the key generation is provided by
   the OTP value.  If the OTP algorithm requires that the OTP value be
   sent to the KDC then it is sent encrypted within the tunnel provided
   by the FAST armor and so is exposed to the attacker if the attacker
   has the Armor Key.

   It is therefore recommended that anonymous PKINIT not be used with
   OTP algorithms that require the OTP value to be sent to the KDC and
   that careful consideration be made of the security implications
   before it is used with other algorithms such as those with short OTP



Richards                  Expires July 22, 2011                [Page 26]


Internet-Draft           OTP Pre-authentication             January 2011


   values.

   Careful consideration should also be made if host key armor is used
   to provide the KDC-authentication facility with OTP algorithms where
   the OTP value is sent within the otp-value field of the PA-OTP-
   REQUEST since compromised host keys would allow an attacker to
   impersonate the KDC.

6.2.  Reflection

   The 4-pass system described above is a challenge-response protocol
   and such protocols are potentially vulnerable to reflection attacks.
   No such attacks are known at this point but to help mitigate against
   such attacks, the system uses different keys to encrypt the client
   and server nonces.

6.3.  Denial of Service

   The protocol supports the use of an iteration count in the generation
   of the Client and Reply keys and the client can send the number of
   iterations used as part of the PA-OTP-REQUEST.  This could open the
   KDC up to a denial of service attack if a large value for the
   iteration count was specified by the attacker.  It is therefore
   particularly important that, as described in Section 3.4, the KDC
   reject any authentication requests where the iteration count is above
   a maximum value specified by local policy.

6.4.  Replay

   In the 4-pass version of this protocol, the client encrypts a KDC
   generated nonce and so replay can be detected by the KDC.  The 2-pass
   version of the protocol does not involve a server nonce but the
   client instead encrypts a timestamp and so is not protected from
   replay in this way but will instead require some other mechanism such
   as an OTP-server based system or a timestamp-based replay cache on
   the KDC.

   As described in section 5.2 of [ZhHa10], a client can not be certain
   that it will use the same KDC for all messages in a conversation.
   Therefore, the client cannot assume that the PA-OTP-REQUEST will be
   sent to the same KDC that issued the PA-OTP-CHALLENGE.  In order to
   support this, a KDC implementing this protocol requires a means of
   sharing session state.  However, doing this does introduce the
   possibility of a replay attack where the same response is sent to
   multiple KDCs.

   In the case of time or event-based tokens or server-generated
   challenges, protection against replay may be provided by the OTP



Richards                  Expires July 22, 2011                [Page 27]


Internet-Draft           OTP Pre-authentication             January 2011


   server being used if that server is capable of keeping track of the
   last used value.  This protection therefore relies upon the
   assumption that the OTP server being used in this protocol is either
   not redundant or involves a commit protocol to synchronize between
   replicas.  If this does not hold for an OTP server being used then
   the system may be vulnerable to replay attack.

   However, OTP servers may not be able to detect replay of OTPs
   generated using only a client generated challenge and since the KDC
   would not be able to detect replay in 2-pass mode, it is recommended
   that the use of OTPs generated from only a client-generated challenge
   (that is, not in combination with some other factor such as time)
   should not be supported in 2-pass mode.

6.5.  Brute Force Attack

   A compromised or hostile KDC may be able to obtain the OTP value used
   by the client via a brute force attack.  If the OTP value is short
   then the KDC could iterate over the possible OTP values until a
   Client Key is generated that can decrypt the encData sent in the PA-
   OTP-REQUEST.

   As described in Section 3.6, an iteration count can be used in the
   generation of the Client Key and the value of the iteration count can
   be controlled by local client policy.  Use of this iteration count
   can make it computationally infeasible/unattractive for an attacker
   to brute-force search for the given OTP within the lifetime of that
   OTP.

6.6.  FAST Facilities

   The secret used to generate the OTP is known only to the client and
   the KDC and so successful decryption of the encrypted nonce by the
   KDC authenticates the user.  If the OTP value is used in the Reply
   Key generation then successful decryption of the encrypted nonce by
   the client proves that the expected KDC replied.  The Reply Key is
   replaced by either a key generated from the OTP and Armor Key or by
   the Armor Key. This FAST factor therefore provides the following
   facilities: client-authentication, replacing-reply-key and, depending
   on the OTP algorithm, KDC-authentication.


7.  Acknowledgments

   Many significant contributions were made to this document by RSA
   employees but special thanks go to Magnus Nystrom, John Linn, Richard
   Zhang, Piers Bowness, Robert Polansky and Boris Khoutorski.




Richards                  Expires July 22, 2011                [Page 28]


Internet-Draft           OTP Pre-authentication             January 2011


   Many valuable suggestions were also made by members of the Kerberos
   Working Group but special thanks go to Larry Zhu, Jeffrey Hutzelman,
   Tim Alsop, Henry Hotz, Nicolas Williams and Sam Hartman.

   I would also like to thank Tim Alsop and Srinivas Cheruku of
   CyberSafe for many valuable review comments.


8.  References

8.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

   [X.680]    ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
              Information technology - Abstract Syntax Notation One
              (ASN.1): Specification of basic notation.".

   [X.690]    ITU-T, "Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
              Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER).".

   [ZhHa10]   Zhu, L. and S. Hartman, "A generalized Framework for
              Kerberos Pre-Authentication",
              draft-ietf-krb-wg-preauth-framework-17 (work in progress),
              June 2010.

   [ZhLe08]   Zhu, L. and P. Leach, "Anonymity Support for Kerberos",
              draft-ietf-krb-wg-anon-12 (work in progress), August 2010.





Richards                  Expires July 22, 2011                [Page 29]


Internet-Draft           OTP Pre-authentication             January 2011


8.2.  Informative References

   [AsNiNy02]
              Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
              in Tunneled Authentication Protocols", Cryptology ePrint
              Archive Report 2002/163, November 2002.

   [HoReNeZo04]
              Horstein, K., Renard, K., Neuman, C., and G. Zorn,
              "Integrating Single-use Authentication Mechanisms with
              Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
              progress), July 2004.

   [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
              Time Password System", RFC 2289, February 1998.

   [RFC2808]  Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
              April 2000.

   [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One-Time Password
              Algorithm", RFC 4226, December 2005.

   [RFC6030]  Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
              Key Container (PSKC)", RFC 6030, October 2010.


Appendix A.  ASN.1 Module

   OTPKerberos
   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS

       KerberosTime, KerberosFlags, EncryptionKey, Int32,
       EncryptedData, LastReq, ETYPE-INFO2-ENTRY
       FROM KerberosV5Spec2 {iso(1) identified-organization(3)
                             dod(6) internet(1) security(5)
                             kerberosV5(2) modules(4) krb5spec2(2)}
                             -- as defined in RFC 4120.
       AlgorithmIdentifier
       FROM PKIX1Explicit88 { iso (1) identified-organization (3)
                              dod (6) internet (1)
                              security (5) mechanisms (5) pkix (7)
                              id-mod (0) id-pkix1-explicit (18) };
                              -- As defined in RFC 3280.




Richards                  Expires July 22, 2011                [Page 30]


Internet-Draft           OTP Pre-authentication             January 2011


       PA-OTP-CHALLENGE ::= SEQUENCE {
         nonce            [0] OCTET STRING,
         otp-service      [1] UTF8String               OPTIONAL,
         otp-keyInfo      [2] SEQUENCE (SIZE(1..MAX)) OF
                                                    OTP-KEYINFO,
         salt             [3] KerberosString           OPTIONAL,
         s2kparams        [4] OCTET STRING             OPTIONAL,
         ...
       }

       OTP-KEYINFO ::= SEQUENCE {
         flags            [0] OTPFlags,
         otp-vendor       [1] UTF8String               OPTIONAL,
         otp-challenge    [2] OCTET STRING (SIZE(8..MAX))
                                                       OPTIONAL,
         otp-length       [3] Int32                    OPTIONAL,
         otp-keyID        [4] OCTET STRING             OPTIONAL,
         otp-algID        [5] AnyURI                   OPTIONAL,
         supportedHashAlg [6] SEQUENCE OF AlgorithmIdentifier
                                                       OPTIONAL,
         iterationCount   [7] Int32                    OPTIONAL,
         ...
       }

       OTPFlags ::= KerberosFlags
       -- reserved(0),
       -- nextOTP(1),
       -- combine(2),
       -- pin-required(3),
       -- pin-not-required(4)
       -- must-encrypt-nonce (5)

       PA-OTP-REQUEST ::= SEQUENCE {
         flags          [0]  OTPFlags,
         nonce          [1]  OCTET STRING                OPTIONAL,
         encData        [2]  EncryptedData,
                            -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
                            -- Key usage of KEY_USAGE_OTP_REQUEST
         hashAlg        [3]  AlgorithmIdentifier         OPTIONAL,
         iterationCount [4]  Int32                       OPTIONAL,
         otp-value      [5]  OCTET STRING                OPTIONAL,
         otp-challenge  [6]  OCTET STRING (SIZE(8..MAX)) OPTIONAL,
         otp-time       [7]  KerberosTime                OPTIONAL,
         otp-counter    [8]  OCTET STRING                OPTIONAL,
         otp-format     [9]  OTPFormat                   OPTIONAL,
         otp-keyID      [10] OCTET STRING                OPTIONAL,
         otp-algID      [11] AnyURI                      OPTIONAL,
         otp-vendor     [12] UTF8String                  OPTIONAL,



Richards                  Expires July 22, 2011                [Page 31]


Internet-Draft           OTP Pre-authentication             January 2011


         ...
       }

       PA-OTP-ENC-REQUEST ::= SEQUENCE {
         nonce     [0] OCTET STRING,
         ...
       }

       OTPFormat ::= INTEGER {
         decimal(0),
         hexadecimal(1),
         alphanumeric(2),
         binary(3)
       }


       PA-OTP-PIN-CHANGE ::= SEQUENCE {
         flags     [0] PinFlags,
         pin       [1] UTF8String OPTIONAL,
         minLength [2] INTEGER    OPTIONAL,
         maxLength [3] INTEGER    OPTIONAL,
         last-req  [4] LastReq    OPTIONAL,
         format    [5] OTPFormat  OPTIONAL,
         ...
       }

       PinFlags ::= KerberosFlags
       -- reserved(0),
       -- systemSetPin(1),
       -- mandatory(2)

       AnyURI ::= UTF8String
          (CONSTRAINED BY {
          -- MUST be a valid URI in accordance with IETF RFC 2396
          })

       PA-OTP-INFO ::= ETYPE-INFO2-ENTRY

   END


Appendix B.  Examples of OTP Pre-Authentication Exchanges

   This section is non-normative.







Richards                  Expires July 22, 2011                [Page 32]


Internet-Draft           OTP Pre-authentication             January 2011


B.1.  Four Pass Authentication

   In this mode, the client sends an initial AS-REQ to the KDC that does
   not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR
   containing a PA-OTP-CHALLENGE.

   In this example, the user has been issued with a connected, time-
   based token and the KDC requires hashed OTP values in the key
   generation with SHA-384 as the preferred hash algorithm and a minimum
   of 1024 iterations.  The local policy on the client supports SHA-256
   and requires 100,000 iterations of the hash of the OTP value.

   The basic sequence of steps involved is as follows:

   1.   The client obtains the user name of the user.

   2.   The client sends an initial AS-REQ to the KDC that does not
        contain a PA-OTP-REQUEST.

   3.   The KDC determines that the user identified by the AS-REQ
        requires OTP authentication.

   4.   The KDC constructs a PA-OTP-CHALLENGE as follows:

        nonce
           A randomly generated value.

        otp-service
           A string that can be used by the client to assist the user in
           locating the correct token.

        otp-keyInfo
           Information about how the OTP should be generated from the
           token.

           flags
              must-encrypt-nonce and pin-required bits set

           supportedHashAlg
              AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1

           iterationCount
              1024

   5.   The KDC returns a KRB-ERROR with an error code of
        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.





Richards                  Expires July 22, 2011                [Page 33]


Internet-Draft           OTP Pre-authentication             January 2011


   6.   The client displays the value of otp-service and prompts the
        user to connect the token.

   7.   The client collects a PIN from the user.

   8.   The client obtains the current OTP value from the token using
        the PIN and records the time as reported by the token.

   9.   The client generates Client Key and Reply Key as described in
        Section 3.6 using SHA-256 from the list of algorithms sent by
        the KDC, the iteration count of 100,000 as required by local
        policy and a randomly generated nonce.

   10.  The client constructs a PA-OTP-REQUEST as follows:

        flags
           0

        nonce
           The randomly generated value.

        encData
           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
           under the Client Key with a key usage of
           KEY_USAGE_OTP_REQUEST and the encryption type of the Armor
           Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-
           OTP-CHALLENGE.

        hashAlg
           SHA-256

        iterationCount
           100,000

        otp-time
           The time used in the OTP calculation as reported by the OTP
           token.

   11.  The client encrypts the PA-OTP-REQUEST within the enc-fast-req
        of a PA-FX-FAST-REQUEST.

   12.  The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
        REQUEST within the padata.

   13.  The KDC validates the pre-authentication data in the PA-OTP-
        REQUEST:





Richards                  Expires July 22, 2011                [Page 34]


Internet-Draft           OTP Pre-authentication             January 2011


        *  Generates the Client Key and Reply Key from the OTP value for
           the user identified in the AS-REQ, using an iteration count
           of 100,000, a hash algorithm of SHA-256 and the nonce as
           specified in the PA-OTP-REQUEST.

        *  Uses the generated Client Key to decrypt the PA-OTP-ENC-
           REQUEST in the encData of the PA-OTP-REQUEST.

        *  Authenticates the user by comparing the nonce value from the
           decrypted PA-OTP-ENC-REQUEST to that sent in the
           corresponding PA-OTP-CHALLENGE.

   14.  The KDC constructs a TGT for the user.

   15.  The KDC returns an AS-REP to the client, encrypted using the
        Reply Key, containing the TGT and padata with the PA-FX-FAST-
        REPLY.

   16.  The client authenticates the KDC and verifies the Reply Key
        change.

        *  Uses the generated Reply Key to decrypt the encrypted data in
           the AS-REP.


B.2.  Two Pass Authentication

   In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-
   FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC.

   In this example, the user has been issued with a hand-held token and
   so none of the OTP generation parameters (otp-length etc) are
   included in the PA-OTP-REQUEST.  The KDC does not require hashed OTP
   values in the key generation.

   It is assumed that the client has been configured with the following
   information or has obtained it from a previous PA-OTP-CHALLENGE.
   o  The fact that the OTP value must not be carried in the otp-value
   o  The fact that hashed OTP values are not required.

   The basic sequence of steps involved is as follows:

   1.  The client obtains the user name and OTP value from the user.

   2.  The client generates Client Key and Reply Key using unhashed OTP
       values as described in Section 3.6.





Richards                  Expires July 22, 2011                [Page 35]


Internet-Draft           OTP Pre-authentication             January 2011


   3.  The client constructs a PA-OTP-REQUEST as follows:

       flags
          0

       encData
          An EncryptedData containing a PA-ENC-TS-ENC encrypted under
          the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and
          an encryption type of the Armor Key. The PA-ENC-TS-ENC
          contains the current client time.

   4.  The client encrypts the PA-OTP-REQUEST within the enc-fast-req of
       a PA-FX-FAST-REQUEST.

   5.  The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
       REQUEST within the padata.

   6.  The KDC validates the pre-authentication data:

       *  Generates the Client Key and Reply Key from the unhashed OTP
          value for the user identified in the AS-REQ.

       *  Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in
          the encData of the PA-OTP-REQUEST.

       *  Authenticates the user using the timestamp in the standard
          manner.

   7.  The KDC constructs a TGT for the user.

   8.  The KDC returns an AS-REP to the client, encrypted using the
       Reply Key, containing the TGT and padata with the PA-FX-FAST-
       REPLY.

   9.  The client authenticates the KDC and verifies the key change.

       *  Uses the generated Reply Key to decrypt the encrypted data in
          the AS-REP.

B.3.  PIN Change

   This exchange follows from the point where the KDC receives the PA-
   OTP-REQUEST from the client in the examples in Appendix B.1 and
   Appendix B.2.  During the validation of the pre-authentication data
   (whether encrypted nonce or encrypted timestamp), the KDC determines
   that the user's PIN has expired and so must be changed.  The KDC
   therefore includes a PA-OTP-PIN-CHANGE in the AS-REP.




Richards                  Expires July 22, 2011                [Page 36]


Internet-Draft           OTP Pre-authentication             January 2011


   In this example, the KDC does not generate PIN values for the user
   but requires that the user generate a new PIN that is between 4 and 8
   characters in length.  The actual PIN change is handled by a PIN
   change service.

   The basic sequence of steps involved is as follows:

   1.  The client constructs and sends a PA-OTP-REQUEST to the KDC as
       described in the previous examples.

   2.  The KDC validates the pre-authentication data and authenticates
       the user as in the previous examples but determines that the
       user's PIN has expired.

   3.  KDC constructs a ticket for a PIN change service with a one
       minute lifetime.

   4.  KDC constructs a PA-OTP-PIN-CHANGE as follows:

       flags
          0

       minLength
          4

       maxLength
          8

   5.  KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep of a
       PA-FX-FAST-REPLY.

   6.  KDC returns a KRB-ERROR to the client of type KDC_ERR_PIN_EXPIRED
       containing the ticket to the PIN change service and padata
       containing the PA-FX-FAST-REPLY.

   7.  The client uses the ticket requests a ticket for a PIN change
       service and changes the user's PIN.

   8.  The client sends a second AS-REQ to the KDC containing a PA-OTP-
       REQUEST constructed using the new PIN.

   9.  The KDC responds with an AS-REP containing a TGT.


B.4.  Resynchronization

   This exchange follows from the point where the KDC receives the PA-
   OTP-REQUEST from the client.  During the validation of the pre-



Richards                  Expires July 22, 2011                [Page 37]


Internet-Draft           OTP Pre-authentication             January 2011


   authentication data (whether encrypted nonce or encrypted timestamp),
   the KDC determines that the local record of the token's state needs
   to be re-synchronized with the token.  The KDC therefore includes a
   KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.

   The sequence of steps below follows is a variation of the four pass
   examples shown in Appendix B.1 but the same process would also work
   in the two-pass case.

   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as
        described in the previous examples.

   2.   The KDC validates the pre-authentication data and authenticates
        the user as in the previous examples but determines that user's
        token requires re-synchronizing.

   3.   KDC constructs a PA-OTP-CHALLENGE as follows:

        nonce
           A randomly generated value.

        otp-service
           Set to a string that can be used by the client to assist the
           user in locating the correct token.

        otp-keyInfo
           Information about how the OTP should be generated from the
           token.

           flags
              must-encrypt-nonce, pin-required and nextOTP bits set

           supportedHashAlg
              AlgorithmIdentifiers for SHA-256 and SHA-1

           iterationCount
              1024

   4.   KDC returns a KRB-ERROR with an error code of
        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.

   5.   The client obtains the next OTP value from the token and records
        the time as reported by the token.

   6.   The client generates Client Key and Reply Key as described in
        Section 3.6 using SHA-256 from the list of algorithms sent by
        the KDC, the iteration count of 100,000 as required by local
        policy and a randomly generated nonce.



Richards                  Expires July 22, 2011                [Page 38]


Internet-Draft           OTP Pre-authentication             January 2011


   7.   The client constructs a PA-OTP-REQUEST as follows:

        flags
           nextOTP bit set

        nonce
           The randomly generated value.

        encData
           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
           under the Client Key with a key usage of
           KEY_USAGE_OTP_REQUEST and the encryption type of the Armor
           Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-
           OTP-CHALLENGE.

        hashAlg
           SHA-256

        iterationCount
           100,000

        otp-time
           The time used in the OTP calculation as reported by the OTP
           token.

   8.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req
        of a PA-FX-FAST-REQUEST.

   9.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
        REQUEST within the padata.

   10.  Authentication process now proceeds as with the classic
        sequence.


Author's Address

   Gareth Richards
   RSA, The Security Division of EMC
   RSA House
   Western Road
   Bracknell, Berkshire  RG12 1RT
   UK

   Email: gareth.richards@rsa.com






Richards                  Expires July 22, 2011                [Page 39]