errata logo graphic

Found 4 records.

Status: Verified (1)

RFC6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area 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 (2)

RFC6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area 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


Status: Held for Document Update (1)

RFC6287, "OCRA: OATH Challenge-Response Algorithm", June 2011

Source of RFC: IETF - NON WORKING GROUP
Area 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;
}


Report New Errata