Include <com_err.h>

[heimdal.git] / doc / standardisation / draft-richards-otp-kerberos-01.txt

Network Working Group                                        G. Richards
Internet-Draft                         RSA, The Security Division of EMC
Intended status: Standards Track                        October 11, 2006
Expires: April 14, 2007


                              OTP Kerberos
                     draft-richards-otp-kerberos-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 14, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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







Richards                 Expires April 14, 2007                 [Page 1]
\f
Internet-Draft                OTP Kerberos                  October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  3
     2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  4
   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  4
     3.1.  Shared Secret  . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Client Request . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  7
     3.6.  Updating the Secret  . . . . . . . . . . . . . . . . . . .  9
   4.  Reply Key Generation Algorithms  . . . . . . . . . . . . . . .  9
     4.1.  Using the OTP Value Directly . . . . . . . . . . . . . . .  9
     4.2.  Hardening the OTP Value  . . . . . . . . . . . . . . . . .  9
       4.2.1.  Using an Iteration Count . . . . . . . . . . . . . . . 10
       4.2.2.  Using a Shared Secret and OTP  . . . . . . . . . . . . 10
       4.2.3.  Using a Password and OTP . . . . . . . . . . . . . . . 11
     4.3.  Generating the Key without the OTP . . . . . . . . . . . . 11
       4.3.1.  Using the Password . . . . . . . . . . . . . . . . . . 11
       4.3.2.  Using a Shared Secret  . . . . . . . . . . . . . . . . 11
   5.  OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  PA-OTP-RESPONSE  . . . . . . . . . . . . . . . . . . . . . 13
     5.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16
     5.4.  PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.5.  OTPChalKeyParam  . . . . . . . . . . . . . . . . . . . . . 17
     5.6.  OTPRespKeyParam  . . . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     7.1.  Active attacks . . . . . . . . . . . . . . . . . . . . . . 19
     7.2.  Denial of service attacks  . . . . . . . . . . . . . . . . 19
     7.3.  Use of a Shared Secret Value . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22











Richards                 Expires April 14, 2007                 [Page 2]
\f
Internet-Draft                OTP Kerberos                  October 2006


1.  Introduction

   A One-Time Password (OTP) token may be a handheld hardware device, a
   hardware device connected to a personal computer through an
   electronic interface such as USB or a software module resident on a
   personal computer.  All these devices generate one-time passwords
   that may be used to authenticate a user towards some service.  This
   document describes extensions to Kerberos V5 [RFC4120] to support
   pre-authentication using an OTP.

   In this proposal, the KDC sends the client a random nonce,
   information on which OTP token is to be used, how the OTP is to be
   generated using that token and how the Reply Key is to be generated.
   The Reply Key is then used to encrypt the nonce value and the
   encrypted value is returned to the KDC as the pre-authentication
   data.  Depending on whether the KDC can obtain the OTP value, the OTP
   value is either used in the generation of the Reply Key or is
   encrypted using the key and returned to the KDC along with the
   encrypted nonce.  The encrypted nonce, an optional encrypted OTP
   value and information on how the Reply Key and OTP value were
   generated are sent to the KDC and used by the KDC to generate the
   same Reply Key and decrypt and verify the nonce.

   This proposal is partially based upon previous work on integrating
   single-use authentication mechanisms into Kerberos [HoReNeZo04] and
   uses the existing password-change extensions to handle PIN change as
   described in [RFC3244].

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

   << This is an early draft of this document and so is liable to change
   significantly. >>


2.  Usage Overview

2.1.  Pre-Authentication

   The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
   and KRB_ERROR.  The client begins by sending an initial KRB_AS_REQ to
   the KDC that may contain pre-authentication data such as the standard
   Kerberos password data.  The KDC will then determine, in an
   implementation dependent fashion, whether OTP authentication is
   required and if it is, it will respond with a KRB_ERROR message
   containing a PA-OTP-CHALLENGE in the PA-DATA.




