RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Held for Document Update (1)

RFC 5709, "OSPFv2 HMAC-SHA Cryptographic Authentication", October 2009

Note: This RFC has been updated by RFC 7474

Source of RFC: ospf (rtg)

Errata ID: 3585
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Mike Dubrovsky
Date Reported: 2013-04-09
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19

Section 3.3 says:

(1) PREPARATION OF KEY
       In this application, Ko is always L octets long.

       If the Authentication Key (K) is L octets long, then Ko is equal
       to K.  If the Authentication Key (K) is more than L octets long,
       then Ko is set to H(K).  If the Authentication Key (K) is less
       than L octets long, then Ko is set to the Authentication Key (K)
       with zeros appended to the end of the Authentication Key (K),
       such that Ko is L octets long.

It should say:

(1) PREPARATION OF KEY
       In this application, Ko is always B octets long and is computed 
       as follows:

       If the Authentication Key (K) is B octets long, then Ko is equal
       to K.  If the Authentication Key (K) is more than B octets long,
       then Ko is set to H(K) and then appended with (B-L) zeroes to 
       create a B octets long string Ko.  If the Authentication Key (K) 
       is less than B octets long, then Ko is set to the Authentication 
       Key (K) with zeros appended to the end of the Authentication Key 
       (K), such that Ko is B octets long.

Notes:

This is in accordance with RFC2104(HMAC: Keyed-Hashing for Message Authentication). Reproducing the relevant text below:

2. Definition of HMAC

The definition of HMAC requires a cryptographic hash function, which
we denote by H, and a secret key K. We assume H to be a cryptographic
hash function where data is hashed by iterating a basic compression
function on blocks of data. We denote by B the byte-length of such
blocks (B=64 for all the above mentioned examples of hash functions),
and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
SHA-1). The authentication key K can be of any length up to B, the
block length of the hash function. Applications that use keys longer
than B bytes will first hash the key using H and then use the
resultant L byte string as the actual key to HMAC. In any case the
minimal recommended length for K is L bytes (as the hash output
length). See section 3 for more information on keys.


Also, according to FIPS PUB 198, section 5(HMAC SPECIFICATION) :

STEPS
STEP-BY-STEP DESCRIPTION
Step 1
If the length of K = B: set K0 = K. Go to step 4.
Step 2
If the length of K > B: hash K to obtain an L byte string,
then append (B-L) zeros to create a B-byte string K0
(i.e., K0 = H(K) || 00...00). Go to step 4.
Step 3
If the length of K < B: append zeros to the end of K to
create a B-byte string K0 (e.g., if K is 20 bytes in
length and B = 64, then K will be appended with 44 zero
bytes 0x00).
Step 4
Exclusive-Or K0 with ipad to produce a B-byte string:
K0 ¯ ipad.
Step 5
Append the stream of data 'text' to the string resulting
from step 4: (K0 ¯ ipad) || text.
Step 6
Apply H to the stream generated in step 5:
H((K0 ¯ ipad) || text).
Step 7
Exclusive-Or K0 with opad: K0 ¯ opad.
Step 8
Append the result from step 6 to step 7:
(K0 ¯ opad) || H((K0 ¯ ipad) || text).
Step 9
Apply H to the result from step 8:
H((K0 ¯ opad )|| H((K0 &#65455; ipad) || text)).
Step 10
Select the leftmost t bytes of the result of step 9 as the MAC.

Verifier's note:
This issue is being addressed by draft-ietf-ospf-rfc6506bis.

Status: Rejected (1)

RFC 5709, "OSPFv2 HMAC-SHA Cryptographic Authentication", October 2009

Note: This RFC has been updated by RFC 7474

Source of RFC: ospf (rtg)

Errata ID: 2989
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Dai Wenjie (David Jet)
Date Reported: 2011-10-10
Rejected by: RFC Editor
Date Rejected: 2011-10-14

Section 3. says:

   With the additions in this document, the currently valid algorithms
   (including mode) for OSPFv2 Cryptographic Authentication include:

           Keyed-MD5               (defined in RFC 2328, Appendix D)

It should say:

   With the additions in this document, the currently valid algorithms
   (including mode) for OSPFv2 Cryptographic Authentication include:

           Keyed-MD5               (defined in RFC 2328, Appendix D)

Notes:

The link 'Appendix D' referenced is incorrect. It is now 'http://tools.ietf.org/html/rfc5709#appendix-D', and it should be 'http://tools.ietf.org/html/rfc2328#appendix-D'.
Pay attention to the difference of the numbers in links,please.

-- VERIFIER NOTES --
Errata are for the RFCs as available from rfc-editor.org.

Report New Errata



Advanced Search