summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6287.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6287.txt')
-rw-r--r--doc/rfc/rfc6287.txt2131
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc6287.txt b/doc/rfc/rfc6287.txt
new file mode 100644
index 0000000..07e69c2
--- /dev/null
+++ b/doc/rfc/rfc6287.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. M'Raihi
+Request for Comments: 6287 Verisign, Inc.
+Category: Informational J. Rydell
+ISSN: 2070-1721 Portwise, Inc.
+ S. Bajaj
+ Symantec Corp.
+ S. Machani
+ Diversinet Corp.
+ D. Naccache
+ Ecole Normale Superieure
+ June 2011
+
+
+ OCRA: OATH Challenge-Response Algorithm
+
+Abstract
+
+ This document describes an algorithm for challenge-response
+ authentication developed by the Initiative for Open Authentication
+ (OATH). The specified mechanisms leverage the HMAC-based One-Time
+ Password (HOTP) algorithm and offer one-way and mutual
+ authentication, and electronic signature capabilities.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6287.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+
+
+
+M'Raihi, et al. Informational [Page 1]
+
+RFC 6287 OCRA June 2011
+
+
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Notation and Terminology ........................................3
+ 3. Algorithm Requirements ..........................................3
+ 4. OCRA Background .................................................4
+ 4.1. HOTP Algorithm .............................................4
+ 5. Definition of OCRA ..............................................5
+ 5.1. DataInput Parameters .......................................5
+ 5.2. CryptoFunction .............................................7
+ 6. The OCRASuite ...................................................8
+ 6.1. Algorithm ..................................................9
+ 6.2. CryptoFunction .............................................9
+ 6.3. DataInput ..................................................9
+ 6.4. OCRASuite Examples ........................................10
+ 7. Algorithm Modes for Authentication .............................10
+ 7.1. One-Way Challenge-Response ................................11
+ 7.2. Mutual Challenge-Response .................................12
+ 7.3. Algorithm Modes for Signature .............................13
+ 7.3.1. Plain Signature ....................................13
+ 7.3.2. Signature with Server Authentication ...............14
+ 8. Security Considerations ........................................16
+ 8.1. Security Analysis of OCRA .................................16
+ 8.2. Implementation Considerations .............................17
+ 9. Conclusion .....................................................18
+ 10. Acknowledgements ..............................................18
+ 11. References ....................................................19
+ 11.1. Normative References .....................................19
+ 11.2. Informative References ...................................19
+ Appendix A. Reference Implementation ..............................20
+ Appendix B. Test Vectors Generation ...............................26
+ Appendix C. Test Vectors ..........................................33
+ C.1. One-Way Challenge Response .................................34
+ C.2. Mutual Challenge-Response ..................................35
+ C.3. Plain Signature ............................................37
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 2]
+
+RFC 6287 OCRA June 2011
+
+
+1. Introduction
+
+ The Initiative for Open Authentication (OATH) [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. A commonly accepted method for this is to use
+ a challenge-response scheme.
+
+ Such a 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 there is a need for a standardized challenge-response
+ algorithm that allows multi-sourcing of token purchases and
+ validation systems to facilitate the democratization of strong
+ authentication.
+
+ Additionally, this specification describes the means to create
+ symmetric key-based short 'electronic signatures'. Such signatures
+ are variants of challenge-response mode where the data to be signed
+ becomes the challenge or is used to derive the challenge. Note that
+ the term 'electronic signature' and 'signature' are used
+ interchangeably in this document.
+
+2. Notation and 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 [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 HMAC-based One-Time
+ Password (HOTP) algorithm [RFC4226] and hardware token capabilities.
+
+ R1 - The algorithm MUST support challenge-response-based
+ authentication.
+
+ R2 - The algorithm MUST be capable of supporting symmetric key-based
+ short electronic 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 trusted server.
+
+
+
+M'Raihi, et al. Informational [Page 3]
+
+RFC 6287 OCRA June 2011
+
+
+ R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building block.
+
+ R5 - The length and format of the input challenge SHOULD be
+ configurable.
+
+ R6 - The output length and format of the generated 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 when the user enters the challenge value into a token.
+
+ R8 - There MUST be a unique secret (key) for each token/soft token
+ that is shared between the token and the authentication server. The
+ keys MUST be randomly generated or derived using a key derivation
+ algorithm.
+
+ R9 - The algorithm MAY enable additional data attributes such as a
+ timestamp 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 towards strengthening 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 is being able to perform mutual authentication between two
+ parties, or short-signature computation for authenticating
+ transaction to improve the security of e-commerce applications.
+
+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))
+
+ where Truncate represents the function that converts an HMAC-SHA-1
+ value into an HOTP value.
+
+
+
+M'Raihi, et al. Informational [Page 4]
+
+RFC 6287 OCRA June 2011
+
+
+ We refer the reader to [RFC4226] for the full description and further
+ details on the rationale and security analysis of HOTP.
+
+ The present document describes the different variants based on
+ similar constructions as HOTP.
+
+5. Definition of OCRA
+
+ The OATH Challenge-Response Algorithm (OCRA) is a generalization of
+ HOTP with variable data inputs not solely based on an incremented
+ counter and secret key values.
+
+ The definition of OCRA requires a cryptographic function, a key K and
+ a set of DataInput parameters. This section first formally
+ introduces OCRA and then introduces the definitions and default
+ values recommended for all parameters.
+
+ In a nutshell,
+ OCRA = CryptoFunction(K, DataInput)
+
+ where:
+
+ o K: a shared secret key known to both parties
+
+ o DataInput: a structure that contains the concatenation of the
+ various input data values defined in details in section 5.1
+
+ o CryptoFunction: this is the function performing the OCRA
+ computation from the secret key K and the DataInput material;
+
+ CryptoFunction is described in details in Section 5.2
+
+5.1. DataInput Parameters
+
+ This structure is the concatenation over byte array of the OCRASuite
+ value as defined in section 6 with the different parameters used in
+ the computation, save for the secret key K.
+
+ DataInput = {OCRASuite | 00 | C | Q | P | S | T} where:
+
+ o OCRASuite is a value representing the suite of operations to
+ compute an OCRA response
+
+ o 00 is a byte value used as a separator
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 5]
+
+RFC 6287 OCRA June 2011
+
+
+ o C is an unsigned 8-byte counter value processed high-order bit
+ first, and MUST be synchronized between all parties; It loops
+ around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts
+ over at "{Hex}0". Note that 'C' is optional for all OCRA modes
+ described in this document.
+
+ o Q, mandatory, is a 128-byte list of (concatenated) challenge
+ question(s) generated by the parties; if Q is less than 128 bytes,
+ then it should be padded with zeroes to the right
+
+ o P is a hash (SHA-1 [RFC3174], SHA-256 and SHA-512 [SHA2] are
+ supported) value of PIN/password that is known to all parties
+ during the execution of the algorithm; the length of P will depend
+ on the hash function that is used
+
+ o S is a UTF-8 [RFC3629] encoded string of length up to 512 bytes
+ that contains information about the current session; the length of
+ S is defined in the OCRASuite string
+
+ o T is an 8-byte unsigned integer in big-endian order (i.e., network
+ byte order) representing the number of time-steps (seconds,
+ minutes, hours, or days depending on the specified granularity)
+ since midnight UTC of January 1, 1970 [UT]. More specifically, if
+ the OCRA computation includes a timestamp T, you should first
+ convert your current local time to UTC time; you can then derive
+ the UTC time in the proper format (i.e., seconds, minutes, hours,
+ or days elapsed from epoch time); the size of the time-step is
+ specified in the OCRASuite string as described in Section 6.3
+
+ When computing a response, the concatenation order is always the
+ following:
+
+ C |
+
+ OTHER-PARTY-GENERATED-CHALLENGE-QUESTION |
+
+ YOUR-GENERATED-CHALLENGE-QUESTION |
+
+ P| S | T
+
+ 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.
+
+ The counter on the token or client MUST be incremented every time a
+ new computation is requested by the user. The server's counter value
+ MUST only be incremented after a successful OCRA authentication.
+
+
+
+
+
+M'Raihi, et al. Informational [Page 6]
+
+RFC 6287 OCRA June 2011
+
+
+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 denote t as the length in decimal digits of the truncation output.
+ For instance, if t = 6, then the output of the truncation is a
+ 6-digit (decimal) value.
+
+ We define the HOTP family of functions as an extension to HOTP:
+
+ 1. 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
+
+ 2. 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 [RFC4226] to extract a t-digit
+ value
+
+ 3. t=0 means that no truncation is performed and the full HMAC value
+ is used for authentication purposes
+
+ We list the following preferred modes of computation, where * denotes
+ the default CryptoFunction:
+
+ o 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 it can be useful when a very
+ short authentication code is needed by an application
+
+ o HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC and a
+ dynamic truncation to a 6-digit value
+
+ o HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC and a
+ dynamic truncation to an 8-digit value
+
+ o HOTP-SHA256-6: HOTP with SHA-256 as the hash function for HMAC and
+ a dynamic truncation to a 6-digit value
+
+ o HOTP-SHA512-6: HOTP with SHA-512 as the hash function for HMAC and
+ a dynamic truncation to a 6-digit value
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 7]
+
+RFC 6287 OCRA June 2011
+
+
+ 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 |
+ +---------------+--------------------+-------------------------+
+
+ Table 1: CryptoFunction Table
+
+6. The OCRASuite
+
+ An OCRASuite value is a text string that captures one mode of
+ operation for OCRA, completely specifying the various options for
+ that computation. An OCRASuite value is represented as follows:
+
+ <Algorithm>:<CryptoFunction>:<DataInput>
+
+
+ The OCRASuite value is the concatenation of three sub-components that
+ are described below. Some example OCRASuite strings are described in
+ Section 6.4.
+
+ The client and server need to agree on one or two values of
+ OCRASuite. These values may be agreed upon at the time of token
+ provisioning or, for more sophisticated client-server interactions,
+ these values may be negotiated for every transaction.
+
+ The provisioning of OCRA keys and related metadata such as OCRASuite
+ is out of scope for this document. [RFC6030] specifies one key
+ container specification that facilitates provisioning of such data
+ between the client and the server.
+
+ Note that for Mutual Challenge-Response or Signature with Server
+ Authentication modes, the client and server will need to agree on two
+ values of OCRASuite -- one for server computation and another for
+ client computation.
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 8]
+
+RFC 6287 OCRA June 2011
+
+
+6.1. Algorithm
+
+ Description: Indicates the version of OCRA.
+
+ Values: OCRA-v where v represents the version number (e.g., 1, 2).
+ This document specifies version 1 of OCRA.
+
+6.2. CryptoFunction
+
+ Description: Indicates the function used to compute OCRA values
+
+ Values: Permitted values are described in Section 5.2.
+
+6.3. DataInput
+
+ Description: This component of the OCRASuite string captures the list
+ of valid inputs for that computation; [] indicates a value is
+ optional:
+
+ [C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation
+
+ [C] | QFxx | [PH | TG] : Plain Signature computation
+
+ Each input that is used for the computation is represented by a
+ single letter (except Q), and they are separated by a hyphen.
+
+ The input for challenge is further qualified by the formats supported
+ by the client for challenge question(s). Supported values can be:
+
+ +------------------+-------------------+
+ | Format (F) | Up to Length (xx) |
+ +------------------+-------------------+
+ | A (alphanumeric) | 04-64 |
+ | N (numeric) | 04-64 |
+ | H (hexadecimal) | 04-64 |
+ +------------------+-------------------+
+
+ Table 2: Challenge Format Table
+
+ The default challenge format is N08, numeric and up to 8 digits.
+
+ The input for P is further qualified by the hash function used for
+ the PIN/password. Supported values for hash function can be:
+
+ Hash function (H) - SHA1, SHA256, SHA512.
+
+ The default hash function for P is SHA1.
+
+
+
+
+M'Raihi, et al. Informational [Page 9]
+
+RFC 6287 OCRA June 2011
+
+
+ The input for S is further qualified by the length of the session
+ data in bytes. The client and server could agree to any length but
+ the typical values are:
+
+ Length (nnn) - 064, 128, 256, and 512.
+
+ The default length is 064 bytes.
+
+ The input for timestamps is further qualified by G, size of the time-
+ step. G can be specified in number of seconds, minutes, or hours:
+
+ +--------------------+------------------------------+
+ | Time-Step Size (G) | Examples |
+ +--------------------+------------------------------+
+ | [1-59]S | number of seconds, e.g., 20S |
+ | [1-59]M | number of minutes, e.g., 5M |
+ | [0-48]H | number of hours, e.g., 24H |
+ +--------------------+------------------------------+
+
+ Table 3: Time-step Size Table
+
+ Default value for G is 1M, i.e., time-step size is one minute and the
+ T represents the number of minutes since epoch time [UT].
+
+6.4. OCRASuite Examples
+
+ Here are some examples of OCRASuite strings:
+
+ o "OCRA-1:HOTP-SHA512-8:C-QN08-PSHA1" means version 1 of OCRA with
+ HMAC-SHA512 function, truncated to an 8-digit value, using the
+ counter, a random challenge, and a SHA1 digest of the PIN/password
+ as parameters. It also indicates that the client supports only
+ numeric challenge up to 8 digits in length
+
+ o "OCRA-1:HOTP-SHA256-6:QA10-T1M" means version 1 of OCRA with HMAC-
+ SHA256 function, truncated to a 6-digit value, using a random
+ alphanumeric challenge up to 10 characters in length and a
+ timestamp in number of minutes since epoch time
+
+ o "OCRA-1:HOTP-SHA1-4:QH8-S512" means version 1 of OCRA with HMAC-
+ SHA1 function, truncated to a 4-digit value, using a random
+ hexadecimal challenge up to 8 nibbles and a session value of 512
+ bytes
+
+7. Algorithm Modes for Authentication
+
+ This section describes the typical modes in which the above defined
+ computation can be used for authentication.
+
+
+
+M'Raihi, et al. Informational [Page 10]
+
+RFC 6287 OCRA June 2011
+
+
+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:
+
+ C - Counter, optional.
+
+ Q - Challenge question, mandatory, supplied by the verifier.
+
+ P - Hashed version of PIN/password, optional.
+
+ S - Session information, optional.
+
+ T - Timestamp, optional.
+
+ The diagram below shows the message exchange between the client
+ (prover) and the server (verifier) to complete a one-way challenge-
+ response authentication.
+
+ It is assumed that the client and server have a pre-shared key K that
+ is used for the computation.
+
+ CLIENT SERVER
+ (PROVER) VERIFIER)
+ | |
+ | Verifier sends challenge to prover |
+ | Challenge = Q |
+ |<---------------------------------------|
+ | |
+ | Prover Computes Response |
+ | R = OCRA(K, {[C] | Q | [P | S | T]}) |
+ | Prover sends Response = R |
+ |--------------------------------------->|
+ | |
+ | Verifier Validates Response |
+ | If Response is valid, Server sends OK |
+ | If Response is not, Server sends NOK |
+ |<---------------------------------------|
+ | |
+
+
+
+M'Raihi, et al. Informational [Page 11]
+
+RFC 6287 OCRA June 2011
+
+
+7.2. Mutual Challenge-Response
+
+ Mutual challenge-response is a variation of one-way challenge-
+ response where both the client and server 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 be assured 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:
+
+ C - Counter, optional.
+
+ QC - Challenge question, mandatory, supplied by the client.
+
+ QS - Challenge question, mandatory, supplied by the server.
+
+ S - Session information, optional.
+
+ T - Timestamp, optional.
+
+ Typical data inputs for client-response computation will be:
+
+ C - Counter, optional.
+
+ QS - Challenge question, mandatory, supplied by the server.
+
+ QC - Challenge question, mandatory, supplied by the client.
+
+ P - Hashed version of PIN/password, optional.
+
+ S - Session information, optional.
+
+ T - Timestamp, optional.
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 12]
+
+RFC 6287 OCRA June 2011
+
+
+ The following diagram shows the messages that are exchanged between
+ the client and the server to complete a two-way mutual challenge-
+ response authentication.
+
+ It is assumed that the client and server have a pre-shared key K (or
+ pair of keys if using dual-key mode of computation) that is used for
+ the computation.
+
+ CLIENT SERVER
+ (PROVER) (VERIFIER)
+ | |
+ | 1. Client sends client-challenge |
+ | QC = Client-challenge |
+ |------------------------------------------------->|
+ | |
+ | 2. Server computes server-response |
+ | and sends server-challenge |
+ | RS = OCRA(K, [C] | QC | QS | [S | T]) |
+ | QS = Server-challenge |
+ | Response = RS, QS |
+ |<-------------------------------------------------|
+ | |
+ | 3. Client verifies server-response |
+ | and computes client-response |
+ | OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP |
+ | RC = OCRA(K, [C] | QS | QC | [P | S | T]) |
+ | Response = RC |
+ |------------------------------------------------->|
+ | |
+ | 4. Server verifies client-response |
+ | OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP |
+ | Response = OK |
+ |<-------------------------------------------------|
+ | |
+
+7.3. Algorithm Modes for Signature
+
+ In this section we describe the typical modes in which the above
+ defined computation can be used for electronic signatures.
+
+7.3.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.
+
+
+
+
+
+M'Raihi, et al. Informational [Page 13]
+
+RFC 6287 OCRA June 2011
+
+
+ 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:
+
+ C - Counter, optional.
+
+ QS - Signature-challenge, mandatory, supplied by the server.
+
+ 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.
+
+ It is assumed 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 = QS |
+ |<------------------------------------------|
+ | |
+ | Client Computes Response |
+ | SIGN = OCRA(K, [C] | QS | [P | T]) |
+ | Response = SIGN |
+ |------------------------------------------>|
+ | |
+ | Verifier Validates Response |
+ | Response = OK |
+ |<------------------------------------------|
+ | |
+
+7.3.2. Signature with Server Authentication
+
+ This mode is a variation of the plain signature mode where the client
+ can first authenticate the server before generating a electronic
+ 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.
+
+
+
+
+M'Raihi, et al. Informational [Page 14]
+
+RFC 6287 OCRA June 2011
+
+
+ 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.
+
+ In this mode there are two computations: client-signature and server-
+ response.
+
+ Typical data inputs for server-response computation will be:
+
+ C - Counter, optional.
+
+ QC - Challenge question, mandatory, supplied by the client.
+
+ QS - Signature-challenge, mandatory, supplied by the server.
+
+ T - Timestamp, optional.
+
+ Typical data inputs for client-signature computation will be:
+
+ C - Counter, optional.
+
+ QC - Challenge question, mandatory, supplied by the client.
+
+ QS - Signature-challenge, mandatory, supplied by the server.
+
+ P - Hashed version of PIN/password, optional.
+
+ T - Timestamp, optional.
+
+ The diagram below shows the messages that are exchanged between the
+ client and the server to complete a signature with server
+ authentication transaction.
+
+ It is assumed that the client and server have a pre-shared key K (or
+ pair of keys if using dual-key mode of computation) that is used for
+ the computation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 15]
+
+RFC 6287 OCRA June 2011
+
+
+ CLIENT SERVER
+ (PROVER) VERIFIER)
+ | |
+ | 1. Client sends client-challenge |
+ | QC = Client-challenge |
+ |-------------------------------------------------->|
+ | |
+ | 2. Server computes server-response |
+ | and sends signature-challenge |
+ | RS = OCRA(K, [C] | QC | QS | [T]) |
+ | QS = signature-challenge |
+ | Response = RS, QS |
+ |<--------------------------------------------------|
+ | |
+ | 3. Client verifies server-response |
+ | and computes signature |
+ | OCRA(K, [C] | QC | QS | [T]) != RS -> STOP |
+ | SIGN = OCRA( K, [C] | QS | QC | [P | T]) |
+ | Response = SIGN |
+ |-------------------------------------------------->|
+ | |
+ | 4. Server verifies Signature |
+ | OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP |
+ | Response = OK |
+ |<--------------------------------------------------|
+ | |
+
+8. 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.
+
+8.1. Security Analysis of OCRA
+
+ The security and strength of this algorithm depend on the properties
+ of the underlying building block HOTP, which is a construction based
+ on HMAC [RFC2104] using SHA-1 [RFC3174] (or SHA-256 or SHA-512
+ [SHA2]) 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.
+
+
+
+
+
+M'Raihi, et al. Informational [Page 16]
+
+RFC 6287 OCRA June 2011
+
+
+ The analysis demonstrates that the best possible attack against the
+ HOTP function is the brute force attack.
+
+8.2. Implementation Considerations
+
+ IC1 - 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.
+
+ IC2 - Keys SHOULD be of the length of the CryptoFunction output to
+ facilitate interoperability.
+
+ IC3 - Keys SHOULD be chosen at random or using a cryptographically
+ strong pseudo-random generator properly seeded with a random value.
+ We RECOMMEND following the recommendations in [RFC4086] 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].
+
+ IC4 - Challenge questions SHOULD be 20-byte values and MUST be at
+ least t-byte values where t stands for the digit-length of the OCRA
+ truncation output.
+
+ IC5 - On the client side, the keys SHOULD be embedded in a tamper-
+ resistant 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) of the
+ authentication system.
+
+ IC6 - All the communications SHOULD take place over a secure channel,
+ e.g., SSL/TLS [RFC5246], IPsec connections.
+
+ IC7 - OCRA, when used in mutual authentication mode or in signature
+ with server authentication mode, MAY 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 it on the
+ server side.
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 17]
+
+RFC 6287 OCRA June 2011
+
+
+ IC8 - 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 mitigate against 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. [RFC5056] contains
+ a relevant discussion of using Channel Bindings to Secure Channels.
+
+ IC9 - In the signature mode, whenever the counter or time (defined as
+ optional elements) are not used in the computation, there might be a
+ risk of replay attack and the implementers should carefully consider
+ this issue in the light of their specific application requirements
+ and security guidelines. The server SHOULD also provide whenever
+ possible a mean for the client (if able) to verify the validity of
+ the signature challenge.
+
+ IC10 - We also RECOMMEND storing the keys securely in the validation
+ system, and more specifically, encrypting them using tamper-resistant
+ hardware encryption and exposing them only when required: for
+ example, the key is decrypted when needed to verify an OCRA response,
+ and re-encrypted immediately to limit exposure in the RAM for a short
+ period of time. The key store MUST be in a secure area, to avoid as
+ much as possible direct attack on the validation system and secrets
+ database. Particularly, access to the key material should be limited
+ to programs and processes required by the validation system only.
+
+9. Conclusion
+
+ This document 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 mutual authentication both in connected
+ and off-line modes, with the support of different response sizes and
+ mode of operations.
+
+10. Acknowledgements
+
+ We would like to thank Jeff Burstein, Shuh Chang, Oanh Hoang, Philip
+ Hoyer, Jon Martinsson, Frederik Mennes, Mingliang Pei, Jonathan
+ Tuliani, Stu Vaeth, Enrique Rodriguez, and Robert Zuccherato for
+ their comments and suggestions to improve this document.
+
+
+
+
+M'Raihi, et al. Informational [Page 18]
+
+RFC 6287 OCRA June 2011
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+ (SHA1)", RFC 3174, September 2001.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
+ O. Ranen, "HOTP: An HMAC-Based One-Time Password
+ Algorithm", RFC 4226, December 2005.
+
+ [SHA2] NIST, "FIPS PUB 180-3: Secure Hash Standard (SHS)",
+ October 2008, <http://csrc.nist.gov/publications/fips/
+ fips180-3/fips180-3_final.pdf>.
+
+11.2. Informative References
+
+ [CN] Coron, J. and D. Naccache, "An accurate evaluation of
+ Maurer's universal test", LNCS 1556, February 1999, <http:
+ //www.gemplus.com/smart/rd/publications/pdf/CN99maur.pdf>.
+
+ [OATH] Initiative for Open Authentication, "OATH Vision",
+ <http://www.openauthentication.org/about>.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
+ Channels", RFC 5056, November 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric
+ Key Container (PSKC)", RFC 6030, October 2010.
+
+ [UT] Wikipedia, "Unix time",
+ <http://en.wikipedia.org/wiki/Unix_time>.
+
+
+
+M'Raihi, et al. Informational [Page 19]
+
+RFC 6287 OCRA June 2011
+
+
+Appendix A. Reference Implementation
+
+ <CODE BEGINS>
+
+ /**
+ Copyright (c) 2011 IETF Trust and the persons identified as
+ authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, is permitted pursuant to, and subject to the license
+ terms contained in, the Simplified BSD License set forth in Section
+ 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info).
+ */
+
+ import javax.crypto.Mac;
+ import javax.crypto.spec.SecretKeySpec;
+ import java.math.BigInteger;
+
+ /**
+ * This an example implementation of OCRA.
+ * 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.
+ */
+
+ private static byte[] hmac_sha1(String crypto,
+ byte[] keyBytes, byte[] text){
+ Mac hmac = null;
+ try {
+ hmac = Mac.getInstance(crypto);
+ SecretKeySpec macKey =
+ new SecretKeySpec(keyBytes, "RAW");
+
+
+
+M'Raihi, et al. Informational [Page 20]
+
+RFC 6287 OCRA June 2011
+
+
+ hmac.init(macKey);
+ return hmac.doFinal(text);
+ } catch (Exception e) {
+ e.printStackTrace();
+ }
+ return null;
+ }
+
+
+ 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 converts HEX string to Byte[]
+ *
+ * @param hex the HEX string
+ *
+ * @return A byte array
+ */
+ private static byte[] hexStr2Bytes(String hex){
+ // Adding one byte to get the right conversion
+ // values starting with "0" can be converted
+ byte[] bArray = new BigInteger("10" + hex,16).toByteArray();
+
+ // Copy all the REAL bytes, not the "first"
+ byte[] ret = new byte[bArray.length - 1];
+ System.arraycopy(bArray, 1, ret, 0, ret.length);
+ return ret;
+ }
+
+
+ /**
+ * This method generates an OCRA HOTP value for the given
+ * set of parameters.
+ *
+ * @param ocraSuite the OCRA Suite
+ * @param key the shared secret, HEX encoded
+ * @param counter the counter that changes on a per use
+ * basis, HEX encoded
+ * @param question the challenge question, HEX encoded
+ * @param password a password that can be used, HEX encoded
+ * @param sessionInformation Static information that identifies
+ * the current session, Hex encoded
+ * @param timeStamp a value that reflects a time
+ *
+ * @return A numeric String in base 10 that includes
+ * {@link truncationDigits} digits
+
+
+
+M'Raihi, et al. Informational [Page 21]
+
+RFC 6287 OCRA June 2011
+
+
+ */
+ static public String generateOCRA(String ocraSuite,
+ String key,
+ String counter,
+ String question,
+ String password,
+ String sessionInformation,
+ String timeStamp){
+
+ int codeDigits = 0;
+ String crypto = "";
+ String result = null;
+ int ocraSuiteLength = (ocraSuite.getBytes()).length;
+ int counterLength = 0;
+ int questionLength = 0;
+ int passwordLength = 0;
+ int sessionInformationLength = 0;
+ int timeStampLength = 0;
+
+ // The OCRASuites components
+ String CryptoFunction = ocraSuite.split(":")[1];
+ String DataInput = ocraSuite.split(":")[2];
+
+
+ if(CryptoFunction.toLowerCase().indexOf("sha1") > 1)
+ crypto = "HmacSHA1";
+ if(CryptoFunction.toLowerCase().indexOf("sha256") > 1)
+ crypto = "HmacSHA256";
+ if(CryptoFunction.toLowerCase().indexOf("sha512") > 1)
+ crypto = "HmacSHA512";
+
+ // How many digits should we return
+ codeDigits = Integer.decode(CryptoFunction.substring(
+ CryptoFunction.lastIndexOf("-")+1));
+
+ // The size of the byte array message to be encrypted
+ // Counter
+ if(DataInput.toLowerCase().startsWith("c")) {
+ // Fix the length of the HEX string
+ while(counter.length() < 16)
+ counter = "0" + counter;
+ counterLength=8;
+ }
+ // Question - always 128 bytes
+ if(DataInput.toLowerCase().startsWith("q") ||
+ (DataInput.toLowerCase().indexOf("-q") >= 0)) {
+ while(question.length() < 256)
+ question = question + "0";
+
+
+
+M'Raihi, et al. Informational [Page 22]
+
+RFC 6287 OCRA June 2011
+
+
+ questionLength=128;
+ }
+
+ // Password - sha1
+ if(DataInput.toLowerCase().indexOf("psha1") > 1){
+ while(password.length() < 40)
+ password = "0" + password;
+ passwordLength=20;
+ }
+
+ // Password - sha256
+ if(DataInput.toLowerCase().indexOf("psha256") > 1){
+ while(password.length() < 64)
+ password = "0" + password;
+ passwordLength=32;
+ }
+
+ // Password - sha512
+ if(DataInput.toLowerCase().indexOf("psha512") > 1){
+ while(password.length() < 128)
+ password = "0" + password;
+ passwordLength=64;
+ }
+
+ // sessionInformation - s064
+ if(DataInput.toLowerCase().indexOf("s064") > 1){
+ while(sessionInformation.length() < 128)
+ sessionInformation = "0" + sessionInformation;
+ sessionInformationLength=64;
+ }
+
+ // sessionInformation - s128
+ if(DataInput.toLowerCase().indexOf("s128") > 1){
+ while(sessionInformation.length() < 256)
+ sessionInformation = "0" + sessionInformation;
+ sessionInformationLength=128;
+ }
+
+ // sessionInformation - s256
+ if(DataInput.toLowerCase().indexOf("s256") > 1){
+ while(sessionInformation.length() < 512)
+ sessionInformation = "0" + sessionInformation;
+ sessionInformationLength=256;
+ }
+
+ // sessionInformation - s512
+ if(DataInput.toLowerCase().indexOf("s512") > 1){
+ while(sessionInformation.length() < 1024)
+
+
+
+M'Raihi, et al. Informational [Page 23]
+
+RFC 6287 OCRA June 2011
+
+
+ sessionInformation = "0" + sessionInformation;
+ sessionInformationLength=512;
+ }
+
+ // TimeStamp
+ if(DataInput.toLowerCase().startsWith("t") ||
+ (DataInput.toLowerCase().indexOf("-t") > 1)){
+ while(timeStamp.length() < 16)
+ timeStamp = "0" + timeStamp;
+ timeStampLength=8;
+ }
+
+ // Remember to add "1" for the "00" byte delimiter
+ byte[] msg = new byte[ocraSuiteLength +
+ counterLength +
+ questionLength +
+ passwordLength +
+ sessionInformationLength +
+ timeStampLength +
+ 1];
+
+
+ // Put the bytes of "ocraSuite" parameters into the message
+ byte[] bArray = ocraSuite.getBytes();
+ System.arraycopy(bArray, 0, msg, 0, bArray.length);
+
+ // Delimiter
+ msg[bArray.length] = 0x00;
+
+ // Put the bytes of "Counter" to the message
+ // Input is HEX encoded
+ if(counterLength > 0 ){
+ bArray = hexStr2Bytes(counter);
+ System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1,
+ bArray.length);
+ }
+
+
+ // Put the bytes of "question" to the message
+ // Input is text encoded
+ if(questionLength > 0 ){
+ bArray = hexStr2Bytes(question);
+ System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
+ counterLength, bArray.length);
+ }
+
+ // Put the bytes of "password" to the message
+ // Input is HEX encoded
+
+
+
+M'Raihi, et al. Informational [Page 24]
+
+RFC 6287 OCRA June 2011
+
+
+ if(passwordLength > 0){
+ bArray = hexStr2Bytes(password);
+ System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
+ counterLength + questionLength, bArray.length);
+
+ }
+
+ // Put the bytes of "sessionInformation" to the message
+ // Input is text encoded
+ if(sessionInformationLength > 0 ){
+ bArray = hexStr2Bytes(sessionInformation);
+ System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
+ counterLength + questionLength +
+ passwordLength, bArray.length);
+ }
+
+ // Put the bytes of "time" to the message
+ // Input is text value of minutes
+ if(timeStampLength > 0){
+ bArray = hexStr2Bytes(timeStamp);
+ System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 +
+ counterLength + questionLength +
+ passwordLength + sessionInformationLength,
+ bArray.length);
+ }
+
+ bArray = hexStr2Bytes(key);
+
+ byte[] hash = hmac_sha1(crypto, bArray, msg);
+
+ // put selected bytes into result int
+ 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;
+ }
+ }
+
+
+
+M'Raihi, et al. Informational [Page 25]
+
+RFC 6287 OCRA June 2011
+
+
+ <CODE ENDS>
+
+Appendix B. Test Vectors Generation
+
+ <CODE BEGINS>
+
+ /**
+ Copyright (c) 2011 IETF Trust and the persons identified as
+ authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, is permitted pursuant to, and subject to the license
+ terms contained in, the Simplified BSD License set forth in Section
+ 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info).
+ */
+
+ import java.math.BigInteger;
+ import java.util.*;
+ import java.text.DateFormat;
+ import java.text.SimpleDateFormat;
+
+ public class TestOCRA {
+
+ public static String asHex (byte buf[]) {
+ StringBuffer strbuf = new StringBuffer(buf.length * 2);
+ int i;
+
+ for (i = 0; i < buf.length; i++) {
+ if (((int) buf[i] & 0xff) < 0x10)
+ strbuf.append("0");
+ strbuf.append(Long.toString((int) buf[i] & 0xff, 16));
+ }
+ return strbuf.toString();
+ }
+
+ /**
+ * @param args
+ */
+ public static void main(String[] args) {
+
+ String ocra = "";
+ String seed = "";
+ String ocraSuite = "";
+ String counter = "";
+ String password = "";
+ String sessionInformation = "";
+ String question = "";
+
+
+
+M'Raihi, et al. Informational [Page 26]
+
+RFC 6287 OCRA June 2011
+
+
+ String qHex = "";
+ String timeStamp = "";
+
+ // PASS1234 is SHA1 hash of "1234"
+ String PASS1234 = "7110eda4d09e062aa5e4a390b0a572ac0d2c0220";
+
+ String SEED = "3132333435363738393031323334353637383930";
+ String SEED32 = "31323334353637383930313233343536373839" +
+ "30313233343536373839303132";
+ String SEED64 = "31323334353637383930313233343536373839" +
+ "3031323334353637383930313233343536373839" +
+ "3031323334353637383930313233343536373839" +
+ "3031323334";
+ int STOP = 5;
+
+ Date myDate = Calendar.getInstance().getTime();
+ BigInteger b = new BigInteger("0");
+ String sDate = "Mar 25 2008, 12:06:30 GMT";
+
+ try{
+ DateFormat df =
+ new SimpleDateFormat("MMM dd yyyy, HH:mm:ss zzz");
+ myDate = df.parse(sDate);
+ b = new BigInteger("0" + myDate.getTime());
+ b = b.divide(new BigInteger("60000"));
+
+
+ System.out.println("Time of \"" + sDate + "\" is in");
+ System.out.println("milli sec: " + myDate.getTime());
+ System.out.println("minutes: " + b.toString());
+ System.out.println("minutes (HEX encoded): "
+ + b.toString(16).toUpperCase());
+ System.out.println("Time of \"" + sDate
+ + "\" is the same as this localized");
+ System.out.println("time, \""
+ + new Date(myDate.getTime()) + "\"");
+
+ System.out.println();
+ System.out.println("Standard 20Byte key: " +
+ "3132333435363738393031323334353637383930");
+ System.out.println("Standard 32Byte key: " +
+ "3132333435363738393031323334353637383930");
+ System.out.println(" " +
+ "313233343536373839303132");
+ System.out.println("Standard 64Byte key: 313233343536373839"
+ + "3031323334353637383930");
+ System.out.println(" 313233343536373839"
+ + "3031323334353637383930");
+
+
+
+M'Raihi, et al. Informational [Page 27]
+
+RFC 6287 OCRA June 2011
+
+
+ System.out.println(" 313233343536373839"
+ + "3031323334353637383930");
+ System.out.println(" 31323334");
+
+ System.out.println();
+ System.out.println("Plain challenge response");
+ System.out.println("========================");
+ System.out.println();
+
+ ocraSuite = "OCRA-1:HOTP-SHA1-6:QN08";
+ System.out.println(ocraSuite);
+ System.out.println("=======================");
+ seed = SEED;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < 10; i++){
+ question = "" + i + i + i + i + i + i + i + i;
+ qHex = new String((new BigInteger(question,10))
+ .toString(16)).toUpperCase();
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
+ qHex,password,
+ sessionInformation,timeStamp);
+ System.out.println("Key: Standard 20Byte Q: "
+ + question + " OCRA: " + ocra);
+ }
+ System.out.println();
+
+ ocraSuite = "OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1";
+ System.out.println(ocraSuite);
+ System.out.println("=================================");
+ seed = SEED32;
+ counter = "";
+ question = "12345678";
+ password = PASS1234;
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < 10; i++){
+ counter = "" + i;
+ qHex = new String((new BigInteger(question,10))
+ .toString(16)).toUpperCase();
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
+ qHex,password,sessionInformation,timeStamp);
+ System.out.println("Key: Standard 32Byte C: "
+ + counter + " Q: "
+ + question + " PIN(1234): ");
+
+
+
+M'Raihi, et al. Informational [Page 28]
+
+RFC 6287 OCRA June 2011
+
+
+ System.out.println(password + " OCRA: " + ocra);
+ }
+ System.out.println();
+
+ ocraSuite = "OCRA-1:HOTP-SHA256-8:QN08-PSHA1";
+ System.out.println(ocraSuite);
+ System.out.println("===============================");
+ seed = SEED32;
+ counter = "";
+ question = "";
+ password = PASS1234;
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < STOP; i++){
+ question = "" + i + i + i + i + i + i + i + i;
+
+ qHex = new String((new BigInteger(question,10))
+ .toString(16)).toUpperCase();
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
+ qHex,password,sessionInformation,timeStamp);
+ System.out.println("Key: Standard 32Byte Q: "
+ + question + " PIN(1234): ");
+ System.out.println(password + " OCRA: " + ocra);
+ }
+ System.out.println();
+
+ ocraSuite = "OCRA-1:HOTP-SHA512-8:C-QN08";
+ System.out.println(ocraSuite);
+ System.out.println("===========================");
+ seed = SEED64;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < 10; i++){
+ question = "" + i + i + i + i + i + i + i + i;
+ qHex = new String((new BigInteger(question,10))
+ .toString(16)).toUpperCase();
+ counter = "0000" + i;
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
+ qHex,password,sessionInformation,timeStamp);
+ System.out.println("Key: Standard 64Byte C: "
+ + counter + " Q: "
+ + question + " OCRA: " + ocra);
+ }
+ System.out.println();
+
+
+
+
+M'Raihi, et al. Informational [Page 29]
+
+RFC 6287 OCRA June 2011
+
+
+ ocraSuite = "OCRA-1:HOTP-SHA512-8:QN08-T1M";
+ System.out.println(ocraSuite);
+ System.out.println("=============================");
+ seed = SEED64;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = b.toString(16);
+ for(int i=0; i < STOP; i++){
+ question = "" + i + i + i + i + i + i + i + i;
+ counter = "";
+ qHex = new String((new BigInteger(question,10))
+ .toString(16)).toUpperCase();
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
+ qHex,password,sessionInformation,timeStamp);
+
+ System.out.println("Key: Standard 64Byte Q: "
+ + question +" T: "
+ + timeStamp.toUpperCase()
+ + " OCRA: " + ocra);
+ }
+ System.out.println();
+
+ System.out.println();
+ System.out.println("Mutual Challenge Response");
+ System.out.println("=========================");
+ System.out.println();
+
+ ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08";
+ System.out.println("OCRASuite (server computation) = "
+ + ocraSuite);
+ System.out.println("OCRASuite (client computation) = "
+ + ocraSuite);
+ System.out.println("===============================" +
+ "===========================");
+ seed = SEED32;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < STOP; i++){
+ question = "CLI2222" + i + "SRV1111" + i;
+ qHex = asHex(question.getBytes());
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
+ password,sessionInformation,timeStamp);
+ System.out.println(
+
+
+
+M'Raihi, et al. Informational [Page 30]
+
+RFC 6287 OCRA June 2011
+
+
+ "(server)Key: Standard 32Byte Q: "
+ + question + " OCRA: "
+ + ocra);
+ question = "SRV1111" + i + "CLI2222" + i;
+ qHex = asHex(question.getBytes());
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
+ password,sessionInformation,timeStamp);
+ System.out.println(
+ "(client)Key: Standard 32Byte Q: "
+ + question + " OCRA: "
+ + ocra);
+ }
+ System.out.println();
+
+ String ocraSuite1 = "OCRA-1:HOTP-SHA512-8:QA08";
+ String ocraSuite2 = "OCRA-1:HOTP-SHA512-8:QA08-PSHA1";
+ System.out.println("OCRASuite (server computation) = "
+ + ocraSuite1);
+ System.out.println("OCRASuite (client computation) = "
+ + ocraSuite2);
+ System.out.println("===============================" +
+ "=================================");
+ ocraSuite = "";
+ seed = SEED64;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < STOP; i++){
+ ocraSuite = ocraSuite1;
+ question = "CLI2222" + i + "SRV1111" + i;
+ qHex = asHex(question.getBytes());
+ password = "";
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
+ password,sessionInformation,timeStamp);
+ System.out.println(
+ "(server)Key: Standard 64Byte Q: "
+ + question + " OCRA: "
+ + ocra);
+ ocraSuite = ocraSuite2;
+ question = "SRV1111" + i + "CLI2222" + i;
+ qHex = asHex(question.getBytes());
+ password = PASS1234;
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
+ password,sessionInformation,timeStamp);
+ System.out.println("(client)Key: Standard 64Byte Q: "
+ + question);
+
+
+
+M'Raihi, et al. Informational [Page 31]
+
+RFC 6287 OCRA June 2011
+
+
+ System.out.println("P: " + password.toUpperCase()
+ + " OCRA: " + ocra);
+ }
+ System.out.println();
+
+ System.out.println();
+ System.out.println("Plain Signature");
+ System.out.println("===============");
+ System.out.println();
+ ocraSuite = "OCRA-1:HOTP-SHA256-8:QA08";
+ System.out.println(ocraSuite);
+ System.out.println("=========================");
+ seed = SEED32;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = "";
+ for(int i=0; i < STOP; i++){
+ question = "SIG1" + i + "000";
+ qHex = asHex(question.getBytes());
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,qHex,
+ password,sessionInformation,timeStamp);
+ System.out.println(
+ "Key: Standard 32Byte Q(Signature challenge): "
+ + question);
+ System.out.println(" OCRA: " + ocra);
+ }
+ System.out.println();
+
+ ocraSuite = "OCRA-1:HOTP-SHA512-8:QA10-T1M";
+ System.out.println(ocraSuite);
+ System.out.println("=============================");
+ seed = SEED64;
+ counter = "";
+ question = "";
+ password = "";
+ sessionInformation = "";
+ timeStamp = b.toString(16);
+ for(int i=0; i < STOP; i++){
+ question = "SIG1" + i + "00000";
+ qHex = asHex(question.getBytes());
+ ocra = OCRA.generateOCRA(ocraSuite,seed,counter,
+ qHex,password,sessionInformation,timeStamp);
+ System.out.println(
+ "Key: Standard 64Byte Q(Signature challenge): "
+ + question);
+ System.out.println(" T: "
+
+
+
+M'Raihi, et al. Informational [Page 32]
+
+RFC 6287 OCRA June 2011
+
+
+ + timeStamp.toUpperCase() + " OCRA: "
+ + ocra);
+ }
+
+ }catch (Exception e){
+ System.out.println("Error : " + e);
+ }
+ }
+ }
+ <CODE ENDS>
+
+Appendix C. Test Vectors
+
+ This section provides test values that can be used for the OCRA
+ interoperability test.
+
+ Standard 20Byte key:
+
+ 3132333435363738393031323334353637383930
+
+ Standard 32Byte key:
+
+ 3132333435363738393031323334353637383930313233343536373839303132
+
+ Standard 64Byte key:
+
+ 313233343536373839303132333435363738393031323334353637383930313233343
+ 53637383930313233343536373839303132333435363738393031323334
+
+ PIN (1234) SHA1 hash value:
+
+ 7110eda4d09e062aa5e4a390b0a572ac0d2c0220
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 33]
+
+RFC 6287 OCRA June 2011
+
+
+C.1. One-Way Challenge Response
+
+ +-----------------+----------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+----------+------------+
+ | Standard 20Byte | 00000000 | 237653 |
+ | Standard 20Byte | 11111111 | 243178 |
+ | Standard 20Byte | 22222222 | 653583 |
+ | Standard 20Byte | 33333333 | 740991 |
+ | Standard 20Byte | 44444444 | 608993 |
+ | Standard 20Byte | 55555555 | 388898 |
+ | Standard 20Byte | 66666666 | 816933 |
+ | Standard 20Byte | 77777777 | 224598 |
+ | Standard 20Byte | 88888888 | 750600 |
+ | Standard 20Byte | 99999999 | 294470 |
+ +-----------------+----------+------------+
+
+ OCRA-1:HOTP-SHA1-6:QN08
+
+ +-----------------+---+----------+------------+
+ | Key | C | Q | OCRA Value |
+ +-----------------+---+----------+------------+
+ | Standard 32Byte | 0 | 12345678 | 65347737 |
+ | Standard 32Byte | 1 | 12345678 | 86775851 |
+ | Standard 32Byte | 2 | 12345678 | 78192410 |
+ | Standard 32Byte | 3 | 12345678 | 71565254 |
+ | Standard 32Byte | 4 | 12345678 | 10104329 |
+ | Standard 32Byte | 5 | 12345678 | 65983500 |
+ | Standard 32Byte | 6 | 12345678 | 70069104 |
+ | Standard 32Byte | 7 | 12345678 | 91771096 |
+ | Standard 32Byte | 8 | 12345678 | 75011558 |
+ | Standard 32Byte | 9 | 12345678 | 08522129 |
+ +-----------------+---+----------+------------+
+
+ OCRA-1:HOTP-SHA256-8:C-QN08-PSHA1
+
+ +-----------------+----------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+----------+------------+
+ | Standard 32Byte | 00000000 | 83238735 |
+ | Standard 32Byte | 11111111 | 01501458 |
+ | Standard 32Byte | 22222222 | 17957585 |
+ | Standard 32Byte | 33333333 | 86776967 |
+ | Standard 32Byte | 44444444 | 86807031 |
+ +-----------------+----------+------------+
+
+ OCRA-1:HOTP-SHA256-8:QN08-PSHA1
+
+
+
+
+M'Raihi, et al. Informational [Page 34]
+
+RFC 6287 OCRA June 2011
+
+
+ +-----------------+-------+----------+------------+
+ | Key | C | Q | OCRA Value |
+ +-----------------+-------+----------+------------+
+ | Standard 64Byte | 00000 | 00000000 | 07016083 |
+ | Standard 64Byte | 00001 | 11111111 | 63947962 |
+ | Standard 64Byte | 00002 | 22222222 | 70123924 |
+ | Standard 64Byte | 00003 | 33333333 | 25341727 |
+ | Standard 64Byte | 00004 | 44444444 | 33203315 |
+ | Standard 64Byte | 00005 | 55555555 | 34205738 |
+ | Standard 64Byte | 00006 | 66666666 | 44343969 |
+ | Standard 64Byte | 00007 | 77777777 | 51946085 |
+ | Standard 64Byte | 00008 | 88888888 | 20403879 |
+ | Standard 64Byte | 00009 | 99999999 | 31409299 |
+ +-----------------+-------+----------+------------+
+
+ OCRA-1:HOTP-SHA512-8:C-QN08
+
+ +-----------------+----------+---------+------------+
+ | Key | Q | T | OCRA Value |
+ +-----------------+----------+---------+------------+
+ | Standard 64Byte | 00000000 | 132d0b6 | 95209754 |
+ | Standard 64Byte | 11111111 | 132d0b6 | 55907591 |
+ | Standard 64Byte | 22222222 | 132d0b6 | 22048402 |
+ | Standard 64Byte | 33333333 | 132d0b6 | 24218844 |
+ | Standard 64Byte | 44444444 | 132d0b6 | 36209546 |
+ +-----------------+----------+---------+------------+
+
+ OCRA-1:HOTP-SHA512-8:QN08-T1M
+
+C.2. Mutual Challenge-Response
+
+ OCRASuite (server computation) = OCRA-1:HOTP-SHA256-8:QA08
+
+ OCRASuite (client computation) = OCRA-1:HOTP-SHA256-8:QA08
+
+ +-----------------+------------------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+------------------+------------+
+ | Standard 32Byte | CLI22220SRV11110 | 28247970 |
+ | Standard 32Byte | CLI22221SRV11111 | 01984843 |
+ | Standard 32Byte | CLI22222SRV11112 | 65387857 |
+ | Standard 32Byte | CLI22223SRV11113 | 03351211 |
+ | Standard 32Byte | CLI22224SRV11114 | 83412541 |
+ +-----------------+------------------+------------+
+
+ Server -- OCRA-1:HOTP-SHA256-8:QA08
+
+
+
+
+
+M'Raihi, et al. Informational [Page 35]
+
+RFC 6287 OCRA June 2011
+
+
+ +-----------------+------------------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+------------------+------------+
+ | Standard 32Byte | SRV11110CLI22220 | 15510767 |
+ | Standard 32Byte | SRV11111CLI22221 | 90175646 |
+ | Standard 32Byte | SRV11112CLI22222 | 33777207 |
+ | Standard 32Byte | SRV11113CLI22223 | 95285278 |
+ | Standard 32Byte | SRV11114CLI22224 | 28934924 |
+ +-----------------+------------------+------------+
+
+ Client -- OCRA-1:HOTP-SHA256-8:QA08
+
+ OCRASuite (server computation) = OCRA-1:HOTP-SHA512-8:QA08
+
+ OCRASuite (client computation) = OCRA-1:HOTP-SHA512-8:QA08-PSHA1
+
+ +-----------------+------------------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+------------------+------------+
+ | Standard 64Byte | CLI22220SRV11110 | 79496648 |
+ | Standard 64Byte | CLI22221SRV11111 | 76831980 |
+ | Standard 64Byte | CLI22222SRV11112 | 12250499 |
+ | Standard 64Byte | CLI22223SRV11113 | 90856481 |
+ | Standard 64Byte | CLI22224SRV11114 | 12761449 |
+ +-----------------+------------------+------------+
+
+ Server -- OCRA-1:HOTP-SHA512-8:QA08
+
+ +-----------------+------------------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+------------------+------------+
+ | Standard 64Byte | SRV11110CLI22220 | 18806276 |
+ | Standard 64Byte | SRV11111CLI22221 | 70020315 |
+ | Standard 64Byte | SRV11112CLI22222 | 01600026 |
+ | Standard 64Byte | SRV11113CLI22223 | 18951020 |
+ | Standard 64Byte | SRV11114CLI22224 | 32528969 |
+ +-----------------+------------------+------------+
+
+ Client -- OCRA-1:HOTP-SHA512-8:QA08-PSHA1
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 36]
+
+RFC 6287 OCRA June 2011
+
+
+C.3. Plain Signature
+
+ In this mode of operation, Q represents the signature challenge.
+
+ +-----------------+----------+------------+
+ | Key | Q | OCRA Value |
+ +-----------------+----------+------------+
+ | Standard 32Byte | SIG10000 | 53095496 |
+ | Standard 32Byte | SIG11000 | 04110475 |
+ | Standard 32Byte | SIG12000 | 31331128 |
+ | Standard 32Byte | SIG13000 | 76028668 |
+ | Standard 32Byte | SIG14000 | 46554205 |
+ +-----------------+----------+------------+
+
+ OCRA-1:HOTP-SHA256-8:QA08
+
+ +-----------------+------------+---------+------------+
+ | Key | Q | T | OCRA Value |
+ +-----------------+------------+---------+------------+
+ | Standard 64Byte | SIG1000000 | 132d0b6 | 77537423 |
+ | Standard 64Byte | SIG1100000 | 132d0b6 | 31970405 |
+ | Standard 64Byte | SIG1200000 | 132d0b6 | 10235557 |
+ | Standard 64Byte | SIG1300000 | 132d0b6 | 95213541 |
+ | Standard 64Byte | SIG1400000 | 132d0b6 | 65360607 |
+ +-----------------+------------+---------+------------+
+
+ OCRA-1:HOTP-SHA512-8:QA10-T1M
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 37]
+
+RFC 6287 OCRA June 2011
+
+
+Authors' Addresses
+
+ David M'Raihi
+ Verisign, Inc.
+ 487 E. Middlefield Road
+ Mountain View, CA 94043
+ USA
+
+ EMail: davidietf@gmail.com
+
+
+ Johan Rydell
+ Portwise, Inc.
+ 275 Hawthorne Ave, Suite 119
+ Palo Alto, CA 94301
+ USA
+
+ EMail: johanietf@gmail.com
+
+
+ Siddharth Bajaj
+ Symantec Corp.
+ 350 Ellis Street
+ Mountain View, CA 94043
+ USA
+
+ EMail: siddharthietf@gmail.com
+
+
+ Salah Machani
+ Diversinet Corp.
+ 2225 Sheppard Avenue East, Suite 1801
+ Toronto, Ontario M2J 5C2
+ Canada
+
+ EMail: smachani@diversinet.com
+
+
+ David Naccache
+ Ecole Normale Superieure
+ ENS DI, 45 rue d'Ulm
+ Paris, 75005
+ France
+
+ EMail: david.naccache@ens.fr
+
+
+
+
+
+
+M'Raihi, et al. Informational [Page 38]
+