Richards                 Expires April 14, 2007                 [Page 3]
\f
Internet-Draft                OTP Kerberos                  October 2006


   The PA-OTP-CHALLENGE contains information on how the OTP should be
   generated, how the Reply Key should be generated and a nonce.  The
   client uses this information to locate the token and generate the
   OTP, generate the Reply Key and then encrypt the nonce using the
   generated key.  Depending on the type of OTP, the Reply Key may be
   generated using the OTP value or alternatively, the generated OTP
   will instead be encrypted along with the nonce using the key.

   The encrypted nonce along with information on how the OTP and Reply
   Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA-
   DATA element.  The KDC then uses this information to generate the
   same key as the client, allowing it to verify the pre-authentication
   by decrypting the nonce.  If the validation succeeds then the KDC
   returns the TGT in a KRB_AS_REP.

2.2.  PIN Change

   If, following successful validation of a PA-OTP-RESPONSE in a
   KRB_AS_REQ, the KDC requires that the user changes their PIN then it
   will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
   This pre-auth data can be used to return a new PIN to the user if the
   KDC has updated the PIN or to indicate to the user that they must
   change their PIN.

   In the latter case, user PIN change shall be handled by a PIN change
   service supporting the ChangePasswdData in a KRB_AP_REQ as described
   in [RFC3244].  If such a user PIN change is required then the KDC
   SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
   only issues tickets for the PIN change service until the PIN has been
   changed.

2.3.  Re-Synchronization

   It is possible with time and event-based tokens, that the client and
   OTP server will loose synchronization.  If, when processing a PA-OTP-
   RESPONSE, the pre-authentication validation fails for this reason
   then the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
   CHALLENGE in the PA-DATA with the "nextOTP" flag set.  The setting of
   this flag will cause the client to re-try the authentication using
   the OTP for the next token "state".


3.  Pre-Authentication Protocol Details

3.1.  Shared Secret

   The method of deriving the Reply Key shall depend upon:




Richards                 Expires April 14, 2007                 [Page 4]
\f
Internet-Draft                OTP Kerberos                  October 2006


   o  Whether the OTP is of sufficiently high entropy to generate the
      key alone.

   o  Whether the OTP has insufficient entropy and so must be
      strengthened.

   o  Whether the OTP value used can be obtained by the KDC.

   If the OTP value is of low entropy then it is important to slow down
   an attacker sufficiently to make it economically unattractive to
   brute-force search for an OTP given an observed OTP-Kerberos
   exchange.  If the OTP value cannot be obtained by the KDC then it
   cannot be used in the derivation of the Reply Key but shall be
   encrypted using the generated key rather than used to derive the key
   and so the Reply Key must be derived from some other value.  Both of
   these issues can be solved using shared secret value known by the
   client and KDC but unknown to the attacker.

   This protocol supports the following types of secret:

   o  A pre-shared secret can be established between the client and KDC
      and stored on the client.

   o  Diffie-Hellman key agreement (as defined in [RFC2631]) can be used
      to establish a shared secret value ZZ.  The server's public key,
      and the base and prime are stored on the client.

   The pre-shared secret value or the Diffie-Hellman shared secret
   value, ZZ, are converted to a value of the required length for the
   encryption scheme's random-to-key function using the n-fold function
   (both defined in [RFC3961]).

3.2.  Client Request

   The client begins by sending an initial KRB_AS_REQ possibly
   containing other pre-authentication data.  If the KDC determines that
   OTP-based pre-authentication is required and the request does not
   contain a PA-OTP-RESPONSE then it will respond as described in
   Section 3.3.

   Alternatively, if the client has all the necessary information, it
   MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and
   include it in the initial request.

3.3.  KDC Challenge

   If the user is required to authenticate using an OTP then the KDC
   SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:



