RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (1)

RFC 6506, "Supporting Authentication Trailer for OSPFv3", February 2012

Note: This RFC has been obsoleted by RFC 7166

Source of RFC: ospf (rtg)

Errata ID: 3335
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Manav Bhatia
Date Reported: 2012-09-05
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07

Section 4.5 says:

If the Protocol-Specific Authentication Key (Ks) is L octets 
long, then Ko is equal to K. 

It should say:

If the Protocol-Specific Authentication Key (Ks) is L octets 
long, then Ko is equal to Ks. 

Notes:

The key K is never used in computing the digest. There is a class of cross protocol attacks that can be prevented if the original key K is appended with a few well known bytes. As a result, the key K is appended with a 2 octet crypto protocol ID to derive a new key Ks. Its this key that must always be used.

Status: Held for Document Update (3)

RFC 6506, "Supporting Authentication Trailer for OSPFv3", February 2012

Note: This RFC has been obsoleted by RFC 7166

Source of RFC: ospf (rtg)

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

Reported By: Srinivasan K L
Date Reported: 2012-10-25
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 4.5 says:

The OSPFv3 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific
Authentication Key (Ks). In this application, Ko is always L
octets long and is computed as follows:

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

It should say:

Please see - notes

====

The OSPFv3 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific
Authentication Key (Ks). In this application, Ko is always B
octets long and is computed as follows:

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

Notes:

Readers should consult: draft-ietf-ospf-rfc6506bis for the resolution of this Erratum

=====

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.

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

Reported By: Marek Karasek
Date Reported: 2013-03-27
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 2.2 says:

   Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both
   OSPFv3 header checksum calculation and verification are omitted when
   the OSPFv3 authentication mechanism described in this specification
   is used.

It should say:

Please see notes

=====

OSPFv3 authentication mechanism provides capability to detect 
corruption of OSPFv3 packet, which is under non authenticated 
operation achieved using OSPFv3 header checksum [RFC 5340] 
and LLS data block checksum [RFC 5613]. In spirit of OSPFv2 
Cryptographic Authentication [RFC2328], OSPFv3 header checksum 
and LLS Data Block Checksum calculation and verification 
are omitted when the OSPFv3 authentication mechanism 
described in this specification is used.

Notes:

Readers should consult: draft-ietf-ospf-rfc6506bis for the
resolution of this Erratum

======

RFC does not specify how to work with LLS Data Block Checksum.
Errata suggests omit checksum calculation/verification in the
same way like for OSPFv3 header checksum.

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

Reported By: Marek Karasek
Date Reported: 2013-03-27
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-17

Section 4.2 says:

OSPFv3 Header Checksum

   Both OSPFv3 header checksum calculation and verification are omitted
   when the OSPFv3 authentication mechanism described in this
   specification is used.  This implies:

   o  For OSPFv3 packets to be transmitted, the OSPFv3 header checksum
      computation is omitted, and the OSPFv3 header checksum SHOULD be
      set to 0 prior to computation of the OSPFv3 Authentication Trailer
      message digest.

   o  For received OSPFv3 packets including an OSPFv3 Authentication
      Trailer, OSPFv3 header checksum verification MUST be omitted.
      However, if the OSPFv3 packet does include a non-zero OSPFv3
      header checksum, it will not be modified by the receiver and will
      simply be included in the OSPFv3 Authentication Trailer message
      digest verification.

It should say:

Please see notes

======

OSPFv3 Header Checksum and LLS Data Block Checksum

OSPFv3 Header Checksum and LLS Data Block Checksum calculation
and verification are omitted when the OSPFv3 authentication 
mechanism described in this specification is used.  This 
implies:

o  For OSPFv3 packets to be transmitted, the OSPFv3 header 
checksum and LLS Data Block checksum computation is omitted, 
and the checksums SHOULD be set to 0 prior to computation 
of the OSPFv3 Authentication Trailer message digest.

o  For received OSPFv3 packets including an OSPFv3 
Authentication Trailer, OSPFv3 header checksum and LLS Data 
Block checksum verification MUST be omitted.  However, 
if the OSPFv3 packet does include a non-zero OSPFv3 header 
or LLS Data Block checksum, it will not be modified by 
the receiver and will simply be included in the OSPFv3 
Authentication Trailer message digest verification.

Notes:

The reader should consult draft-ietf-ospf-rfc6506bis for
the resolution of this erratum

======

RFC does not specify how to work with LLS Data Block
Checksum. Errata suggests omit checksum calculation/
verification in the same way like for OSPFv3 header
checksum.

Report New Errata



Advanced Search