Internet Draft                                        David M'Raihi
                                                               VeriSign
    Category:                                              Johan Rydell
      Informational                                            Portwise
    Document:                                            David Naccache
      draft-mraihi-mutual-oath-hotp-variants-02.txt                 ENS
                                                          Salah Machani
                                                             Diversinet
 
    Expires:
      June 2006                                       December 2005
 
           Mutual OATH: HOTP Extensions for mutual authentication
 
 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 Mutual OATH, a mechanism for mutual
    authentication based on the HOTP algorithm [RFC4226] introduced by
    OATH (initiative for Open AuTHentication) [OATH] and submitted as
    an individual draft to the IETF last year. The security and
    strength of Mutual OATH 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.
 
 
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 1]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
 
 Table of Contents
 
    1.   Introduction...............................................2
    2.   Requirements Terminology...................................3
    3.   Algorithm Requirements.....................................3
    4.   Mutual OATH Definition.....................................4
    4.1  HOTP Algorithm.............................................4
    4.2  Algorithm Identifier.......................................5
    4.3  HOTP-based Challenge-Response..............................6
    4.4  Mutual OATH Authentication.................................6
    4.5  Dual-key Mode..............................................7
    4.6  Chained Mode...............................................7
    4.7  PIN/Password "salted" HOTP Response........................8
    4.8  Signature - Using HOTP with challenge and fixed value......8
    5.   Security Considerations....................................9
    6.   IANA Considerations........................................9
    7.   Conclusion.................................................9
    8.   Acknowledgements..........................................10
    9.   References................................................10
    9.1  Normative.................................................10
    9.2  Informative...............................................10
    10.  Authors' Addresses........................................11
    11.  Full Copyright Statement..................................11
    12. Intellectual Property......................................12
 
 
   1. Introduction
 
    The HOTP algorithm is counter based and intended for synchronous
    authentication mode systems. It has been implemented under various
    form factors such as USB tokens, software client application,
    validation servers, applets for smart-cards, etc.
 
    OATH has identified several user 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.
 
    This draft introduces the concept of randomized versions of HOTP,
    where the counter field is replaced or extended by a function of
    several parameters such as a random question and a personal
    identification code or password.
 
    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
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 2]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
    allow multi-sourcing of token purchases and validation systems to
    facilitate the democratization of strong authentication.
 
   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 BCP 14.
 
   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 shared secret MUST be embedded in a tamper resistance
    device or securely implemented in a software application.
 
    R2 - The secret SHOULD be stored in a hardware device for
    additional flexibility (mobility) and security.
 
    R3 - The algorithm MUST be capable of supporting different modes of
    authentications.
 
    R4 - The challenge value MUST be randomly generated for each use of
    the authentication protocol and SHALL NOT be re-used.
 
    R5 - The algorithm MUST allow for the challenge to be presented to
    the user in numeric or alphanumeric form.
 
    R6 - If the challenge is displayed to the user, the challenge
    length SHOULD be selectable; the specification should define the
    maximum length for a challenge.
 
    R7 - There MUST be a fixed randomly generated secret (key) for each
    token/soft token that is shared between the token and the
    authentication server.
 
    R8 - 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.
 
    R9 - The algorithm MAY include a counter function.
 
    R10 - The algorithm SHOULD be used in dual-key mode. The single key
    is mainly to support legacy tokens.
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 3]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
    R11 - All the HOTP communications MUST take place over a secure
    channel e.g. SSL/TLS, IPsec connections.
 
   4. Mutual OATH Definition
 
    In this section, we introduce the HOTP algorithm variants for
    mutual authentication.
 
    Words used in this chapter:
 
    K - Key, a shared secret known to all parties
    C - Counter, a predefined sequence of values that can be calculated
    by all parties
    P - Hashed version of PIN/password that is known to all parties
    Q - Challenge, a predefined value that may change and is known to
    all parties during execution of the algorithm
    T - Fixed value that is used in a transaction
    AI - Algorithm identifier, describes in detail in section 4.2
 
    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-SHA-1(K,C))
 
    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.
 
    We introduced in [RFC4226] the notion of a Data field that would be
    used for generating the One-Time Password values. Using a Data
    field opens for more flexibility in the algorithm implementation,
    provided that the Data field is clearly specified.
 
    A straightforward variant is to replace the counter value C by a
    random question Q to define a Response as a function of the
    challenge Q:
 
       Response = HOTP (K,Q) = Truncate (HMAC-SHA-1(K,Q))
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 4]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
 
    The present draft describes the different variants based on similar
    constructions.
 
    4.2  Algorithm Identifier
 
    It is important for both parties willing to interact to know the
    operations to be performed, namely which variant is to be used.
 
    Let AI bit a binary string, and the different bits indicate which
    combination of parameters is used to compute an HOTP response.
 
    We could also specify the algorithm itself - by default, HOTP is
    based on HMAC-SHA-1 but recent attacks on hash functions and new
    standard works might result in recommendations to use another
    function for HMAC.
 
    We define the algorithm identifier AI as follows:
 
    AI = Type | Truncation | Pb | Qb | Cb | Tb | Mode | Key
 
    Where:
       Type is a 4-bit value to specify the algorithm type; at the
    moment, 4 types are defined:
          0000: HMAC-SHA-1 (default value)
          0001: HMAC-SHA-256
          0010: HMAC-SHA-512
       Truncation is a 4-bit value to specify the truncation used to
    generate the one-time password value:
          0000: No Truncation
          0110: Dynamic Truncation, 6 digits (default value)
          0111: Dynamic Truncation, 7 digits
          1000: Dynamic Truncation, 8 digits
       Pb - single bit that indicates whether or not a hash of a PIN or
    Password will be used in the computation;
       Qb - single bit that indicates whether or not a random Q will be
    used in the computation;
       Cb - single bit that indicates whether or not a counter C will
    be used in the computation;
       Tb - single bit that indicates whether or not a fixed value T
    will be used in the computation.
       Mode is a 2-bit value that defines the different modes of
    computation; at the moment, 2 types are defined:
          00: plain mode
          01: chained mode
       Key is a 2-bit value that defines the type of key used in the
    computation; at the moment, 3 types are defined:
          00: single key (K)
          01: dual key, computed (K1 = K, K2 = F(K))
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 5]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
          10: dual key, stored (K1 and K2)
    With the chained mode as described in section 4.6
 
    For instance, if the algorithm used is HOTP (K, C) with Dynamic
    Truncation to generate 6-digit HOTP values as described in
    [RFC4226] as default mode then AI = 0000 0110 0010 0000.
 
    4.3  HOTP-based 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. The simplest example
    of a challenge-response protocol is password authentication, where
    the challenge is asking for the password and the valid response is
    the correct password.
 
    A straightforward variant of the HOTP algorithm is to replace the
    counter value C by a random question Q to define a randomized
    Response as a function of the challenge Q:
 
       Response = HOTP (K,Q) = Truncate (HMAC-SHA-1(K,Q))
 
    Here is the challenge-response sequence, in which A is the verifier
    and B the prover, both sharing the knowledge of secret key K:
 
       1- A sends a random question Q_A to B and AI = 0000 0110 0100
    0000
       2- B computes Response_B = HOTP (K,Q_A) and sends it to A
       3- A checks Response_B and if correct, B is authenticated
 
    Optionnaly, B could include an identifier of A to avoid reflection
    attacks; in this case, Response_B = HOTP(K,Q_A|ID_A) where ID_A
    stands for the identifier.
 
    Injecting an identifier is important when using bi-directional
    keys; in the following sections, we will not reintroduce this
    nothing, but obviously, depending on the key material, an
    identifier SHOULD be used when computing responses to avoid an
    adversary to re-use a message to get authenticated.
 
    4.4  Mutual OATH Authentication
 
    The challenge-response sequence is the following for parties A and
    B sharing knowledge of secret (key) K and willing to perform Mutual
    OATH authentication:
 
       1- A sends a random question Q_A to B and AI = 0000 0110 0100
    0000
 
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 6]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
       2- B computes Response_B = HOTP (K,Q_A|Q_B) and sends it to A
    with his own random question Q_B
       3- A checks Response_B and if correct, computes Response_A =
    HOTP (K,Q_B|Q_A)
       4- B checks Response_A and if correct, acknowledges party A
 
    Both parties are authenticated.
 
    4.5  Dual-key Mode
 
    The key SHOULD be pre-divided into different usages. K1 is used for
    computing responses and K2 to check responses. The opposite is used
    for the other party. Depending on whether storage or computation is
    cheaper, we could either store a longer key K = K1 | K2 or set K1 =
    K and K2 = K xor Constant or K2 = SHA-1(K) for instance.
 
    The challenge-response sequence is the following for parties A and
    B sharing knowledge of secret (key) K and computing HOTP values in
    dual key stored mode:
 
       1- A sends a random question Q_A to B and AI = 0000 0110 0100
    0010
       2- B computes Response_B = HOTP (K2,Q_A|Q_B) and sends it to A
    with his own random question Q_B
       3- A checks Response_B and if correct, computes Response_A =
    HOTP (K1,Q_B|Q_A)
       4- B checks Response_A and if correct, acknowledges party A
 
    Both parties are authenticated. Separating into K1 and K2 protects
    against another party sending predefined questions "Q_A"'s to B for
    querying specific information.
 
    We recommend this mode of computation for mutual OATH.
 
    4.6  Chained Mode
 
    Another interesting computation mode is to chain the computations
    of different responses. It might have valuable applications such as
    to verify that a certain sequence of operations has taken place.
 
    The challenge-response sequence is the following for parties A and
    B sharing knowledge of secret (key) K and willing to perform Mutual
    OATH authentication in chained, dual-key stored mode:
 
       1- A sends a random question Q_A to B and AI = 0000 0110 0100
    0110
       2- B computes Response_B = HOTP (K2,Q_A|Q_B) and sends it to A
    with his own random question Q_B
 
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 7]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
       3- A checks Response_B and if correct, computes Response_A =
    HOTP (K1,Q_B|Q_A|Response_B)
       4- B checks Response_A and if correct, acknowledges party A
 
    Both parties are authenticated.
 
    4.7  PIN/Password "salted" HOTP Response
 
    In this case, the PIN/password value used to control the usage of
    the token and/or protect access to the key embedded in the hardware
    (or software) token can be injected in the Response computation, as
    well as the random question Q:
 
       Response = HOTP (K, Q|P)
 
    Where | stands for concatenation.
 
    The challenge-response sequence is the following for parties A and
    B sharing knowledge of secret (key) K and willing to perform Mutual
    OATH authentication:
 
       1- A sends a random question Q_A to B and AI = 0000 0110 1000
    0010
       2- B computes Response_B = HOTP (K2,Q_A|Q_B|P) and sends it to A
    with his own random question Q_B
       3- A checks Response_B and if correct, computes Response_A =
    HOTP (K1,Q_B|Q_A|P)
       4- B checks Response_A and if correct, acknowledges party A
 
    Obviously, the string P can be empty if party A or B does not have
    a PIN or Password - e.g. a validation server computing a response
    to be authenticated by a user will probably not have the usage of a
    PIN or password.
 
    It opens for interesting combinations where the algorithm
    identifier AI could be used to specify computations both ways -
    e.g. the token could include the PIN in his computation and the
    server, knowing the hash checks the HOTP response; in its
    calculation on the other hand, no PIN value would be included since
    the server would not have one.
 
    4.8  Signature - Using HOTP with challenge and fixed value
 
    The combination of a fixed value and random value enables to
    generate different signature values for different fixed values -
    the computation is randomized by the question Q. This is important
    when signing the same value more then once.
 
       Signature = HOTP (K, Q|T) where | stands for concatenation.
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 8]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
 
    The sequence for B generating a signature to be checked by A is the
    following, assuming the mode of computation is plain, dual-key
    stored mode:
       1- A sends a fixed value C, a random question Q to B and AI =
    0000 0110 0110 0010
       2- B computes Response_B = HOTP (K2,Q|T) and sends it to A
       3- A checks Response_B and if correct, acknowledges party B has
    validated the value T
 
    In an hostile environment a third party can trick party B to reveal
    the correct response for a given value. Again, all exchanges should
    take place over a secure channel - using SSL/TLS, or similar
    encryption mechanism.
 
   5. Security Considerations
 
    The keys for HOTP can be of any length equal or longer than 20
    bytes. Keys longer than 20 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 Mutual OATH, 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].
 
    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.
 
   6. IANA Considerations
 
    This document has no actions for IANA.
 
   7. Conclusion
 
    This draft introduced several variants of HOTP for randomized
    response and short signature-like computations.
 
 
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                 [Page 9]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
    The algorithm identifier AI provides for an easy integration and
    support of different HOTP flavors within an authentication and
    validation system.
 
    Mutual OATH should enable cross-authentication both in connected
    and off-line modes, with the support of different response sizes
    and mode of operations.
 
   8. Acknowledgements
 
    We would like to thank Siddharth Bajaj, Philip Hoyer, Jon
    Martinsson, Frederik Mennes and Stu Vaeth for their comments and
    suggestions to improve this draft document.
 
   9. References
 
    9.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 Recommendantions 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 Propery 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.
 
    9.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
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                [Page 10]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
 
                '98), vol. 1556 of Lecture Notes in Computer Science,
                S. Tavares and H. Meijer, Eds., pp. 57-71, Springer-
                Verlag, 1999
 
   10. 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-472-3582
    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
 
   11. Full Copyright Statement
 
    Copyright (C) The Internet Society (2006).
 
    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.
 
    This document and the information contained herein are provided on
    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
    THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
    ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE.
 
 
 
 OATH-HOTP-VARIANTS       Expires - June 2006                [Page 11]


 Mutual OATH: HOTP Extensions for mutual authentication   December 2005
 
   12. 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 - June 2006                [Page 12]