One document matched: draft-mraihi-mutual-oath-hotp-variants-07.txt
Differences from draft-mraihi-mutual-oath-hotp-variants-06.txt
Internet Draft David M'Raihi
VeriSign
Category: Johan Rydell
Informational PortWise
Document: David Naccache
draft-mraihi-mutual-oath-hotp-variants-07.txt ENS
Salah Machani
Diversinet
Siddharth Bajaj
VeriSign
Expires: October 03, 2008 April 03, 2008
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 in 2006.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 1]
OCRA: OATH Challenge Response Algorithms April 2008
Table of Contents
1. Introduction...............................................3
2. Requirements 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..............................................6
6. The OCRASuite..............................................7
7. Algorithm Modes for Authentication.........................8
7.1 One way Challenge-Response..................................9
7.2 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...................................13
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: Source Code........................................17
14. Authors' Addresses........................................24
15. Full Copyright Statement..................................25
16. Intellectual Property.....................................26
OATH-HOTP-VARIANTS Expires - October 2008 [Page 2]
OCRA: OATH Challenge Response Algorithms April 2008
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. A 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 there is a need for a standardized challenge-response
algorithm which 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 digital signatures. Such signatures 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 need 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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 3]
OCRA: OATH Challenge Response Algorithms April 2008
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))
OATH-HOTP-VARIANTS Expires - October 2008 [Page 4]
OCRA: OATH Challenge Response Algorithms April 2008
Where Truncate represents the function that converts an HMAC-SHA-1
value into an HOTP value.
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.
5. Definition of OCRA
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 the OCRA algorithm and then introduces the definitions
and default values recommended for all parameters.
In a nutshell,
OCRA = CryptoFunction(K, DataInput)
Where:
- K: a shared secret key known to both parties;
- DataInput: a structure that contains the concatenation of the
various input data values defined in details in section 5.1;
- 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:
. OCRASuite is a value representing the suite of operations to
compute an OCRA response;
. 00 is a byte value used as a separator;
. 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";
OATH-HOTP-VARIANTS Expires - October 2008 [Page 5]
OCRA: OATH Challenge Response Algorithms April 2008
. 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;
. P is a 20-byte SHA1-hash of PIN/password that is known to all
parties during the execution of the algorithm;
. S is a 64-byte UTF-8 encoded string that contains information
about the current session;
. T is an 8-byte unsigned integer in big endian (i.e. network
byte order) representing the number of minutes since midnight
UTC of January 1, 1970. More specificatlly, if the OCRA
computation includes a timestamp T, you SHOULD first convert
your current local time to UTC time (text form). You can then
derive the UTC time in milliseconds and T (minutes from Epoch
time).
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.
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.
As indicated in section 5.1, we denote t as the length in digits of
the truncation output. For instance, if t = 6, then the output of
the truncation is a 6-digit value.
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
OATH-HOTP-VARIANTS Expires - October 2008 [Page 6]
OCRA: OATH Challenge Response Algorithms April 2008
dynamic truncation as described in [RFC 4226] to extract a t-
digit value;
- t=0 means that no truncation is performed and the full HMAC value
is used for authentication purpose.
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-SHA1-8: HOTP with SHA-1 as the hash function for HMAC
and a dynamic truncation to an 8-digit value;
. HOTP-SHA256-6: HOTP with SHA-256 as the hash function for
HMAC and a dynamic truncation to a 6-digit value;
. HOTP-SHA512-6: HOTP with SHA-512 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
An OCRASuite value is a text string that captures one mode of
operation for the OCRA algorithm, completely specifying the various
options for that computation. An OCRASuite value is represented as
follows:
Algorithm:CryptoFunction:DataInput
The client and server need to agree on one or two values of
OCRASuite. These values may be agreed at time of token provisioning
or for more sophisticated client-server interactions these values
may be negotiated for every transaction.
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.
Algorithm
OATH-HOTP-VARIANTS Expires - October 2008 [Page 7]
OCRA: OATH Challenge Response Algorithms April 2008
---------
Description: Indicates the version of OCRA algorithm.
Values: OCRA-v where v represents the version number (e.g. 1, 2
etc.). This document specifies version 1 of the OCRA algorithm.
CryptoFunction
--------------
Description: Indicates the function used to compute OCRA values
Values: Permitted values are described in section 5.2
DataInput
---------
Description: This component of the OCRASuite string captures the
list of valid inputs for that computation; [] indicates a value is
optional:
[C] | QFxx | [P | S | T]: Challenge-Response computation
[C] | QFxx | [P | T]: 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
The default format for challenge question is N08, numeric and upto
8 digits.
For example OCRA-1:HOTP-SHA512-8:C-QN08-P means version 1 of the
OCRA algorithm with HMAC-SHA512 function, truncated to an 8-digit
value, using the counter, a random challenge and a hash of the
PIN/Password as parameters. It also indicates that the client
supports only numeric challenge upto 8 digits in length.
7. Algorithm Modes for Authentication
This section describes the typical modes in which the above defined
computation can be used for authentication.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 8]
OCRA: OATH Challenge Response Algorithms April 2008
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 |
|<------------------------------------------|
| |
OATH-HOTP-VARIANTS Expires - October 2008 [Page 9]
OCRA: OATH Challenge Response Algorithms April 2008
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.
The following picture 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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 10]
OCRA: OATH Challenge Response Algorithms April 2008
CLIENT SERVER
| |
| 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 |
|<--------------------------------------------------|
| |
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.
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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 11]
OCRA: OATH Challenge Response Algorithms April 2008
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 |
|<------------------------------------------|
| |
8.2 Signature with Server Authentication
This mode is a variation of the plain signature mode where the
client can first authenticates the server before generating 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.
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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 12]
OCRA: OATH Challenge Response Algorithms April 2008
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.
CLIENT SERVER
| |
| 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 |
|<--------------------------------------------------|
| |
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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 13]
OCRA: OATH Challenge Response Algorithms April 2008
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
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 [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].
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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 14]
OCRA: OATH Challenge Response Algorithms April 2008
IC6 - We RECOMMEND following the recommendations in [RFC1750] for
all pseudo-random and random challenge generations.
IC7 - All the communications SHOULD take place over a secure
channel e.g. SSL/TLS, IPsec connections.
IC8 - The OCRA algorithm 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.
IC9 - 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.
IC10 - 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.
IC11 - 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.
10. IANA Considerations
This document has no actions for IANA.
11. Conclusion
OATH-HOTP-VARIANTS Expires - October 2008 [Page 15]
OCRA: OATH Challenge Response Algorithms April 2008
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 mutual authentication both in connected
and off-line modes, with the support of different response sizes
and mode of operations.
12. 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 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
OATH-HOTP-VARIANTS Expires - October 2008 [Page 16]
OCRA: OATH Challenge Response Algorithms April 2008
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
Appendix A: Source Code
import java.lang.reflect.UndeclaredThrowableException;
import java.security.GeneralSecurityException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.math.BigInteger;
/**
* 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);
OATH-HOTP-VARIANTS Expires - October 2008 [Page 17]
OCRA: OATH Challenge Response Algorithms April 2008
} 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
* 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
* @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
*
* @return A numeric String in base 10 that includes
* {@link truncationDigits} digits
*/
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.length();
int counterLength = 0;
int questionLength = 0;
int passwordLength = 0;
int sessionInformationLength = 0;
int timeStampLength = 0;
if(ocraSuite.toLowerCase().indexOf("sha1") > 1)
crypto = "HmacSHA1";
if(ocraSuite.toLowerCase().indexOf("sha256") > 1)
crypto = "HmacSHA256";
if(ocraSuite.toLowerCase().indexOf("sha512") > 1)
crypto = "HmacSHA512";
OATH-HOTP-VARIANTS Expires - October 2008 [Page 18]
OCRA: OATH Challenge Response Algorithms April 2008
// How many digits should we return
String oS = ocraSuite.substring(ocraSuite.indexOf(":"),
ocraSuite.indexOf(":", ocraSuite.indexOf(":") + 1));
codeDigits = Integer.decode(oS.substring
(oS.lastIndexOf("-")+1,
oS.length()));
// The size of the byte array message to be encrypted
// Counter
if(ocraSuite.toLowerCase().indexOf(":c") > 1) {
counterLength=8;
}
// Question
if((ocraSuite.toLowerCase().indexOf(":q") > 1) ||
(ocraSuite.toLowerCase().indexOf("-q") > 1)) {
questionLength=128;
}
// Password
if((ocraSuite.toLowerCase().indexOf(":p") > 1) ||
(ocraSuite.toLowerCase().indexOf("-p") > 1)){
passwordLength=20;
}
// sessionInformation
if((ocraSuite.toLowerCase().indexOf(":s") > 1) ||
(ocraSuite.toLowerCase().indexOf("-s",
ocraSuite.indexOf(":",
ocraSuite.indexOf(":") + 1)) > 1)){
sessionInformationLength=64;
}
// TimeStamp
if((ocraSuite.toLowerCase().indexOf(":t") > 1) ||
(ocraSuite.toLowerCase().indexOf("-t") > 1)){
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();
for(int i = 0; i < bArray.length; i++){
msg[i] = bArray[i];
}
OATH-HOTP-VARIANTS Expires - October 2008 [Page 19]
OCRA: OATH Challenge Response Algorithms April 2008
// Put the bytes of "Counter" to the message
// Input is HEX encoded
if(counter.length() > 0 ){
bArray = new BigInteger(counter,16).toByteArray();
if(bArray.length == 9){
// First byte is the "sign" byte
for (int i = 0; i < 8 && i < bArray.length ; i++)
{
msg[i + 8 - bArray.length
+ ocraSuiteLength + 1] =
bArray[i+1];
}
}
else {
for (int i = 0; i < 8 && i < bArray.length ; i++)
{
msg[i + 8 - bArray.length
+ ocraSuiteLength + 1] = bArray[i];
}
}
}
// Put the bytes of "question" to the message
// Input is text encoded
if(question.length() > 0 ){
bArray = question.getBytes();
for (int i = 0; i < 128 && i < bArray.length ; i++)
{
msg[i + ocraSuiteLength + 1
+ counterLength] = bArray[i];
}
}
// Put the bytes of "password" to the message
// Input is HEX encoded
if(password.length() > 0){
bArray = new BigInteger(password,16).toByteArray();
if(bArray.length == 21){
// First byte is the "sign" byte
for (int i = 0; i < 20 && i < bArray.length ; i++)
{
msg[i + ocraSuiteLength + 1 + counterLength
+ questionLength] = bArray[i+1];
}
}
else {
for (int i = 0; i < 20 && i < bArray.length ; i++)
{
msg[i + ocraSuiteLength + 1 + counterLength +
questionLength] = bArray[i];
}
}
}
OATH-HOTP-VARIANTS Expires - October 2008 [Page 20]
OCRA: OATH Challenge Response Algorithms April 2008
// Put the bytes of "sessionInformation" to the message
// Input is text encoded
if(sessionInformation.length() > 0 ){
bArray = sessionInformation.getBytes();
for (int i = 0; i < 128 && i < bArray.length ; i++) {
msg[i + ocraSuiteLength + 1
+ counterLength + questionLength
+ passwordLength] = bArray[i];
}
}
// Put the bytes of "time" to the message
// Input is text value of minutes
if(timeStamp.length() > 0){
bArray = new BigInteger(timeStamp,16).toByteArray();
if(bArray.length == 9){
// First byte is the "sign" byte
for (int i = 0; i < 8 && i < bArray.length ; i++) {
msg[i + 8 - bArray.length +
ocraSuiteLength + 1 + counterLength
+ questionLength + passwordLength +
sessionInformationLength] = bArray[i+1];
}
}
else {
for (int i = 0; i < 8 && i < bArray.length ; i++) {
msg[i + 8 - bArray.length
+ ocraSuiteLength + 1 + counterLength
+ questionLength + passwordLength +
sessionInformationLength] = bArray[i];
}
}
}
byte[] hash;
bArray = new BigInteger(key,16).toByteArray();
if(bArray[0] == 0){
byte[] b = new byte[bArray.length - 1];
for(int i = 0 ; i < b.length; i++)
b[i]=bArray[i+1];
hash = hmac_sha1(crypto, b, msg);
}
else{
// compute hmac hash
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)
OATH-HOTP-VARIANTS Expires - October 2008 [Page 21]
OCRA: OATH Challenge Response Algorithms April 2008
|((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
OCRA Test Vectors (OCRA Test Vectors generated on March 29, 2008)
For all computations, Key (K) = 12345678901234567890
***** OCRA-V1 Plain Challenge Response *****
==> Q only, Digit (D) = 6, Algorithm (A) = HMACSHA1
ID OCRASuite Question(Q) OCRA(O)
T1.1 OCRA-1:HOTP-SHA1-6:QN08 00000000 713673
T1.2 OCRA-1:HOTP-SHA1-6:QN08 11111111 640542
T1.3 OCRA-1:HOTP-SHA1-6:QN08 22222222 434144
T1.4 OCRA-1:HOTP-SHA1-6:QN08 33333333 024883
T1.5 OCRA-1:HOTP-SHA1-6:QN08 44444444 473006
T1.6 OCRA-1:HOTP-SHA1-6:QN08 55555555 911781
T1.7 OCRA-1:HOTP-SHA1-6:QN08 66666666 059218
T1.8 OCRA-1:HOTP-SHA1-6:QN08 77777777 175339
T1.9 OCRA-1:HOTP-SHA1-6:QN08 88888888 478461
T1.10 OCRA-1:HOTP-SHA1-6:QN08 99999999 681743
==> Q and P = 1234, Digit (D) = 8,
Algorithm (A) = HMACSHA256
ID OCRASuite Question(Q) OCRA(O)
T2.1 OCRA-1:HOTP-SHA256-8:QN08-P 00000000 98280381
T2.2 OCRA-1:HOTP-SHA256-8:QN08-P 11111111 77892831
T2.3 OCRA-1:HOTP-SHA256-8:QN08-P 22222222 11994562
T2.4 OCRA-1:HOTP-SHA256-8:QN08-P 33333333 62731746
T2.5 OCRA-1:HOTP-SHA256-8:QN08-P 44444444 27309033
T2.6 OCRA-1:HOTP-SHA256-8:QN08-P 55555555 16123184
T2.7 OCRA-1:HOTP-SHA256-8:QN08-P 66666666 29679588
T2.8 OCRA-1:HOTP-SHA256-8:QN08-P 77777777 86592637
T2.9 OCRA-1:HOTP-SHA256-8:QN08-P 88888888 65897507
T2.10 OCRA-1:HOTP-SHA256-8:QN08-P 99999999 58356750
OATH-HOTP-VARIANTS Expires - October 2008 [Page 22]
OCRA: OATH Challenge Response Algorithms April 2008
==> C & Q, Digit (D) = 8, Algorithm (A) = HMACSHA512
ID OCRASuite Question(Q) Counter(C) OCRA(O)
T3.1 OCRA-1:HOTP-SHA512-8:C-QN08 00000000 0 86391474
T3.2 OCRA-1:HOTP-SHA512-8:C-QN08 11111111 1 05308362
T3.3 OCRA-1:HOTP-SHA512-8:C-QN08 22222222 2 71230448
T3.4 OCRA-1:HOTP-SHA512-8:C-QN08 33333333 3 24744363
T3.5 OCRA-1:HOTP-SHA512-8:C-QN08 44444444 4 51162507
T3.6 OCRA-1:HOTP-SHA512-8:C-QN08 55555555 5 69873452
T3.7 OCRA-1:HOTP-SHA512-8:C-QN08 66666666 6 67398361
T3.8 OCRA-1:HOTP-SHA512-8:C-QN08 77777777 7 78278396
T3.9 OCRA-1:HOTP-SHA512-8:C-QN08 88888888 8 13228238
T3.10 OCRA-1:HOTP-SHA512-8:C-QN08 99999999 9 40655008
==> Q & T, Digit (D) = 8, Algorithm (A) = HMACSHA512,
Time (T) Mar 25 2008, 12:06:30 PM ie. OCRATime = 20107866 *****
ID OCRASuite Question(Q) OCRA(O)
T4.1 OCRA-1:HOTP-SHA512-8:QN08-T 00000000 83093542
T4.2 OCRA-1:HOTP-SHA512-8:QN08-T 11111111 90956975
T4.3 OCRA-1:HOTP-SHA512-8:QN08-T 22222222 79746883
T4.4 OCRA-1:HOTP-SHA512-8:QN08-T 33333333 93368550
T4.5 OCRA-1:HOTP-SHA512-8:QN08-T 44444444 12212433
T4.6 OCRA-1:HOTP-SHA512-8:QN08-T 55555555 02514283
T4.7 OCRA-1:HOTP-SHA512-8:QN08-T 66666666 25817828
T4.8 OCRA-1:HOTP-SHA512-8:QN08-T 77777777 52087425
T4.9 OCRA-1:HOTP-SHA512-8:QN08-T 88888888 26000130
T4.10 OCRA-1:HOTP-SHA512-8:QN08-T 99999999 66638242
***** OCRA-V1 Mutual Challenge/Response, Digit (D) = 8,
Algorithm (A) = HMACSHA256 *****
ID OCRASuite Question(Q) OCRA(O)
T5.1 OCRA-1:HOTP-SHA256-8:QA08 CLI22220SRV11110 25876570
T5.2 OCRA-1:HOTP-SHA256-8:QA08 SRV11110CLI22220 65475908
T5.3 OCRA-1:HOTP-SHA256-8:QA08 CLI22221SRV11111 68337907
T5.4 OCRA-1:HOTP-SHA256-8:QA08 SRV11111CLI22221 36352242
T5.5 OCRA-1:HOTP-SHA256-8:QA08 CLI22222SRV11112 51935447
T5.6 OCRA-1:HOTP-SHA256-8:QA08 SRV11112CLI22222 20036871
T5.7 OCRA-1:HOTP-SHA256-8:QA08 CLI22223SRV11113 12325872
T5.8 OCRA-1:HOTP-SHA256-8:QA08 SRV11113CLI22223 58392008
T5.9 OCRA-1:HOTP-SHA256-8:QA08 CLI22224SRV11114 50478153
T5.10 OCRA-1:HOTP-SHA256-8:QA08 SRV11114CLI22224 53668312
***** OCRA-V1 Mutual Challenge/Response with Client PIN = 1234 *****
ID OCRASuite Question(Q) OCRA(O)
T6.1 OCRA-1:HOTP-SHA512-8:QA08 CLI22220SRV11110 22014886
T6.2 OCRA-1:HOTP-SHA512-8:QA08-P SRV11110CLI22220 55542963
T6.3 OCRA-1:HOTP-SHA512-8:QA08 CLI22221SRV11111 52086443
T6.4 OCRA-1:HOTP-SHA512-8:QA08-P SRV11111CLI22221 54291950
T6.5 OCRA-1:HOTP-SHA512-8:QA08 CLI22222SRV11112 77303083
T6.6 OCRA-1:HOTP-SHA512-8:QA08-P SRV11112CLI22222 39425683
T6.7 OCRA-1:HOTP-SHA512-8:QA08 CLI22223SRV11113 39015190
OATH-HOTP-VARIANTS Expires - October 2008 [Page 23]
OCRA: OATH Challenge Response Algorithms April 2008
T6.8 OCRA-1:HOTP-SHA512-8:QA08-P SRV11113CLI22223 38936793
T6.9 OCRA-1:HOTP-SHA512-8:QA08 CLI22224SRV11114 03327937
T6.10 OCRA-1:HOTP-SHA512-8:QA08-P SRV11114CLI22224 89550664
***** OCRA-V1 Plain Signature (a) no time stamp, Digit (D) = 8,
Algorithm (A) = HMACSHA256 *****
ID OCRASuite Question(Q) OCRA(O)
T7.1 OCRA-1:HOTP-SHA256-8:QA08 SIG10000 90869451
T7.2 OCRA-1:HOTP-SHA256-8:QA08 SIG11000 12253571
T7.3 OCRA-1:HOTP-SHA256-8:QA08 SIG12000 13568297
T7.4 OCRA-1:HOTP-SHA256-8:QA08 SIG13000 96520389
T7.5 OCRA-1:HOTP-SHA256-8:QA08 SIG14000 57061117
T7.6 OCRA-1:HOTP-SHA256-8:QA08 SIG15000 31653201
T7.7 OCRA-1:HOTP-SHA256-8:QA08 SIG16000 87506781
T7.8 OCRA-1:HOTP-SHA256-8:QA08 SIG17000 25237541
T7.9 OCRA-1:HOTP-SHA256-8:QA08 SIG18000 48988608
T7.10 OCRA-1:HOTP-SHA256-8:QA08 SIG19000 79070512
***** OCRA-V1 Plain Signature (b) with timestamp
Time (T), Mar 25 2008, 12:06:30 PM, OCRATime = 20107866 *****
ID OCRASuite Question(Q) OCRA(O)
T8.1 OCRA-1:HOTP-SHA512-8:QA10-T SIG1000000 00051074
T8.2 OCRA-1:HOTP-SHA512-8:QA10-T SIG1100000 85317316
T8.3 OCRA-1:HOTP-SHA512-8:QA10-T SIG1200000 67561993
T8.4 OCRA-1:HOTP-SHA512-8:QA10-T SIG1300000 99207637
T8.5 OCRA-1:HOTP-SHA512-8:QA10-T SIG1400000 81467939
T8.6 OCRA-1:HOTP-SHA512-8:QA10-T SIG1500000 53960486
T8.7 OCRA-1:HOTP-SHA512-8:QA10-T SIG1600000 13472538
T8.8 OCRA-1:HOTP-SHA512-8:QA10-T SIG1700000 03719182
T8.9 OCRA-1:HOTP-SHA512-8:QA10-T SIG1800000 20840783
T8.10 OCRA-1:HOTP-SHA512-8:QA10-T SIG1900000 39923448
Notes:
1. Computations are done on March 21, 2008 based on the OCRA
specification draft-mraihi-mutual-oath-hotp-variants-07.txt
2. OCRA Time calculations:
Local Time "Mar 25 2008, 12:06:30 PM" at "America/Los_Angeles"
time zone (local OCRAtime=20107446) is converted (with time
zone plus daylight time savings) to UTC Time "Mar 25 2008,
19:06:30 PM" at "GMT" time zone (UTC OCRAtime=20107866)
3. OCRA Time is treated the same as Counter of 8-byte long value
with big-endian order and no base64 encoding.
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
OATH-HOTP-VARIANTS Expires - October 2008 [Page 24]
OCRA: OATH Challenge Response Algorithms April 2008
Mountain View, CA 94043 USA Email: dmraihi@verisign.com
Other Authors' contact information:
Johan Rydell
Portwise, Inc.
275 Hawthorne Ave, Suite 119 Phone: 1-650-515-3569
Palo Alto, CA 94301 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
15. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
OATH-HOTP-VARIANTS Expires - October 2008 [Page 25]
OCRA: OATH Challenge Response Algorithms April 2008
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 - October 2008 [Page 26] | PAFTECH AB 2003-2026 | 2026-04-23 17:28:42 |