# RFC Errata

Found 13 records.

## Status: Verified (1)

### RFC 6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 3729

**Status: Verified
Type: Editorial
**

Reported By: Simon Josefsson

Date Reported: 2013-09-17

Verifier Name: Sean Turner

Date Verified: 2014-01-12

Section 6.3 says:

The input for timestamps is further qualified by G, size of the time- step. G can be specified in number of seconds, minutes, or hours: +--------------------+------------------------------+ | Time-Step Size (G) | Examples | +--------------------+------------------------------+ | [1-59]S | number of seconds, e.g., 20S | | [1-59]M | number of minutes, e.g., 5M | | [0-48]H | number of hours, e.g., 24H | +--------------------+------------------------------+ Table 3: Time-step Size Table Default value for G is 1M, i.e., time-step size is one minute and the T represents the number of minutes since epoch time [UT].

It should say:

The input for timestamps is further qualified by G, size of the time- step. G can be specified in number of seconds, minutes, or hours: +--------------------+------------------------------+ | Time-Step Size (G) | Examples | +--------------------+------------------------------+ | [1-59]S | number of seconds, e.g., 20S | | [1-59]M | number of minutes, e.g., 5M | | [1-48]H | number of hours, e.g., 24H | +--------------------+------------------------------+ Table 3: Time-step Size Table Default value for G is 1M, i.e., time-step size is one minute and the T represents the number of minutes since epoch time [UT].

Notes:

I have changed "[0-48]H" to "[1-48]H".

According to section 5.1, T is "representing the number of time-steps (seconds, minutes, hours, or days depending on the specified granularity) since midnight UTC of January 1, 1970 [UT]."

Having a granualarity of 0 is non-sense, and likely an editorial error.

## Status: Reported (11)

### RFC 6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 3730

**Status: Reported
Type: Technical
**

Reported By: Simon Josefsson

Date Reported: 2013-09-17

Section 5.2 says:

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 | +---------------+--------------------+-------------------------+

It should say:

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-9 | | HOTP-SHA256-t | HMAC-SHA256 | 0 (no truncation), 4-9 | | HOTP-SHA512-t | HMAC-SHA512 | 0 (no truncation), 4-9 | +---------------+--------------------+-------------------------+

Notes:

The change disallows 10 digit OCRA codes. The reason for this is subtle and could be discussed. An alternative to disallowing 10 digit codes is to add a Security Consideration discussion about the behaviour when 10 is used.

The Truncate function defined in RFC 4226 section 5.3 works on 31-bit numbers and uses modulo 10^Digit. When Digit=10, that means 10^10. However, 2^31 is smaller than 10^10. This means that the output code can never take on values 2^31..10^10 which causes a significant bias in the number of valid codes.

The entire security analysis in RFC 4226 assumes this is not the case. For example quoting section A.5 "Security Analysis of HOTP": "Suppose m = 10^Digit < 2^31,".

To clarify, there is no attack enabled by this flaw. OCRA with 10 digit codes just doesn't offer as good security as it could. 10 digits is only roughly twice as secure as 9 digit codes instead of 10 times as one would expect.

Errata ID: 3899

**Status: Reported
Type: Technical
**

Reported By: Marcus Bring

Date Reported: 2014-02-24

Section Appendix A. says:

// Put the bytes of "time" to the message // Input is text value of minutes if(timeStampLength > 0){ bArray = hexStr2Bytes(timeStamp); System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 + counterLength + questionLength + passwordLength + sessionInformationLength, bArray.length); }

It should say:

// Put the bytes of "time" to the message // Input is HEX encoded value of minutes if(timeStampLength > 0){ bArray = hexStr2Bytes(timeStamp); System.arraycopy(bArray, 0, msg, ocraSuiteLength + 1 + counterLength + questionLength + passwordLength + sessionInformationLength, bArray.length); }

Notes:

The timestamp should be HEX encoded since hexStr2Bytes() is used. Otherwise it will fail to generate the correct OTP

Errata ID: 4114

**Status: Reported
Type: Technical
**

Reported By: Marc Girault

Date Reported: 2014-09-16

Section 7 says:

