[OSPF] [Technical Errata Reported] RFC5709 (3585)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 10 April 2013 02:54 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245C221F8E9E for <ospf@ietfa.amsl.com>; Tue, 9 Apr 2013 19:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vQJhZDEM5Ja for <ospf@ietfa.amsl.com>; Tue, 9 Apr 2013 19:54:47 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A121F91D4 for <ospf@ietf.org>; Tue, 9 Apr 2013 19:54:44 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5C921B1E002; Tue, 9 Apr 2013 19:54:10 -0700 (PDT)
To: manav@alcatel-lucent.com, vishwas@ipinfusion.com, mfanto@aegisdatasecurity.com, riw@cisco.com, mjbarnes@cisco.com, tony.li@tony.li, rja@extremenetworks.com, stbryant@cisco.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20130410025410.5C921B1E002@rfc-editor.org>
Date: Tue, 09 Apr 2013 19:54:10 -0700
Cc: ospf@ietf.org, rfc-editor@rfc-editor.org
Subject: [OSPF] [Technical Errata Reported] RFC5709 (3585)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 02:54:49 -0000
The following errata report has been submitted for RFC5709, "OSPFv2 HMAC-SHA Cryptographic Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5709&eid=3585 -------------------------------------- Type: Technical Reported by: Mike Dubrovsky <mdubrovs@cisco.com> Section: 3.3 Original Text ------------- (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. Corrected Text -------------- (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 ᆵ 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. -------------------------------------- RFC5709 (draft-ietf-ospf-hmac-sha-07) -------------------------------------- Title : OSPFv2 HMAC-SHA Cryptographic Authentication Publication Date : October 2009 Author(s) : M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG
- [OSPF] [Technical Errata Reported] RFC5709 (3585) RFC Errata System