Richards                 Expires April 14, 2007                 [Page 5]
\f
Internet-Draft                OTP Kerberos                  October 2006


   o  An error code of KDC_ERR_PREAUTH_REQUIRED

   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.

   The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by
   the generated Reply Key and it MAY also contain information on how
   the OTP value is to be generated and information on how the Reply Key
   is to be generated in an otp-keyParam element.

   Use of the otp-keyParam element is OPTIONAL.  If it is not present
   the Reply Key SHALL be generated directly from the OTP value as
   specified in Section 4.1 and the OTP value SHALL NOT be included in
   the client response.

   If the otp-keyParam element is present and the "sendOTP" flag is set
   then the OTP value MUST NOT be used in the generation of the Reply
   Key but it must instead be returned to the KDC encrypted using the
   key.  The Reply Key MUST be derived using one of the methods
   described in Section 4.3.  If the "sendOTP" flag is not set then the
   OTP value is to be used in the key derivation then the client MUST
   use one of the methods described in Section 4.2.

   The otp-keyParam element will control the use of a shared secret in
   the key derivation.  If the "noSecret" flag is set the the client
   MUST NOT use a secret value in the key derivation.  If the "noSecret"
   flag is not set and secret identifier is present then the client MUST
   NOT use any other secret value.  If the "noSecret" flag is not set
   and a secret identifier is not present then the client MAY still use
   a value if there is a value associated with the KDC.

   If the "noSecret" flag is not set and the client can locate a secret
   value for the KDC then the Reply Key will be generated using one of
   the following methods:

   o  If the OTP is to be included in the key derivation then the key
      SHALL be derived as specified in Section 4.2.2.

   o  If the OTP is to be sent encrypted in the response then the key
      SHALL be derived as specified in Section 4.3.2.

   If the client fails to find a shared secret for the KDC or the
   "noSecret" flag was set in the challenge then the Reply Key will be
   generated using one of the following methods:

   o  If the OTP is to be used in the key derivation then the KDC MAY
      specify an iteration count.  If such a value is specified then the
      key SHALL be derived from the OTP as described in Section 4.2.1.




Richards                 Expires April 14, 2007                 [Page 6]
\f
Internet-Draft                OTP Kerberos                  October 2006


   o  If the OTP is to be used in the key derivation but an iteration
      count was not specified then the key SHALL be derived from the OTP
      value and the user's Kerberos password as described in
      Section 4.2.3.

   o  If the OTP is to be sent encrypted then the key SHALL be derived
      from the user's Kerberos password as described in section
      Section 4.3.1.

3.4.  Client Response

   The client will use the generated Reply Key to encrypt the nonce from
   the KDC challenge and, if required, to encrypt the OTP value.  This
   encrypted data SHALL be sent to the KDC in the otp-encData of a PA-
   OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ.

   This response MAY also include information on how the Reply Key was
   generated in an optional otp-keyParam element.  The client MUST NOT
   include this element if the Reply Key was generated directly from the
   OTP value.  The element MUST be included if the Reply Key was
   generated using either a secret value or an iteration count and
   contain the secret identifier and iteration count value.  If the
   Reply Key was generated using a password then the element MUST be
   present and MUST be empty.

   The response SHOULD also include information on the generated OTP
   value.

3.5.  Verifying the pre-auth Data

   If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use
   the information in the otp-keyParam to generate the same Reply Key
   and decrypt the encrypted nonce contained in the otp-encData.

   If the encrypted OTP value is not included in the otp-encData then
   the Reply Key was generated using the OTP value.  The KDC SHALL
   therefore use the OTP information in the PA-OTP-RESPONSE to obtain
   the OTP value for the user and use the value along with the
   information in the otp-keyParam to generate the Reply Key. This
   information SHALL be used as follows:

   o  If the otp-keyParam is not present then the Reply Key SHALL be
      generated directly from the OTP value as described in Section 4.1.

   o  If the otp-keyParam is present but empty then the Reply Key SHALL
      be generated using the OTP value and the user's Kerberos Password
      as described in Section 4.2.3.