R = OCRA(K, {[C] | Q | [P | S | T]}) RS = OCRA(K, [C] | QC | QS | [S | T]) OCRA(K, [C] | QC | QS | [S | T]) != RS RC = OCRA(K, [C] | QS | QC | [P | S | T]) OCRA(K, [C] | QS | QC | [P|S|T]) != RC SIGN = OCRA(K, [C] | QS | [P | T]) RS = OCRA(K, [C] | QC | QS | [T] OCRA(K, [C] | QC | QS | [T]) != RS SIGN = OCRA( K, [C] | QS | QC | [P | T]) OCRA(K, [C] | QS | QC | [P|T]) != SIGN

It should say:

R = CryptoFunction(K, OCRASuite | 00 | [C] | Q | [P | S | T]) RS = CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [S | T]) CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [S | T]) != RS RC = CryptoFunction(K, OCRASuite | 00 | [C] | QS | QC | [P | S | T]) CryptoFunction(K, OCRASuite | 00 | [C] | QS | QC | [P|S|T]) != RC SIGN = CryptoFunction(K, OCRASuite | 00 | [C] | QS | [P | T]) RS = CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [T] CryptoFunction(K, OCRASuite | 00 | [C] | QC | QS | [T]) != RS SIGN = CryptoFunction( K, OCRASuite | 00 | [C] | QS | QC | [P | T]) CryptoFunction(K, OCRASuite | 00 | [C] | QS | QC | [P|T]) != SIGN

Notes:

Page 5, DataInput is defined as the concatenation of OCRASuite, byte 00 and five parameters. Pages 11 and subsequent ones, it is defined as the concatenation of only those five parameters, omitting OCRASuite and byte 00. This is technically inconsistent.

The proposed new text anticipates positive verification of errata n°4113 and supersedes it.

Errata ID: 5625

**Status: Reported
Type: Technical
**

Reported By: Emanuele Giacomelli

Date Reported: 2019-02-07

Section Appendix A says:

// put selected bytes into result int int offset = hash[hash.length - 1] & 0xf; int binary = ((hash[offset] & 0x7f) << 24) | ((hash[offset + 1] & 0xff) << 16) | ((hash[offset + 2] & 0xff) << 8) | (hash[offset + 3] & 0xff); int otp = binary % DIGITS_POWER[codeDigits]; result = Integer.toString(otp); while (result.length() < codeDigits) { result = "0" + result; } return result;

It should say:

