[OSPF] [Technical Errata Reported] RFC6506 (3394)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC6506,
"Supporting Authentication Trailer for OSPFv3".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6506&eid=3394

--------------------------------------
Type: Technical
Reported by: Srinivasan K L <[e-mail]>

Section: 4.5

Original Text
-------------
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.

Corrected Text
--------------
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
-----
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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6506 (draft-ietf-ospf-auth-trailer-ospfv3-11)
--------------------------------------
Title               : Supporting Authentication Trailer for OSPFv3
Publication Date    : February 2012
Author(s)           : M. Bhatia, V. Manral, A. Lindem
Category            : PROPOSED STANDARD
Source              : Open Shortest Path First IGP
Area                : Routing
Stream              : IETF
Verifying Party     : IESG