Richards                 Expires April 14, 2007                 [Page 7]
\f
Internet-Draft                OTP Kerberos                  October 2006


   o  If the otp-keyParam is present and contains a secret identifier
      then the Reply Key SHALL be generated using the OTP value and the
      secret value as described in Section 4.2.2.

      If the identified secret value can not be found then the KDC SHALL
      respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
      but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.

   o  if the otp-keyParam is present and contains an iteration count
      then the Reply Key shall be generated from the OTP value using the
      iteration count value as described in Section 4.2.1.

   If the encrypted OTP value is included in the otp-encData then the
   Reply Key was not generated using the OTP value but was instead used
   to encrypt the OTP value.  The KDC SHALL therefore use the
   information in the otp-keyParam to generate the Reply Key and decrypt
   the OTP value.  It SHALL then validate the decrypted value using the
   OTP information included in the response and fail the authentication
   if the value is not valid.

   This Reply Key SHALL be generated as follows:

   o  If the otp-keyParam is not present the the KDC SHALL fail the pre-
      authentication with an error of KDC_ERR_PREAUTH_FAILED.

      If the otp-keyParam is omitted then the Reply Key was generated
      directly from the OTP value and so is an error if the OTP value is
      encrypted using the key.

   o  If the otp-keyParam is present but empty then the Reply Key SHALL
      be generated using the user's Kerberos Password as described in
      Section 4.3.1.

   o  If the otp-keyParam is present and contains a secret identifier
      then the Reply Key SHALL be generated using the secret value as
      described in Section 4.3.2.

      If the identified secret value can not be found then the KDC SHALL
      respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
      but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.

   o  If the otp-keyParam is present and contains an iteration count
      then the KDC SHALL fail the authentication with an error of
      KDC_ERR_PREAUTH_FAILED.







Richards                 Expires April 14, 2007                 [Page 8]
\f
Internet-Draft                OTP Kerberos                  October 2006


3.6.  Updating the Secret

   The secret value can be pre-configured on the client but MAY also be
   transferred from the KDC to the client in encrypted form in the PA-
   OTP-CONFIRM of the KRB_AS_REP.  If a client receives a new secret
   value in this way then it MUST update any stored value associated
   with the KDC.


4.  Reply Key Generation Algorithms

4.1.  Using the OTP Value Directly

   If only the OTP value is to be used then the Reply Key SHALL be
   generated by passing the OTP value through string-to-key (defined in
   [RFC3961]).

             K = string-to-key(OTP)

   The salt and additional parameters for string-to-key will be as
   defined in section 3.1.3 of [RFC4120].

4.2.  Hardening the OTP Value

   If the OTP value requires strengthening then several methods shall be
   supported.

   o  The OTP can be used on its own in the key derivation but run
      through an iteration process many times as described in
      Section 4.2.1.

   o  A secret value, shared between the KDC and client can be used
      along with the OTP value to derive the key as described in
      Section 4.2.2.

   o  The user's Kerberos password can be used along with the OTP value
      in the key derivation as described in Section 4.2.3.

   A shared secret can only be used if the client supports the storing
   of persistent values and has such a value stored.  The other two
   methods could be used to establish a secret value or when client are
   not capable of storing such values.

   <<Is there value in another mode which uses the Kerberos password in
   conjunction with an iteration-hardened OTP value?>>






Richards                 Expires April 14, 2007                 [Page 9]
\f
Internet-Draft                OTP Kerberos                  October 2006


4.2.1.  Using an Iteration Count

   An initial key is generated by running the OTP value through string-
   to-key.

             K = string-to-key(OTP)

   The following key generation process is then repeated iteration count
   times with the resulting key being used as the protocol key for the
   next iteration.

   A sequence of octets, R, is produced from K by iterating over calls
   to the function pseudo-random (defined in [RFC3961]) and appending
   the results until at least the number of bits required by random-to-
   key have been produced.  If the result of the iteration is longer
   than the required length then the result shall be truncated.

   The octet string parameter for pseudo-random shall be the ASCII
   string "CombineA" with the loop number appended.  This string has the
   following byte value:

      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}

   A new key is then generated by running R through random-to-key.

             K = random-to-key(R)