if (codeDigits > 0) { // put selected bytes into result int int offset = hash[hash.length - 1] & 0xf; int binary = ((hash[offset] & 0x7f) << 24) | ((hash[offset + 1] & 0xff) << 16) | ((hash[offset + 2] & 0xff) << 8) | (hash[offset + 3] & 0xff); int otp = binary % DIGITS_POWER[codeDigits]; result = Integer.toString(otp); while (result.length() < codeDigits) { result = "0" + result; } return result; } else { return asHex(hash); }

Notes:

The code does not honor what the RFC says in section 5.2:

3. t=0 means that no truncation is performed and the full HMAC value

is used for authentication purposes

and still applies dynamic truncation to suites requesting "0" digits.

As a result, the computation performs a "modulo 1" operation causing

the code to always return 0 for such suites.

The proposed patch explicitly disables dynamic truncation for such suites and returns the full HMAC

encoded as a Base16 string. The "asHex" function is the same defined in Appendix B.

Errata ID: 4112

**Status: Reported
Type: Editorial
**

Reported By: Marc Girault

Date Reported: 2014-09-16

Section 5 says:

OCRA = CryptoFunction(K, DataInput)

It should say:

R = CryptoFunction(K, DataInput)

Notes:

The acronym “OCRA” is used page 5 as the output of the CryptoFunction, page 9 as the name of a (family of) algorithm(s), in diagrams of pages 11, 13, 14 and 16 as a cryptographic function. This is inconsistent.

Errata ID: 4113

**Status: Reported
Type: Editorial
**

Reported By: Marc Girault

Date Reported: 2014-09-16

Section 7 says:

R = OCRA(K, {[C] | Q | [P | S | T]}) RS = OCRA(K, [C] | QC | QS | [S | T]) OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP RC = OCRA(K, [C] | QS | QC | [P | S | T]) OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP SIGN = OCRA(K, [C] | QS | [P | T]) RS = OCRA(K, [C] | QC | QS | [T] OCRA(K, [C] | QC | QS | [T]) != RS -> STOP SIGN = OCRA( K, [C] | QS | QC | [P | T]) OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP

It should say:

R = CryptoFunction(K, {[C] | Q | [P | S | T]}) RS = CryptoFunction(K, [C] | QC | QS | [S | T]) CryptoFunction(K, [C] | QC | QS | [S | T]) != RS -> STOP RC = CryptoFunction(K, [C] | QS | QC | [P | S | T]) CryptoFunction(K, [C] | QS | QC | [P|S|T]) != RC -> STOP SIGN = CryptoFunction(K, [C] | QS | [P | T]) RS = CryptoFunction(K, [C] | QC | QS | [T] CryptoFunction(K, [C] | QC | QS | [T]) != RS -> STOP SIGN = CryptoFunction( K, [C] | QS | QC | [P | T]) CryptoFunction(K, [C] | QS | QC | [P|T]) != SIGN -> STOP

Notes:

The acronym “OCRA” is used page 5 as the output of the CryptoFunction, page 9 as the name of a (family of) algorithm(s), in diagrams of pages 11, 13, 14 and 16 as a cryptographic function. This is inconsistent.

Errata ID: 4115

**Status: Reported
Type: Editorial
**

Reported By: Marc Girault

Date Reported: 2014-09-16

Section 5 says:

DataInput = {OCRASuite | 00 | C | Q | P | S | T} where: o OCRASuite is a value representing the suite of operations to compute an OCRA response

It should say:

DataInput = {OCRASuite | 00 | [C] | Q | [P | S | T]) where: o [] indicates a value is optional o OCRASuite is a value representing the suite of operations to compute an OCRA response

Notes:

It is useful to know as early as possible which parameters are optional or not, especially as it is not exhaustively specified page 6.

Errata ID: 4116

**Status: Reported
Type: Editorial
**

Reported By: Marc Girault

Date Reported: 2014-09-16

Section 5 says:

5.1. DataInput Parameters

It should say:

5.1. DataInput

Notes:

DataInput means two different things in (contents of) section 5.1 and (title of) section 6.3. This is inconsistent.

Errata ID: 4117

**Status: Reported
Type: Editorial
**

Reported By: Marc Girault

Date Reported: 2014-09-16

Section 6.3 says:

6.3. DataInput

It should say:

6.3. DataInput Parameters

Notes:

DataInput means two different things in (contents of) section 5.1 and (title of) section 6.3. This is inconsistent.

Errata ID: 4401

**Status: Reported
Type: Editorial
**

Reported By: Anthony

Date Reported: 2015-06-25

Section 6.4 says:

"OCRA-1:HOTP-SHA1-4:QH8-S512" means version 1 of OCRA with HMAC- SHA1 function, truncated to a 4-digit value, using a random hexadecimal challenge up to 8 nibbles and a session value of 512 bytes

It should say:

"OCRA-1:HOTP-SHA1-4:QH08-S512" means version 1 of OCRA with HMAC- SHA1 function, truncated to a 4-digit value, using a random hexadecimal challenge up to 8 nibbles and a session value of 512 bytes

Notes:

I have changed "QH8" to "QH08".

Errata ID: 5133

**Status: Reported
Type: Editorial
**

Reported By: Mathieu Lechat

Date Reported: 2017-09-29

Section 6.3 says:

The input for S is further qualified by the length of the session data in bytes. The client and server could agree to any length but the typical values are:

It should say:

The input for S is further qualified by the length of the session data in bytes. The client and server could agree to any length up to 512 but the typical values are:

Notes:

Section 6.3 it is said the session data can be any length, as it is three digits this means it could be from 000 to 999. However in section 5.1 it is said session data cannot exceed 512 bytes so this should be reflected.

## Status: Held for Document Update (1)

### RFC 6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec

Errata ID: 3900

**Status: Held for Document Update
Type: Editorial
**

Reported By: Marcus Bring

Date Reported: 2014-02-24

Held for Document Update by: Stephen Farrell

Date Held: 2014-07-03

Section Appendix A. says:

* @param password a password that can be used, HEX encoded . . . // Put the bytes of "password" to the message // Input is HEX encoded

It should say:

* @param password a password that can be used, hashed with the * SHA-version declared in OCRA-suite and HEX encoded. . . . // Put the bytes of "password" to the message // Input is SHA hashed and HEX encoded

Notes:

The password should be hashed as stated in the RFC and as it is done in the testOCRA class.

This should also eliminate the need to padd the password with zeros since the hash is always of the correct length.

// Password - sha1

if(DataInput.toLowerCase().indexOf("psha1") > 1){

passwordLength=20;

}

// Password - sha256

if(DataInput.toLowerCase().indexOf("psha256") > 1){

passwordLength=32;

}

// Password - sha512

if(DataInput.toLowerCase().indexOf("psha512") > 1){

passwordLength=64;

}