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-02.txt < prev    next >
Text File  |  2014-05-02  |  42KB  |  1,121 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                        G. Richards
  5. Internet-Draft                         RSA, The Security Division of EMC
  6. Intended status: Standards Track                        January 17, 2008
  7. Expires: July 20, 2008
  8.  
  9.  
  10.                          OTP Preauthentication
  11.                     draft-ietf-krb-wg-otp-preauth-02
  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 July 20, 2008.
  37.  
  38. Copyright Notice
  39.  
  40.    Copyright (C) The IETF Trust (2008).
  41.  
  42. Abstract
  43.  
  44.    The Kerberos protocol provides a framework authenticating a client
  45.    using the exchange of pre-authentication data.  This document
  46.    describes the use of this framework to carry out One Time Password
  47.    (OTP) authentication.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Richards                  Expires July 20, 2008                 [Page 1]
  56.  
  57. Internet-Draft            OTP Preauthentication             January 2008
  58.  
  59.  
  60. Table of Contents
  61.  
  62.    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63.    2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  4
  64.      2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  4
  65.      2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  5
  66.      2.3.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  5
  67.    3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  5
  68.      3.1.  Initial Client Request . . . . . . . . . . . . . . . . . .  5
  69.      3.2.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  6
  70.      3.3.  Client Response  . . . . . . . . . . . . . . . . . . . . .  6
  71.      3.4.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  7
  72.      3.5.  Confirming the Reply Key Change  . . . . . . . . . . . . .  8
  73.      3.6.  Reply Key Generation . . . . . . . . . . . . . . . . . . .  8
  74.    4.  OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 10
  75.      4.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 10
  76.      4.2.  PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 12
  77.      4.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 14
  78.      4.4.  PA-OTP-PIN-CHANGE  . . . . . . . . . . . . . . . . . . . . 15
  79.    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
  80.    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
  81.      6.1.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . . . 16
  82.      6.2.  Reflection . . . . . . . . . . . . . . . . . . . . . . . . 16
  83.      6.3.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  84.      6.4.  FAST Facilities  . . . . . . . . . . . . . . . . . . . . . 16
  85.    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  86.      7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
  87.      7.2.  Informative References . . . . . . . . . . . . . . . . . . 17
  88.    Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 17
  89.    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
  90.    Intellectual Property and Copyright Statements . . . . . . . . . . 20
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. Richards                  Expires July 20, 2008                 [Page 2]
  112.  
  113. Internet-Draft            OTP Preauthentication             January 2008
  114.  
  115.  
  116. 1.  Introduction
  117.  
  118.    A One-Time Password (OTP) token may be a handheld hardware device, a
  119.    hardware device connected to a personal computer through an
  120.    electronic interface such as USB or a software module resident on a
  121.    personal computer.  All these devices generate one-time passwords
  122.    that may be used to authenticate a user towards some service.  This
  123.    document describes a FAST [ZhHa07] factor that allows OTP values to
  124.    be used in the Kerberos V5 [RFC4120] pre-authentication in a manner
  125.    that does not require use of the user's Kerberos password.
  126.  
  127.    This FAST factor provides the following facilities (as defined in
  128.    [ZhHa07]): client-authentication, replacing-reply-key and KDC-
  129.    authentication.  It does not provide the strengthening-reply-key
  130.    facility.
  131.  
  132.    This proposal supports 4-pass and 2-pass variants.  In the 4-pass
  133.    system, the client sends the KDC an initial AS-REQ and the KDC
  134.    responds with a KRB-ERROR containing padata that includes a random
  135.    nonce.  The client then encrypts the nonce and returns it along with
  136.    its own random value to the KDC in a second AS-REQ.  Finally, the KDC
  137.    returns the client's random value encrypted within the padata of the
  138.    AS-REP.  In the 2-pass variant, the client encrypts a timestamp
  139.    rather than a nonce from the KDC and the encrypted data is sent to
  140.    the KDC in the initial AS-REQ.  This variant can be used in cases
  141.    where the client can determine in advance that OTP pre-authentication
  142.    is supported by the KDC and which OTP key should be used.
  143.  
  144.    In both systems, in order to create the message sent to the KDC, the
  145.    client must generate the OTP value and three keys: the standard Reply
  146.    Key, a key to encrypt the data sent to the KDC and a final key to
  147.    decrypt the KDC's reply.  In most cases, the OTP value will be used
  148.    in the key generation but in order to support algorithms where the
  149.    KDC cannot obtain the value, the system also supports the option of
  150.    including the OTP value in the request along with the encrypted
  151.    nonce.  In addition, in order to support situations where the KDC is
  152.    unable to obtain the plaintext OTP value, the system also supports
  153.    the use of hashed OTP values in the key derivation.
  154.  
  155.    The message from the client to the KDC is sent within the encrypted
  156.    data provided by the FAST padata type of the AS-REQ.  The KDC then
  157.    obtains the OTP value, generates the same keys and verifies the pre-
  158.    authentication data by decrypting the nonce.  If the verification
  159.    succeeds then it confirms knowledge of the Reply Key by returning the
  160.    client's nonce encrypted under one of the generated keys within the
  161.    encrypted part of the FAST padata of the AS-REP.
  162.  
  163.    This proposal is partially based upon previous work on integrating
  164.  
  165.  
  166.  
  167. Richards                  Expires July 20, 2008                 [Page 3]
  168.  
  169. Internet-Draft            OTP Preauthentication             January 2008
  170.  
  171.  
  172.    single-use authentication mechanisms into Kerberos [HoReNeZo04] and
  173.    uses the existing password-change extensions to handle PIN change as
  174.    described in [RFC3244].
  175.  
  176.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  177.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  178.    document are to be interpreted as described in [RFC2119].
  179.  
  180.  
  181. 2.  Usage Overview
  182.  
  183. 2.1.  Pre-Authentication
  184.  
  185.    The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
  186.    and KRB_ERROR messages.
  187.  
  188.    In the 4-pass system, the client begins by sending an initial
  189.    KRB_AS_REQ to the KDC that may contain pre-authentication data such
  190.    as the standard Kerberos password data.  The KDC will then determine,
  191.    in an implementation dependent fashion, whether OTP authentication is
  192.    required and if it is, it will respond with a KRB_ERROR message
  193.    containing a PA-OTP-CHALLENGE in the PA-DATA.
  194.  
  195.    The PA-OTP-CHALLENGE will contain a KDC generated nonce, an
  196.    encryption type, an optional list of hash algorithm identifiers, an
  197.    optional iteration count and optional information on how the OTP
  198.    should be generated by the client.  The client will then generate the
  199.    OTP value, its own nonce and three keys: the Reply Key, a Client Key
  200.    to encrypt the KDC's nonce and a Server Key used to decrypt the KDC's
  201.    reply.
  202.  
  203.    As described in Section 3.6, these keys will be generated from the
  204.    Armor Key (defined in [ZhHa07]) and the OTP value unless the OTP
  205.    algorithm does not allow the KDC to obtain the OTP value.  If hash
  206.    algorithm identifiers were included in the request then the client
  207.    will use the hash of the OTP value rather than the plaintext value in
  208.    the key generation.
  209.  
  210.    The generated Client Key will be used to encrypt the nonce received
  211.    from the KDC using the specified encryption type.  The encrypted
  212.    value, a random nonce generated by the client along with information
  213.    on how the OTP was generated are then sent to the KDC in a PA-OTP-
  214.    REQUEST element encrypted within the armored-data of a PA-FX-FAST-
  215.    REQUEST PA-DATA element of a second KRB_AS_REQ.
  216.  
  217.    In the 2-pass system, the client sends the PA-OTP-REQUEST in the
  218.    initial AS-REQ instead of sending it in response to a PA-OTP-
  219.    CHALLENGE returned by the KDC.  Since no challenge is received from
  220.  
  221.  
  222.  
  223. Richards                  Expires July 20, 2008                 [Page 4]
  224.  
  225. Internet-Draft            OTP Preauthentication             January 2008
  226.  
  227.  
  228.    the KDC, the client includes an encrypted timestamp in the request
  229.    rather than the encrypted KDC nonce.
  230.  
  231.    On receipt of a PA-OTP-REQUEST, the KDC generate the same keys as the
  232.    client, and use the generated Client Key to verify the pre-
  233.    authentication by decrypting the encrypted data sent by the client
  234.    (either nonce or timestamp).  If the validation succeeds then the KDC
  235.    will confirm that the Reply Key was updated by encrypting the
  236.    client's nonce under the Server Key and returning the encrypted value
  237.    in a PA-OTP-CONFIRM element encrypted within the armored-data of a
  238.    PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP.
  239.  
  240. 2.2.  PIN Change
  241.  
  242.    If, following successful validation of a PA-OTP-REQUEST in a
  243.    KRB_AS_REQ, the KDC requires that the user changes their PIN then it
  244.    will include a PA-OTP-PIN-CHANGE element in the armored data of the
  245.    PA-FX-FAST-REPLY PA-DATA element of the KRB_AS_REP.  This data can be
  246.    used to return a new PIN to the user if the KDC has updated the PIN
  247.    or to indicate to the user that they must change their PIN.
  248.  
  249.    In the latter case, it is recommended that user PIN change be handled
  250.    by a PIN change service supporting the ChangePasswdData in a
  251.    KRB_AP_REQ as described in [RFC3244].  If a user PIN change is
  252.    required and such a service is used then the KDC MAY return a TGT in
  253.    the KRB_AS_REP but it is RECOMMENDED that it return an INITIAL ticket
  254.    for the PIN change service until the PIN has been changed.
  255.  
  256. 2.3.  Re-Synchronization
  257.  
  258.    It is possible with time and event-based tokens that the client and
  259.    OTP server will lose synchronization.  If, when processing a PA-OTP-
  260.    REQUEST, the pre-authentication validation fails for this reason then
  261.    the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
  262.    CHALLENGE in the PA-DATA with the "nextOTP" flag set.  If this flag
  263.    is set then the client MUST re-try the authentication using the OTP
  264.    for the token "state" after that used in the failed authentication
  265.    attempt.
  266.  
  267.  
  268. 3.  Pre-Authentication Protocol Details
  269.  
  270. 3.1.  Initial Client Request
  271.  
  272.    The client begins by sending an initial KRB_AS_REQ possibly
  273.    containing other pre-authentication data.  If the KDC determines that
  274.    OTP-based pre-authentication is required and the request does not
  275.    contain a PA-OTP-REQUEST then it will respond as described in
  276.  
  277.  
  278.  
  279. Richards                  Expires July 20, 2008                 [Page 5]
  280.  
  281. Internet-Draft            OTP Preauthentication             January 2008
  282.  
  283.  
  284.    Section 3.2.
  285.  
  286.    Alternatively, if the client has all the necessary information, it
  287.    MAY construct a PA-OTP-REQUEST as described in Section 3.3 and
  288.    include it in the initial request.
  289.  
  290. 3.2.  KDC Challenge
  291.  
  292.    If the user is required to authenticate using an OTP then the KDC
  293.    SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:
  294.  
  295.    o  An error code of KDC_ERR_PREAUTH_REQUIRED
  296.  
  297.    o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
  298.  
  299.    The PA-OTP-CHALLENGE SHALL contain a random nonce value to be
  300.    returned encrypted in the client response and the enctype to be used
  301.    by the client to encrypt the nonce.
  302.  
  303.    In order to support situations where the KDC can determine which OTP
  304.    key the client should use, the challenge MAY also contain information
  305.    on how the OTP value is to be generated.
  306.  
  307.    In addition, in order to support cases where the KDC cannot obtain
  308.    plaintext values for the OTPs, the challenge MAY also contain a
  309.    sequence of one way hash function algorithm identifiers and a minimum
  310.    value of the iteration count to be used by the client when hashing
  311.    the OTP value.
  312.  
  313. 3.3.  Client Response
  314.  
  315.    The client response SHALL be sent to the KDC as a PA-OTP-REQUEST
  316.    included within the enc-fast-req of a PA-FX-FAST-REQUEST encrypted
  317.    under the current Armor Key.
  318.  
  319.    In order to generate its response, the client first generates an OTP
  320.    value.  The OTP value MUST be based on the parameters in the KDC
  321.    challenge if present and the response SHOULD include information on
  322.    the generated OTP value.
  323.  
  324.    The client derives three keys as described in Section 3.6.  In order
  325.    to support OTP algorithms where the KDC cannot obtain the OTP value,
  326.    the client MAY include the generated value in the otp-value field of
  327.    the response.  However, the client MUST NOT include the OTP value in
  328.    the response unless it is allowed by the algorithm profile.  If it is
  329.    included then the OTP value MUST NOT be used in the key derivation.
  330.  
  331.    If the KDC challenge contains hash algorithm identifiers and the OTP
  332.  
  333.  
  334.  
  335. Richards                  Expires July 20, 2008                 [Page 6]
  336.  
  337. Internet-Draft            OTP Preauthentication             January 2008
  338.  
  339.  
  340.    value is to be used in the key derivation then the client MUST select
  341.    one of the algorithms and MUST use the hash of the OTP value to
  342.    derive the keys as described in Section 3.6.  The selected algorithm
  343.    identifier and the iteration count used MUST be included in the
  344.    client's response.  If the algorithm identifiers do not conform to
  345.    local policy restrictions then the authentication attempt MUST NOT
  346.    proceed.  If the iteration count does not conform to local policy
  347.    then the client MAY use a higher value but MUST NOT use a lower
  348.    value.  That is, the value in the KDC challenge is a minimum value.
  349.  
  350.    The generated Client Key is used by the client to encrypt data to be
  351.    included in the encData of the response to allow the KDC to
  352.    authenticate the user.
  353.  
  354.    o  If the response is being generated in response to a KDC challenge
  355.       then client encrypts the value of nonce from the corresponding
  356.       challenge.
  357.  
  358.    o  If the response is not in response to a KDC challenge then the
  359.       client encrypts the current time as in the encrypted timestamp
  360.       pre-authentication mechanism [RFC4120].
  361.  
  362.    Finally, the client generates a random value to include in the nonce
  363.    of the response.  This value will then be returned encrypted by the
  364.    KDC.
  365.  
  366. 3.4.  Verifying the pre-auth Data
  367.  
  368.    The KDC validates the pre-authentication data by generating the same
  369.    keys as the client as described in Section 3.6.  The generated Client
  370.    Key is used to decrypt the value of encData from the PA-OTP-REQUEST.
  371.  
  372.    If the otp-value field is not included in the response, then the KDC
  373.    SHOULD use any OTP information in the PA-OTP-REQUEST to obtain the
  374.    OTP value in order to generate the keys.  If the hashAlg field is
  375.    present then the hash of the OTP value, as given by the hash
  376.    algorithm identifier, was used in the key generation rather than the
  377.    plaintext value.
  378.  
  379.    The client authentication MUST fail if the KDC requires hashed OTP
  380.    values and the hashAlg field was not present or if the hash algorithm
  381.    identifier or iteration count included in the PA-OTP-REQUEST do not
  382.    conform to local KDC policy.  In such situations, the KDC MAY return
  383.    a PA-OTP-CHALLENGE with the required values in the error response.
  384.    For example, this technique could be used to return required values
  385.    to the client in response to a PA-OTP-REQUEST that was not the result
  386.    of a PA-OTP-CHALLENGE.
  387.  
  388.  
  389.  
  390.  
  391. Richards                  Expires July 20, 2008                 [Page 7]
  392.  
  393. Internet-Draft            OTP Preauthentication             January 2008
  394.  
  395.  
  396.    If the client response was sent as a result of a PA-OTP-CHALLENGE
  397.    then the client authentication MUST fail if the decrypted value is
  398.    not the same as the nonce value sent in the challenge.  If the
  399.    response was not sent as a result of a PA-OTP-CHALLENGE then the
  400.    decrypted value will be a PA-ENC-TIMESTAMP and the authentication
  401.    process will be the same as with standard encrypted timestamp pre-
  402.    authentication [RFC4120]
  403.  
  404. 3.5.  Confirming the Reply Key Change
  405.  
  406.    If the pre-authentication data was successfully verified, then in
  407.    order to support mutual authentication, the KDC SHALL respond to the
  408.    client's PA-OTP-REQUEST by including in the AS-REP, the client nonce
  409.    from PA-OTP-REQUEST encrypted under the generated Server Key.
  410.  
  411.    The KDC response SHALL be sent to client as a PA-OTP-CONFIRM included
  412.    within the enc-fast-rep of a PA-FX-FAST-REPLY encrypted under the
  413.    current Armor Key.
  414.  
  415. 3.6.  Reply Key Generation
  416.  
  417.    In order to authenticate the user, the client and KDC need to
  418.    generate three encryption keys:
  419.  
  420.    o  The Client Key to be used by the client to encrypt and by the KDC
  421.       to decrypt the encData in the PA-OTP-REQUEST.
  422.  
  423.    o  The Server Key to be used by the KDC to encrypt and by the client
  424.       to decrypt the encData value in the PA-OTP-CONFIRM.
  425.  
  426.    o  The Reply Key will be used in the standard manner by the KDC to
  427.       encrypt data in the AS-REP.
  428.  
  429.    The method used to generate the three keys will depend on the OTP
  430.    algorithm.
  431.  
  432.    o  If the OTP value is included in the otp-value of the PA-OTP-
  433.       REQUEST then all three keys SHALL be the same as the Armor Key
  434.       (defined in [ZhHa07]).
  435.  
  436.    o  If the OTP value is not included in the otp-value of the PA-OTP-
  437.       REQUEST then the three keys SHALL be derived from the Armor Key
  438.       and the OTP value as described below.
  439.  
  440.    If the OTP value is not included in the client response, then the
  441.    Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from
  442.    [ZhHa07]
  443.  
  444.  
  445.  
  446.  
  447. Richards                  Expires July 20, 2008                 [Page 8]
  448.  
  449. Internet-Draft            OTP Preauthentication             January 2008
  450.  
  451.  
  452.              ClientKey = KRB_FX_CF2(K1, K2, O1, O2)
  453.              ServerKey = KRB_FX_CF2(K1, K2, O3, O4)
  454.              ReplyKey = KRB_FX_CF2(K1, K2, O5, O6)
  455.  
  456.    The first input keys, K1, shall be the Armor Key. The second input
  457.    key, K2, shall be derived from the OTP value using string-to-key
  458.    (defined in [RFC3961]).
  459.  
  460.    The octet string parameters, O1, O2, O3, O4, O5 and O6, shall be the
  461.    ASCII string "Combine1" to "Combine6".  For example, O1 and O2 have
  462.    the following byte values:
  463.  
  464.       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31}
  465.       {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32}
  466.  
  467.    If the hash of the OTP value is to be used then K2 SHALL be derived
  468.    as follows:
  469.  
  470.    o  An initial hash value, H, is generated:
  471.  
  472.              H = hash(sname|nonce|OTP)
  473.  
  474.       Where:
  475.       *  "|" denotes concatenation
  476.       *  hash is the hash algorithm selected by the client.
  477.       *  sname is the principal name of the KDC as included in the AS-
  478.          REQ.
  479.       *  nonce is the random nonce value generated by the client to be
  480.          included in the PA-OTP-REQUEST.
  481.       *  OTP is the OTP value.
  482.  
  483.    o  The initial hash value is then hashed iterationCount-1 times to
  484.       produce a final hash value, H'.  (Where iterationCount is the
  485.       value from the PA-OTP-REQUEST.)
  486.  
  487.              H' = hash(hash(...(iterationCount-1 times)...(H)))
  488.  
  489.    o  The value of K2 is then derived from the base64 [RFC2045] encoding
  490.       of this final hash value.
  491.  
  492.              K2 = string-to-key(Base64(H')||"Krb-preAuth")
  493.  
  494.    If the OTP value is binary and the hash value is not used, then K2
  495.    SHALL be derived from the base64 encoding of the OTP value.
  496.  
  497.              K2 = string-to-key(Base64(OTP)||"Krb-preAuth")
  498.  
  499.    If the OTP value is not binary and the hash value is not used, then
  500.  
  501.  
  502.  
  503. Richards                  Expires July 20, 2008                 [Page 9]
  504.  
  505. Internet-Draft            OTP Preauthentication             January 2008
  506.  
  507.  
  508.    K2 SHALL be derived by running the OTP value once through string-to-
  509.    key.
  510.  
  511.              K2 = string-to-key(OTP||"Krb-preAuth")
  512.  
  513.    The salt and additional parameters for string-to-key will be as
  514.    defined in section 3.1.3 of [RFC4120].  The symbol "||" denotes
  515.    string concatenation.
  516.  
  517.  
  518. 4.  OTP Kerberos Message Types
  519.  
  520. 4.1.  PA-OTP-CHALLENGE
  521.  
  522.    The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in
  523.    the PA-DATA of a KRB_ERROR when pre-authentication using an OTP value
  524.    is required.  The corresponding padata-value field contains the DER
  525.    encoding of a PA-OTP-CHALLENGE containing a server generated nonce
  526.    and information for the client on how to generate the OTP.
  527.  
  528.              PA_OTP_CHALLENGE     << TBA >>
  529.  
  530.              PA-OTP-CHALLENGE ::= SEQUENCE {
  531.                flags              OTPFlags,
  532.                nonce              UInt32,
  533.                etype              INTEGER,
  534.                supportedHashAlg   SEQUENCE OF AlgorithmIdentifier
  535.                                                   OPTIONAL,
  536.                iterationCount     INTEGER         OPTIONAL,
  537.                otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,
  538.                otp-length     [0] INTEGER         OPTIONAL,
  539.                otp-service        UTF8String      OPTIONAL,
  540.                otp-keyID      [1] OCTET STRING    OPTIONAL,
  541.                otp-algID      [2] INTEGER         OPTIONAL,
  542.                ...
  543.              }
  544.  
  545.              OTPFlags ::= KerberosFlags
  546.              -- nextOTP (0)
  547.  
  548.    flags
  549.       If the "nextOTP" flag is set then the OTP SHALL be based on the
  550.       next token "state" rather than the current one.  As an example,
  551.       for a time-based token, this means the next time slot.  For an
  552.       event-based token, this could mean the next counter value, if
  553.       counter values are used.
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Richards                  Expires July 20, 2008                [Page 10]
  560.  
  561. Internet-Draft            OTP Preauthentication             January 2008
  562.  
  563.  
  564.    nonce
  565.       A KDC-supplied nonce value to be encrypted by the client in the
  566.       PA-OTP-REQUEST.
  567.  
  568.    etype
  569.       The encryption type to be used by the client to encrypt the nonce
  570.       in the PA-OTP-REQUEST.
  571.  
  572.    supportedHashAlg
  573.       If present then a hash of the OTP value MUST be used in the key
  574.       derivation rather than the plain text value.  Each
  575.       AlgorithmIdentifier identifies a hash algorithm that is supported
  576.       by the KDC in decreasing order of preference.  The client MUST
  577.       select the first algorithm from the list that it supports.
  578.       Support for SHA1 by both the client and KDC is REQUIRED.  The
  579.       AlgorithmIdentifer selected by the client MUST be placed in the
  580.       hashAlg element of the PA-OTP-REQUEST.
  581.  
  582.    iterationCount
  583.       The minimum value of the iteration count to be used by the client
  584.       when hashing the OTP value.  This value MUST be present if and
  585.       only if supportedHashAlg is present.  If the value of this element
  586.       does not conform to local policy on the client then the client MAY
  587.       use a larger value but MUST NOT use a lower value.  The value of
  588.       the iteration count used by the client MUST be returned in the PA-
  589.       OTP-REQUEST sent to the KDC.
  590.  
  591.    otp-challenge
  592.       The otp-challenge is used by the KDC to send a challenge value for
  593.       use in the OTP calculation.  The challenge is an optional octet
  594.       string that SHOULD be uniquely generated for each request it is
  595.       present in, and SHOULD be eight octets or longer when present.
  596.       When the challenge is not present, the OTP will be calculated on
  597.       the current token state only.  The client MAY ignore a provided
  598.       challenge if and only if the OTP token the client is interacting
  599.       with is not capable of including a challenge in the OTP
  600.       calculation.  In this case, KDC policies will determine whether to
  601.       accept a provided OTP value or not.
  602.  
  603.    otp-length
  604.       The otp-length is used by the KDC to specify the desired length of
  605.       the generated OTP.
  606.  
  607.    otp-service
  608.       An identifier of the service supported by the KDC.  This value can
  609.       be used by the client to locate the OTP key to use.
  610.  
  611.  
  612.  
  613.  
  614.  
  615. Richards                  Expires July 20, 2008                [Page 11]
  616.  
  617. Internet-Draft            OTP Preauthentication             January 2008
  618.  
  619.  
  620.    otp-keyID
  621.       The identifier of the OTP key to be used in the OTP calculation.
  622.       If this value is not present then the client SHOULD use other
  623.       values such as the otp-service and otp-algID to locate the
  624.       appropriate key.
  625.  
  626.    otp-algID
  627.       The identifier of the algorithm to use when generating the OTP.
  628.  
  629. 4.2.  PA-OTP-REQUEST
  630.  
  631.    The padata-type PA_OTP_RESPONSE is sent by the client to the KDC in
  632.    the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the
  633.    PA-DATA of an AS-REQ.  The corresponding padata-value field contains
  634.    the DER encoding of a PA-OTP-REQUEST.
  635.  
  636.    The message contains pre-authentication data encrypted by the client
  637.    using the generated Client Key and information on how the OTP was
  638.    generated.  It may also, optionally, contain the generated OTP value.
  639.  
  640.            PA_OTP_REQUEST     << TBA >>
  641.  
  642.            PA-OTP-REQUEST ::= SEQUENCE {
  643.              flags             OTPFlags,
  644.              nonce             UInt32,
  645.              encData           EncryptedData,
  646.                                -- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP
  647.                                -- Key usage of KEY_USAGE_OTP_REQUEST
  648.              hashAlg           AlgorithmIdentifier OPTIONAL,
  649.              iterationCount    INTEGER         OPTIONAL,
  650.              otp-value         OCTET STRING    OPTIONAL,
  651.              otp-challenge [0] OCTET STRING    OPTIONAL,
  652.              otp-time          KerberosTime    OPTIONAL,
  653.              otp-counter   [1] OCTET STRING    OPTIONAL,
  654.              otp-format    [2] OTPFormat       OPTIONAL,
  655.              otp-keyID     [3] OCTET STRING    OPTIONAL,
  656.              otp-algID     [4] INTEGER         OPTIONAL,
  657.              ...
  658.            }
  659.  
  660.            KEY_USAGE_OTP_REQUEST  << TBA >>
  661.  
  662.  
  663.              PA-OTP-ENC-REQUEST ::= SEQUENCE {
  664.                nonce     OCTET STRING,
  665.                ...
  666.              }
  667.  
  668.  
  669.  
  670.  
  671. Richards                  Expires July 20, 2008                [Page 12]
  672.  
  673. Internet-Draft            OTP Preauthentication             January 2008
  674.  
  675.  
  676.              OTPFormat ::= INTEGER {
  677.                decimal(0),
  678.                hexadecimal(1),
  679.                alphanumeric(2),
  680.                binary(3)
  681.              }
  682.  
  683.    flags
  684.       If the "nextOTP" flag is set then the OTP was calculated based on
  685.       the next token "state" rather than the current one.  This flag
  686.       MUST be set if and only if it was set in a corresponding PA-OTP-
  687.       CHALLENGE.
  688.  
  689.    nonce
  690.       A random nonce value generated by the client.
  691.  
  692.    encData
  693.       If the PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE
  694.       then this MUST contain the nonce from the challenge encrypted
  695.       under the Client Key. If no challenge was received then this MUST
  696.       contain a PA-ENC-TIMESTAMP encrypted under the Client Key.
  697.  
  698.    hashAlg
  699.       This field MUST be present if a hash of the OTP value was used as
  700.       input to string-to-key (see Section 3.6) and MUST contain the
  701.       AlgorithmIdentifier of the hash algorithm used.  If the PA-OTP-
  702.       REQUEST is sent as a result of a PA-OTP-CHALLENGE then the
  703.       AlgorithmIdentifer MUST be one of those specified in the
  704.       supportedHashAlg of the PA-OTP-CHALLENGE.
  705.  
  706.    iterationCount
  707.       This field MUST be present if a hash of the OTP value was used as
  708.       input to string-to-key (see Section 3.6) and MUST contain the
  709.       iteration count used when hashing the OTP value.  If the PA-OTP-
  710.       REQUEST is sent as a result of a PA-OTP-CHALLENGE then the value
  711.       MUST NOT be less that that specified in the PA-OTP-CHALLENGE.
  712.  
  713.    otp-value
  714.       The generated OTP value.  This value MUST NOT be present unless
  715.       allowed by the OTP algorithm profile.
  716.  
  717.    otp-challenge
  718.       Value used by the client in the OTP calculation.  It MUST be sent
  719.       to the KDC if and only if the value would otherwise be unknown to
  720.       the KDC.  For example, the token or client modified or generated
  721.       challenge.
  722.  
  723.  
  724.  
  725.  
  726.  
  727. Richards                  Expires July 20, 2008                [Page 13]
  728.  
  729. Internet-Draft            OTP Preauthentication             January 2008
  730.  
  731.  
  732.    otp-time
  733.       Value used by the client to send the time used in the OTP
  734.       calculation.
  735.  
  736.    otp-counter
  737.       The counter value used in the OTP calculation.  Use of this
  738.       element is OPTIONAL but it MAY be used by a client to simplify the
  739.       OTP calculations of the KDC to contain the counter value as
  740.       reported by the OTP token.
  741.  
  742.    otp-format
  743.       The format of the generated OTP.
  744.  
  745.    otp-keyID
  746.       The identifier of the OTP key used.
  747.  
  748.    otp-algID
  749.       The identifier of the algorithm to used to generate the OTP.
  750.  
  751. 4.3.  PA-OTP-CONFIRM
  752.  
  753.    The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc-
  754.    fast-rep of a PA-FX-FAST-REPLY in the KRB_AS_REP of the KDC.  It is
  755.    used to return the client's nonce encrypted under the new Server Key
  756.    in order to confirm that the KDC has knowledge of this key.
  757.  
  758.    The corresponding padata-value field contains the DER encoding of a
  759.    PA-OTP-CONFIRM.
  760.  
  761.             PA_OTP_CONFIRM     << TBA >>
  762.  
  763.             PA-OTP-CONFIRM ::= SEQUENCE {
  764.               encData        EncryptedData,
  765.                                    -- PA-OTP-ENC-CONFIRM
  766.                                    -- Key usage of KEY_USAGE_OTP_CONFIRM
  767.               ...
  768.             }
  769.  
  770.             KEY_USAGE_OTP_CONFIRM  << TBA >>
  771.  
  772.  
  773.              PA-OTP-ENC-CONFIRM ::= SEQUENCE {
  774.                nonce     OCTET STRING,
  775.                ...
  776.              }
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783. Richards                  Expires July 20, 2008                [Page 14]
  784.  
  785. Internet-Draft            OTP Preauthentication             January 2008
  786.  
  787.  
  788.    encData
  789.       The value of nonce from the corresponding PA-OTP-REQUEST encrypted
  790.       under the current Server Key.
  791.  
  792. 4.4.  PA-OTP-PIN-CHANGE
  793.  
  794.    The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the enc-
  795.    fast-rep of a PA-FX-FAST-REPLY in the KRB_AS_REP if the user must
  796.    change their PIN or if the user's PIN has been changed.
  797.  
  798.    The corresponding padata-value field contains the DER encoding of a
  799.    PA-OTP-PIN-CHANGE.
  800.  
  801.              PA_OTP_PIN_CHANGE     << TBA >>
  802.  
  803.              PA-OTP-PIN-CHANGE ::= SEQUENCE {
  804.                flags         PinFlags,
  805.                pin           UTF8String OPTIONAL,
  806.                minLength     INTEGER    OPTIONAL,
  807.                maxLength [1] INTEGER    OPTIONAL,
  808.                ...
  809.              }
  810.  
  811.              PinFlags ::= KerberosFlags
  812.                -- systemSetPin (0)
  813.  
  814.    If the "systemSetPin" flag is set then the user's PIN has been
  815.    changed and the new PIN value is contained in the pin field.  The pin
  816.    field MUST therefore be present.
  817.  
  818.    If the "systemSetPin" flag is not set then the user's PIN has not
  819.    been changed by the server but it MUST instead be changed by the
  820.    user.  Restrictions on the size of the PIN MAY be given by the
  821.    minLength and maxLength fields.  If the pin field is present then it
  822.    contains a PIN value that MAY be used by the user when changing the
  823.    PIN.
  824.  
  825.  
  826. 5.  IANA Considerations
  827.  
  828.    A registry may be required for the otp-AlgID values as introduced in
  829.    Section 4.1.  No other IANA actions are anticipated.
  830.  
  831.  
  832. 6.  Security Considerations
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839. Richards                  Expires July 20, 2008                [Page 15]
  840.  
  841. Internet-Draft            OTP Preauthentication             January 2008
  842.  
  843.  
  844. 6.1.  Man-in-the-Middle
  845.  
  846.    In the system described in this document, the OTP pre-authentication
  847.    protocol is tunneled within the FAST Armor channel provided by the
  848.    pre-authentication framework.  As described in [AsNiNy02], tunneled
  849.    protocols are potentially vulnerable to man-in-the-middle attacks if
  850.    the outer tunnel is compromised and it is generally considered good
  851.    practice in such cases to bind the inner encryption to the outer
  852.    tunnel.
  853.  
  854.    Even though no such attacks are known at this point, the proposed
  855.    system uses the outer Armor Key in the derivation of the inner Client
  856.    and Server keys and so achieve crypto-binding to the outer channel.
  857.  
  858. 6.2.  Reflection
  859.  
  860.    The 4-pass system described above is a challenge-response protocol
  861.    and such protocols are potentially vulnerable to reflection attacks.
  862.    No such attacks are known at this point but to help mitigate against
  863.    such attacks, the system uses different keys to encrypt the client
  864.    and server nonces.
  865.  
  866. 6.3.  Replay
  867.  
  868.    The 2-pass version of the protocol does not involve a server nonce
  869.    and so the client instead encrypts a timestamp.  To reduce the chance
  870.    of replay attacks, the KDC must check that the client time used in
  871.    such a request is later than that used in previous requests.
  872.  
  873. 6.4.  FAST Facilities
  874.  
  875.    The secret used to generate the OTP is known only to the client and
  876.    the KDC and so successful decryption of the encrypted nonce by the
  877.    KDC authenticates the user.  Similarly, successful decryption of the
  878.    encrypted nonce by the client proves that the expected KDC replied.
  879.    The Reply Key is replaced by a key generated from the OTP and Armor
  880.    Key. This FAST factor therefore provides the following facilities:
  881.    client-authentication, replacing-reply-key and KDC-authentication.
  882.  
  883.  
  884. 7.  References
  885.  
  886. 7.1.  Normative References
  887.  
  888.    [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
  889.               Extensions (MIME) Part One: Format of Internet Message
  890.               Bodies", RFC 2045, November 1996.
  891.  
  892.  
  893.  
  894.  
  895. Richards                  Expires July 20, 2008                [Page 16]
  896.  
  897. Internet-Draft            OTP Preauthentication             January 2008
  898.  
  899.  
  900.    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  901.               Requirement Levels", BCP 14, RFC 2119, March 1997.
  902.  
  903.    [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
  904.               Kerberos 5", RFC 3961, February 2005.
  905.  
  906.    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
  907.               Kerberos Network Authentication Service (V5)", RFC 4120,
  908.               July 2005.
  909.  
  910.    [ZhHa07]   Znu, L. and S. Hartman, "A generalized Framework for
  911.               Kerberos Pre-Authentication",
  912.               draft-ietf-krb-wg-preauth-framework-06 (work in progress),
  913.               March 2007.
  914.  
  915. 7.2.  Informative References
  916.  
  917.    [AsNiNy02]
  918.               Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
  919.               in Tunneled Authentication Protocols", Cryptology ePrint
  920.               Archive Report 2002/163, November 2002.
  921.  
  922.    [HoReNeZo04]
  923.               Horstein, K., Renard, K., Neuman, C., and G. Zorn,
  924.               "Integrating Single-use Authentication Mechanisms with
  925.               Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
  926.               progress), July 2004.
  927.  
  928.    [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
  929.               2000 Kerberos Change Password and Set Password Protocols",
  930.               RFC 3244, February 2002.
  931.  
  932.  
  933. Appendix A.  ASN.1 Module
  934.  
  935.   OTPKerberos
  936.   DEFINITIONS IMPLICIT TAGS ::=
  937.   BEGIN
  938.  
  939.   IMPORTS
  940.       KerberosTime, KerberosFlags, EncryptionKey, UInt32,
  941.       Int32, EncryptedData
  942.       FROM KerberosV5Spec2 {iso(1) identified-organization(3)
  943.                             dod(6) internet(1) security(5) kerberosV5(2)
  944.                             modules(4) krb5spec2(2) }
  945.                             -- as defined in RFC 4120.
  946.       AlgorithmIdentifier
  947.       FROM PKIX1Explicit88 { iso (1) identified-organization (3)
  948.  
  949.  
  950.  
  951. Richards                  Expires July 20, 2008                [Page 17]
  952.  
  953. Internet-Draft            OTP Preauthentication             January 2008
  954.  
  955.  
  956.                              dod (6) internet (1)
  957.                              security (5) mechanisms (5) pkix (7)
  958.                              id-mod (0) id-pkix1-explicit (18) };
  959.                              -- As defined in RFC 3280.
  960.  
  961.       PA-OTP-CHALLENGE ::= SEQUENCE {
  962.         flags              OTPFlags,
  963.         nonce              UInt32,
  964.         etype              INTEGER,
  965.         supportedHashAlg   SEQUENCE OF AlgorithmIdentifier
  966.                                            OPTIONAL,
  967.         iterationCount     INTEGER         OPTIONAL,
  968.         otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,
  969.         otp-length     [0] INTEGER         OPTIONAL,
  970.         otp-service        UTF8String      OPTIONAL,
  971.         otp-keyID      [1] OCTET STRING    OPTIONAL,
  972.         otp-algID      [2] INTEGER         OPTIONAL,
  973.         ...
  974.       }
  975.  
  976.       OTPFlags ::= KerberosFlags
  977.       -- nextOTP (0)
  978.  
  979.       PA-OTP-REQUEST ::= SEQUENCE {
  980.         flags             OTPFlags,
  981.         nonce             UInt32,
  982.         encData           EncryptedData,
  983.                           -- PA-OTP-ENC-REQUEST or PA-ENC-TIMESTAMP
  984.                           -- Key usage of KEY_USAGE_OTP_REQUEST
  985.         hashAlg           AlgorithmIdentifier OPTIONAL,
  986.         iterationCount    INTEGER         OPTIONAL,
  987.         otp-value         OCTET STRING    OPTIONAL,
  988.         otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL,
  989.         otp-time          KerberosTime    OPTIONAL,
  990.         otp-counter   [1] OCTET STRING    OPTIONAL,
  991.         otp-format    [2] OTPFormat       OPTIONAL,
  992.         otp-keyID     [3] OCTET STRING    OPTIONAL,
  993.         otp-algID     [4] INTEGER         OPTIONAL,
  994.         ...
  995.       }
  996.  
  997.       PA-OTP-ENC-REQUEST ::= SEQUENCE {
  998.         nonce     OCTET STRING,
  999.         ...
  1000.       }
  1001.  
  1002.       OTPFormat ::= INTEGER {
  1003.         decimal(0),
  1004.  
  1005.  
  1006.  
  1007. Richards                  Expires July 20, 2008                [Page 18]
  1008.  
  1009. Internet-Draft            OTP Preauthentication             January 2008
  1010.  
  1011.  
  1012.         hexadecimal(1),
  1013.         alphanumeric(2),
  1014.         binary(3)
  1015.       }
  1016.  
  1017.       PA-OTP-CONFIRM ::= SEQUENCE {
  1018.         encData        EncryptedData,
  1019.                        -- PA-OTP-ENC-CONFIRM
  1020.                        -- Key usage of KEY_USAGE_OTP_CONFIRM
  1021.         ...
  1022.       }
  1023.  
  1024.       PA-OTP-ENC-CONFIRM ::= SEQUENCE {
  1025.         nonce     OCTET STRING,
  1026.         ...
  1027.       }
  1028.  
  1029.       PA-OTP-PIN-CHANGE ::= SEQUENCE {
  1030.         flags         PinFlags,
  1031.         pin           UTF8String OPTIONAL,
  1032.         minLength     INTEGER    OPTIONAL,
  1033.         maxLength [0] INTEGER    OPTIONAL,
  1034.         ...
  1035.       }
  1036.  
  1037.       PinFlags ::= KerberosFlags
  1038.       -- systemSetPin (0)
  1039.  
  1040.   END
  1041.  
  1042.  
  1043. Author's Address
  1044.  
  1045.    Gareth Richards
  1046.    RSA, The Security Division of EMC
  1047.    RSA House
  1048.    Western Road
  1049.    Bracknell, Berkshire  RG12 1RT
  1050.    UK
  1051.  
  1052.    Email: gareth.richards@rsa.com
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063. Richards                  Expires July 20, 2008                [Page 19]
  1064.  
  1065. Internet-Draft            OTP Preauthentication             January 2008
  1066.  
  1067.  
  1068. Full Copyright Statement
  1069.  
  1070.    Copyright (C) The IETF Trust (2008).
  1071.  
  1072.    This document is subject to the rights, licenses and restrictions
  1073.    contained in BCP 78, and except as set forth therein, the authors
  1074.    retain all their rights.
  1075.  
  1076.    This document and the information contained herein are provided on an
  1077.    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  1078.    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
  1079.    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
  1080.    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  1081.    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  1082.    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1083.  
  1084.  
  1085. Intellectual Property
  1086.  
  1087.    The IETF takes no position regarding the validity or scope of any
  1088.    Intellectual Property Rights or other rights that might be claimed to
  1089.    pertain to the implementation or use of the technology described in
  1090.    this document or the extent to which any license under such rights
  1091.    might or might not be available; nor does it represent that it has
  1092.    made any independent effort to identify any such rights.  Information
  1093.    on the procedures with respect to rights in RFC documents can be
  1094.    found in BCP 78 and BCP 79.
  1095.  
  1096.    Copies of IPR disclosures made to the IETF Secretariat and any
  1097.    assurances of licenses to be made available, or the result of an
  1098.    attempt made to obtain a general license or permission for the use of
  1099.    such proprietary rights by implementers or users of this
  1100.    specification can be obtained from the IETF on-line IPR repository at
  1101.    http://www.ietf.org/ipr.
  1102.  
  1103.    The IETF invites any interested party to bring to its attention any
  1104.    copyrights, patents or patent applications, or other proprietary
  1105.    rights that may cover technology that may be required to implement
  1106.    this standard.  Please address the information to the IETF at
  1107.    ietf-ipr@ietf.org.
  1108.  
  1109.  
  1110. Acknowledgment
  1111.  
  1112.    Funding for the RFC Editor function is provided by the IETF
  1113.    Administrative Support Activity (IASA).
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119. Richards                  Expires July 20, 2008                [Page 20]
  1120.  
  1121.