4.2.2.  Using a Shared Secret and OTP

   Two intermediate keys, K1 and K2, shall be generated by running the
   OTP value once through string-to-key and the shared secret through
   random-to-key.

             K1 = random-to-key(shared secret)
             K2 = string-to-key(OTP)

   Two sequences of octets, R1 and R2, are then produced from K1 and K2
   by iterating over calls to pseudo-random and appending the results
   until the required number of bits have been generated for random-to-
   key.  If the result of the iteration is longer than the required
   length then the result shall be truncated.

   The octet string parameter for pseudo-random shall be the ASCII
   string "CombineA" for K1 and "CombineB" for K2 with the loop number
   appended.  These have the following byte values:






Richards                 Expires April 14, 2007                [Page 10]
\f
Internet-Draft                OTP Kerberos                  October 2006


      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42}

   The final key is then generated by combining R1 and R2 using
   exclusive-OR and running the result through random-to-key.

             K = random-to-key(R1 ^ R2)

   << Check on issue around combining DES keys. >>

4.2.3.  Using a Password and OTP

   Two intermediate keys, K1 and K2, shall be generated by running the
   OTP and password through string-to-key.

             K1 = string-to-key(Password)
             K2 = string-to-key(OTP)

   The same process as described in Section 4.2.2 is then used to derive
   the final reply key.

4.3.  Generating the Key without the OTP

   If the OTP value cannot be used in the derivation of the reply key
   then this protocol supports the following options:

   o  A secret value, shared between the KDC and client can be used to
      derive the key as described in Section 4.3.2.

   o  The user's Kerberos password can be used in the key derivation as
      described in Section 4.3.1.

   A shared secret can only be used if the client supports the storing
   of persistent values and has such a value stored.  The password-only
   method could be used to establish a secret value or when clients are
   not capable of storing such values.

4.3.1.  Using the Password

   The Reply Key SHALL be generated by passing the password value
   through string-to-key (defined in [RFC3961]).

4.3.2.  Using a Shared Secret

   The reply key shall be generated by running the shared secret value
   through random-to-key.

             K = random-to-key(shared secret)



Richards                 Expires April 14, 2007                [Page 11]
\f
Internet-Draft                OTP Kerberos                  October 2006


5.  OTP Kerberos Types

5.1.  PA-OTP-CHALLENGE

   This is a pre-authentication type sent by the KDC to the client in a
   KRB_ERROR.  It contains information for the client on how to generate
   the OTP and reply key.

             PA-OTP-CHALLENGE ::= SEQUENCE {
               otp-flags         OTPFlags,
               otp-nonce         UInt32,
               otp-etype         INTEGER,
               otp-track-id  [0] OCTET STRING    OPTIONAL,
               otp-challenge [1] OCTET STRING    OPTIONAL,
               otp-length    [2] INTEGER         OPTIONAL,
               otp-service   [3] UTF8String      OPTIONAL,
               otp-keyID     [4] OCTET STRING    OPTIONAL,
               otp-algID     [5] INTEGER         OPTIONAL,
               otp-keyParam  [6] OTPChalKeyParam OPTIONAL
             }

             OTPFlags ::= KerberosFlags
             -- nextOTP (0)

   otp-flags
      If the "nextOTP" flag is set then the OTP calculated SHALL be
      based on the next token "state" rather than the current one.  As
      an example, for a time-based token, this means the next time slot.
      For an event-based token, this could mean the next counter value,
      if counter values are used.

   otp-nonce
      A KDC-supplied nonce value to be encrypted by the client in the
      PA-OTP-RESPONSE.

   otp-etype
      The encryption type to be used by the client for all encrypted
      fields in the PA-OTP-RESPONSE.

   otp-track-id
      This optional element is used by the KDC to link a client response
      to the corresponding KDC challenge.  If present, this element MUST
      be copied by the client to the corresponding element in the PA-
      OTP-RESPONSE.







