Internet Draft                                           David M'Raihi
                                                               VeriSign
    Category:                                              Johan Rydell
      Informational                                            PortWise
    Document:                                            David Naccache
      draft-mraihi-mutual-oath-hotp-variants-05.txt                 ENS
                                                          Salah Machani
                                                             Diversinet
                                                        Siddharth Bajaj
                                                               VeriSign
    Expires:
      December 2007                                     June 2007
 
                  OCRA: OATH Challenge-Response Algorithms
 
 Status of this Memo
 
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups. Note that
    other groups may also distribute working documents as
    Internet-Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than as "work in
    progress".
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/1id-abstracts.html
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html
 
 Abstract
 
    This document describes the OATH algorithm for challenge-response
    authentication and signatures. This algorithm is based on the HOTP
    algorithm [RFC4226] that was introduced by OATH (initiative for
    Open AuTHentication) [OATH] and submitted as an individual draft to
    the IETF last year.
 
 
 
 
 
 
 
 OATH-HOTP-VARIANTS        Expires - Mar 2007                  [Page 1]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 
 
 
 
 
                             Table of Contents
 
 
 
 
 
 
    1.   Introduction...............................................3
    2.   Requirements Terminology...................................3
    3.   Algorithm Requirements.....................................3
    4.   OCRA Background............................................4
    4.1  HOTP Algorithm.............................................4
    4.2  OCRA Algorithm.............................................5
    5.   Definition of OCRA.........................................5
    5.1 DataInput Parameters........................................6
    5.2 CryptoFunction..............................................6
    6.   The OCRASuite..............................................7
    7.   Algorithm Modes for Authentication.........................8
    7.1. One way Challenge-Response.................................8
    7.2. Response Only (OTP) Mode...................................9
    7.3. Mutual Challenge-Response.................................10
    8.   Algorithm Modes for Signature.............................11
    8.1  Plain Signature...........................................11
    8.2  Signature with Server Authentication......................12
    9.   Security Considerations...................................14
    9.1 Security Analysis of the OCRA algorithm....................14
    9.2 Implementation Considerations..............................14
    10.  IANA Considerations.......................................15
    11.  Conclusion................................................15
    12.  Acknowledgements..........................................16
    13.  References................................................16
    13.1. Normative................................................16
    13.2. Informative..............................................16
    Appendix A: Code Source........................................17
    Appendix B: Test Vectors.......................................19
    14.  Authors' Addresses........................................21
    15.  Full Copyright Statement..................................22
    16.  Intellectual Property.....................................22
 
 
 
 
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 2]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
   1. Introduction
 
    OATH has identified several use cases and scenarios that require an
    asynchronous variant to accommodate users who do not want to
    maintain a synchronized authentication system. The commonly
    accepted method for this is to use a challenge-response scheme.
 
    Such challenge response mode of authentication is widely adopted in
    the industry. Several vendors already offer software applications
    and hardware devices implementing challenge-response - but each of
    those uses vendor-specific proprietary algorithms. For the benefits
    of users we need a standardized challenge-response algorithm to
    allow multi-sourcing of token purchases and validation systems to
    facilitate the democratization of strong authentication.
    Additionally, this specification can also be used to create
    symmetric key based digital signatures. Such systems are variants
    of challenge-response mode where the data to be signed becomes the
    challenge.
 
 
   2. Requirements Terminology
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in RFC 2119
    [RFC2119].
 
 
   3. Algorithm Requirements
 
    This section presents the main requirements that drove this
    algorithm design. A lot of emphasis was placed on flexibility and
    usability, under the constraints and specificity of the HOTP
    algorithm and hardware token capabilities.
 
    R1 - The algorithm MUST support asynchronous challenge-response
    based authentication.
 
    R2 - The algorithm MUST be capable of supporting symmetric key
    based digital signatures. Essentially this is a variation of
    challenge-response where the challenge is derived from the data
    that needs to be signed.
 
    R3 - The algorithm MUST be capable of supporting server-
    authentication, whereby the user can verify that he/she is talking
    to a valid server.
 
    R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building
    block.
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 3]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    R5 - The length and format for the input challenge SHOULD be
    configurable.
 
    R6 - The output length and format for the response SHOULD be
    configurable.
 
    R7 - The challenge MAY be generated with integrity checking (e.g.,
    parity bits). This will allow tokens with pin pads to perform
    simple error checking if the user enters the value into a token.
 
    R8 - There MUST be a fixed randomly generated secret (key) for each
    token/soft token that is shared between the token and the
    authentication server.
    R9 - The algorithm MUST enable additional data attributes such as a
    counter, a time function or session information to be included in
    the computation. These data inputs MAY be used individually or all
    together.
 
 
   4. OCRA Background
 
    OATH introduced the HOTP algorithm as a first open, freely
    available building block toward hardening authentication for end-
    users in a variety of applications. One-time passwords are very
    efficient at solving specific security issues thanks to the dynamic
    nature of OTP computations.
 
    After carefully analyzing different use cases, OATH came to the
    conclusion that providing for extensions to the HOTP algorithms was
    important. A very natural extension is to introduce a challenge
    mode for computing HOTP values based on random questions. Equally
    beneficial, being able to perform mutual authentication between two
    parties, or short-signature computation for authenticating
    transaction was also identified as critical for improving the
    security of e-commerce applications.
 
    This section summarizes the HOTP algorithm and then, formally
    introduces the OCRA algorithm.
 
    4.1  HOTP Algorithm
 
    The HOTP algorithm, as defined in [RFC4226] is based on an
    increasing counter value and a static symmetric key known only to
    the prover and verifier parties.
 
    As a reminder:
 
                    HOTP(K,C) = Truncate(HMAC-SHA1(K,C))
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 4]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    Where Truncate represents the function that converts an HMAC-SHA-1
    value into an HOTP value.
 
    The Key (K), the Counter (C) and Data values are hashed high-order
    byte first. The HOTP values generated by the HOTP generator are
    treated as big endian.
 
    We refer the reader to [RFC4226] for the full description and
    further details on the rationale and security analysis of HOTP.
 
    The present draft describes the different variants based on similar
    constructions as HOTP.
 
    4.2  OCRA Algorithm
 
    In a nutshell, OCRA is a generalization of HOTP with variable data
    inputs not solely based on an incremented counter and secret key
    values.
 
                    OCRA = CryptoFunction(K, DataInput)
 
    Where:
 
    - K: a shared secret key known to both parties;
    - CryptoFunction: this is the function performing the OCRA
    computation from the secret key K and DataInput material;
    CryptoFunction is described in details in section 5.2;
    - DataInput: a structure that contains the concatenation of the
    various input data values. Defined in details in section 5.1.
 
 
   5. Definition of OCRA
 
    The definition of OCRA requires a cryptographic function, a key K
    and a set of DataInput parameters. This section introduces these
    definitions and default value recommended for all the parameters.
 
    We denote L as the byte-length of the CryptoFunction output. For
    instance, if CryptoFunction was SHA-1, then L = 20.
 
    We denote B as the byte-length of the blocks manipulated by the
    core function internally. For instance if CryptoFunction was HMAC-
    SHA-1, then B = 64 since SHA-1 manipulates 64-byte blocks.
 
    We denote t as the byte-length of the truncation output. For
    instance, if t = 6, then the output of the truncation is a 6-byte
    value.
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 5]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    5.1 DataInput Parameters
 
    This structure is the concatenation of all the parameters used in
    the computation of the OCRA values, save for the secret key K.
 
    DataInput = {Q | C | P | S | T} where:
       . Q is the list of (concatenated) challenge question(s)
         generated by the verifier(s);the questions SHOULD be L-byte
         values and MUST be at least t-byte values;
       . C is a 8-byte counter value processed high-order bit first,
         and MUST be synchronized between all parties;
       . P is a SHA1-hash of PIN/password that is known to all parties
         during the execution of the algorithm;
       . S is a string that contains information about the current
         session;
       . T is a timestamp value, UTC formatted.
 
    When computing a response, the concatenation order is always the
    following:
 
                  OTHER-PARTY-GENERATED-CHALLENGE-QUESTION
                     YOUR-GENERATED-CHALLENGE-QUESTION
                         C, P, S and then T values.
 
    If a value is empty (i.e. a certain input is not used in the
    computation) then the value is simply not represented in the
    string.
 
    5.2 CryptoFunction
 
    The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of
    computation for OCRA is HOTP with the default 6-digit dynamic
    truncation and a combination of DataInput values as the message to
    compute the HMAC-SHA1 digest.
 
 
    We define the HOTP family of functions as an extension to HOTP:
    - HOTP-H-t: these are the different possible truncated versions of
      HOTP, using the dynamic truncation method for extracting an HOTP
      value from the HMAC output;
    - We will denote HOTP-H-t as the realization of an HOTP function
      that uses an HMAC function with the hash function H, and the
      dynamic truncation as described in [RFC 4226] to extract a t-byte
      value;
    - t=0 means that no truncation is performed and the full HMAC value
      is used for authentication purpose.
 
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 6]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    We list the following preferred modes of computation, where *
    denotes the default CryptoFunction:
       . HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC
          and a dynamic truncation to a 4-digit value; this mode is not
          recommended in the general case but can be useful when a very
          short authentication code is needed by an application;
       . *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC
          and a dynamic truncation to a 6-digit value;
       . HOTP-SHA256-6: HOTP with SHA-1 as the hash function for HMAC
          and a dynamic truncation to a 6-digit value;
       . HOTP-SHA512-6: HOTP with SHA-1 as the hash function for HMAC
          and a dynamic truncation to a 6-digit value;
 
 
    This table summarizes all possible values for the CryptoFunction:
 
    Name           HMAC Function Used      Size of Truncation (t)
    --------------------------------------------------------------
    HOTP-SHA1-t       HMAC-SHA1            0 (no truncation), 4-10
    HOTP-SHA256-t     HMAC-SHA256          0 (no truncation), 4-10
    HOTP-SHA512-t     HMAC-SHA512          0 (no truncation), 4-10
 
 
   6. The OCRASuite
 
    The following values define the OcraSuite codes used in the
    description of modes of operation for the OCRA algorithm.
 
    An OCRASuite value defines an OCRA suite of operations as supported
    in the present draft and is represented as follows:
 
 
                     Algorithm-CryptoFunction-DataInput
 
 
    Algorithm
    ---------
 
    Description: Indicates the OCRA algorithm (possibly authenticated)
    Values: String MUST contains OCRA and optionally, the OCRA computed
    value of the string
 
    CryptoFunction
    --------------
 
    Description: Indicated the function used to compute OCRA values
    Values: As described in previous section; other values COULD be
    added in the future
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 7]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 
    DataInput
    ---------
 
    Description: List of valid inputs for the computation; [] indicates
    a value is optional.
    Values:
    Q | [C | P | S | T]: Challenge-Response computation
    C | [P]: Response-only (OTP) computation
    Q | [C | P | T]: Plain Signature computation
 
    Example of possible values: OCRA-HOTP-SHA512-8-C-P-Q means OCRA
    algorithm with HMAC-SHA512 function, truncated to an 8-digit value,
    using the counter, hash of the PIN/Password and a random challenge
    as parameter, the other party MUST check the value received before
    computing and sending his response.
 
 
   7. Algorithm Modes for Authentication
 
    In this section we describe the typical modes in which the above
    defined computation can be used for authentication.
 
    7.1. One way Challenge-Response
 
    A challenge/response is a security mechanism in which the verifier
    presents a question (challenge) to the prover who must provide a
    valid answer (response) to be authenticated.
 
    To use this algorithm for a one-way challenge-response, the
    verifier will communicate a challenge value (typically randomly
    generated) to the prover. The prover will use the challenge in the
    computation as described above. The prover then communicates the
    response to the verifier to authenticate.
 
    Therefore in this mode, the typical data inputs will be:
 
    Q - Challenge question, mandatory, supplied by the verifier.
    C - Counter, optional.
    P - Hashed version of PIN/password, optional.
    S - Session information, optional
    T - Timestamp, optional.
 
    The picture below shows the messages that are exchanged between the
    client (prover) and the server (verifier) to complete a one-way
    challenge-response authentication.
 
    We assume that the client and server have a pre-shared key K that
    is used for the computation.
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 8]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 
     CLIENT                                     SERVER
    (PROVER)                                  (VERIFIER)
      |                                           |
      |    Verifier sends challenge to prover     |
      |    Challenge = Q                          |
      |<------------------------------------------|
      |                                           |
      |    Prover Computes Response               |
      |    R = OCRA(K, {Q| [C | P | S | T]})      |
      |    Response = R                           |
      |------------------------------------------>|
      |                                           |
      |    Verifier Validates Response            |
      |    Response = OK                          |
      |<------------------------------------------|
      |                                           |
 
 
    7.2. Response Only (OTP) Mode
 
    Response Only mode is a variation of one-way challenge-response
    where the challenge is implicitly derived.
 
    In order to implicitly derive the challenge, the verifier and the
    prover need to maintain a moving factor that is synchronized.
    Commonly used moving factors include a counter, time or combination
    of both.
 
    To use this algorithm, the prover will use the implicit challenge
    in the computation as described above. The prover then communicates
    the response to the verifier to authenticate.
 
 
    Therefore in this mode, the data inputs will be:
 
    C - Counter mandatory.
    P - Hashed version of PIN/password, optional.
 
 
    The picture below shows the messages that are exchanged between the
    client (prover) and the server (verifier) to complete a response
    only authentication.
 
 
    We assume that the client and server have a pre-shared key K that
    is used for the computation.
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                 [Page 9]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
     CLIENT                                     SERVER
    (PROVER)                                  (VERIFIER)
      |                                           |
      |                                           |
      |    Prover Computes Response               |
      |    R = OCRA(K, C | [P])                   |
      |    Response = R                           |
      |------------------------------------------>|
      |                                           |
      |    Verifier Validates Response            |
      |    Response = OK                          |
      |<------------------------------------------|
      |                                           |
 
    7.3. Mutual Challenge-Response
 
    Mutual challenge-response is a variation of one-way challenge-
    response where both the client and server and mutually authenticate
    each other.
 
    To use this algorithm, the client will first send a random client-
    challenge to the server. The server computes the server-response
    and sends it to the client along with a server-challenge.
 
    The client will first verify the server-response to authenticate
    that it is talking to a valid server. It will then compute the
    client-response and send it to the server to authenticate. The
    server verifies the client-response to complete the two-way
    authentication process.
 
    In this mode there are two computations: client-response and
    server-response. There are two separate challenge questions,
    generated by both parties. We denote these challenge questions Q1
    and Q2.
 
    Typical data inputs for server-response computation will be:
    Q1 - Challenge question, mandatory, supplied by the client.
    Q2 - Challenge question, mandatory, supplied by the server.
    C  - Counter, optional.
    S  - Session information, optional.
    T  - Timestamp, optional.
 
    Typical data inputs for client-response computation will be:
    Q2 - Challenge question, mandatory, supplied by the server.
    Q1 - Challenge question, mandatory, supplied by the client.
    C  - Counter, optional.
    P  - Hashed version of PIN/password, optional.
    S  - Session information, optional.
    T  - Timestamp, optional.
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 10]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 
    The following picture shows the messages that are exchanged between
    the client and the server to complete a two-way mutual challenge-
    response authentication.
 
    We assume that the client and server have a pre-shared key K that
    is used for the computation.
 
 
    CLIENT                                      SERVER
      |                                           |
      |    1. Client sends client-challenge       |
      |    Q1 = Client-challenge                  |
      |------------------------------------------>|
      |                                           |
      |    2. Server computes server-response     |
      |       and sends server-challenge          |
      |    R1 = OCRA(K, Q1 | Q2 | [C | S | T])    |
      |    Q2 = Server-challenge                  |
      |    Response = R1, Q2                      |
      |<------------------------------------------|
      |                                           |
      |    3. Client verifies server-response     |
      |       and computes client-response        |
      |    OCRA(K, Q1, Q2,[C,S,T]) != R1 -> STOP  |
      |    R2 = ORCA( K,Q2 | Q1 | [C | P | S | T])|
      |    Response = R2                          |
      |------------------------------------------>|
      |                                           |
      |    4. Server verifies client-response     |
      |    OCRA(K, Q2|Q1|[C|P|S|T]) != R2 -> STOP |
      |    Response = OK                          |
      |<------------------------------------------|
      |                                           |
 
 
   8. Algorithm Modes for Signature
 
    In this section we describe the typical modes in which the above
    defined computation can be used for digital signatures.
 
    8.1  Plain Signature
 
    To use this algorithm in plain signature mode, the server will
    communicate a signature-challenge value to the client (signer). The
    signature-challenge is either the data to be signed or derived from
    the data to be signed using a hash function, for example.
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 11]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    The client will use the signature-challenge in the computation as
    described above. The client then communicates the signature value
    (response) to the server to authenticate.
 
    Therefore in this mode, the data inputs will be:
 
    Q - Signature-challenge, mandatory, supplied by the server.
    C - Counter, optional.
    P - Hashed version of PIN/password, optional.
    T - Timestamp, optional.
 
    The picture below shows the messages that are exchanged between the
    client (prover) and the server (verifier) to complete a plain
    signature operation.
 
    We assume that the client and server have a pre-shared key K that
    is used for the computation.
 
     CLIENT                                     SERVER
    (PROVER)                                  (VERIFIER)
      |                                           |
      |    Verifier sends signature-challenge     |
      |    Challenge = Q                          |
      |<------------------------------------------|
      |                                           |
      |    Client Computes Response               |
      |    SIGN = OCRA(K, Q | [C | P | T])        |
      |    Response = SIGN                        |
      |------------------------------------------>|
      |                                           |
      |    Verifier Validates Response            |
      |    Response = OK                          |
      |<------------------------------------------|
      |                                           |
 
 
    8.2  Signature with Server Authentication
 
    This mode is a variation of the plain signature mode where the
    client can first authenticate that it is talking to a valid server
    before creating a digital signature.
 
    To use this algorithm, the client will first send a random client-
    challenge to the server. The server computes the server-response
    and sends it to the client along with a signature-challenge. The
    client will first verify the server-response to authenticate that
    it is talking to a valid server. It will then compute the signature
    and send it to the server.
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 12]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    In this mode there are two computations: client-signature and
    server-response.
 
    Typical data inputs for server-response computation will be:
    Q - Challenge question, mandatory, supplied by the client.
    C - Counter, optional.
    T - Timestamp, optional.
 
    Typical data inputs for client-signature computation will be:
    Q - Signature-challenge, mandatory, supplied by the server.
    P - Hashed version of PIN/password, optional.
    C - Counter, optional.
    T - Timestamp, optional.
 
    The picture below shows the messages that are exchanged between the
    client and the server to complete a signature with server
    authentication transaction.
 
    We assume that the client and server have a pre-shared key K that
    is used for the computation.
 
 
    CLIENT                                      SERVER
      |                                           |
      |    1. Client sends client-challenge       |
      |    Q1 = Client-challenge                  |
      |------------------------------------------>|
      |                                           |
      |    2. Server computes server-response     |
      |       and sends signature-challenge       |
      |    R1 = OCRA(K, Q1 | Q2 | [C | T])        |
      |    Q2 = signature-challenge               |
      |    Response = R1, Q2                      |
      |<------------------------------------------|
      |                                           |
      |    3. Client verifies server-response     |
      |       and computes signature              |
      |    OCRA(K, Q1 | [T | C]) != R1 -> STOP    |
      |    R2 = ORCA( K, Q2 | Q1 | [C | P | T])   |
      |    Signature = R2                         |
      |------------------------------------------>|
      |                                           |
      |    4. Server verifies Signature           |
      |    OCRA(K, Q2|Q1| [C|P|T]) != R2 -> STOP  |
      |    Response = OK                          |
      |<------------------------------------------|
      |                                           |
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 13]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
   9. Security Considerations
 
    Any algorithm is only as secure as the application and the
    authentication protocols that implement it. Therefore, this section
    discusses the critical security requirements that our choice of
    algorithm imposes on the authentication protocol and validation
    software.
 
    9.1 Security Analysis of the OCRA algorithm
 
    The security and strength of this algorithm depends on the
    properties of the underlying building block HOTP, which is a
    construction based on HMAC [RFC2104] using SHA-1 as the hash
    function.
 
    The conclusion of the security analysis detailed in [RFC4226] is
    that, for all practical purposes, the outputs of the dynamic
    truncation on distinct counter inputs are uniformly and
    independently distributed strings.
 
    The analysis demonstrates that the best possible attack against the
    HOTP function is the brute force attack.
 
    9.2 Implementation Considerations
 
    In the authentication mode, the client MUST support two-factor
    authentication, i.e., the communication and verification of
    something you know (secret code such as a Password, Pass phrase,
    PIN code, etc.) and something you have (token).  The secret code is
    known only to the user and usually entered with the Response value
    for authentication purpose (two-factor authentication).
    Alternatively, instead of sending something you know to the server,
    the client may use a hash of the Password or PIN code in the
    computation itself, thus implicitly enabling two-factor
    authentication.
 
    The keys for HOTP can be of any length equal or longer than L
    bytes. Keys longer than L bytes are acceptable; they are first
    hashed using the supported hash function, e.g. SHA-1, to become
    usable. Nevertheless, the extra length would not significantly
    increase the cryptographic strength of OCRA, provided the
    randomness of the original key material is sufficient.
 
    Keys need to be chosen at random or using a cryptographically
    strong pseudo-random generator properly seeded with a random value.
    We RECOMMEND following the recommendations in [RFC1750] for all
    pseudo-random and random generations. The pseudo-random numbers
    used for generating the keys SHOULD successfully pass the
    randomness test specified in [CN].
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 14]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 
    The keys MUST be embedded in a tamper resistance device or securely
    implemented in a software application. Additionally, by embedding
    the keys in a hardware device, you also have the advantage of
    improving the flexibility (mobility).
 
    The challenge value MUST be randomly generated for each use of the
    authentication protocol and SHALL NOT be re-used. We RECOMMEND
    following the recommendations in [RFC1750] for all pseudo-random
    and random generations.
 
    All the communications SHOULD take place over a secure channel e.g.
    SSL/TLS, IPsec connections.
 
    The OCRA algorithm when used in mutual authentication mode or in
    signature with server authentication mode SHOULD use dual key mode
    -  i.e. there are two keys that are shared between the client and
    the server. One shared key is used to generate the server response
    on the server side and to verify it on the client side. The other
    key is used to create the response or signature on the client side
    and to verify the same on the server side.
 
    We recommend that implementations MAY use the session information,
    S as an additional input in the computation. For example, S could
    be the session identifier from the TLS session. This will enable
    you to counter certain types of man-in-the-middle attacks. However,
    this will introduce the additional dependency that first of all the
    prover needs to have access to the session identifier to compute
    the response and the verifier will need access to the session
    identifier to verify the response.
 
 
   10. IANA Considerations
 
    This document has no actions for IANA.
 
   11. Conclusion
 
    This draft introduced several variants of HOTP for challenge-
    response based authentication and short signature-like
    computations.
 
    The OCRASuite provides for an easy integration and support of
    different flavors within an authentication and validation system.
 
    Finally, OCRA should enable cross-authentication both in connected
    and off-line modes, with the support of different response sizes
    and mode of operations.
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 15]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
   12. Acknowledgements
 
    We would like to thank Philip Hoyer, Jon Martinsson, Frederik
    Mennes and Stu Vaeth for their comments and suggestions to improve
    this draft document.
 
   13. References
 
    13.1. Normative
 
    [RFC2104]   M. Bellare, R. Canetti and H. Krawczyk, "HMAC:
                Keyed-Hashing for Message Authentication", IETF Network
                Working Group, RFC 2104, February 1997.
 
    [RFC1750]  D. Eastlake, 3rd., S. Crocker and J. Schiller,
                "Randomness Recommendations for Security", IETF Network
                Working Group, RFC 1750, December 2004.
 
    [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [RFC3668]  S. Bradner, "Intellectual Property Rights in IETF
                Technology", BCP 79, RFC 3668, February 2004.
 
    [RFC4226]   D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and
                O. Ranen, "HOTP: An HMAC-based One Time Password
                Algorithm", IETF Network Working Group, RFC 4226,
                December 2005.
 
 
    13.2. Informative
 
    [BCK]       M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash
                Functions and Message Authentication", Proceedings of
                Crypto'96, LNCS Vol. 1109, pp. 1-15.
 
    [OATH]     Initiative for Open AuTHentication
    http://www.openauthentication.org
 
    [CN]       J.S. Coron and D. Naccache, "An accurate evaluation of
                Maurer's universal test" by Jean-Sebastien Coron and
                David Naccache In Selected Areas in Cryptography (SAC
                '98), vol. 1556 of Lecture Notes in Computer Science,
                S. Tavares and H. Meijer, Eds., pp. 57-71, Springer-
                Verlag, 1999
 
 
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 16]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 Appendix A: Code Source
 
    import java.lang.reflect.UndeclaredThrowableException;
    import java.security.GeneralSecurityException;
    import javax.crypto.Mac;
    import javax.crypto.spec.SecretKeySpec;
 
    /**
     * This an example implementation of the OATH OCRA algorithm.
     * Visit www.openauthentication.org for more information.
     *
     * @author Johan Rydell, PortWise
     */
    public class OCRA {
       private OCRA() {}
 
       /**
        * This method uses the JCE to provide the crypto
        * algorithm.
        * HMAC computes a Hashed Message Authentication Code with the
        * crypto hash algorithm as a parameter.
        *
        * @param crypto     the crypto algorithm
        *                   (HmacSHA1, HmacSHA256, HmacSHA512)
        * @param keyBytes   the bytes to use for the HMAC key
        * @param text       the message or text to be authenticated.
        */
       public static byte[] hmac_sha1(String crypto,
                                       byte[] keyBytes,
                                       byte[] text)
       {
          try {
             Mac hmac;
             hmac = Mac.getInstance(crypto);
             SecretKeySpec macKey =
                new SecretKeySpec(keyBytes, "RAW");
             hmac.init(macKey);
             return hmac.doFinal(text);
          } catch (GeneralSecurityException gse) {
             throw new UndeclaredThrowableException(gse);
          }
       }
 
       private static final int[] DIGITS_POWER
       // 0 1  2   3    4     5      6       7        8
       = {1,10,100,1000,10000,100000,1000000,10000000,100000000};
 
       /**
        * This method generates an OCRA HOTP value for the given
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 17]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
        * set of parameters.
        *
        * @param crypto              the crypto algorithm
        * @param key                 the shared secret
        * @param movingFactor        the counter that changes
        *                             on a per use basis
        * @param question            the challenge question
        * @param password            a password that can be used
        * @param sessionInformation    Static information that
        *                            identifies the current session
        * @param timeStamp           a value that reflects a time
        * @param codeDigits          number of digits in the OTP
        *
        * @return A numeric String in base 10 that includes
        * {@link truncationDigits} digits
        */
       static public String generateOTP(String crypto,
             String key,
             String movingFactor,
             String question,
             String password,
             String sessionInformation,
             String timeStamp,
             int codeDigits)
       {
          String result = null;
          String messageStr =
             question + password +
             sessionInformation + timeStamp ;
          byte[] msg;
 
          // Using the counter
          if (0 < movingFactor.length()){
             // First 8 bytes are for the movingFactor
             // Complient with RFC 4226
             messageStr = "00000000" + messageStr;
             msg = messageStr.getBytes();
             long mFactor = Long.decode(movingFactor);
             for (int i = 7; i >= 0; i--) {
                msg[i] = (byte) (mFactor & 0xff);
                mFactor >>= 8;
             }
          }else
             msg = messageStr.getBytes();
 
          // compute hmac hash
          byte[] hash = hmac_sha1(crypto, key.getBytes(), msg);
 
          // put selected bytes into result int
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 18]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
          int offset = hash[hash.length - 1] & 0xf;
 
          int binary =
             ((hash[offset] & 0x7f) << 24) |
               ((hash[offset + 1] & 0xff) << 16) |
             ((hash[offset + 2] & 0xff) << 8) |
               (hash[offset + 3] & 0xff);
 
          int otp = binary % DIGITS_POWER[codeDigits];
 
          result = Integer.toString(otp);
          while (result.length() < codeDigits) {
             result = "0" + result;
          }
          return result;
       }
    }
 
 Appendix B: Test Vectors
 
    Plain challenge response
    ========================
 
    OCRA-HOTP-SHA1-8-Q
    ------------------
    K = 12345678901234567890      Q = 10000000      OCRA = 57953866
    K = 12345678901234567890      Q = 10000001      OCRA = 15772773
    K = 12345678901234567890      Q = 10000002      OCRA = 68105940
 
    OCRA-HOTP-SHA256-8-Q
    --------------------
    K = 12345678901234567890      Q = 10000000      OCRA = 79730854
    K = 12345678901234567890      Q = 10000001      OCRA = 22925447
    K = 12345678901234567890      Q = 10000002      OCRA = 15947867
 
    OCRA-HOTP-SHA512-8-Q
    --------------------
    K = 12345678901234567890      Q = 10000000      OCRA = 68325835
    K = 12345678901234567890      Q = 10000001      OCRA = 53995836
    K = 12345678901234567890      Q = 10000002      OCRA = 89008345
 
    Response Only
    =============
 
    OCRA-HOTP-SHA1-6-C
    ------------------
    K = 12345678901234567890      C = 0 OCRA = 755224
    K = 12345678901234567890      C = 1 OCRA = 287082
    K = 12345678901234567890      C = 2 OCRA = 359152
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 19]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
 
    OCRA-HOTP-SHA256-6-C
    --------------------
    K = 12345678901234567890      C = 0 OCRA = 875740
    K = 12345678901234567890      C = 1 OCRA = 247374
    K = 12345678901234567890      C = 2 OCRA = 254785
 
    OCRA-HOTP-SHA512-6-C
    --------------------
    K = 12345678901234567890      C = 0 OCRA = 125165
    K = 12345678901234567890      C = 1 OCRA = 342147
    K = 12345678901234567890      C = 2 OCRA = 730102
 
    OCRA-HOTP-SHA1-6-C-P
    --------------------
    K = 12345678901234567890      C = 0 P = 12341234      OCRA = 106753
    K = 12345678901234567890      C = 1 P = 12341234      OCRA = 747071
    K = 12345678901234567890      C = 2 P = 12341234      OCRA = 714367
 
    OCRA-HOTP-SHA256-6-C-P
    ----------------------
    K = 12345678901234567890      C = 0 P = 12341234      OCRA = 744059
    K = 12345678901234567890      C = 1 P = 12341234      OCRA = 735947
    K = 12345678901234567890      C = 2 P = 12341234      OCRA = 167188
 
    OCRA-HOTP-SHA512-6-C-P
    ----------------------
    K = 12345678901234567890      C = 0 P = 12341234      OCRA = 249058
    K = 12345678901234567890      C = 1 P = 12341234      OCRA = 738728
    K = 12345678901234567890      C = 2 P = 12341234      OCRA = 556127
 
 
    Mutual challenge response
    =========================
 
    OCRA-HOTP-SHA512-8-Q
    --------------------
    (From server) K = 12345678901234567890
    Q1 = 11111110     Q2 = 22222220     OCRA = 70933163
    (From client) K = 12345678901234567890
    Q1 = 11111110     Q2 = 22222220     OCRA = 63875222
 
    (From server) K = 12345678901234567890
    Q1 = 11111111     Q2 = 22222221     OCRA = 08364053
    (From client) K = 12345678901234567890
    Q1 = 11111111     Q2 = 22222221     OCRA = 91844292
 
    (From server) K = 12345678901234567890
    Q1 = 11111112     Q2 = 22222222     OCRA = 70960179
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 20]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
    (From client) K = 12345678901234567890
    Q1 = 11111112     Q2 = 22222222     OCRA = 75789938
 
    Plain signature
    ===============
 
    OCRA-HOTP-SHA512-8-Q
    --------------------
    K = 12345678901234567890      Q (value) = 00010000
    OCRA (signature) = 13175449
    K = 12345678901234567890      Q (value) = 00011000
    OCRA (signature) = 41866883
    K = 12345678901234567890      Q (value) = 00012000
    OCRA (signature) = 82912137
 
 
   14. Authors' Addresses
 
    Primary point of contact (for sending comments and question):
 
    David M'Raihi
    VeriSign, Inc.
    685 E. Middlefield Road          Phone: 1-650-426-3832
    Mountain View, CA 94043 USA      Email: dmraihi@verisign.com
 
 
    Other Authors' contact information:
 
    Johan Rydell
    Portwise, Inc.
    624 Ellis Street, Suite 102      Phone: 1-650-515-3569
    Mountain View, CA 94043 USA      Email: johan.rydell@portwise.com
 
    David Naccache
    ENS, DI
    45 rue d'Ulm                     Phone: +33 6 16 59 83 49
    75005, Paris France              Email: david.naccache@ens.fr
 
    Salah Machani
    Diversinet Corp.
    2225 Sheppard Avenue East
    Suite 1801
    Toronto, Ontario M2J 5C2         Phone: 1-416-756-2324 Ext. 321
    Canada                           Email: smachani@diversinet.com
 
    Siddharth Bajaj
    VeriSign, Inc.
    487 E. Middlefield Road          Phone: 1-650-426-3458
    Mountain View, CA 94043 USA      Email: sbajaj@verisign.com
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 21]


 OCRA: OATH Challenge Response Algorithms                September 2006
 
 
   15. Full Copyright Statement
 
    Copyright (C) The IETF Trust (2007).
 
    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.
 
    This document and the information contained herein are provided on
    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
    FOR A PARTICULAR PURPOSE.
 
 
   16. Intellectual Property
 
    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed
    to pertain to the implementation or use of the technology described
    in this document or the extent to which any license under such
    rights might or might not be available; nor does it represent that
    it has made any independent effort to identify any such rights.
    Information on the procedures with respect to rights in RFC
    documents can be found in BCP 78 and BCP 79.
 
    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use
    of such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository
    at http://www.ietf.org/ipr.
 
    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard. Please address the information to the IETF at ietf-
    ipr@ietf.org.
 
 
 
 
 
 
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - March 2007                [Page 22]