< draft-mraihi-mutual-oath-hotp-variants-05.txt		draft-mraihi-mutual-oath-hotp-variants-06.txt >
	Internet Draft David M'Raihi		Internet Draft David M'Raihi
	VeriSign		VeriSign
	Category: Johan Rydell		Category: Johan Rydell
	Informational PortWise		Informational PortWise
	Document: David Naccache		Document: David Naccache
	draft-mraihi-mutual-oath-hotp-variants-05.txt ENS		draft-mraihi-mutual-oath-hotp-variants-06.txt ENS
	Salah Machani		Salah Machani
	Diversinet		Diversinet
	Siddharth Bajaj		Siddharth Bajaj
	VeriSign		VeriSign
	Expires:		Expires:
	December 2007 June 2007		June 2008 December 2007
	OCRA: OATH Challenge-Response Algorithms		OCRA: OATH Challenge-Response Algorithms
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Abstract		Abstract
	This document describes the OATH algorithm for challenge-response		This document describes the OATH algorithm for challenge-response
	authentication and signatures. This algorithm is based on the HOTP		authentication and signatures. This algorithm is based on the HOTP
	algorithm [RFC4226] that was introduced by OATH (initiative for		algorithm [RFC4226] that was introduced by OATH (initiative for
	Open AuTHentication) [OATH] and submitted as an individual draft to		Open AuTHentication) [OATH] and submitted as an individual draft to
	the IETF last year.		the IETF last year.
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	Table of Contents		Table of Contents
	1. Introduction...............................................3		1. Introduction...............................................3
	2. Requirements Terminology...................................3		2. Requirements Terminology...................................3
	3. Algorithm Requirements.....................................3		3. Algorithm Requirements.....................................3
	4. OCRA Background............................................4		4. OCRA Background............................................4
	4.1 HOTP Algorithm.............................................4		4.1 HOTP Algorithm.............................................4
	4.2 OCRA Algorithm.............................................5
	5. Definition of OCRA.........................................5		5. Definition of OCRA.........................................5
	5.1 DataInput Parameters........................................6		5.1 DataInput Parameters........................................5
	5.2 CryptoFunction..............................................6		5.2 CryptoFunction..............................................6
	6. The OCRASuite..............................................7		6. The OCRASuite..............................................7
	7. Algorithm Modes for Authentication.........................8		7. Algorithm Modes for Authentication.........................8
	7.1. One way Challenge-Response.................................8		7.1 One way Challenge-Response..................................8
	7.2. Response Only (OTP) Mode...................................9		7.2 Mutual Challenge-Response...................................9
	7.3. Mutual Challenge-Response.................................10		8. Algorithm Modes for Signature.............................10
	8. Algorithm Modes for Signature.............................11		8.1 Plain Signature...........................................10
	8.1 Plain Signature...........................................11		8.2 Signature with Server Authentication......................11
	8.2 Signature with Server Authentication......................12		9. Security Considerations...................................13
	9. Security Considerations...................................14		9.1 Security Analysis of the OCRA algorithm....................13
	9.1 Security Analysis of the OCRA algorithm....................14		9.2 Implementation Considerations..............................13
	9.2 Implementation Considerations..............................14
	10. IANA Considerations.......................................15		10. IANA Considerations.......................................15
	11. Conclusion................................................15		11. Conclusion................................................15
	12. Acknowledgements..........................................16		12. Acknowledgements..........................................15
	13. References................................................16		13. References................................................15
	13.1. Normative................................................16		13.1 Normative.................................................15
	13.2. Informative..............................................16		13.2 Informative...............................................16
	Appendix A: Code Source........................................17		Appendix A: Source Code........................................16
	Appendix B: Test Vectors.......................................19		Appendix B: Test Vectors.......................................19
	14. Authors' Addresses........................................21		14. Authors' Addresses........................................20
	15. Full Copyright Statement..................................22		15. Full Copyright Statement..................................21
	16. Intellectual Property.....................................22		16. Intellectual Property.....................................21
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	1. Introduction		1. Introduction
	OATH has identified several use cases and scenarios that require an		OATH has identified several use cases and scenarios that require an
	asynchronous variant to accommodate users who do not want to		asynchronous variant to accommodate users who do not want to
	maintain a synchronized authentication system. The commonly		maintain a synchronized authentication system. The commonly
	accepted method for this is to use a challenge-response scheme.		accepted method for this is to use a challenge-response scheme.
	Such challenge response mode of authentication is widely adopted in		Such challenge response mode of authentication is widely adopted in
	the industry. Several vendors already offer software applications		the industry. Several vendors already offer software applications
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	challenge-response where the challenge is derived from the data		challenge-response where the challenge is derived from the data
	that needs to be signed.		that needs to be signed.
	R3 - The algorithm MUST be capable of supporting server-		R3 - The algorithm MUST be capable of supporting server-
	authentication, whereby the user can verify that he/she is talking		authentication, whereby the user can verify that he/she is talking
	to a valid server.		to a valid server.
	R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building		R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building
	block.		block.
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	R5 - The length and format for the input challenge SHOULD be		R5 - The length and format for the input challenge SHOULD be
	configurable.		configurable.
	R6 - The output length and format for the response SHOULD be		R6 - The output length and format for the response SHOULD be
	configurable.		configurable.
	R7 - The challenge MAY be generated with integrity checking (e.g.,		R7 - The challenge MAY be generated with integrity checking (e.g.,
	parity bits). This will allow tokens with pin pads to perform		parity bits). This will allow tokens with pin pads to perform
	simple error checking if the user enters the value into a token.		simple error checking if the user enters the value into a token.
	R8 - There MUST be a fixed randomly generated secret (key) for each		R8 - There MUST be a unique secret (key) for each token/soft token
	token/soft token that is shared between the token and the		that is shared between the token and the authentication server. The
	authentication server.		keys MUST be randomly generated or derived using some key
			derivation algorithm.
	R9 - The algorithm MUST enable additional data attributes such as a		R9 - The algorithm MUST enable additional data attributes such as a
	counter, a time function or session information to be included in		counter, a time function or session information to be included in
	the computation. These data inputs MAY be used individually or all		the computation. These data inputs MAY be used individually or all
	together.		together.
	4. OCRA Background		4. OCRA Background
	OATH introduced the HOTP algorithm as a first open, freely		OATH introduced the HOTP algorithm as a first open, freely
	available building block toward hardening authentication for end-		available building block toward hardening authentication for end-
	users in a variety of applications. One-time passwords are very		users in a variety of applications. One-time passwords are very
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 44 ¶
	After carefully analyzing different use cases, OATH came to the		After carefully analyzing different use cases, OATH came to the
	conclusion that providing for extensions to the HOTP algorithms was		conclusion that providing for extensions to the HOTP algorithms was
	important. A very natural extension is to introduce a challenge		important. A very natural extension is to introduce a challenge
	mode for computing HOTP values based on random questions. Equally		mode for computing HOTP values based on random questions. Equally
	beneficial, being able to perform mutual authentication between two		beneficial, being able to perform mutual authentication between two
	parties, or short-signature computation for authenticating		parties, or short-signature computation for authenticating
	transaction was also identified as critical for improving the		transaction was also identified as critical for improving the
	security of e-commerce applications.		security of e-commerce applications.
	This section summarizes the HOTP algorithm and then, formally
	introduces the OCRA algorithm.
	4.1 HOTP Algorithm		4.1 HOTP Algorithm
	The HOTP algorithm, as defined in [RFC4226] is based on an		The HOTP algorithm, as defined in [RFC4226] is based on an
	increasing counter value and a static symmetric key known only to		increasing counter value and a static symmetric key known only to
	the prover and verifier parties.		the prover and verifier parties.
	As a reminder:		As a reminder:
	HOTP(K,C) = Truncate(HMAC-SHA1(K,C))		HOTP(K,C) = Truncate(HMAC-SHA1(K,C))
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	Where Truncate represents the function that converts an HMAC-SHA-1		Where Truncate represents the function that converts an HMAC-SHA-1
	value into an HOTP value.		value into an HOTP value.
	The Key (K), the Counter (C) and Data values are hashed high-order
	byte first. The HOTP values generated by the HOTP generator are
	treated as big endian.
	We refer the reader to [RFC4226] for the full description and		We refer the reader to [RFC4226] for the full description and
	further details on the rationale and security analysis of HOTP.		further details on the rationale and security analysis of HOTP.
	The present draft describes the different variants based on similar		The present draft describes the different variants based on similar
	constructions as HOTP.		constructions as HOTP.
	4.2 OCRA Algorithm		5. Definition of OCRA
	In a nutshell, OCRA is a generalization of HOTP with variable data		OCRA is a generalization of HOTP with variable data inputs not
	inputs not solely based on an incremented counter and secret key		solely based on an incremented counter and secret key values.
	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 the parameters.
			In a nutshell,
	OCRA = CryptoFunction(K, DataInput)		OCRA = CryptoFunction(K, DataInput)
	Where:		Where:
	- K: a shared secret key known to both parties;		- 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		- CryptoFunction: this is the function performing the OCRA
	computation from the secret key K and DataInput material;		computation from the secret key K and DataInput material;
	CryptoFunction is described in details in section 5.2;		CryptoFunction is described in details in section 5.2.
	- DataInput: a structure that contains the concatenation of the
	various input data values. Defined in details in section 5.1.
	5. Definition of OCRA
	The definition of OCRA requires a cryptographic function, a key K
	and a set of DataInput parameters. This section introduces these
	definitions and default value recommended for all the parameters.
	We denote L as the byte-length of the CryptoFunction output. For
	instance, if CryptoFunction was SHA-1, then L = 20.
	We denote B as the byte-length of the blocks manipulated by the
	core function internally. For instance if CryptoFunction was HMAC-
	SHA-1, then B = 64 since SHA-1 manipulates 64-byte blocks.
	We denote t as the byte-length of the truncation output. For
	instance, if t = 6, then the output of the truncation is a 6-byte
	value.
	OCRA: OATH Challenge Response Algorithms September 2006
	5.1 DataInput Parameters		5.1 DataInput Parameters
	This structure is the concatenation of all the parameters used in		This structure is the concatenation of all the parameters used in
	the computation of the OCRA values, save for the secret key K.		the computation of the OCRA values, save for the secret key K.
	DataInput = {Q | C | P | S | T} where:		DataInput = {C | Q | P | S | T} where:
			. C is a 8-byte counter value processed high-order bit first,
			and MUST be synchronized between all parties;
	. Q is the list of (concatenated) challenge question(s)		. Q is the list of (concatenated) challenge question(s)
	generated by the verifier(s);the questions SHOULD be L-byte		generated by the verifier(s);the questions SHOULD be L-byte
	values and MUST be at least t-byte values;		values and MUST be at least t-byte values;
	. C is a 8-byte counter value processed high-order bit first,
	and MUST be synchronized between all parties;
	. P is a SHA1-hash of PIN/password that is known to all parties		. P is a SHA1-hash of PIN/password that is known to all parties
	during the execution of the algorithm;		during the execution of the algorithm;
	. S is a string that contains information about the current		. S is a string that contains information about the current
	session;		session;
	. T is a timestamp value, UTC formatted.		. T is a timestamp value in number of minutes since midnight UTC
			of January 1, 1970.
			OCRA: OATH Challenge Response Algorithms December 2007
	When computing a response, the concatenation order is always the		When computing a response, the concatenation order is always the
	following:		following:
	OTHER-PARTY-GENERATED-CHALLENGE-QUESTION		C,
	YOUR-GENERATED-CHALLENGE-QUESTION		OTHER-PARTY-GENERATED-CHALLENGE-QUESTION,
	C, P, S and then T values.		YOUR-GENERATED-CHALLENGE-QUESTION,
			P, S and then T values.
	If a value is empty (i.e. a certain input is not used in the		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		computation) then the value is simply not represented in the
	string.		string.
			We always start with C to be compliant and follow the HOPT RFC when
			all the other values are empty. The counter on the token or client
			is incremented every time a new computation is requested by the
			user. The server's counter value is only incremented after a
			successful OCRA authentication
	5.2 CryptoFunction		5.2 CryptoFunction
	The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of		The default CryptoFunction is HOTP-SHA1-6, i.e. the default mode of
	computation for OCRA is HOTP with the default 6-digit dynamic		computation for OCRA is HOTP with the default 6-digit dynamic
	truncation and a combination of DataInput values as the message to		truncation and a combination of DataInput values as the message to
	compute the HMAC-SHA1 digest.		compute the HMAC-SHA1 digest.
			We denote t as the digit-length 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:		We define the HOTP family of functions as an extension to HOTP:
	- HOTP-H-t: these are the different possible truncated versions of		- HOTP-H-t: these are the different possible truncated versions of
	HOTP, using the dynamic truncation method for extracting an HOTP		HOTP, using the dynamic truncation method for extracting an HOTP
	value from the HMAC output;		value from the HMAC output;
	- We will denote HOTP-H-t as the realization of an HOTP function		- 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		that uses an HMAC function with the hash function H, and the
	dynamic truncation as described in [RFC 4226] to extract a t-byte		dynamic truncation as described in [RFC 4226] to extract a t-
	value;		digit value;
	- t=0 means that no truncation is performed and the full HMAC value		- t=0 means that no truncation is performed and the full HMAC value
	is used for authentication purpose.		is used for authentication purpose.
	OCRA: OATH Challenge Response Algorithms September 2006
	We list the following preferred modes of computation, where *		We list the following preferred modes of computation, where *
	denotes the default CryptoFunction:		denotes the default CryptoFunction:
	. HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC		. 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		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		recommended in the general case but can be useful when a very
	short authentication code is needed by an application;		short authentication code is needed by an application;
	. *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC		. *HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC
	and a dynamic truncation to a 6-digit value;		and a dynamic truncation to a 6-digit value;
	. HOTP-SHA256-6: HOTP with SHA-1 as the hash function for HMAC		OCRA: OATH Challenge Response Algorithms December 2007
	and a dynamic truncation to a 6-digit value;
	. HOTP-SHA512-6: HOTP with SHA-1 as the hash function for HMAC		. HOTP-SHA256-6: HOTP with SHA-256 as the hash function for
	and a dynamic truncation to a 6-digit value;		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:		This table summarizes all possible values for the CryptoFunction:
	Name HMAC Function Used Size of Truncation (t)		Name HMAC Function Used Size of Truncation (t)
	--------------------------------------------------------------		--------------------------------------------------------------
	HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10		HOTP-SHA1-t HMAC-SHA1 0 (no truncation), 4-10
	HOTP-SHA256-t HMAC-SHA256 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		HOTP-SHA512-t HMAC-SHA512 0 (no truncation), 4-10
	6. The OCRASuite		6. The OCRASuite
	The following values define the OcraSuite codes used in the		The following values define the OCRASuite codes used in the
	description of modes of operation for the OCRA algorithm.		description of modes of operation for the OCRA algorithm.
	An OCRASuite value defines an OCRA suite of operations as supported		An OCRASuite value defines an OCRA suite of operations as supported
	in the present draft and is represented as follows:		in the present draft and is represented as follows:
	Algorithm-CryptoFunction-DataInput		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		Algorithm
	---------		---------
	Description: Indicates the OCRA algorithm (possibly authenticated)		Description: Indicates the version of OCRA algorithm.
	Values: String MUST contains OCRA and optionally, the OCRA computed		Values: OCRA-v where v represents the version number (e.g. 1, 2
	value of the string		etc.). This document describes version 1 of the OCRA algorithm.
	CryptoFunction		CryptoFunction
	--------------		--------------
	Description: Indicated the function used to compute OCRA values		Description: Indicates the function used to compute OCRA values
	Values: As described in previous section; other values COULD be		Values: Permitted values are described in section 5.2
	added in the future
	OCRA: OATH Challenge Response Algorithms September 2006
	DataInput		DataInput
	---------		---------
			OCRA: OATH Challenge Response Algorithms December 2007
	Description: List of valid inputs for the computation; [] indicates		Description: List of valid inputs for the computation; [] indicates
	a value is optional.		a value is optional.
	Values:		Values:
	Q | [C | P | S | T]: Challenge-Response computation		[C] | Q | [P | S | T]: Challenge-Response computation
	C | [P]: Response-only (OTP) computation		[C] | Q | [P | T]: Plain Signature computation
	Q | [C | P | T]: Plain Signature computation
	Example of possible values: OCRA-HOTP-SHA512-8-C-P-Q means OCRA		Example of possible values: OCRA-1:HOTP-SHA512-8:C-Q-P means
	algorithm with HMAC-SHA512 function, truncated to an 8-digit value,		version 1 of the OCRA algorithm with HMAC-SHA512 function,
	using the counter, hash of the PIN/Password and a random challenge		truncated to an 8-digit value, using the counter, a random
	as parameter, the other party MUST check the value received before		challenge and a hash of the PIN/Password as parameters.
	computing and sending his response.
	7. Algorithm Modes for Authentication		7. Algorithm Modes for Authentication
	In this section we describe the typical modes in which the above		In this section we describe the typical modes in which the above
	defined computation can be used for authentication.		defined computation can be used for authentication.
	7.1. One way Challenge-Response		7.1 One way Challenge-Response
	A challenge/response is a security mechanism in which the verifier		A challenge/response is a security mechanism in which the verifier
	presents a question (challenge) to the prover who must provide a		presents a question (challenge) to the prover who must provide a
	valid answer (response) to be authenticated.		valid answer (response) to be authenticated.
	To use this algorithm for a one-way challenge-response, the		To use this algorithm for a one-way challenge-response, the
	verifier will communicate a challenge value (typically randomly		verifier will communicate a challenge value (typically randomly
	generated) to the prover. The prover will use the challenge in the		generated) to the prover. The prover will use the challenge in the
	computation as described above. The prover then communicates the		computation as described above. The prover then communicates the
	response to the verifier to authenticate.		response to the verifier to authenticate.
	Therefore in this mode, the typical data inputs will be:		Therefore in this mode, the typical data inputs will be:
	Q - Challenge question, mandatory, supplied by the verifier.
	C - Counter, optional.		C - Counter, optional.
			Q - Challenge question, mandatory, supplied by the verifier.
	P - Hashed version of PIN/password, optional.		P - Hashed version of PIN/password, optional.
	S - Session information, optional		S - Session information, optional
	T - Timestamp, optional.		T - Timestamp, optional.
	The picture below shows the messages that are exchanged between the		The picture below shows the messages that are exchanged between the
	client (prover) and the server (verifier) to complete a one-way		client (prover) and the server (verifier) to complete a one-way
	challenge-response authentication.		challenge-response authentication.
	We assume that the client and server have a pre-shared key K that		We assume that the client and server have a pre-shared key K that
	is used for the computation.		is used for the computation.
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	CLIENT SERVER		CLIENT SERVER
	(PROVER) (VERIFIER)		(PROVER) (VERIFIER)
	| |		| |
	| Verifier sends challenge to prover |		| Verifier sends challenge to prover |
	| Challenge = Q |		| Challenge = Q |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	| Prover Computes Response |		| Prover Computes Response |
	| R = OCRA(K, {Q| [C | P | S | T]}) |		| R = OCRA(K, {[C] | Q | [P | S | T]}) |
	| Response = R |
	|------------------------------------------>|
	| |
	| Verifier Validates Response |
	| Response = OK |
	|<------------------------------------------|
	| |
	7.2. Response Only (OTP) Mode
	Response Only mode is a variation of one-way challenge-response
	where the challenge is implicitly derived.
	In order to implicitly derive the challenge, the verifier and the
	prover need to maintain a moving factor that is synchronized.
	Commonly used moving factors include a counter, time or combination
	of both.
	To use this algorithm, the prover will use the implicit challenge
	in the computation as described above. The prover then communicates
	the response to the verifier to authenticate.
	Therefore in this mode, the data inputs will be:
	C - Counter mandatory.
	P - Hashed version of PIN/password, optional.
	The picture below shows the messages that are exchanged between the
	client (prover) and the server (verifier) to complete a response
	only authentication.
	We assume that the client and server have a pre-shared key K that
	is used for the computation.
	OCRA: OATH Challenge Response Algorithms September 2006
	CLIENT SERVER
	(PROVER) (VERIFIER)
	| |
	| |
	| Prover Computes Response |
	| R = OCRA(K, C | [P]) |
	| Response = R |		| Response = R |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| Verifier Validates Response |		| Verifier Validates Response |
	| Response = OK |		| Response = OK |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	7.3. Mutual Challenge-Response		7.2 Mutual Challenge-Response
	Mutual challenge-response is a variation of one-way challenge-		Mutual challenge-response is a variation of one-way challenge-
	response where both the client and server and mutually authenticate		response where both the client and server and mutually authenticate
	each other.		each other.
	To use this algorithm, the client will first send a random client-		To use this algorithm, the client will first send a random client-
	challenge to the server. The server computes the server-response		challenge to the server. The server computes the server-response
	and sends it to the client along with a server-challenge.		and sends it to the client along with a server-challenge.
	The client will first verify the server-response to authenticate		The client will first verify the server-response to authenticate
	skipping to change at page 10, line 43 ¶		skipping to change at page 9, line 46 ¶
	client-response and send it to the server to authenticate. The		client-response and send it to the server to authenticate. The
	server verifies the client-response to complete the two-way		server verifies the client-response to complete the two-way
	authentication process.		authentication process.
	In this mode there are two computations: client-response and		In this mode there are two computations: client-response and
	server-response. There are two separate challenge questions,		server-response. There are two separate challenge questions,
	generated by both parties. We denote these challenge questions Q1		generated by both parties. We denote these challenge questions Q1
	and Q2.		and Q2.
	Typical data inputs for server-response computation will be:		Typical data inputs for server-response computation will be:
	Q1 - Challenge question, mandatory, supplied by the client.
	Q2 - Challenge question, mandatory, supplied by the server.
	C - Counter, optional.		C - Counter, optional.
			QC - Challenge question, mandatory, supplied by the client.
			QS - Challenge question, mandatory, supplied by the server.
	S - Session information, optional.		S - Session information, optional.
	T - Timestamp, optional.		T - Timestamp, optional.
	Typical data inputs for client-response computation will be:		Typical data inputs for client-response computation will be:
	Q2 - Challenge question, mandatory, supplied by the server.
	Q1 - Challenge question, mandatory, supplied by the client.
	C - Counter, optional.		C - Counter, optional.
			QS - Challenge question, mandatory, supplied by the server.
			QC - Challenge question, mandatory, supplied by the client.
			OCRA: OATH Challenge Response Algorithms December 2007
	P - Hashed version of PIN/password, optional.		P - Hashed version of PIN/password, optional.
	S - Session information, optional.		S - Session information, optional.
	T - Timestamp, optional.		T - Timestamp, optional.
	OCRA: OATH Challenge Response Algorithms September 2006
	The following picture shows the messages that are exchanged between		The following picture shows the messages that are exchanged between
	the client and the server to complete a two-way mutual challenge-		the client and the server to complete a two-way mutual challenge-
	response authentication.		response authentication.
	We assume that the client and server have a pre-shared key K that		We assume that the client and server have a pre-shared key K that
	is used for the computation.		is used for the computation.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| 1. Client sends client-challenge |		| 1. Client sends client-challenge |
	| Q1 = Client-challenge |		| QC = Client-challenge |
	|------------------------------------------>|		|-------------------------------------------------->|
	| |		| |
	| 2. Server computes server-response |		| 2. Server computes server-response |
	| and sends server-challenge |		| and sends server-challenge |
	| R1 = OCRA(K, Q1 | Q2 | [C | S | T]) |		| RS = OCRA(K, [C] | QC | QS | [S | T]) |
	| Q2 = Server-challenge |		| QS = Server-challenge |
	| Response = R1, Q2 |		| Response = RS, QS |
	|<------------------------------------------|		|<--------------------------------------------------|
	| |		| |
	| 3. Client verifies server-response |		| 3. Client verifies server-response |
	| and computes client-response |		| and computes client-response |
	| OCRA(K, Q1, Q2,[C,S,T]) != R1 -> STOP |		| OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP |
	| R2 = ORCA( K,Q2 | Q1 | [C | P | S | T])|		| RC = OCRA(K, [C] | QS | QC | [P | S | T]) |
	| Response = R2 |		| Response = RC |
	|------------------------------------------>|		|-------------------------------------------------->|
	| |		| |
	| 4. Server verifies client-response |		| 4. Server verifies client-response |
	| OCRA(K, Q2|Q1|[C|P|S|T]) != R2 -> STOP |		| OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP |
	| Response = OK |		| Response = OK |
	|<------------------------------------------|		|<--------------------------------------------------|
	| |		| |
	8. Algorithm Modes for Signature		8. Algorithm Modes for Signature
	In this section we describe the typical modes in which the above		In this section we describe the typical modes in which the above
	defined computation can be used for digital signatures.		defined computation can be used for digital signatures.
	8.1 Plain Signature		8.1 Plain Signature
	To use this algorithm in plain signature mode, the server will		To use this algorithm in plain signature mode, the server will
	communicate a signature-challenge value to the client (signer). The		communicate a signature-challenge value to the client (signer). The
			OCRA: OATH Challenge Response Algorithms December 2007
	signature-challenge is either the data to be signed or derived from		signature-challenge is either the data to be signed or derived from
	the data to be signed using a hash function, for example.		the data to be signed using a hash function, for example.
	OCRA: OATH Challenge Response Algorithms September 2006
	The client will use the signature-challenge in the computation as		The client will use the signature-challenge in the computation as
	described above. The client then communicates the signature value		described above. The client then communicates the signature value
	(response) to the server to authenticate.		(response) to the server to authenticate.
	Therefore in this mode, the data inputs will be:		Therefore in this mode, the data inputs will be:
	Q - Signature-challenge, mandatory, supplied by the server.
	C - Counter, optional.		C - Counter, optional.
			QS - Signature-challenge, mandatory, supplied by the server.
	P - Hashed version of PIN/password, optional.		P - Hashed version of PIN/password, optional.
	T - Timestamp, optional.		T - Timestamp, optional.
	The picture below shows the messages that are exchanged between the		The picture below shows the messages that are exchanged between the
	client (prover) and the server (verifier) to complete a plain		client (prover) and the server (verifier) to complete a plain
	signature operation.		signature operation.
	We assume that the client and server have a pre-shared key K that		We assume that the client and server have a pre-shared key K that
	is used for the computation.		is used for the computation.
	CLIENT SERVER		CLIENT SERVER
	(PROVER) (VERIFIER)		(PROVER) (VERIFIER)
	| |		| |
	| Verifier sends signature-challenge |		| Verifier sends signature-challenge |
	| Challenge = Q |		| Challenge = QS |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	| Client Computes Response |		| Client Computes Response |
	| SIGN = OCRA(K, Q | [C | P | T]) |		| SIGN = OCRA(K, [C] | QS | [P | T]) |
	| Response = SIGN |		| Response = SIGN |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| Verifier Validates Response |		| Verifier Validates Response |
	| Response = OK |		| Response = OK |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	8.2 Signature with Server Authentication		8.2 Signature with Server Authentication
	This mode is a variation of the plain signature mode where the		This mode is a variation of the plain signature mode where the
	client can first authenticate that it is talking to a valid server		client can first authenticates the server before generating a
	before creating a digital signature.		digital signature.
	To use this algorithm, the client will first send a random client-		To use this algorithm, the client will first send a random client-
	challenge to the server. The server computes the server-response		challenge to the server. The server computes the server-response
	and sends it to the client along with a signature-challenge. The		and sends it to the client along with a signature-challenge. The
	client will first verify the server-response to authenticate that		client will first verify the server-response to authenticate that
			OCRA: OATH Challenge Response Algorithms December 2007
	it is talking to a valid server. It will then compute the signature		it is talking to a valid server. It will then compute the signature
	and send it to the server.		and send it to the server.
	OCRA: OATH Challenge Response Algorithms September 2006
	In this mode there are two computations: client-signature and		In this mode there are two computations: client-signature and
	server-response.		server-response.
	Typical data inputs for server-response computation will be:		Typical data inputs for server-response computation will be:
	Q - Challenge question, mandatory, supplied by the client.
	C - Counter, optional.		C - Counter, optional.
			QC - Challenge question, mandatory, supplied by the client.
	T - Timestamp, optional.		T - Timestamp, optional.
	Typical data inputs for client-signature computation will be:		Typical data inputs for client-signature computation will be:
	Q - Signature-challenge, mandatory, supplied by the server.
	P - Hashed version of PIN/password, optional.
	C - Counter, optional.		C - Counter, optional.
			QS - Signature-challenge, mandatory, supplied by the server.
			P - Hashed version of PIN/password, optional.
	T - Timestamp, optional.		T - Timestamp, optional.
	The picture below shows the messages that are exchanged between the		The picture below shows the messages that are exchanged between the
	client and the server to complete a signature with server		client and the server to complete a signature with server
	authentication transaction.		authentication transaction.
	We assume that the client and server have a pre-shared key K that		We assume that the client and server have a pre-shared key K that
	is used for the computation.		is used for the computation.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| 1. Client sends client-challenge |		| 1. Client sends client-challenge |
	| Q1 = Client-challenge |		| QC = Client-challenge |
	|------------------------------------------>|		|-------------------------------------------------->|
	| |		| |
	| 2. Server computes server-response |		| 2. Server computes server-response |
	| and sends signature-challenge |		| and sends signature-challenge |
	| R1 = OCRA(K, Q1 | Q2 | [C | T]) |		| RS = OCRA(K, [C] | QC | QS | [T]) |
	| Q2 = signature-challenge |		| QS = signature-challenge |
	| Response = R1, Q2 |		| Response = RS, QS |
	|<------------------------------------------|		|<--------------------------------------------------|
	| |		| |
	| 3. Client verifies server-response |		| 3. Client verifies server-response |
	| and computes signature |		| and computes signature |
	| OCRA(K, Q1 | [T | C]) != R1 -> STOP |		| OCRA(K, [C] | QC | QS | [T]) != R1 -> STOP |
	| R2 = ORCA( K, Q2 | Q1 | [C | P | T]) |		| SIGN = OCRA( K, [C] | QS | QC | [P | T]) |
	| Signature = R2 |		| Signature = SIGN |
	|------------------------------------------>|		|-------------------------------------------------->|
	| |		| |
	| 4. Server verifies Signature |		| 4. Server verifies Signature |
	| OCRA(K, Q2|Q1| [C|P|T]) != R2 -> STOP |		| OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP |
	| Response = OK |		| Response = OK |
	|<------------------------------------------|		|<--------------------------------------------------|
	| |		| |
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	9. Security Considerations		9. Security Considerations
	Any algorithm is only as secure as the application and the		Any algorithm is only as secure as the application and the
	authentication protocols that implement it. Therefore, this section		authentication protocols that implement it. Therefore, this section
	discusses the critical security requirements that our choice of		discusses the critical security requirements that our choice of
	algorithm imposes on the authentication protocol and validation		algorithm imposes on the authentication protocol and validation
	software.		software.
	9.1 Security Analysis of the OCRA algorithm		9.1 Security Analysis of the OCRA algorithm
	skipping to change at page 14, line 31 ¶		skipping to change at page 13, line 31 ¶
	The conclusion of the security analysis detailed in [RFC4226] is		The conclusion of the security analysis detailed in [RFC4226] is
	that, for all practical purposes, the outputs of the dynamic		that, for all practical purposes, the outputs of the dynamic
	truncation on distinct counter inputs are uniformly and		truncation on distinct counter inputs are uniformly and
	independently distributed strings.		independently distributed strings.
	The analysis demonstrates that the best possible attack against the		The analysis demonstrates that the best possible attack against the
	HOTP function is the brute force attack.		HOTP function is the brute force attack.
	9.2 Implementation Considerations		9.2 Implementation Considerations
	In the authentication mode, the client MUST support two-factor		S1 - In the authentication mode, the client MUST support two-factor
	authentication, i.e., the communication and verification of		authentication, i.e., the communication and verification of
	something you know (secret code such as a Password, Pass phrase,		something you know (secret code such as a Password, Pass phrase,
	PIN code, etc.) and something you have (token). The secret code is		PIN code, etc.) and something you have (token). The secret code is
	known only to the user and usually entered with the Response value		known only to the user and usually entered with the Response value
	for authentication purpose (two-factor authentication).		for authentication purpose (two-factor authentication).
	Alternatively, instead of sending something you know to the server,		Alternatively, instead of sending something you know to the server,
	the client may use a hash of the Password or PIN code in the		the client may use a hash of the Password or PIN code in the
	computation itself, thus implicitly enabling two-factor		computation itself, thus implicitly enabling two-factor
	authentication.		authentication.
	The keys for HOTP can be of any length equal or longer than L		S2 - The keys for HOTP can be of any length equal or longer than L
	bytes. Keys longer than L bytes are acceptable; they are first		bytes, where L is the byte-length of the CryptoFunction output.
	hashed using the supported hash function, e.g. SHA-1, to become		Keys longer than L bytes are acceptable; they are first hashed
	usable. Nevertheless, the extra length would not significantly		using the supported hash function, e.g. SHA-1, to become usable.
	increase the cryptographic strength of OCRA, provided the		Nevertheless, the extra length would not significantly increase the
	randomness of the original key material is sufficient.		cryptographic strength of OCRA, provided the randomness of the
			original key material is sufficient.
	Keys need to be chosen at random or using a cryptographically		S3 - Keys need to be chosen at random or using a cryptographically
	strong pseudo-random generator properly seeded with a random value.		strong pseudo-random generator properly seeded with a random value.
	We RECOMMEND following the recommendations in [RFC1750] for all		We RECOMMEND following the recommendations in [RFC1750] for all
	pseudo-random and random generations. The pseudo-random numbers		pseudo-random and random generations. The pseudo-random numbers
			OCRA: OATH Challenge Response Algorithms December 2007
	used for generating the keys SHOULD successfully pass the		used for generating the keys SHOULD successfully pass the
	randomness test specified in [CN].		randomness test specified in [CN].
	OCRA: OATH Challenge Response Algorithms September 2006		S4 - On the client side, the keys MUST 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).
	The keys MUST be embedded in a tamper resistance device or securely		S5 - For authentication computations, the challenge value MUST be
	implemented in a software application. Additionally, by embedding		randomly generated and SHALL NOT be re-used. We RECOMMEND following
	the keys in a hardware device, you also have the advantage of		the recommendations in [RFC1750] for all pseudo-random and random
	improving the flexibility (mobility).		generations.
	The challenge value MUST be randomly generated for each use of the		S6 - All the communications SHOULD take place over a secure channel
	authentication protocol and SHALL NOT be re-used. We RECOMMEND		e.g. SSL/TLS, IPsec connections.
	following the recommendations in [RFC1750] for all pseudo-random
	and random generations.
	All the communications SHOULD take place over a secure channel e.g.		S7 - The OCRA algorithm when used in mutual authentication mode or
	SSL/TLS, IPsec connections.		in signature with server authentication mode SHOULD use dual key
			mode - i.e. there are two keys that are shared between the client
			and the server. One shared key is used to generate the server
			response on the server side and to verify it on the client side.
			The other key is used to create the response or signature on the
			client side and to verify the same on the server side.
	The OCRA algorithm when used in mutual authentication mode or in		S8 - We recommend that implementations MAY use the session
	signature with server authentication mode SHOULD use dual key mode		information, S as an additional input in the computation. For
	- i.e. there are two keys that are shared between the client and		example, S could be the session identifier from the TLS session.
	the server. One shared key is used to generate the server response		This will enable you to counter certain types of man-in-the-middle
	on the server side and to verify it on the client side. The other		attacks. However, this will introduce the additional dependency
	key is used to create the response or signature on the client side		that first of all the prover needs to have access to the session
	and to verify the same on the server side.		identifier to compute the response and the verifier will need
			access to the session identifier to verify the response.
	We recommend that implementations MAY use the session information,		S9 - In the signature mode, whenever the counter or time (defined
	S as an additional input in the computation. For example, S could		as optional elements) are not used in the computation, there might
	be the session identifier from the TLS session. This will enable		be a risk of replay attack and the implementers should carefully
	you to counter certain types of man-in-the-middle attacks. However,		consider this issue in the light of their specific application
	this will introduce the additional dependency that first of all the		requirements and security guidelines.
	prover needs to have access to the session identifier to compute
	the response and the verifier will need access to the session		S10 - We also RECOMMEND storing the shared secrets securely in the
	identifier to verify the response.		validation system, and more specifically encrypting the shared
			secrets using tamper-resistant hardware encryption and exposing
			them only when required: for example, the shared secret is
			decrypted when needed to verify an HOTP value, and re-encrypted
			immediately to limit exposure in the RAM for a short period of
			time. The data store holding the shared secrets MUST be in a
			secure area, to avoid as much as possible direct attack on the
			validation system and secrets database.
			OCRA: OATH Challenge Response Algorithms December 2007
			Particularly, access to the shared secrets should be limited to
			programs and processes required by the validation system only. We
			will not elaborate on the different security mechanisms to put in
			place, but obviously, the protection of shared secrets is of the
			uttermost importance.
	10. IANA Considerations		10. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	11. Conclusion		11. Conclusion
	This draft introduced several variants of HOTP for challenge-		This draft introduced several variants of HOTP for challenge-
	response based authentication and short signature-like		response based authentication and short signature-like
	computations.		computations.
	The OCRASuite provides for an easy integration and support of		The OCRASuite provides for an easy integration and support of
	different flavors within an authentication and validation system.		different flavors within an authentication and validation system.
	Finally, OCRA should enable cross-authentication both in connected		Finally, OCRA should enable cross-authentication both in connected
	and off-line modes, with the support of different response sizes		and off-line modes, with the support of different response sizes
	and mode of operations.		and mode of operations.
	OCRA: OATH Challenge Response Algorithms September 2006
	12. Acknowledgements		12. Acknowledgements
	We would like to thank Philip Hoyer, Jon Martinsson, Frederik		We would like to thank Philip Hoyer, Jonathan Tuliani, Shuh Chang,
	Mennes and Stu Vaeth for their comments and suggestions to improve		Stu Vaeth, Jon Martinsson, Jeff Burstein, Frederik Mennes, Oanh
	this draft document.		Hoang, Mingliang Pei and Enrique Rodriguez for their comments and
			suggestions to improve this draft document.
	13. References		13. References
	13.1. Normative		13.1 Normative
	[RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC:		[RFC2104] M. Bellare, R. Canetti and H. Krawczyk, "HMAC:
	Keyed-Hashing for Message Authentication", IETF Network		Keyed-Hashing for Message Authentication", IETF Network
	Working Group, RFC 2104, February 1997.		Working Group, RFC 2104, February 1997.
	[RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller,		[RFC1750] D. Eastlake, 3rd., S. Crocker and J. Schiller,
	"Randomness Recommendations for Security", IETF Network		"Randomness Recommendations for Security", IETF Network
	Working Group, RFC 1750, December 2004.		Working Group, RFC 1750, December 2004.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			OCRA: OATH Challenge Response Algorithms December 2007
	[RFC3668] S. Bradner, "Intellectual Property Rights in IETF		[RFC3668] S. Bradner, "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.		Technology", BCP 79, RFC 3668, February 2004.
	[RFC4226] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and		[RFC4226] D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache and
	O. Ranen, "HOTP: An HMAC-based One Time Password		O. Ranen, "HOTP: An HMAC-based One Time Password
	Algorithm", IETF Network Working Group, RFC 4226,		Algorithm", IETF Network Working Group, RFC 4226,
	December 2005.		December 2005.
	13.2. Informative		13.2 Informative
	[BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash		[BCK] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash
	Functions and Message Authentication", Proceedings of		Functions and Message Authentication", Proceedings of
	Crypto'96, LNCS Vol. 1109, pp. 1-15.		Crypto'96, LNCS Vol. 1109, pp. 1-15.
	[OATH] Initiative for Open AuTHentication		[OATH] Initiative for Open AuTHentication
	http://www.openauthentication.org		http://www.openauthentication.org
	[CN] J.S. Coron and D. Naccache, "An accurate evaluation of		[CN] J.S. Coron and D. Naccache, "An accurate evaluation of
	Maurer's universal test" by Jean-Sebastien Coron and		Maurer's universal test" by Jean-Sebastien Coron and
	David Naccache In Selected Areas in Cryptography (SAC		David Naccache In Selected Areas in Cryptography (SAC
	'98), vol. 1556 of Lecture Notes in Computer Science,		'98), vol. 1556 of Lecture Notes in Computer Science,
	S. Tavares and H. Meijer, Eds., pp. 57-71, Springer-		S. Tavares and H. Meijer, Eds., pp. 57-71, Springer-
	Verlag, 1999		Verlag, 1999
	OCRA: OATH Challenge Response Algorithms September 2006
	Appendix A: Code Source		Appendix A: Source Code
	import java.lang.reflect.UndeclaredThrowableException;		import java.lang.reflect.UndeclaredThrowableException;
	import java.security.GeneralSecurityException;		import java.security.GeneralSecurityException;
	import javax.crypto.Mac;		import javax.crypto.Mac;
	import javax.crypto.spec.SecretKeySpec;		import javax.crypto.spec.SecretKeySpec;
	/**		/**
	* This an example implementation of the OATH OCRA algorithm.		* This an example implementation of the OATH OCRA algorithm.
	* Visit www.openauthentication.org for more information.		* Visit www.openauthentication.org for more information.
	*		*
	* @author Johan Rydell, PortWise		* @author Johan Rydell, PortWise
	*/		*/
	public class OCRA {		public class OCRA {
	private OCRA() {}		private OCRA() {}
	/**		/**
	* This method uses the JCE to provide the crypto		* This method uses the JCE to provide the crypto
	* algorithm.		* algorithm.
	* HMAC computes a Hashed Message Authentication Code with the		* HMAC computes a Hashed Message Authentication Code with the
	* crypto hash algorithm as a parameter.		* crypto hash algorithm as a parameter.
			OCRA: OATH Challenge Response Algorithms December 2007
	*		*
	* @param crypto the crypto algorithm		* @param crypto the crypto algorithm
	* (HmacSHA1, HmacSHA256, HmacSHA512)		* (HmacSHA1, HmacSHA256, HmacSHA512)
	* @param keyBytes the bytes to use for the HMAC key		* @param keyBytes the bytes to use for the HMAC key
	* @param text the message or text to be authenticated.		* @param text the message or text to be authenticated.
	*/		*/
	public static byte[] hmac_sha1(String crypto,		public static byte[] hmac_sha1(String crypto,
	byte[] keyBytes,		byte[] keyBytes,
	byte[] text)		byte[] text)
	{		{
	skipping to change at page 18, line 4 ¶		skipping to change at page 17, line 35 ¶
	throw new UndeclaredThrowableException(gse);		throw new UndeclaredThrowableException(gse);
	}		}
	}		}
	private static final int[] DIGITS_POWER		private static final int[] DIGITS_POWER
	// 0 1 2 3 4 5 6 7 8		// 0 1 2 3 4 5 6 7 8
	= {1,10,100,1000,10000,100000,1000000,10000000,100000000};		= {1,10,100,1000,10000,100000,1000000,10000000,100000000};
	/**		/**
	* This method generates an OCRA HOTP value for the given		* This method generates an OCRA HOTP value for the given
	OCRA: OATH Challenge Response Algorithms September 2006
	* set of parameters.		* set of parameters.
	*		*
	* @param crypto the crypto algorithm		* @param crypto the crypto algorithm
	* @param key the shared secret		* @param key the shared secret
	* @param movingFactor the counter that changes		* @param movingFactor the counter that changes
	* on a per use basis		* on a per use basis
	* @param question the challenge question		* @param question the challenge question
	* @param password a password that can be used		* @param password a password that can be used
	* @param sessionInformation Static information that		* @param sessionInformation Static information that
	* identifies the current session		* identifies the current session
	skipping to change at page 18, line 27 ¶		skipping to change at page 18, line 4 ¶
	* @param codeDigits number of digits in the OTP		* @param codeDigits number of digits in the OTP
	*		*
	* @return A numeric String in base 10 that includes		* @return A numeric String in base 10 that includes
	* {@link truncationDigits} digits		* {@link truncationDigits} digits
	*/		*/
	static public String generateOTP(String crypto,		static public String generateOTP(String crypto,
	String key,		String key,
	String movingFactor,		String movingFactor,
	String question,		String question,
	String password,		String password,
			OCRA: OATH Challenge Response Algorithms December 2007
	String sessionInformation,		String sessionInformation,
	String timeStamp,		String timeStamp,
	int codeDigits)		int codeDigits)
	{		{
	String result = null;		String result = null;
	String messageStr =		String messageStr =
	question + password +		question + password +
	sessionInformation + timeStamp ;		sessionInformation + timeStamp ;
	byte[] msg;		byte[] msg;
	skipping to change at page 19, line 4 ¶		skipping to change at page 18, line 34 ¶
	msg[i] = (byte) (mFactor & 0xff);		msg[i] = (byte) (mFactor & 0xff);
	mFactor >>= 8;		mFactor >>= 8;
	}		}
	}else		}else
	msg = messageStr.getBytes();		msg = messageStr.getBytes();
	// compute hmac hash		// compute hmac hash
	byte[] hash = hmac_sha1(crypto, key.getBytes(), msg);		byte[] hash = hmac_sha1(crypto, key.getBytes(), msg);
	// put selected bytes into result int		// put selected bytes into result int
	OCRA: OATH Challenge Response Algorithms September 2006
	int offset = hash[hash.length - 1] & 0xf;		int offset = hash[hash.length - 1] & 0xf;
	int binary =		int binary =
	((hash[offset] & 0x7f) << 24) |		((hash[offset] & 0x7f) << 24) |
	((hash[offset + 1] & 0xff) << 16) |		((hash[offset + 1] & 0xff) << 16) |
	((hash[offset + 2] & 0xff) << 8) |		((hash[offset + 2] & 0xff) << 8) |
	(hash[offset + 3] & 0xff);		(hash[offset + 3] & 0xff);
	int otp = binary % DIGITS_POWER[codeDigits];		int otp = binary % DIGITS_POWER[codeDigits];
	result = Integer.toString(otp);		result = Integer.toString(otp);
	while (result.length() < codeDigits) {		while (result.length() < codeDigits) {
	result = "0" + result;		result = "0" + result;
	}		}
	return result;		return result;
	}		}
	}		}
			OCRA: OATH Challenge Response Algorithms December 2007
	Appendix B: Test Vectors		Appendix B: Test Vectors
	Plain challenge response		Plain challenge response
	========================		========================
	OCRA-HOTP-SHA1-8-Q		OCRA-HOTP-SHA1-8-Q
	------------------		------------------
	K = 12345678901234567890 Q = 10000000 OCRA = 57953866		K = 12345678901234567890 Q = 10000000 OCRA = 57953866
	K = 12345678901234567890 Q = 10000001 OCRA = 15772773		K = 12345678901234567890 Q = 10000001 OCRA = 15772773
	skipping to change at page 19, line 47 ¶		skipping to change at page 19, line 29 ¶
	K = 12345678901234567890 Q = 10000000 OCRA = 79730854		K = 12345678901234567890 Q = 10000000 OCRA = 79730854
	K = 12345678901234567890 Q = 10000001 OCRA = 22925447		K = 12345678901234567890 Q = 10000001 OCRA = 22925447
	K = 12345678901234567890 Q = 10000002 OCRA = 15947867		K = 12345678901234567890 Q = 10000002 OCRA = 15947867
	OCRA-HOTP-SHA512-8-Q		OCRA-HOTP-SHA512-8-Q
	--------------------		--------------------
	K = 12345678901234567890 Q = 10000000 OCRA = 68325835		K = 12345678901234567890 Q = 10000000 OCRA = 68325835
	K = 12345678901234567890 Q = 10000001 OCRA = 53995836		K = 12345678901234567890 Q = 10000001 OCRA = 53995836
	K = 12345678901234567890 Q = 10000002 OCRA = 89008345		K = 12345678901234567890 Q = 10000002 OCRA = 89008345
	Response Only
	=============
	OCRA-HOTP-SHA1-6-C
	------------------
	K = 12345678901234567890 C = 0 OCRA = 755224
	K = 12345678901234567890 C = 1 OCRA = 287082
	K = 12345678901234567890 C = 2 OCRA = 359152
	OCRA: OATH Challenge Response Algorithms September 2006
	OCRA-HOTP-SHA256-6-C
	--------------------
	K = 12345678901234567890 C = 0 OCRA = 875740
	K = 12345678901234567890 C = 1 OCRA = 247374
	K = 12345678901234567890 C = 2 OCRA = 254785
	OCRA-HOTP-SHA512-6-C
	--------------------
	K = 12345678901234567890 C = 0 OCRA = 125165
	K = 12345678901234567890 C = 1 OCRA = 342147
	K = 12345678901234567890 C = 2 OCRA = 730102
	OCRA-HOTP-SHA1-6-C-P
	--------------------
	K = 12345678901234567890 C = 0 P = 12341234 OCRA = 106753
	K = 12345678901234567890 C = 1 P = 12341234 OCRA = 747071
	K = 12345678901234567890 C = 2 P = 12341234 OCRA = 714367
	OCRA-HOTP-SHA256-6-C-P
	----------------------
	K = 12345678901234567890 C = 0 P = 12341234 OCRA = 744059
	K = 12345678901234567890 C = 1 P = 12341234 OCRA = 735947
	K = 12345678901234567890 C = 2 P = 12341234 OCRA = 167188
	OCRA-HOTP-SHA512-6-C-P
	----------------------
	K = 12345678901234567890 C = 0 P = 12341234 OCRA = 249058
	K = 12345678901234567890 C = 1 P = 12341234 OCRA = 738728
	K = 12345678901234567890 C = 2 P = 12341234 OCRA = 556127
	Mutual challenge response		Mutual challenge response
	=========================		=========================
	OCRA-HOTP-SHA512-8-Q		OCRA-HOTP-SHA512-8-Q
	--------------------		--------------------
	(From server) K = 12345678901234567890		(From server) K = 12345678901234567890
	Q1 = 11111110 Q2 = 22222220 OCRA = 70933163		Q1 = 11111110 Q2 = 22222220 OCRA = 70933163
	(From client) K = 12345678901234567890		(From client) K = 12345678901234567890
	Q1 = 11111110 Q2 = 22222220 OCRA = 63875222		Q1 = 11111110 Q2 = 22222220 OCRA = 63875222
	(From server) K = 12345678901234567890		(From server) K = 12345678901234567890
	Q1 = 11111111 Q2 = 22222221 OCRA = 08364053		Q1 = 11111111 Q2 = 22222221 OCRA = 08364053
	(From client) K = 12345678901234567890		(From client) K = 12345678901234567890
	Q1 = 11111111 Q2 = 22222221 OCRA = 91844292		Q1 = 11111111 Q2 = 22222221 OCRA = 91844292
	(From server) K = 12345678901234567890		(From server) K = 12345678901234567890
	Q1 = 11111112 Q2 = 22222222 OCRA = 70960179		Q1 = 11111112 Q2 = 22222222 OCRA = 70960179
	OCRA: OATH Challenge Response Algorithms September 2006
	(From client) K = 12345678901234567890		(From client) K = 12345678901234567890
	Q1 = 11111112 Q2 = 22222222 OCRA = 75789938		Q1 = 11111112 Q2 = 22222222 OCRA = 75789938
			OCRA: OATH Challenge Response Algorithms December 2007
	Plain signature		Plain signature
	===============		===============
	OCRA-HOTP-SHA512-8-Q		OCRA-HOTP-SHA512-8-Q
	--------------------		--------------------
	K = 12345678901234567890 Q (value) = 00010000		K = 12345678901234567890 Q (value) = 00010000
	OCRA (signature) = 13175449		OCRA (signature) = 13175449
	K = 12345678901234567890 Q (value) = 00011000		K = 12345678901234567890 Q (value) = 00011000
	OCRA (signature) = 41866883		OCRA (signature) = 41866883
	skipping to change at page 21, line 34 ¶		skipping to change at page 20, line 31 ¶
	David M'Raihi		David M'Raihi
	VeriSign, Inc.		VeriSign, Inc.
	685 E. Middlefield Road Phone: 1-650-426-3832		685 E. Middlefield Road Phone: 1-650-426-3832
	Mountain View, CA 94043 USA Email: dmraihi@verisign.com		Mountain View, CA 94043 USA Email: dmraihi@verisign.com
	Other Authors' contact information:		Other Authors' contact information:
	Johan Rydell		Johan Rydell
	Portwise, Inc.		Portwise, Inc.
	624 Ellis Street, Suite 102 Phone: 1-650-515-3569		275 Hawthorne Ave, Suite 119 Phone: 1-650-515-3569
	Mountain View, CA 94043 USA Email: johan.rydell@portwise.com		Palo Alto, CA 94301 USA Email: johan.rydell@portwise.com
	David Naccache		David Naccache
	ENS, DI		ENS, DI
	45 rue d'Ulm Phone: +33 6 16 59 83 49		45 rue d'Ulm Phone: +33 6 16 59 83 49
	75005, Paris France Email: david.naccache@ens.fr		75005, Paris France Email: david.naccache@ens.fr
	Salah Machani		Salah Machani
	Diversinet Corp.		Diversinet Corp.
	2225 Sheppard Avenue East		2225 Sheppard Avenue East
	Suite 1801		Suite 1801
	Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321		Toronto, Ontario M2J 5C2 Phone: 1-416-756-2324 Ext. 321
	Canada Email: smachani@diversinet.com		Canada Email: smachani@diversinet.com
	Siddharth Bajaj		Siddharth Bajaj
	VeriSign, Inc.		VeriSign, Inc.
	487 E. Middlefield Road Phone: 1-650-426-3458		487 E. Middlefield Road Phone: 1-650-426-3458
	Mountain View, CA 94043 USA Email: sbajaj@verisign.com		Mountain View, CA 94043 USA Email: sbajaj@verisign.com
	OCRA: OATH Challenge Response Algorithms September 2006		OCRA: OATH Challenge Response Algorithms December 2007
	15. Full Copyright Statement		15. Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
End of changes. 87 change blocks.
	301 lines changed or deleted		244 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/