Richards                 Expires April 14, 2007                [Page 12]
\f
Internet-Draft                OTP Kerberos                  October 2006


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

   otp-length
      The otp-length is used by the KDC to specify the desired length of
      the generated OTP.

   otp-service
      An identifier of the service supported by the KDC.  This value can
      be used by the client to locate information such as the shared
      secret value and OTP key to use.

   otp-keyID
      The identifier of the OTP key to be used in the OTP calculation.
      If this value is not present then the client SHOULD use other
      values such as the otp-service and otp-algID to locate the
      appropriate key.

   otp-algID
      The identifier of the algorithm to use when generating the OTP.

   otp-keyParam
      Information on how the Reply Key should be generated from the OTP
      and shared secret.  If the value is not present then the reply key
      MUST be generated directly from the OTP value.

   <<TBD: Should a checksum be added to allow the client to verify the
   challenge?>>

5.2.  PA-OTP-RESPONSE

   This is a pre-authentication type sent by the client to the KDC in a
   KRB_AS_REQ containing the encrypted pre-authentication data.  It
   contains information on the OTP used and how the key was generated
   that encrypts the pre-authentication data.  This information will
   then allow the KDC to generate the same key and validate the pre-
   authentication data.





Richards                 Expires April 14, 2007                [Page 13]
\f
Internet-Draft                OTP Kerberos                  October 2006


             PA-OTP-RESPONSE ::= SEQUENCE {
               otp-flags         OTPFlags,
               otp-nonce         UInt32,
               otp-encData       EncryptedData,
                                      -- PA-ENC-RESPONSE
                                      -- Key usage of <<TBD>>
               otp-track-id  [0] OCTET STRING    OPTIONAL,
               otp-challenge [1] OCTET STRING    OPTIONAL,
               otp-time      [2] KerberosTime    OPTIONAL,
               otp-counter   [3] OCTET STRING    OPTIONAL,
               otp-format    [4] OTPFormat       OPTIONAL,
               otp-keyID     [5] OCTET STRING    OPTIONAL,
               otp-keyParam  [6] OTPRespKeyParam OPTIONAL
             }



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



             PA-ENC-RESPONSE ::= SEQUENCE {
               nonce     OCTET STRING OPTIONAL,
               otp   [0] OCTET STRING OPTIONAL
             }

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

   otp-nonce
      The nonce value encrypted in the otp-encData.  If the PA-OTP-
      RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value
      MUST be a copy of the corresponding value in the challenge.  If no
      challenge was received then the nonce value MUST be generated by
      the client.








Richards                 Expires April 14, 2007                [Page 14]
\f
Internet-Draft                OTP Kerberos                  October 2006


   otp-track-id
      This element MUST be included if and only if an otp-track-id was
      included in the corresponding PA-OTP-CHALLENGE.  If included, then
      the value MUST be copied from the PA-OTP-CHALLENGE.

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

   otp-time
      Value used by the client to send the time used in the OTP
      calculation.

   otp-counter
      The counter value used in the OTP calculation.  Use of this
      element is OPTIONAL but it MAY be used by a client to simplify the
      OTP calculations of the KDC to contain the counter value as
      reported by the OTP token.

   otp-format
      The format of the generated OTP.

   otp-keyID
      The identifier of the OTP key used.

   otp-keyParam
      Information on how the reply key was generated from the OTP and
      shared secret.  If the value is not present then the reply key was
      generated directly from the OTP value.

   otp-encData
      The otp-encData field contains the result of the pre-
      authentication process and is encrypted using the generated Reply
      Key. The fields of this element are populated as follows:

      nonce
         The value of otp-nonce.

      otp
         The generated OTP value.  Present if the "sendOTP" flag is set
         in the challenge.

   <<TBD: Does the response need something such as an encrypted
   timestamp to protect against replay?>>





