home *** CD-ROM | disk | FTP | other *** search
/ ftp.rsa.com / 2014.05.ftp.rsa.com.tar / ftp.rsa.com / pub / otps / kerberos / draft-ietf-krb-wg-otp-preauth-06.txt < prev    next >
Text File  |  2014-05-02  |  75KB  |  1,961 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                        G. Richards
  5. Internet-Draft                         RSA, The Security Division of EMC
  6. Intended status: Standards Track                       September 4, 2008
  7. Expires: March 8, 2009
  8.  
  9.  
  10.                          OTP Pre-authentication
  11.                     draft-ietf-krb-wg-otp-preauth-06
  12.  
  13. Status of this Memo
  14.  
  15.    By submitting this Internet-Draft, each author represents that any
  16.    applicable patent or other IPR claims of which he or she is aware
  17.    have been or will be disclosed, and any of which he or she becomes
  18.    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19.  
  20.    Internet-Drafts are working documents of the Internet Engineering
  21.    Task Force (IETF), its areas, and its working groups.  Note that
  22.    other groups may also distribute working documents as Internet-
  23.    Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six months
  26.    and may be updated, replaced, or obsoleted by other documents at any
  27.    time.  It is inappropriate to use Internet-Drafts as reference
  28.    material or to cite them other than as "work in progress."
  29.  
  30.    The list of current Internet-Drafts can be accessed at
  31.    http://www.ietf.org/ietf/1id-abstracts.txt.
  32.  
  33.    The list of Internet-Draft Shadow Directories can be accessed at
  34.    http://www.ietf.org/shadow.html.
  35.  
  36.    This Internet-Draft will expire on March 8, 2009.
  37.  
  38. Abstract
  39.  
  40.    The Kerberos protocol provides a framework authenticating a client
  41.    using the exchange of pre-authentication data.  This document
  42.    describes the use of this framework to carry out One Time Password
  43.    (OTP) authentication.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Richards                  Expires March 8, 2009                 [Page 1]
  56.  
  57. Internet-Draft           OTP Pre-authentication           September 2008
  58.  
  59.  
  60. Table of Contents
  61.  
  62.    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63.      1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  64.      1.2.  Overall Design . . . . . . . . . . . . . . . . . . . . . .  3
  65.      1.3.  Conventions Used in this Document  . . . . . . . . . . . .  4
  66.    2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  4
  67.      2.1.  OTP Mechanism Support  . . . . . . . . . . . . . . . . . .  4
  68.      2.2.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  4
  69.      2.3.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  5
  70.      2.4.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  6
  71.    3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  6
  72.      3.1.  Initial Client Request . . . . . . . . . . . . . . . . . .  7
  73.      3.2.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  7
  74.      3.3.  Client Response  . . . . . . . . . . . . . . . . . . . . .  8
  75.      3.4.  Verifying the pre-auth Data  . . . . . . . . . . . . . . . 10
  76.      3.5.  Confirming the Reply Key Change  . . . . . . . . . . . . . 11
  77.      3.6.  Reply Key Generation . . . . . . . . . . . . . . . . . . . 11
  78.    4.  OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 13
  79.      4.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 13
  80.      4.2.  PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 16
  81.      4.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 19
  82.      4.4.  PA-OTP-PIN-CHANGE  . . . . . . . . . . . . . . . . . . . . 19
  83.    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
  84.    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
  85.      6.1.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . . . 20
  86.      6.2.  Reflection . . . . . . . . . . . . . . . . . . . . . . . . 21
  87.      6.3.  Denial of Service  . . . . . . . . . . . . . . . . . . . . 21
  88.      6.4.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 21
  89.      6.5.  Brute Force Attack . . . . . . . . . . . . . . . . . . . . 22
  90.      6.6.  FAST Facilities  . . . . . . . . . . . . . . . . . . . . . 22
  91.    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
  92.    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
  93.      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
  94.      8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
  95.    Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 24
  96.    Appendix B.  Examples of OTP Pre-Authentication Exchanges  . . . . 26
  97.      B.1.  Four Pass Authentication . . . . . . . . . . . . . . . . . 26
  98.      B.2.  Two Pass Authentication  . . . . . . . . . . . . . . . . . 29
  99.      B.3.  Pin Change . . . . . . . . . . . . . . . . . . . . . . . . 31
  100.      B.4.  Resynchronization  . . . . . . . . . . . . . . . . . . . . 32
  101.    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
  102.    Intellectual Property and Copyright Statements . . . . . . . . . . 35
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. Richards                  Expires March 8, 2009                 [Page 2]
  112.  
  113. Internet-Draft           OTP Pre-authentication           September 2008
  114.  
  115.  
  116. 1.  Introduction
  117.  
  118. 1.1.  Scope
  119.  
  120.    This document describes a FAST [ZhHa08] factor that allows One-Time
  121.    Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-
  122.    authentication in a manner that does not require use of the user's
  123.    Kerberos password.  The system is designed to work with different
  124.    types of OTP algorithms such as time-based OTPs [RFC2808], counter-
  125.    based tokens [RFC4226] and challenge-response systems such as
  126.    [RFC2289].  It is also designed to work with tokens that are
  127.    electronically connected to the user's computer via means such as a
  128.    USB interface.
  129.  
  130.    This FAST factor provides the following facilities (as defined in
  131.    [ZhHa08]): client-authentication, replacing-reply-key and KDC-
  132.    authentication.  It does not provide the strengthening-reply-key
  133.    facility.
  134.  
  135.    This proposal is partially based upon previous work on integrating
  136.    single-use authentication mechanisms into Kerberos [HoReNeZo04] and
  137.    allows for the use of the existing password-change extensions to
  138.    handle PIN change as described in [RFC3244].
  139.  
  140. 1.2.  Overall Design
  141.  
  142.    This proposal supports 4-pass and 2-pass variants.  In the 4-pass
  143.    system, the client sends the KDC an initial AS-REQ and the KDC
  144.    responds with a KRB-ERROR containing padata that includes a random
  145.    nonce.  The client then encrypts the nonce and returns it, along with
  146.    its own random value, to the KDC in a second AS-REQ.  Finally, the
  147.    KDC returns the client's random value encrypted within the padata of
  148.    the AS-REP.  Note that this variant can only be used for users that
  149.    require pre-authentication.  In the 2-pass variant, the client
  150.    encrypts a timestamp rather than a nonce from the KDC and the
  151.    encrypted data is sent to the KDC in the initial AS-REQ.  This
  152.    variant can be used in cases where the client can determine in
  153.    advance that OTP pre-authentication is supported by the KDC, which
  154.    OTP key should be used and the encryption parameters required by the
  155.    KDC.
  156.  
  157.    In both systems, in order to create the message sent to the KDC, the
  158.    client must generate the OTP value and two keys: the standard Reply
  159.    Key used to decrypt the KDC's reply and a key to encrypt the data
  160.    sent to the KDC.  In most cases, the OTP value will be used in the
  161.    key generation but in order to support algorithms where the KDC
  162.    cannot obtain the value (e.g.  [RFC2289]), the system also supports
  163.    the option of including the OTP value in the request along with the
  164.  
  165.  
  166.  
  167. Richards                  Expires March 8, 2009                 [Page 3]
  168.  
  169. Internet-Draft           OTP Pre-authentication           September 2008
  170.  
  171.  
  172.    encrypted nonce.  In addition, in order to support situations where
  173.    the KDC is unable to obtain the plaintext OTP value, the system also
  174.    supports the use of hashed OTP values in the key derivation.
  175.  
  176.    The preauth data sent from the client to the KDC is sent within the
  177.    encrypted data provided by the FAST padata type of the AS-REQ.  The
  178.    KDC then obtains the OTP value, generates the same keys and verifies
  179.    the pre-authentication data by decrypting the nonce.  If the
  180.    verification succeeds then it confirms knowledge of the Reply Key by
  181.    returning the client's nonce encrypted under one the generated Reply
  182.    Key within the encrypted part of the FAST padata of the AS-REP.
  183.  
  184. 1.3.  Conventions Used in this Document
  185.  
  186.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  187.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  188.    document are to be interpreted as described in [RFC2119].
  189.  
  190.    This document assumes familiarity with the Kerberos pre-
  191.    authentication framework [ZhHa08] and so freely uses terminology and
  192.    notation from this document.
  193.  
  194.    The word padata is used as shorthand for pre-authentication data.
  195.  
  196.  
  197. 2.  Usage Overview
  198.  
  199. 2.1.  OTP Mechanism Support
  200.  
  201.    As described above, this document describes a generic system for
  202.    supporting different OTP mechanisms in Kerberos pre-authentication.
  203.    However, to ensure interoperability, all implementations of this
  204.    specification SHOULD provide a mechanism for OTP mechanism support to
  205.    be added or removed.
  206.  
  207. 2.2.  Pre-Authentication
  208.  
  209.    The approach uses pre-authentication data in AS-REQ, AS-REP and KRB-
  210.    ERROR messages.
  211.  
  212.    In the 4-pass system, the client begins by sending an initial AS-REQ
  213.    to the KDC that may contain pre-authentication data such as the
  214.    standard Kerberos password data.  The KDC will then determine, in an
  215.    implementation dependent fashion, whether OTP authentication is
  216.    required and if it is, it will respond with a KRB-ERROR message
  217.    containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA.
  218.  
  219.    The PA-OTP-CHALLENGE will contain a KDC generated nonce, an
  220.  
  221.  
  222.  
  223. Richards                  Expires March 8, 2009                 [Page 4]
  224.  
  225. Internet-Draft           OTP Pre-authentication           September 2008
  226.  
  227.  
  228.    encryption type, an optional list of hash algorithm identifiers, an
  229.    optional iteration count and optional information on how the OTP
  230.    should be generated by the client.  The client will then generate the
  231.    OTP value, its own nonce and two keys: a Client Key to encrypt the
  232.    KDC's nonce and a Reply Key used to decrypt the KDC's reply.
  233.  
  234.    As described in section 6.5.1 of [ZhHa08], the FAST system uses an
  235.    Armor Key to set up an encrypted tunnel for use by FAST factors.  As
  236.    described in Section 3.6, the Client Key and Reply Key will be
  237.    generated from the Armor Key and the OTP value unless the OTP
  238.    algorithm does not allow the KDC to obtain the OTP value.  If hash
  239.    algorithm identifiers were included in the PA-OTP-CHALLENGE then the
  240.    client will use the hash of the OTP value rather than the plaintext
  241.    value in the key generation.
  242.  
  243.    The generated Client Key will be used to encrypt the nonce received
  244.    from the KDC using the specified encryption type.  The encrypted
  245.    value, a random nonce generated by the client along with optional
  246.    information on how the OTP was generated are then sent to the KDC in
  247.    a PA-OTP-REQUEST (see Section 4.2) encrypted within the armored-data
  248.    of a PA-FX-FAST-REQUEST PA-DATA element of a second AS-REQ.
  249.  
  250.    In the 2-pass system, the client sends the PA-OTP-REQUEST in the
  251.    initial AS-REQ instead of sending it in response to a PA-OTP-
  252.    CHALLENGE returned by the KDC.  Since no challenge is received from
  253.    the KDC, the client includes an encrypted timestamp in the request
  254.    rather than the encrypted KDC nonce.
  255.  
  256.    In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the
  257.    keys in the same way as the client, and uses the generated Client Key
  258.    to verify the pre-authentication by decrypting the encrypted data
  259.    sent by the client (either nonce or timestamp).  If the validation
  260.    succeeds then the KDC will authenticate itself to the client and
  261.    confirm that the Reply Key has been updated by encrypting the
  262.    client's nonce under the Reply Key and returning the encrypted value
  263.    in the encData of a PA-OTP-CONFIRM (see Section 4.3).  The PA-OTP-
  264.    CONFIRM is encrypted within the armored-data of a PA-FX-FAST-REPLY
  265.    PA-DATA element of the AS-REP as described in [ZhHa08].
  266.  
  267. 2.3.  PIN Change
  268.  
  269.    Most OTP tokens involve the use of a PIN in the generation of the OTP
  270.    value.  This PIN value will be entered by the user on the client and
  271.    combined with the value produced by the token in a manner specific to
  272.    the algorithm to generate the final OTP value that will be used in
  273.    this protocol.
  274.  
  275.    If, following successful validation of a PA-OTP-REQUEST in a AS-REQ,
  276.  
  277.  
  278.  
  279. Richards                  Expires March 8, 2009                 [Page 5]
  280.  
  281. Internet-Draft           OTP Pre-authentication           September 2008
  282.  
  283.  
  284.    the KDC requires that the user changes their PIN then it will include
  285.    a PA-OTP-PIN-CHANGE (see Section 4.4) encrypted within the armored
  286.    data of the PA-FX-FAST-REPLY PA-DATA element of the AS-REP.  This
  287.    data can be used to return a new PIN to the user if the KDC has
  288.    updated the PIN or to indicate to the user that they must change
  289.    their PIN.
  290.  
  291.    In the user is required to change their PIN then it is recommended
  292.    that user PIN change be handled by a PIN-change service supporting
  293.    the ChangePasswdData in a AP-REQ as described in [RFC3244].  If such
  294.    a service is used then the KDC MUST NOT return a TGT when the user is
  295.    authenticated and user PIN change is required, the KDC SHOULD instead
  296.    return a service ticket to the PIN-change service, in order for the
  297.    client to compute an AP-REQ according to [RFC3244].  In order to
  298.    complicate stealing service tickets intended for the PIN-change
  299.    service (and the corresponding session keys), the lifetime of the
  300.    PIN-change service tickets should be just long enough to complete the
  301.    PIN change, regardless whether the existing PIN needs to be changed
  302.    or not.  A 1-minute lifetime is RECOMMENDED.  This way the PIN change
  303.    service can effectively force the user to present the existing PIN in
  304.    order to change to use a new PIN.
  305.  
  306.    If the user's PIN has been changed and the KDC is returning the new
  307.    value to the user then no such restrictions are required and the KDC
  308.    SHOULD return a standard TGT.
  309.  
  310. 2.4.  Re-Synchronization
  311.  
  312.    It is possible with time and event-based tokens that the OTP server
  313.    will lose synchronization with the current token state.  For example,
  314.    event-based tokens may drift since the counter on the token is
  315.    incremented every time the token is used but the counter on the
  316.    server is only incremented on an authentication.  Similarly, the
  317.    clocks on time-based tokens may drift.
  318.  
  319.    If, when processing a PA-OTP-REQUEST, the pre-authentication
  320.    validation fails for this reason then the KDC MAY return a KRB-ERROR
  321.    message.  The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the
  322.    PA-DATA with the "nextOTP" flag set.  If this flag is set then the
  323.    client SHOULD re-try the authentication using the OTP for the token
  324.    "state" after that used in the failed authentication attempt.
  325.  
  326.  
  327. 3.  Pre-Authentication Protocol Details
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335. Richards                  Expires March 8, 2009                 [Page 6]
  336.  
  337. Internet-Draft           OTP Pre-authentication           September 2008
  338.  
  339.  
  340. 3.1.  Initial Client Request
  341.  
  342.    In the 4-pass mode, the client begins by sending an initial AS-REQ,
  343.    possibly containing other pre-authentication data.  If the KDC
  344.    determines that OTP-based pre-authentication is required and the
  345.    request does not contain a PA-OTP-REQUEST then it will respond as
  346.    described in Section 3.2.
  347.  
  348.    If the client has all the necessary information, it MAY use the
  349.    2-pass system by constructing a PA-OTP-REQUEST as described in
  350.    Section 3.3 and including it in the initial request.
  351.  
  352. 3.2.  KDC Challenge
  353.  
  354.    If the user is required to authenticate using an OTP then the KDC
  355.    SHALL respond to the initial AS-REQ with a KRB-ERROR containing:
  356.  
  357.    o  An error code of KDC_ERR_PREAUTH_REQUIRED
  358.  
  359.    o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
  360.  
  361.    Alternatively, if the OTP mechanism is required as part of an
  362.    authentication set then KDC SHOULD respond with a PA-AUTHENTICATION-
  363.    SET as described in section 6.4 of [ZhHa08].  In this case, the PA-
  364.    OTP-CHALLENGE SHALL be returned within the pa-data of a PA-
  365.    AUTHENTICATION-SET-ELEM
  366.  
  367.    The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned
  368.    encrypted in the client's response and the encryption type to be used
  369.    by the client.  This nonce string MUST be as long as the longest key
  370.    length of the symmetric key types that the KDC supports and MUST be
  371.    chosen randomly.  In order to allow it to maintain any state
  372.    necessary to verify the returned nonce, the KDC SHOULD use the
  373.    mechanism described in section 6.3 of [ZhHa08].
  374.  
  375.    If the OTP is to be generated using an server generated challenge
  376.    then the value of the challenge SHALL be included in the otp-
  377.    challenge field.  If the OTP is to be generated by combining the
  378.    challenge with the token's current state (e.g. time) then the
  379.    "combine" flag SHALL be set.
  380.  
  381.    The KDC MAY use the otp-service to identify the service provided by
  382.    the KDC in order to assist the client in locating the OTP token to be
  383.    used.  For example, this field could be used when a client has
  384.    multiple OTP tokens from different servers to identify the KDC.
  385.    Similarly, if the KDC can determine which OTP token key (the seed
  386.    value on the token used to generate the OTP) is to be used, then the
  387.    otp-keyID field MAY be used to pass that value to the client.
  388.  
  389.  
  390.  
  391. Richards                  Expires March 8, 2009                 [Page 7]
  392.  
  393. Internet-Draft           OTP Pre-authentication           September 2008
  394.  
  395.  
  396.    The otp-algID field MAY be used to identify the algorithm that should
  397.    be used in the OTP calculation.  For example, it could be used when a
  398.    user has been issued with multiple tokens of different types.
  399.  
  400.    In order to support connected tokens that can generate OTP values of
  401.    varying length, the KDC MAY include the desired length of the OTP in
  402.    the otp-length field.
  403.  
  404.    In order to support cases where the KDC cannot obtain plaintext
  405.    values for the OTPs, the challenge MAY also contain a sequence of one
  406.    way hash function algorithm identifiers and a minimum value of the
  407.    iteration count to be used by the client when hashing the OTP value.
  408.  
  409. 3.3.  Client Response
  410.  
  411.    The client response SHALL be sent to the KDC as a PA-OTP-REQUEST
  412.    included within the enc-fast-req of a PA-FX-FAST-REQUEST encrypted
  413.    under the current Armor Key as described in [ZhHa08].
  414.  
  415.    In order to generate its response, the client must generate an OTP
  416.    value.  The OTP value MUST be based on the parameters in the KDC
  417.    challenge if present and the response SHOULD include any information
  418.    on the generated OTP value reported by the OTP token.
  419.  
  420.    If the "nextOTP" flag is set in the PA-OTP-CHALLENGE, then the client
  421.    MUST generate the OTP value in the next token state than that used in
  422.    the previous PA-OTP-REQUEST.  The "nextOTP" flag MUST also be set in
  423.    the new PA-OTP-REQUEST.
  424.  
  425.    The otp-time and otp-counter fields MAY be used to return the time
  426.    and counter values used by the token.  The otp-format field MAY be
  427.    used to report the format of the generated OTP.  This field SHOULD be
  428.    used if a token can generate OTP values in multiple formats.  The
  429.    otp-algID field MAY be used by the client to report the algorithm
  430.    used in the OTP calculation and the otp-keyID MAY be used to report
  431.    the identifier of the OTP token key used.
  432.  
  433.    If an otp-challenge is present in the PA-OTP-CHALLENGE then the OTP
  434.    value MUST be generated based on a challenge if the token is capable
  435.    of accepting a challenge.  The client MAY ignore the provided
  436.    challenge if and only if the token is not capable of including a
  437.    challenge in the OTP calculation.  If the "combine" flag is not set
  438.    in the PA-OTP-CHALLENGE then the OTP SHALL be calculated based only
  439.    the challenge and not the internal state (e.g. time or counter) of
  440.    the token.  If the "combine" flag is set then the OTP SHALL be
  441.    calculated using both the internal state and the provided challenge.
  442.    If the flag is set but otp-challenge is not present then the client
  443.    SHALL regard the request as invalid.
  444.  
  445.  
  446.  
  447. Richards                  Expires March 8, 2009                 [Page 8]
  448.  
  449. Internet-Draft           OTP Pre-authentication           September 2008
  450.  
  451.  
  452.    If the OTP value was generated using a challenge that was not sent by
  453.    the KDC then the challenge SHALL be included in the otp-challenge of
  454.    the PA-OTP-REQUEST.  If the OTP was generated by combining a
  455.    challenge (either received from the KDC or generated by the client)
  456.    with the token state then the "combine" flag SHALL be set in the PA-
  457.    OTP-REQUEST.
  458.  
  459.    The client MUST derive the Client Key and Reply Key as described in
  460.    Section 3.6.  In order to support OTP algorithms where the KDC cannot
  461.    obtain the OTP value, the client MAY include the generated value in
  462.    the otp-value field of the PA-OTP-REQUEST.  However, the client MUST
  463.    NOT include the OTP value unless it is allowed by the algorithm
  464.    profile.  If it is included then the OTP value MUST NOT be used in
  465.    the key derivation.
  466.  
  467.    If the client used hashed OTP values in the key derivation process
  468.    then it MUST include the hash algorithm and iteration count used in
  469.    the hashAlg and iterationCount fields of the PA-OTP-REQUEST.  These
  470.    fields MUST NOT be included if hashed OTP values were not used.  It
  471.    is RECOMMENDED that the iteration count used by the client be chosen
  472.    in such a way that it is computationally infeasible/unattractive for
  473.    an attacker to brute-force search for the given OTP within the
  474.    lifetime of that OTP.
  475.  
  476.    If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE
  477.    that contained hash algorithm identifiers and the OTP value is to be
  478.    used in the key derivation then the client MUST use hashed OTP values
  479.    and MUST select the first algorithm from the list that it supports.
  480.    However, if the algorithm identifiers do not conform to local policy
  481.    restrictions then the authentication attempt MUST NOT proceed.  If
  482.    the iteration count specified in the PA-OTP-CHALLENGE does not
  483.    conform to local policy then the client MAY use a higher value but
  484.    MUST NOT use a lower value.  That is, the value in the KDC challenge
  485.    is a minimum value.
  486.  
  487.    The generated Client Key is used by the client to encrypt data to be
  488.    included in the encData of the PA-OTP-REQUEST to allow the KDC to
  489.    authenticate the user.  The key usage for this encryption is
  490.    KEY_USAGE_OTP_REQUEST.
  491.  
  492.    o  If the response is being generated in response to a PA-OTP-
  493.       CHALLENGE returned by the KDC then client encrypts a PA-OTP-ENC-
  494.       REQUEST containing the value of nonce from the PA-OTP-CHALLENGE
  495.       using the encryption type specified in the challenge.
  496.  
  497.    o  If the response is not in response to a PA-OTP-CHALLENGE then the
  498.       client encrypts a PA-ENC-TS-ENC containing the current time as in
  499.       the encrypted timestamp pre-authentication mechanism [RFC4120].
  500.  
  501.  
  502.  
  503. Richards                  Expires March 8, 2009                 [Page 9]
  504.  
  505. Internet-Draft           OTP Pre-authentication           September 2008
  506.  
  507.  
  508.    If the client is working in 2-pass mode and so is not responding to
  509.    an initial KDC challenge then the values of the iteration count, hash
  510.    algorithms and encryption type cannot be obtained from that
  511.    challenge.  The client SHOULD use any values obtained from a previous
  512.    PA-OTP-CHALLENGE or, if no values are available, it MAY use initial
  513.    configured values.
  514.  
  515.    Finally, the client generates a nonce value to include in the
  516.    response that will be returned encrypted by the KDC.  This nonce
  517.    string MUST be as long as the longest key length of the symmetric key
  518.    types that the client supports.  This nonce MUST be chosen randomly.
  519.  
  520. 3.4.  Verifying the pre-auth Data
  521.  
  522.    The KDC validates the pre-authentication data by generating the
  523.    Client Key and Reply Key in the same way as the client and using the
  524.    generated Client Key to decrypt the value of encData from the PA-OTP-
  525.    REQUEST.
  526.  
  527.    If the otp-value field is included in the PA-OTP-REQUEST then the KDC
  528.    MUST use that value.  Otherwise, the KDC will need to generate or
  529.    obtain the value.
  530.  
  531.    If the otp-challenge field is present, then the OTP was calculated
  532.    using that challenge.  If the "combine" flag is also set, then the
  533.    OTP was calculated using the challenge and the token's current state.
  534.  
  535.    It is RECOMMENDED that the KDC acts upon the values of otp-time, otp-
  536.    counter, otp-format, otp-algID and otp-keyID if they are present in
  537.    the PA-OTP-REQUEST.  If the KDC receives a request containing these
  538.    values but cannot act upon them then they MAY be ignored.
  539.  
  540.    The KDC generates the Client Key and Reply Key as described in
  541.    Section 3.6 from the OTP value using the hash algorithm and iteration
  542.    count if present in the PA-OTP-REQUEST.  However, the client
  543.    authentication MUST fail if the KDC requires hashed OTP values and
  544.    the hashAlg field was not present in the PA-OTP-REQUEST, if the hash
  545.    algorithm identifier or the value of iterationCount included in the
  546.    PA-OTP-REQUEST do not conform to local KDC policy or if the value of
  547.    the iterationCount is less than that specified in the PA-OTP-
  548.    CHALLENGE.
  549.  
  550.    The generated Client Key is then used to decrypt the encData from the
  551.    PA-OTP-REQUEST.  If the client response was sent as a result of a PA-
  552.    OTP-CHALLENGE then the decrypted data will be a PA-OTP-ENC-REQUEST
  553.    and the client authentication MUST fail if the nonce value from the
  554.    PA-OTP-ENC-REQUEST is not the same as the nonce value sent in the PA-
  555.    OTP-CHALLENGE.  If the response was not sent as a result of a PA-OTP-
  556.  
  557.  
  558.  
  559. Richards                  Expires March 8, 2009                [Page 10]
  560.  
  561. Internet-Draft           OTP Pre-authentication           September 2008
  562.  
  563.  
  564.    CHALLENGE then the decrypted value will be a PA-ENC-TS-ENC and the
  565.    authentication process will be the same as with standard encrypted
  566.    timestamp pre-authentication [RFC4120]
  567.  
  568.    The authentication MUST fail if the encryption type used by the
  569.    client in the encData does not conform to KDC policy.
  570.  
  571.    If authentication fails due to the hash algorithm, iteration count or
  572.    encryption type used by the client then the KDC SHOULD return a PA-
  573.    OTP-CHALLENGE with the required values in the error response.  If the
  574.    authentication fails due to the token state on the server no longer
  575.    being synchronized with the token used then the KDC SHALL return a
  576.    PA-OTP-CHALLENGE with the "nextOTP" flag set as described in
  577.    Section 2.4.
  578.  
  579.    If during the authentication process, the KDC determines that the
  580.    user's PIN has expired then it MAY include a PA-OTP-PIN-CHANGE in the
  581.    response as described in Section 2.3.
  582.  
  583. 3.5.  Confirming the Reply Key Change
  584.  
  585.    If the pre-authentication data was successfully verified, then, in
  586.    order to support mutual authentication, the KDC SHALL respond to the
  587.    client's PA-OTP-REQUEST by including in the AS-REP, a PA-OTP-CONFIRM
  588.    containing the client's nonce from PA-OTP-REQUEST encrypted under the
  589.    generated Reply Key.
  590.  
  591.    The nonce SHALL be returned within a PA-OTP-ENC-CONFIRM encrypted
  592.    within the encData of the PA-OTP-CONFIRM.  The key usage SHALL be
  593.    KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as
  594.    used by the client in the encData of the PA-OTP-REQUEST.
  595.  
  596.    The PA-OTP-CONFIRM SHALL be sent to the client within the enc-fast-
  597.    rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key.
  598.  
  599.    The client then uses its generated Reply Key to decrypt the PA-OTP-
  600.    ENC-CONFIRM from the encData of the PA-OTP-CONFIRM.  The client MUST
  601.    fail the authentication process if the nonce value in the PA-OTP-ENC-
  602.    CONFIRM is not the same as the nonce value sent in the PA-OTP-
  603.    REQUEST.
  604.  
  605. 3.6.  Reply Key Generation
  606.  
  607.    In order to authenticate the user, the client and KDC need to
  608.    generate two encryption keys:
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615. Richards                  Expires March 8, 2009                [Page 11]
  616.  
  617. Internet-Draft           OTP Pre-authentication           September 2008
  618.  
  619.  
  620.    o  The Client Key to be used by the client to encrypt and by the KDC
  621.       to decrypt the encData in the PA-OTP-REQUEST.
  622.  
  623.    o  The Reply Key to be used in the standard manner by the KDC to
  624.       encrypt data in the AS-REP but also to be used by the KDC to
  625.       encrypt and by the client to decrypt the encData value in the PA-
  626.       OTP-CONFIRM.
  627.  
  628.    The method used to generate the two keys will depend on the OTP
  629.    algorithm.
  630.  
  631.    o  If the OTP value is included in the otp-value of the PA-OTP-
  632.       REQUEST then the two keys SHALL be the same as the Armor Key
  633.       (defined in [ZhHa08]).
  634.  
  635.    o  If the OTP value is not included in the otp-value of the PA-OTP-
  636.       REQUEST then the two keys SHALL be derived from the Armor Key and
  637.       the OTP value as described below.
  638.  
  639.    If the OTP value is not included in the PA-OTP-REQUEST, then the
  640.    Reply Key and Client Key SHALL be generated using the KRB_FX_CF2
  641.    algorithm from [ZhHa08] as follows:
  642.  
  643.              Client Key = KRB_FX_CF2(K1, K2, O1, O2)
  644.              Reply Key = KRB_FX_CF2(K1, K2, O3, O4)
  645.  
  646.    The octet string parameters, O1, O2, O3 and O4, shall be the ASCII
  647.    string "Combine1", "Combine2", "Combine3" and "Combine4" as shown
  648.    below:
  649.  
  650.       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31}
  651.       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32}
  652.       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x33}
  653.       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x34}
  654.  
  655.    The first input keys, K1, shall be the Armor Key. The second input
  656.    key, K2, shall be derived from the OTP value using string-to-key
  657.    (defined in [RFC3961]) as follows.
  658.  
  659.    If the hash of the OTP value is to be used then K2 SHALL be derived
  660.    as follows:
  661.  
  662.    o  An initial hash value, H, is generated:
  663.  
  664.              H = hash(sname|nonce|OTP)
  665.  
  666.       Where:
  667.  
  668.  
  669.  
  670.  
  671. Richards                  Expires March 8, 2009                [Page 12]
  672.  
  673. Internet-Draft           OTP Pre-authentication           September 2008
  674.  
  675.  
  676.       *  "|" denotes concatenation
  677.       *  hash is the hash algorithm selected by the client.
  678.       *  sname is the UTF-8 encoding of the KDC's fully qualified domain
  679.          name.  If the domain name is an Internationalized Domain Name
  680.          then the value shall be the output of nameprep [RFC3491] as
  681.          described in [RFC3490]
  682.       *  nonce is the random nonce value generated by the client to be
  683.          included in the PA-OTP-REQUEST.
  684.       *  OTP is the OTP value.
  685.  
  686.    o  The initial hash value is then hashed iterationCount-1 times to
  687.       produce a final hash value, H'.  (Where iterationCount is the
  688.       value from the PA-OTP-REQUEST.)
  689.  
  690.              H' = hash(hash(...(iterationCount-1 times)...(H)))
  691.  
  692.    o  The value of K2 is then derived from the base64 [RFC2045] encoding
  693.       of this final hash value.
  694.  
  695.              K2 = string-to-key(Base64(H')||"Krb-preAuth")
  696.  
  697.    If the OTP value is binary and the hash value is not used, then K2
  698.    SHALL be derived from the base64 encoding of the OTP value.
  699.  
  700.              K2 = string-to-key(Base64(OTP)||"Krb-preAuth")
  701.  
  702.    If the OTP value is not binary and the hash value is not used, then
  703.    K2 SHALL be derived by running the OTP value once through string-to-
  704.    key.
  705.  
  706.              K2 = string-to-key(OTP||"Krb-preAuth")
  707.  
  708.    The salt and any additional parameters for string-to-key will be
  709.    derived as described in section 3.1.3 of [RFC4120] using preauth data
  710.    or default values defined for the particular enctype.  The symbol
  711.    "||" denotes string concatenation.
  712.  
  713.  
  714. 4.  OTP Kerberos Message Types
  715.  
  716. 4.1.  PA-OTP-CHALLENGE
  717.  
  718.    The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in
  719.    the PA-DATA of a KRB-ERROR when pre-authentication using an OTP value
  720.    is required.  The corresponding padata-value field contains the DER
  721.    encoding of a PA-OTP-CHALLENGE containing a server generated nonce
  722.    and information for the client on how to generate the OTP.
  723.  
  724.  
  725.  
  726.  
  727. Richards                  Expires March 8, 2009                [Page 13]
  728.  
  729. Internet-Draft           OTP Pre-authentication           September 2008
  730.  
  731.  
  732.              PA_OTP_CHALLENGE     131;
  733.  
  734.              PA-OTP-CHALLENGE ::= SEQUENCE {
  735.                flags              OTPFlags,
  736.                nonce              OCTET STRING,
  737.                etype              Int32,
  738.                supportedHashAlg   SEQUENCE OF AlgorithmIdentifier
  739.                                                   OPTIONAL,
  740.                iterationCount     INTEGER         OPTIONAL,
  741.                otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,
  742.                otp-length     [0] Int32           OPTIONAL,
  743.                otp-service        UTF8String      OPTIONAL,
  744.                otp-keyID      [1] OCTET STRING    OPTIONAL,
  745.                otp-algID      [2] AnyURI          OPTIONAL,
  746.                ...
  747.              }
  748.  
  749.              OTPFlags ::= KerberosFlags
  750.              -- nextOTP (0)
  751.              -- combine (1)
  752.  
  753.    flags
  754.       If the "nextOTP" flag is set then the OTP SHALL be based on the
  755.       next token "state" rather than the current one.  As an example,
  756.       for a time-based token, this means the next time slot and for an
  757.       event-based token, this could mean the next counter value.
  758.  
  759.       The "combine flag controls how the challenge included in otp-
  760.       challenge shall be used.  If the flag is set then OTP SHALL be
  761.       calculated using the challenge from otp-challenge and the internal
  762.       token state (e.g. time or counter).  If the "combine" flag is not
  763.       set then the OTP SHALL be calculated based only on the challenge.
  764.       If the flag is set and otp-challenge is not present then the
  765.       request SHALL be regarded as invalid.
  766.  
  767.    nonce
  768.       A KDC-supplied nonce value to be encrypted by the client in the
  769.       PA-OTP-REQUEST.  This nonce string MUST be as long as the longest
  770.       key length of the symmetric key types that the KDC supports and
  771.       MUST be chosen randomly. the Client Key and MUST be chosen
  772.       randomly.
  773.  
  774.    etype
  775.       The encryption type to be used by the client to encrypt the nonce
  776.       in the PA-OTP-REQUEST.
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783. Richards                  Expires March 8, 2009                [Page 14]
  784.  
  785. Internet-Draft           OTP Pre-authentication           September 2008
  786.  
  787.  
  788.    supportedHashAlg
  789.       If present then a hash of the OTP value MUST be used in the key
  790.       derivation rather than the plain text value.  Each
  791.       AlgorithmIdentifier identifies a hash algorithm that is supported
  792.       by the KDC in decreasing order of preference.  The client MUST
  793.       select the first algorithm from the list that it supports.
  794.       Support for SHA1 by both the client and KDC is REQUIRED.  The
  795.       AlgorithmIdentifer selected by the client MUST be placed in the
  796.       hashAlg element of the PA-OTP-REQUEST.
  797.  
  798.    iterationCount
  799.       The minimum value of the iteration count to be used by the client
  800.       when hashing the OTP value.  This value MUST be present if and
  801.       only if supportedHashAlg is present.  If the value of this element
  802.       does not conform to local policy on the client then the client MAY
  803.       use a larger value but MUST NOT use a lower value.  The value of
  804.       the iteration count used by the client MUST be returned in the PA-
  805.       OTP-REQUEST sent to the KDC.
  806.  
  807.    otp-challenge
  808.       The otp-challenge is used by the KDC to send a challenge value for
  809.       use in the OTP calculation.  The challenge is an optional octet
  810.       string that SHOULD be uniquely generated for each request it is
  811.       present in, and SHOULD be eight octets or longer when present.
  812.       When the challenge is not present, the OTP will be calculated on
  813.       the current token state only.  The client MAY ignore a provided
  814.       challenge if and only if the OTP token the client is interacting
  815.       with is not capable of including a challenge in the OTP
  816.       calculation.  In this case, KDC policies will determine whether to
  817.       accept a provided OTP value or not.
  818.  
  819.    otp-length
  820.       Use of this field is OPTIONAL, but MAY be used by the KDC to
  821.       specify the desired length of the generated OTP in octets.  For
  822.       example, this field could be used when a token is capable of
  823.       producing OTP values of different lengths.
  824.  
  825.    otp-service
  826.       Use of this field is OPTIONAL, but MAY be used by the KDC to
  827.       identify the appropriate OTP tokens to be used.  For example, this
  828.       field could be used when a client has multiple OTP tokens from
  829.       different servers.
  830.  
  831.    otp-keyID
  832.       Use of this field is OPTIONAL, but MAY be used by the KDC to
  833.       identify which token key should be used for the authentication.
  834.       For example, this field could be used when a user has been issued
  835.       multiple token keys by the same server.
  836.  
  837.  
  838.  
  839. Richards                  Expires March 8, 2009                [Page 15]
  840.  
  841. Internet-Draft           OTP Pre-authentication           September 2008
  842.  
  843.  
  844.    otp-algID
  845.       Use of this field is OPTIONAL, but MAY be used by the KDC to
  846.       identify the algorithm to use when generating the OTP.
  847.  
  848. 4.2.  PA-OTP-REQUEST
  849.  
  850.    The padata-type PA_OTP_REQUEST is sent by the client to the KDC in
  851.    the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the
  852.    PA-DATA of an AS-REQ.  The corresponding padata-value field contains
  853.    the DER encoding of a PA-OTP-REQUEST.
  854.  
  855.    The message contains pre-authentication data encrypted by the client
  856.    using the generated Client Key and optional information on how the
  857.    OTP was generated.  It may also, optionally, contain the generated
  858.    OTP value.
  859.  
  860.              PA_OTP_REQUEST     132;
  861.  
  862.              PA-OTP-REQUEST ::= SEQUENCE {
  863.                flags             OTPFlags,
  864.                nonce             OCTET STRING,
  865.                encData           EncryptedData,
  866.                                  -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
  867.                                  -- Key usage of KEY_USAGE_OTP_REQUEST
  868.                hashAlg           AlgorithmIdentifier OPTIONAL,
  869.                iterationCount    INTEGER         OPTIONAL,
  870.                otp-value         OCTET STRING    OPTIONAL,
  871.                otp-challenge [0] OCTET STRING    OPTIONAL,
  872.                otp-time          KerberosTime    OPTIONAL,
  873.                otp-counter   [1] OCTET STRING    OPTIONAL,
  874.                otp-format    [2] OTPFormat       OPTIONAL,
  875.                otp-keyID     [3] OCTET STRING    OPTIONAL,
  876.                otp-algID         AnyURI          OPTIONAL,
  877.                ...
  878.              }
  879.  
  880.              KEY_USAGE_OTP_REQUEST  45
  881.  
  882.  
  883.              PA-OTP-ENC-REQUEST ::= SEQUENCE {
  884.                nonce     OCTET STRING,
  885.                ...
  886.              }
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895. Richards                  Expires March 8, 2009                [Page 16]
  896.  
  897. Internet-Draft           OTP Pre-authentication           September 2008
  898.  
  899.  
  900.              OTPFormat ::= INTEGER {
  901.                decimal(0),
  902.                hexadecimal(1),
  903.                alphanumeric(2),
  904.                binary(3)
  905.              }
  906.  
  907.    flags
  908.       If the "nextOTP" flag is set then the OTP was calculated based on
  909.       the next token "state" rather than the current one.  This flag
  910.       MUST be set if and only if it was set in a corresponding PA-OTP-
  911.       CHALLENGE.
  912.  
  913.       If the "combine" flag is set then the OTP was calculated based on
  914.       a challenge and the token state.
  915.  
  916.    nonce
  917.       A value generated by the client to be returned encrypted by the
  918.       KDC in the PA-OTP-CONFIRM.  This nonce string MUST be as long as
  919.       the longest key length of the symmetric key types that the client
  920.       supports and MUST be chosen randomly.
  921.  
  922.    encData
  923.       This field contains the pre-authentication data encrypted under
  924.       the Client Key with a key usage of KEY_USAGE_OTP_REQUEST.  If the
  925.       PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE then this
  926.       MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-
  927.       CHALLENGE.  If no challenge was received then this MUST contain a
  928.       PA-ENC-TS-ENC.
  929.  
  930.    hashAlg
  931.       This field MUST be present if and only if a hash of the OTP value
  932.       was used as input to string-to-key (see Section 3.6) and MUST
  933.       contain the AlgorithmIdentifier of the hash algorithm used.  If
  934.       the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then
  935.       the AlgorithmIdentifer MUST be the first one supported by the
  936.       client from the supportedHashAlg of the PA-OTP-CHALLENGE.
  937.  
  938.    iterationCount
  939.       This field MUST be present if and only if a hash of the OTP value
  940.       was used as input to string-to-key (see Section 3.6) and MUST
  941.       contain the iteration count used when hashing the OTP value.  If
  942.       the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then
  943.       the value MUST NOT be less that that specified in the PA-OTP-
  944.       CHALLENGE.
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951. Richards                  Expires March 8, 2009                [Page 17]
  952.  
  953. Internet-Draft           OTP Pre-authentication           September 2008
  954.  
  955.  
  956.    otp-value
  957.       The generated OTP value.  This value MUST NOT be present unless
  958.       allowed by the OTP algorithm profile.
  959.  
  960.    otp-challenge
  961.       Value used by the client in the OTP calculation.  It MUST be sent
  962.       to the KDC if and only if the value would otherwise be unknown to
  963.       the KDC.  For example, the token or client modified or generated
  964.       challenge.
  965.  
  966.    otp-time
  967.       This field MAY be included by the client to carry the time value
  968.       as reported by the OTP token.  Use of this element is OPTIONAL but
  969.       it MAY be used by a client to simplify the OTP calculations of the
  970.       KDC.  It is RECOMMENDED that the KDC act upon this value if it is
  971.       present in the request and it is capable of using it in the
  972.       generation of the OTP value.
  973.  
  974.    otp-counter
  975.       This field MAY be included by the client to carry the token
  976.       counter value, as reported by the OTP token.  Use of this element
  977.       is OPTIONAL but it MAY be used by a client to simplify the OTP
  978.       calculations of the KDC.  It is RECOMMENDED that the KDC act upon
  979.       this value if it is present in the request and it is capable of
  980.       using it in the generation of the OTP value.
  981.  
  982.    otp-format
  983.       This field MAY be used by the client to send the format of the
  984.       generated OTP as reported by the OTP token.  Use of this element
  985.       is OPTIONAL but it MAY be used by the client to simplify the OTP
  986.       calculation.  It is RECOMMENDED that the KDC act upon this value
  987.       if it is present in the request and it is capable of using it in
  988.       the generation of the OTP value.
  989.  
  990.    otp-keyID
  991.       This field MAY be used by the client to send the identifier of the
  992.       token key used, as reported by the OTP token.  Use of this field
  993.       is OPTIONAL but MAY be used by the client to simplify the
  994.       authentication process by identifying a particular token key
  995.       associated with the user.  It is RECOMMENDED that the KDC act upon
  996.       this value if it is present in the request and it is capable of
  997.       using it in the generation of the OTP value.
  998.  
  999.    otp-algID
  1000.       This field MAY be used by the client to send the identifier of the
  1001.       OTP algorithm used, as reported by the OTP token.  Use of this
  1002.       element is OPTIONAL but it MAY be used by the client to simplify
  1003.       the OTP calculation.  It is RECOMMENDED that the KDC act upon this
  1004.  
  1005.  
  1006.  
  1007. Richards                  Expires March 8, 2009                [Page 18]
  1008.  
  1009. Internet-Draft           OTP Pre-authentication           September 2008
  1010.  
  1011.  
  1012.       value if it is present in the request and it is capable of using
  1013.       it in the generation of the OTP value.
  1014.  
  1015. 4.3.  PA-OTP-CONFIRM
  1016.  
  1017.    The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc-
  1018.    fast-rep of a PA-FX-FAST-REPLY in the AS-REP of the KDC.  It is used
  1019.    to return the client's nonce encrypted under the new Reply Key in
  1020.    order to authenticate the KDC and confirm the Reply Key change.
  1021.  
  1022.    The corresponding padata-value field contains the DER encoding of a
  1023.    PA-OTP-CONFIRM.
  1024.  
  1025.              PA_OTP_CONFIRM     133
  1026.  
  1027.              PA-OTP-CONFIRM ::= SEQUENCE {
  1028.                encData        EncryptedData,
  1029.                                    -- PA-OTP-ENC-CONFIRM
  1030.                                    -- Key usage of KEY_USAGE_OTP_CONFIRM
  1031.                ...
  1032.              }
  1033.  
  1034.              KEY_USAGE_OTP_CONFIRM  46
  1035.  
  1036.  
  1037.              PA-OTP-ENC-CONFIRM ::= SEQUENCE {
  1038.                nonce     OCTET STRING,
  1039.                ...
  1040.              }
  1041.  
  1042.    encData
  1043.       An EncryptedData containing a PA-OTP-ENC-CONFIRM containing the
  1044.       value of the nonce from the corresponding PA-OTP-REQUEST encrypted
  1045.       under the current Reply Key. The key usage SHALL be
  1046.       KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same
  1047.       as that used by the client in the PA-OTP-REQUEST.
  1048.  
  1049. 4.4.  PA-OTP-PIN-CHANGE
  1050.  
  1051.    The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the enc-
  1052.    fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change
  1053.    their PIN or if the user's PIN has been changed.
  1054.  
  1055.    The corresponding padata-value field contains the DER encoding of a
  1056.    PA-OTP-PIN-CHANGE.
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063. Richards                  Expires March 8, 2009                [Page 19]
  1064.  
  1065. Internet-Draft           OTP Pre-authentication           September 2008
  1066.  
  1067.  
  1068.              PA_OTP_PIN_CHANGE     134
  1069.  
  1070.              PA-OTP-PIN-CHANGE ::= SEQUENCE {
  1071.                flags         PinFlags,
  1072.                pin           UTF8String OPTIONAL,
  1073.                minLength     INTEGER    OPTIONAL,
  1074.                maxLength [1] INTEGER    OPTIONAL,
  1075.                ...
  1076.              }
  1077.  
  1078.              PinFlags ::= KerberosFlags
  1079.                -- systemSetPin (0)
  1080.  
  1081.    If the "systemSetPin" flag is set then the user's PIN has been
  1082.    changed and the new PIN value is contained in the pin field.  The pin
  1083.    field MUST therefore be present.
  1084.  
  1085.    If the "systemSetPin" flag is not set then the user's PIN has not
  1086.    been changed by the server but it MUST instead be changed by the
  1087.    user.  Restrictions on the size of the PIN MAY be given by the
  1088.    minLength and maxLength fields.  If the pin field is present then it
  1089.    contains a PIN value that MAY be used by the user when changing the
  1090.    PIN.
  1091.  
  1092.  
  1093. 5.  IANA Considerations
  1094.  
  1095.    A registry will be required for the URIs to be used as otp-algID
  1096.    values as introduced in Section 4.1.  It is currently anticipated
  1097.    that the registry being introduced in section 8.4 of [HoPeMa08] can
  1098.    be used for this purpose and no other IANA actions are anticipated.
  1099.  
  1100.  
  1101. 6.  Security Considerations
  1102.  
  1103. 6.1.  Man-in-the-Middle
  1104.  
  1105.    In the system described in this document, the OTP pre-authentication
  1106.    protocol is tunneled within the FAST Armor channel provided by the
  1107.    pre-authentication framework.  As described in [AsNiNy02], tunneled
  1108.    protocols are potentially vulnerable to man-in-the-middle attacks if
  1109.    the outer tunnel is compromised and it is generally considered good
  1110.    practice in such cases to bind the inner encryption to the outer
  1111.    tunnel.
  1112.  
  1113.    In order to mitigate against such attacks, the proposed system uses
  1114.    the outer Armor Key in the derivation of the inner Client and Reply
  1115.    keys and so achieve crypto-binding to the outer channel.
  1116.  
  1117.  
  1118.  
  1119. Richards                  Expires March 8, 2009                [Page 20]
  1120.  
  1121. Internet-Draft           OTP Pre-authentication           September 2008
  1122.  
  1123.  
  1124.    As described in section 6.5 of [ZhHa08], FAST can use an anonymous
  1125.    TGT obtained using anonymous PKINIT [ZhLe08] [RFC4556] as the Armor
  1126.    Key. However, the current anonymous PKINIT proposal is open to man-
  1127.    in-the-middle attacks since the attacker can choose a session key
  1128.    such that the session key between the MITM and the real KDC is the
  1129.    same as the session key between the client and the MITM.
  1130.  
  1131.    As described in Section 3.6, if the OTP value is not being sent to
  1132.    the KDC then the Armor Key is used along with the OTP value in the
  1133.    generation of the Client Key and Reply Key. If the Armor Key is known
  1134.    then the only entropy remaining in the the key generation is provided
  1135.    by the OTP value.  If the OTP algorithm requires that the OTP value
  1136.    be sent to the KDC then it is sent encrypted within the tunnel
  1137.    provided by the FAST armor and so is exposed to the attacker if the
  1138.    attacker has the Armor Key.
  1139.  
  1140.    It is therefore recommended that anonymous PKINIT not be used with
  1141.    OTP algorithms that require the OTP value to be sent to the KDC and
  1142.    that careful consideration be made of the security implications
  1143.    before it is used with other algorithms.
  1144.  
  1145. 6.2.  Reflection
  1146.  
  1147.    The 4-pass system described above is a challenge-response protocol
  1148.    and such protocols are potentially vulnerable to reflection attacks.
  1149.    No such attacks are known at this point but to help mitigate against
  1150.    such attacks, the system uses different keys to encrypt the client
  1151.    and server nonces.
  1152.  
  1153. 6.3.  Denial of Service
  1154.  
  1155.    The protocol supports the use of an iteration count in the generation
  1156.    of the Client and Reply keys and the client can send the number of
  1157.    iterations used as part of the PA-OTP-REQUEST.  This could open the
  1158.    KDC up to a denial of service attack if a large value for the
  1159.    iteration count was specified by the attacker.  It is therefore
  1160.    particularly important that, as described in Section 3.4, the KDC
  1161.    reject any authentication requests where the iteration count is above
  1162.    a maximum value specified by local policy.
  1163.  
  1164. 6.4.  Replay
  1165.  
  1166.    The 2-pass version of the protocol does not involve a server nonce
  1167.    and so the client instead encrypts a timestamp.  To reduce the chance
  1168.    of replay attacks, the KDC must check that the client time used in
  1169.    such a request is later than that used in previous requests.
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175. Richards                  Expires March 8, 2009                [Page 21]
  1176.  
  1177. Internet-Draft           OTP Pre-authentication           September 2008
  1178.  
  1179.  
  1180. 6.5.  Brute Force Attack
  1181.  
  1182.    A compromised or hostile KDC may be able to obtain the OTP value used
  1183.    by the client via a brute force attack.  If the OTP value is short
  1184.    then the KDC could iterate over the possible OTP values until a
  1185.    Client Key is generated that can decrypt the encData sent in the PA-
  1186.    OTP-REQUEST.
  1187.  
  1188.    As described in Section 3.6, an iteration count can be used in the
  1189.    generation of the Client Key and the value of the iteration count can
  1190.    be controlled by local client policy.  Use of this iteration count
  1191.    can make it computationally infeasible/unattractive for an attacker
  1192.    to brute-force search for the given OTP within the lifetime of that
  1193.    OTP.
  1194.  
  1195. 6.6.  FAST Facilities
  1196.  
  1197.    The secret used to generate the OTP is known only to the client and
  1198.    the KDC and so successful decryption of the encrypted nonce by the
  1199.    KDC authenticates the user.  Similarly, successful decryption of the
  1200.    encrypted nonce by the client proves that the expected KDC replied.
  1201.    The Reply Key is replaced by a key generated from the OTP and Armor
  1202.    Key. This FAST factor therefore provides the following facilities:
  1203.    client-authentication, replacing-reply-key and KDC-authentication.
  1204.  
  1205.  
  1206. 7.  Acknowledgments
  1207.  
  1208.    Many significant contributions were made to this document by RSA
  1209.    employees but special thanks go to Magnus Nystrom, John Linn, Robert
  1210.    Polansky and Boris Khoutorski.
  1211.  
  1212.    Many valuable suggestions were also made by members of the Kerberos
  1213.    Working Group but special thanks go to Larry Zhu, Jeffrey Hutzelman,
  1214.    Tim Alsop, Henry Hotz and Nicolas Williams.
  1215.  
  1216.    I would also like to thank Tim Alsop and Srinivas Cheruku of
  1217.    CyberSafe for many valuable review comments.
  1218.  
  1219.  
  1220. 8.  References
  1221.  
  1222. 8.1.  Normative References
  1223.  
  1224.    [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
  1225.               Extensions (MIME) Part One: Format of Internet Message
  1226.               Bodies", RFC 2045, November 1996.
  1227.  
  1228.  
  1229.  
  1230.  
  1231. Richards                  Expires March 8, 2009                [Page 22]
  1232.  
  1233. Internet-Draft           OTP Pre-authentication           September 2008
  1234.  
  1235.  
  1236.    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  1237.               Requirement Levels", BCP 14, RFC 2119, March 1997.
  1238.  
  1239.    [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
  1240.               "Internationalizing Domain Names in Applications (IDNA)",
  1241.               RFC 3490, March 2003.
  1242.  
  1243.    [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
  1244.               Profile for Internationalized Domain Names (IDN)",
  1245.               RFC 3491, March 2003.
  1246.  
  1247.    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
  1248.               Kerberos 5", RFC 3961, February 2005.
  1249.  
  1250.    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
  1251.               Kerberos Network Authentication Service (V5)", RFC 4120,
  1252.               July 2005.
  1253.  
  1254.    [ZhHa08]   Zhu, L. and S. Hartman, "A generalized Framework for
  1255.               Kerberos Pre-Authentication",
  1256.               draft-ietf-krb-wg-preauth-framework-08 (work in progress),
  1257.               July 2008.
  1258.  
  1259. 8.2.  Informative References
  1260.  
  1261.    [AsNiNy02]
  1262.               Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
  1263.               in Tunneled Authentication Protocols", Cryptology ePrint
  1264.               Archive Report 2002/163, November 2002.
  1265.  
  1266.    [HoPeMa08]
  1267.               Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
  1268.               Key Container",
  1269.               draft-ietf-keyprov-portable-symmetric-key-container-05
  1270.               (work in progress), July 2008.
  1271.  
  1272.    [HoReNeZo04]
  1273.               Horstein, K., Renard, K., Neuman, C., and G. Zorn,
  1274.               "Integrating Single-use Authentication Mechanisms with
  1275.               Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
  1276.               progress), July 2004.
  1277.  
  1278.    [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-
  1279.               Time Password System", RFC 2289, February 1998.
  1280.  
  1281.    [RFC2808]  Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,
  1282.               April 2000.
  1283.  
  1284.  
  1285.  
  1286.  
  1287. Richards                  Expires March 8, 2009                [Page 23]
  1288.  
  1289. Internet-Draft           OTP Pre-authentication           September 2008
  1290.  
  1291.  
  1292.    [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
  1293.               2000 Kerberos Change Password and Set Password Protocols",
  1294.               RFC 3244, February 2002.
  1295.  
  1296.    [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
  1297.               O. Ranen, "HOTP: An HMAC-Based One-Time Password
  1298.               Algorithm", RFC 4226, December 2005.
  1299.  
  1300.    [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
  1301.               Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
  1302.  
  1303.    [ZhLe08]   Zhu, L. and P. Leach, "Anonymity Support for Kerberos",
  1304.               draft-ietf-krb-wg-anon-08 (work in progress), August 2008.
  1305.  
  1306.  
  1307. Appendix A.  ASN.1 Module
  1308.  
  1309.    OTPKerberos
  1310.    DEFINITIONS IMPLICIT TAGS ::=
  1311.    BEGIN
  1312.  
  1313.    IMPORTS
  1314.  
  1315.        KerberosTime, KerberosFlags, EncryptionKey, Int32, EncryptedData
  1316.        FROM KerberosV5Spec2 {iso(1) identified-organization(3)
  1317.                              dod(6) internet(1) security(5)
  1318.                              kerberosV5(2) modules(4) krb5spec2(2)}
  1319.                              -- as defined in RFC 4120.
  1320.        AlgorithmIdentifier
  1321.        FROM PKIX1Explicit88 { iso (1) identified-organization (3)
  1322.                               dod (6) internet (1)
  1323.                               security (5) mechanisms (5) pkix (7)
  1324.                               id-mod (0) id-pkix1-explicit (18) };
  1325.                               -- As defined in RFC 3280.
  1326.  
  1327.        PA-OTP-CHALLENGE ::= SEQUENCE {
  1328.          flags              OTPFlags,
  1329.          nonce              OCTET STRING,
  1330.          etype              Int32,
  1331.          supportedHashAlg   SEQUENCE OF AlgorithmIdentifier
  1332.                                             OPTIONAL,
  1333.          iterationCount     INTEGER         OPTIONAL,
  1334.          otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,
  1335.          otp-length     [0] Int32           OPTIONAL,
  1336.          otp-service        UTF8String      OPTIONAL,
  1337.          otp-keyID      [1] OCTET STRING    OPTIONAL,
  1338.          otp-algID      [2] AnyURI          OPTIONAL,
  1339.          ...
  1340.  
  1341.  
  1342.  
  1343. Richards                  Expires March 8, 2009                [Page 24]
  1344.  
  1345. Internet-Draft           OTP Pre-authentication           September 2008
  1346.  
  1347.  
  1348.        }
  1349.  
  1350.        OTPFlags ::= KerberosFlags
  1351.        -- nextOTP (0)
  1352.        -- combine (1)
  1353.  
  1354.        PA-OTP-REQUEST ::= SEQUENCE {
  1355.          flags             OTPFlags,
  1356.          nonce             OCTET STRING,
  1357.          encData           EncryptedData,
  1358.                            -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
  1359.                            -- Key usage of KEY_USAGE_OTP_REQUEST
  1360.          hashAlg           AlgorithmIdentifier OPTIONAL,
  1361.          iterationCount    INTEGER         OPTIONAL,
  1362.          otp-value         OCTET STRING    OPTIONAL,
  1363.          otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL,
  1364.          otp-time          KerberosTime    OPTIONAL,
  1365.          otp-counter   [1] OCTET STRING    OPTIONAL,
  1366.          otp-format    [2] OTPFormat       OPTIONAL,
  1367.          otp-keyID     [3] OCTET STRING    OPTIONAL,
  1368.          otp-algID         AnyURI          OPTIONAL,
  1369.          ...
  1370.        }
  1371.  
  1372.        PA-OTP-ENC-REQUEST ::= SEQUENCE {
  1373.          nonce     OCTET STRING,
  1374.          ...
  1375.        }
  1376.  
  1377.        OTPFormat ::= INTEGER {
  1378.          decimal(0),
  1379.          hexadecimal(1),
  1380.          alphanumeric(2),
  1381.          binary(3)
  1382.        }
  1383.  
  1384.        PA-OTP-CONFIRM ::= SEQUENCE {
  1385.          encData        EncryptedData,
  1386.                         -- PA-OTP-ENC-CONFIRM
  1387.                         -- Key usage of KEY_USAGE_OTP_CONFIRM
  1388.          ...
  1389.        }
  1390.  
  1391.        PA-OTP-ENC-CONFIRM ::= SEQUENCE {
  1392.          nonce     OCTET STRING,
  1393.          ...
  1394.        }
  1395.  
  1396.  
  1397.  
  1398.  
  1399. Richards                  Expires March 8, 2009                [Page 25]
  1400.  
  1401. Internet-Draft           OTP Pre-authentication           September 2008
  1402.  
  1403.  
  1404.        PA-OTP-PIN-CHANGE ::= SEQUENCE {
  1405.          flags         PinFlags,
  1406.          pin           UTF8String OPTIONAL,
  1407.          minLength     INTEGER    OPTIONAL,
  1408.          maxLength [0] INTEGER    OPTIONAL,
  1409.          ...
  1410.        }
  1411.  
  1412.        PinFlags ::= KerberosFlags
  1413.        -- systemSetPin (0)
  1414.  
  1415.        AnyURI ::= UTF8String
  1416.           (CONSTRAINED BY {
  1417.           /* MUST be a valid URI in accordance with IETF RFC 2396 */
  1418.           })
  1419.  
  1420.    END
  1421.  
  1422.  
  1423. Appendix B.  Examples of OTP Pre-Authentication Exchanges
  1424.  
  1425.    This section is non-normative.
  1426.  
  1427. B.1.  Four Pass Authentication
  1428.  
  1429.    In this mode, the client sends an initial AS-REQ to the KDC that does
  1430.    not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR
  1431.    containing a PA-OTP-CHALLENGE.
  1432.  
  1433.    In this example, the user has been issued with a connected, time-
  1434.    based token and the KDC requires hashed OTP values in the key
  1435.    generation with SHA-384 as the preferred hash algorithm and a minimum
  1436.    of 1024 iterations.  It also requires that 256-bit AES be used to
  1437.    encrypt the nonce.  The local policy on the client supports SHA-256
  1438.    and requires 100,000 iterations of the hash of the OTP value.
  1439.  
  1440.    The basic sequence of steps involved is as follows:
  1441.  
  1442.    1.   The client obtains the user name of the user.
  1443.  
  1444.    2.   The client sends an initial AS-REQ to the KDC that does not
  1445.         contain a PA-OTP-REQUEST.
  1446.  
  1447.    3.   The KDC determines that the user identified by the AS-REQ
  1448.         requires OTP authentication.
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455. Richards                  Expires March 8, 2009                [Page 26]
  1456.  
  1457. Internet-Draft           OTP Pre-authentication           September 2008
  1458.  
  1459.  
  1460.    4.   The KDC constructs a PA-OTP-CHALLENGE as follows:
  1461.  
  1462.         flags
  1463.            0
  1464.  
  1465.         nonce
  1466.            A randomly generated value.
  1467.  
  1468.         etype
  1469.            aes256-cts-hmac-sha1-96
  1470.  
  1471.         supportedHashAlg
  1472.            AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1
  1473.  
  1474.         iterationCount
  1475.            1024
  1476.  
  1477.         otp-service
  1478.            A string that can be used by the client to assist the user in
  1479.            locating the correct token.
  1480.  
  1481.    5.   The KDC returns a KRB-ERROR with an error code of
  1482.         KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
  1483.  
  1484.    6.   The client displays the value of otp-service and prompts the
  1485.         user to connect the token.
  1486.  
  1487.    7.   The client obtains the current OTP value from the token and
  1488.         records the time as reported by the token.
  1489.  
  1490.    8.   The client generates Client Key and Reply Key as described in
  1491.         Section 3.6 using SHA-256 from the list of algorithms sent by
  1492.         the KDC and the iteration count of 100,000 as required by local
  1493.         policy.
  1494.  
  1495.    9.   The client constructs a PA-OTP-REQUEST as follows:
  1496.  
  1497.         flags
  1498.            0
  1499.  
  1500.         nonce
  1501.            A randomly generated value.
  1502.  
  1503.         encData
  1504.            An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
  1505.            under the Client Key with a key usage of
  1506.            KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-
  1507.            hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from
  1508.  
  1509.  
  1510.  
  1511. Richards                  Expires March 8, 2009                [Page 27]
  1512.  
  1513. Internet-Draft           OTP Pre-authentication           September 2008
  1514.  
  1515.  
  1516.            the PA-OTP-CHALLENGE.
  1517.  
  1518.         hashAlg
  1519.            SHA-256
  1520.  
  1521.         iterationCount
  1522.            100,000
  1523.  
  1524.         otp-time
  1525.            The time used in the OTP calculation as reported by the OTP
  1526.            token.
  1527.  
  1528.    10.  The client encrypts the PA-OTP-REQUEST within the enc-fast-req
  1529.         of a PA-FX-FAST-REQUEST.
  1530.  
  1531.    11.  The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
  1532.         REQUEST within the padata.
  1533.  
  1534.    12.  The KDC validates the pre-authentication data in the PA-OTP-
  1535.         REQUEST:
  1536.  
  1537.         *  Generates the Client Key and Reply Key from the OTP value for
  1538.            the user identified in the AS-REQ, using an iteration count
  1539.            of 100,000 and hash algorithm of SHA-256 as specified in the
  1540.            PA-OTP-REQUEST.
  1541.  
  1542.         *  Uses the generated Client Key to decrypt the PA-OTP-ENC-
  1543.            REQUEST in the encData of the PA-OTP-REQUEST.
  1544.  
  1545.         *  Authenticates the user by comparing the nonce value from the
  1546.            decrypted PA-OTP-ENC-REQUEST to that sent in the
  1547.            corresponding PA-OTP-CHALLENGE.
  1548.  
  1549.    13.  The KDC constructs a TGT for the user.
  1550.  
  1551.    14.  The KDC constructs a PA-OTP-CONFIRM as follows:
  1552.  
  1553.         encData
  1554.            An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted
  1555.            under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM
  1556.            and an encryption type of aes256-cts-hmac-sha1-96 (the
  1557.            encryption type used by the client in the PA-OTP-REQUEST).
  1558.            The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-
  1559.            REQUEST.
  1560.  
  1561.    15.  The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a
  1562.         PA-FX-FAST-REPLY.
  1563.  
  1564.  
  1565.  
  1566.  
  1567. Richards                  Expires March 8, 2009                [Page 28]
  1568.  
  1569. Internet-Draft           OTP Pre-authentication           September 2008
  1570.  
  1571.  
  1572.    16.  The KDC returns an AS-REP to the client, encrypted using the
  1573.         Reply Key, containing the TGT and padata with the PA-FX-FAST-
  1574.         REPLY.
  1575.  
  1576.    17.  The client authenticates the KDC and verifies the Reply Key
  1577.         change.
  1578.  
  1579.         *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-
  1580.            CONFIRM in the encData of the PA-OTP-CONFIRM.
  1581.  
  1582.         *  Authenticates the KDC by comparing the nonce value from the
  1583.            decrypted PA-OTP-ENC-CONFIRM to that sent in the
  1584.            corresponding PA-OTP-REQUEST.
  1585.  
  1586. B.2.  Two Pass Authentication
  1587.  
  1588.    In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-
  1589.    FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC.
  1590.  
  1591.    In this example, the user has been issued with a hand-held token and
  1592.    so none of the OTP generation parameters (otp-length etc) are
  1593.    included in the PA-OTP-REQUEST.  The KDC does not require hashed OTP
  1594.    values in the key generation.
  1595.  
  1596.    It is assumed that the client has been configured with the following
  1597.    information or has obtained it from a previous PA-OTP-CHALLENGE.
  1598.    o  The encryption type of aes128-cts-hmac-sha1-96 to use to encrypt
  1599.       the encData.
  1600.    o  The fact that hashed OTP values are not required.
  1601.  
  1602.    The basic sequence of steps involved is as follows:
  1603.  
  1604.    1.   The client obtains the user name and OTP value from the user.
  1605.  
  1606.    2.   The client generates Client Key and Reply Key using unhashed OTP
  1607.         values as described in Section 3.6.
  1608.  
  1609.    3.   The client constructs a PA-OTP-REQUEST as follows:
  1610.  
  1611.         flags
  1612.            0
  1613.  
  1614.         nonce
  1615.            A randomly generated value.
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623. Richards                  Expires March 8, 2009                [Page 29]
  1624.  
  1625. Internet-Draft           OTP Pre-authentication           September 2008
  1626.  
  1627.  
  1628.         encData
  1629.            An EncryptedData containing a PA-ENC-TS-ENC encrypted under
  1630.            the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and
  1631.            an encryption type of aes128-cts-hmac-sha1-96.  The PA-ENC-
  1632.            TS-ENC contains the current client time.
  1633.  
  1634.    4.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req
  1635.         of a PA-FX-FAST-REQUEST.
  1636.  
  1637.    5.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
  1638.         REQUEST within the padata.
  1639.  
  1640.    6.   The KDC validates the pre-authentication data:
  1641.  
  1642.         *  Generates the Client Key and Reply Key from the unhashed OTP
  1643.            value for the user identified in the AS-REQ.
  1644.  
  1645.         *  Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in
  1646.            the encData of the PA-OTP-REQUEST.
  1647.  
  1648.         *  Authenticates the user using the timestamp in the standard
  1649.            manner.
  1650.  
  1651.    7.   The KDC constructs a TGT for the user.
  1652.  
  1653.    8.   The KDC constructs a PA-OTP-CONFIRM as follows:
  1654.  
  1655.         encData
  1656.            An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted
  1657.            under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM
  1658.            and an encryption type of aes128-cts-hmac-sha1-96 (the
  1659.            encryption type used by the client in the PA-OTP-REQUEST).
  1660.            The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-
  1661.            REQUEST.
  1662.  
  1663.    9.   The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a
  1664.         PA-FX-FAST-REPLY.
  1665.  
  1666.    10.  The KDC returns an AS-REP to the client, encrypted using the
  1667.         Reply Key, containing the TGT and padata with the PA-FX-FAST-
  1668.         REPLY.
  1669.  
  1670.    11.  The client authenticates the KDC and verifies the key change.
  1671.  
  1672.         *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-
  1673.            CONFIRM in the encData of the PA-OTP-CONFIRM.
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679. Richards                  Expires March 8, 2009                [Page 30]
  1680.  
  1681. Internet-Draft           OTP Pre-authentication           September 2008
  1682.  
  1683.  
  1684.         *  Authenticates the KDC by comparing the nonce value from the
  1685.            decrypted PA-OTP-ENC-CONFIRM to that sent in the
  1686.            corresponding PA-OTP-REQUEST.
  1687.  
  1688. B.3.  Pin Change
  1689.  
  1690.    This exchange follows from the point where the KDC receives the PA-
  1691.    OTP-REQUEST from the client in the examples in Appendix B.1 and
  1692.    Appendix B.2.  During the validation of the pre-authentication data
  1693.    (whether encrypted nonce or encrypted timestamp), the KDC determines
  1694.    that the user's PIN has expired and so must be changed.  The KDC
  1695.    therefore includes a PA-OTP-PIN-CHANGE along with the PA-OTP-CONFIRM
  1696.    in the AS-REP.
  1697.  
  1698.    In this example, the KDC does not generate PIN values for the user
  1699.    but requires that the user generate a new PIN that is between 4 and 8
  1700.    characters in length.  The actual PIN change is handled by a PIN
  1701.    change service.
  1702.  
  1703.    The basic sequence of steps involved is as follows:
  1704.  
  1705.    1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as
  1706.         described in the previous examples.
  1707.  
  1708.    2.   The KDC validates the pre-authentication data and authenticates
  1709.         the user as in the previous examples but determines that the
  1710.         user's PIN has expired.
  1711.  
  1712.    3.   KDC constructs a ticket for a PIN change service with a one
  1713.         minute lifetime.
  1714.  
  1715.    4.   KDC constructs a PA-OTP-CONFIRM as in the previous examples.
  1716.  
  1717.    5.   KDC constructs a PA-OTP-PIN-CHANGE as follows:
  1718.  
  1719.         flags
  1720.            0
  1721.  
  1722.         minLength
  1723.            4
  1724.  
  1725.         maxLength
  1726.            8
  1727.  
  1728.    6.   KDC encrypts the PA-OTP-PIN-CHANGE and PA-OTP-CONFIRM within the
  1729.         enc-fast-rep of a PA-FX-FAST-REPLY.
  1730.  
  1731.  
  1732.  
  1733.  
  1734.  
  1735. Richards                  Expires March 8, 2009                [Page 31]
  1736.  
  1737. Internet-Draft           OTP Pre-authentication           September 2008
  1738.  
  1739.  
  1740.    7.   KDC returns an AS-REP to the client containing the ticket to the
  1741.         PIN change service and padata containing the PA-FX-FAST-REPLY.
  1742.  
  1743.    8.   The client authenticates the KDC as in the previous examples.
  1744.  
  1745.    9.   The client uses the ticket in the AS-REP to call the PIN change
  1746.         service and change the user's PIN.
  1747.  
  1748.    10.  The client sends a second AS-REQ to the KDC containing a PA-OTP-
  1749.         REQUEST constructed using the new PIN.
  1750.  
  1751.    11.  The KDC responds with an AS-REP containing a TGT and a PA-OTP-
  1752.         CONFRIM.
  1753.  
  1754.  
  1755. B.4.  Resynchronization
  1756.  
  1757.    This exchange follows from the point where the KDC receives the PA-
  1758.    OTP-REQUEST from the client.  During the validation of the pre-
  1759.    authentication data (whether encrypted nonce or encrypted timestamp),
  1760.    the KDC determines that the local record of the token's state needs
  1761.    to be re-synchronized with the token.  The KDC therefore includes a
  1762.    KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.
  1763.  
  1764.    The sequence of steps below follows is a variation of the four pass
  1765.    examples shown in Appendix B.1 but the same process would also work
  1766.    in the two-pass case.
  1767.  
  1768.    1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as
  1769.         described in the previous examples.
  1770.  
  1771.    2.   The KDC validates the pre-authentication data and authenticates
  1772.         the user as in the previous examples but determines that user's
  1773.         token requires re-synchronizing.
  1774.  
  1775.    3.   KDC constructs a PA-OTP-CHALLENGE as follows:
  1776.  
  1777.         flags
  1778.            nextOTP bit set
  1779.  
  1780.         nonce
  1781.            A randomly generated value.
  1782.  
  1783.         etype
  1784.            aes256-cts-hmac-sha1-96
  1785.  
  1786.  
  1787.  
  1788.  
  1789.  
  1790.  
  1791. Richards                  Expires March 8, 2009                [Page 32]
  1792.  
  1793. Internet-Draft           OTP Pre-authentication           September 2008
  1794.  
  1795.  
  1796.         supportedHashAlg
  1797.            AlgorithmIdentifiers for SHA-256 and SHA-1
  1798.  
  1799.         iterationCount
  1800.            1024
  1801.  
  1802.         otp-service
  1803.            Set to a string that can be used by the client to assist the
  1804.            user in locating the correct token.
  1805.  
  1806.    4.   KDC returns a KRB-ERROR with an error code of
  1807.         KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
  1808.  
  1809.    5.   The client obtains the next OTP value from the token and records
  1810.         the time as reported by the token.
  1811.  
  1812.    6.   The client generates Client Key Reply Key as described in
  1813.         Section 3.6 using SHA-256 from the list of algorithms sent by
  1814.         the KDC and the iteration count of 100,000 as required by local
  1815.         policy.
  1816.  
  1817.    7.   The client constructs a PA-OTP-REQUEST as follows:
  1818.  
  1819.         flags
  1820.            nextOTP bit set
  1821.  
  1822.         nonce
  1823.            A randomly generated value.
  1824.  
  1825.         encData
  1826.            An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted
  1827.            under the Client Key with a key usage of
  1828.            KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-
  1829.            hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from
  1830.            the PA-OTP-CHALLENGE.
  1831.  
  1832.         hashAlg
  1833.            SHA-256
  1834.  
  1835.         iterationCount
  1836.            100,000
  1837.  
  1838.         otp-time
  1839.            The time used in the OTP calculation as reported by the OTP
  1840.            token.
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847. Richards                  Expires March 8, 2009                [Page 33]
  1848.  
  1849. Internet-Draft           OTP Pre-authentication           September 2008
  1850.  
  1851.  
  1852.    8.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req
  1853.         of a PA-FX-FAST-REQUEST.
  1854.  
  1855.    9.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-
  1856.         REQUEST within the padata.
  1857.  
  1858.    10.  Authentication process now proceeds as with the standard
  1859.         sequence.
  1860.  
  1861.  
  1862. Author's Address
  1863.  
  1864.    Gareth Richards
  1865.    RSA, The Security Division of EMC
  1866.    RSA House
  1867.    Western Road
  1868.    Bracknell, Berkshire  RG12 1RT
  1869.    UK
  1870.  
  1871.    Email: gareth.richards@rsa.com
  1872.  
  1873.  
  1874.  
  1875.  
  1876.  
  1877.  
  1878.  
  1879.  
  1880.  
  1881.  
  1882.  
  1883.  
  1884.  
  1885.  
  1886.  
  1887.  
  1888.  
  1889.  
  1890.  
  1891.  
  1892.  
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903. Richards                  Expires March 8, 2009                [Page 34]
  1904.  
  1905. Internet-Draft           OTP Pre-authentication           September 2008
  1906.  
  1907.  
  1908. Full Copyright Statement
  1909.  
  1910.    Copyright (C) The IETF Trust (2008).
  1911.  
  1912.    This document is subject to the rights, licenses and restrictions
  1913.    contained in BCP 78, and except as set forth therein, the authors
  1914.    retain all their rights.
  1915.  
  1916.    This document and the information contained herein are provided on an
  1917.    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  1918.    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
  1919.    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
  1920.    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  1921.    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  1922.    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1923.  
  1924.  
  1925. Intellectual Property
  1926.  
  1927.    The IETF takes no position regarding the validity or scope of any
  1928.    Intellectual Property Rights or other rights that might be claimed to
  1929.    pertain to the implementation or use of the technology described in
  1930.    this document or the extent to which any license under such rights
  1931.    might or might not be available; nor does it represent that it has
  1932.    made any independent effort to identify any such rights.  Information
  1933.    on the procedures with respect to rights in RFC documents can be
  1934.    found in BCP 78 and BCP 79.
  1935.  
  1936.    Copies of IPR disclosures made to the IETF Secretariat and any
  1937.    assurances of licenses to be made available, or the result of an
  1938.    attempt made to obtain a general license or permission for the use of
  1939.    such proprietary rights by implementers or users of this
  1940.    specification can be obtained from the IETF on-line IPR repository at
  1941.    http://www.ietf.org/ipr.
  1942.  
  1943.    The IETF invites any interested party to bring to its attention any
  1944.    copyrights, patents or patent applications, or other proprietary
  1945.    rights that may cover technology that may be required to implement
  1946.    this standard.  Please address the information to the IETF at
  1947.    ietf-ipr@ietf.org.
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959. Richards                  Expires March 8, 2009                [Page 35]
  1960.  
  1961.