

Found 10 records.
Errata ID: 3729
Status: Verified
Type: Editorial
Reported By: Simon Josefsson
Date Reported: 20130917
Verifier Name: Sean Turner
Date Verified: 20140112
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: +++  TimeStep Size (G)  Examples  +++  [159]S  number of seconds, e.g., 20S   [159]M  number of minutes, e.g., 5M   [048]H  number of hours, e.g., 24H  +++ Table 3: Timestep Size Table Default value for G is 1M, i.e., timestep 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: +++  TimeStep Size (G)  Examples  +++  [159]S  number of seconds, e.g., 20S   [159]M  number of minutes, e.g., 5M   [148]H  number of hours, e.g., 24H  +++ Table 3: Timestep Size Table Default value for G is 1M, i.e., timestep size is one minute and the T represents the number of minutes since epoch time [UT].
Notes:
I have changed "[048]H" to "[148]H".
According to section 5.1, T is "representing the number of timesteps (seconds, minutes, hours, or days depending on the specified granularity) since midnight UTC of January 1, 1970 [UT]."
Having a granualarity of 0 is nonsense, and likely an editorial error.
Errata ID: 3730
Status: Reported
Type: Technical
Reported By: Simon Josefsson
Date Reported: 20130917
Section 5.2 says:
This table summarizes all possible values for the CryptoFunction: ++++  Name  HMAC Function Used  Size of Truncation (t)  ++++  HOTPSHA1t  HMACSHA1  0 (no truncation), 410   HOTPSHA256t  HMACSHA256  0 (no truncation), 410   HOTPSHA512t  HMACSHA512  0 (no truncation), 410  ++++
It should say:
This table summarizes all possible values for the CryptoFunction: ++++  Name  HMAC Function Used  Size of Truncation (t)  ++++  HOTPSHA1t  HMACSHA1  0 (no truncation), 49   HOTPSHA256t  HMACSHA256  0 (no truncation), 49   HOTPSHA512t  HMACSHA512  0 (no truncation), 49  ++++
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 31bit 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: 20140224
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: 20140916
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  [PST]) != 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  [PT]) != 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  [PST]) != 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  [PT]) != 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: 4112
Status: Reported
Type: Editorial
Reported By: Marc Girault
Date Reported: 20140916
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: 20140916
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  [PST]) != 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  [PT]) != 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  [PST]) != 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  [PT]) != 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: 20140916
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: 20140916
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: 20140916
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: 3900
Status: Held for Document Update
Type: Editorial
Reported By: Marcus Bring
Date Reported: 20140224
Held for Document Update by: Stephen Farrell
Date Held: 20140703
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 * SHAversion declared in OCRAsuite 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;
}