Richards                 Expires April 14, 2007                [Page 15]
\f
Internet-Draft                OTP Kerberos                  October 2006


5.3.  PA-OTP-CONFIRM

   This is a pre-authentication type returned by the KDC in a KRB_AS_REP
   if the client requires a new shared secret value.  The value is
   encrypted as described in section 5.2.9 of [RFC4120] using the
   current reply key as derived by the KDC from the OTP.

             PA-OTP-CONFIRM ::= SEQUENCE {
               identifier      OCTET STRING,
               newSecretValue  EncryptedData  -- OTPNewSecret
                                              -- Key usage of <<TBD>>
             }

             OTPNewSecret ::= CHOICE {
               sharedSecret [0] OCTET STRING,
               dhParams     [1] DHParam
             }

             DHParam ::= SEQUENCE {
               dhParameter DHParameter,
               dhPublic    INTEGER
             }

   identifier
      An octet string identifying the new secret value.

   newSecretValue
      The new secret data encrypted using the current Reply Key. The
      encrypted data can be of one of the following types:

      sharedSecret
         A random bit string.

      dhParams
         A Diffie-Hellman public value, prime and modulus.

5.4.  PA-ENC-PIN

   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
   user must change their PIN or if the user's PIN has been changed.











Richards                 Expires April 14, 2007                [Page 16]
\f
Internet-Draft                OTP Kerberos                  October 2006


             PA-ENC-PIN     ::= EncryptedData -- PA-ENC-PIN-ENC
                                              -- Key usage of <<TBD>>
             PA-ENC-PIN-ENC ::= SEQUENCE {
               flags         PinFlags,
               pin       [0] UTF8String OPTIONAL,
               minLength [1] INTEGER    OPTIONAL,
               maxLength [2] INTEGER    OPTIONAL
             }

             PinFlags ::= KerberosFlags
               -- systemSetPin (0)

   If the "systemSetPin" flag is set then the user's PIN has been
   changed and the new PIN value is contained in the pin field.  The PIN
   field MUST therefore be present.

   If the "systemSetPin" flag is not set then the user's PIN has not
   been changed by the server but it MUST instead be changed by the user
   using the PIN change service.  Restrictions on the size of the PIN
   MAY be given by the minLength and maxLength fields.  If the pin field
   is present then it contains a PIN value that MAY be used by the user
   when changing the PIN.  The KDC MAY only issue tickets for the PIN
   change service until the PIN has been changed.

5.5.  OTPChalKeyParam

   This data type can optionally be included by the KDC in a PA-OTP-
   CHALLENGE to instruct the client on how to generate the reply key.

   This value is included in the challenge if the OTP generated by the
   token is too weak to be used alone in the generation of the key.

             OTPChalKeyParam ::= SEQUENCE {
               flags              ChallengeFlags,
               identifer      [0] OCTET STRING OPTIONAL,
               iterationCount [1] INTEGER OPTIONAL
             }

             ChallengeFlags ::= KerberosFlags
               -- sendOTP  (0)
               -- noSecret (1)

   flags
      Flags controlling the generation of the Reply Key.







Richards                 Expires April 14, 2007                [Page 17]
\f
Internet-Draft                OTP Kerberos                  October 2006


      sendOTP
         If the "sendOTP" flag is set then the client MUST NOT use the
         OTP value to generate the reply key.  It must instead use the
         generated key to encrypt the OTP value and include the
         encrypted value in the PA-OTP-RESPONSE.

      noSecret
         If the "noSecret" flag is set then the client MUST NOT use any
         stored secret value in the derivation of the Reply Key. If the
         "sendOTP" flag is also set then the Kerberos password MUST be
         used.  If the "sendOTP" flag is not set then the iteration
         count MUST be used if it is present or the Kerberos password
         MUST be used if the iteration count is not specified.

   identifier
      Name of the secret that the client SHOULD use to generate the
      reply key.

      If a secret is specified but cannot be located by the client and
      an iteration count is specified then the client should generate
      the key using the iteration count.  If a secret value is specified
      and cannot be located and an iteration count is not specified then
      the reply key MUST be generated using the user's Kerberos
      password.

   iterationCount
      This value contains the iteration count to use when the generated
      OTP value is used in the derivation of the reply key.  This value
      is used by the client if a shared secret is not specified or is
      specified but cannot be found.  The value has no meaning if the
      "sendOTP" flag is set.

5.6.  OTPRespKeyParam

   This data type can optionally be included by the client in a PA-OTP-
   RESPONSE to inform the KDC of how the reply key was generated.

             OTPRespKeyParam ::= SEQUENCE {
               iterationCount [0] INTEGER OPTIONAL,
               secret SEQUENCE {
                 identifier       OCTET STRING,
                 dhPublic     [1] INTEGER OPTIONAL
               }
             }







Richards                 Expires April 14, 2007                [Page 18]
\f
Internet-Draft                OTP Kerberos                  October 2006


   iterationCount
      The actual value of the iteration count used by the client in the
      key derivation.  If omitted then no iteration was used in the
      derivation of the reply key.

   secret
      Information on the secret used in the key derivation.  If this
      value is omitted then no shared secret was used.

      identifier
         An octet string identifying the shared secret value used by the
         client in the key derivation.
      dhPublic
         The client's Diffie-Hellman public key.  Present only if a
         Diffie-Hellman secret was used.


6.  IANA Considerations

   A registry may be required for the otp-AlgID values as introduced in
   Section 5.1.  No other IANA actions are anticipated.


7.  Security Considerations

7.1.  Active attacks

   <<TBS >>

7.2.  Denial of service attacks

   An active attacker may replace the iteration count value in the PA-
   OTP-RESPONSE sent by the client to slow down an authentication
   server.  Authentication servers SHOULD protect against this, e.g. by
   disregarding PA-OTP-RESPONSE elements with an iteration count value
   higher than some pre- or dynamically- (depending on load) set number.

7.3.  Use of a Shared Secret Value

   As described in Section 3.1, the use of a shared secret value will
   slow down an attacker's search for a matching OTP.  The ability to
   transfer such a value in encrypted form from the KDC to the client
   means that, even though there may be an initial computational cost
   for the KDC to authenticate the user if an iteration count is used,
   subsequent authentications will be efficient, while at the same time
   more secure, since a pre-shared, value will not be easily found by an
   attacker.




Richards                 Expires April 14, 2007                [Page 19]
\f
Internet-Draft                OTP Kerberos                  October 2006


   If a client does not have a pre-configured secret value for a KDC
   then it will have to generate the Reply Key using an iteration count
   or the Kerberos password.  If an iteration count is used then an
   attacker observing such a KRB_AS_REQ may, depending on available
   resources, be able to successfully attack that request.  Once the
   correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
   will potentially give the attacker access to the server-provided
   secret value.  For this reason, initial exchanges with KDC servers
   SHOULD occur in a secure environment and the lifetime of this value
   must also be calculated with this in mind.  Finally, the value MUST
   be securely stored by the client and the KDC, associated with the
   user.


8.  References

8.1.  Normative References

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

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2631, June 1999.

   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
              2000 Kerberos Change Password and Set Password Protocols",
              RFC 3244, February 2002.

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, February 2005.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

8.2.  Informative References

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









Richards                 Expires April 14, 2007                [Page 20]
\f
Internet-Draft                OTP Kerberos                  October 2006


Author's Address

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

   Email: grichards@rsa.com









































Richards                 Expires April 14, 2007                [Page 21]
\f
Internet-Draft                OTP Kerberos                  October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Richards                 Expires April 14, 2007                [Page 22]
\f