draft-ietf-bfd-hmac-sha-01.txt   draft-ietf-bfd-hmac-sha-02.txt 
Network Working Group D. Zhang Network Working Group D. Zhang
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track M. Bhatia Intended status: Standards Track M. Bhatia
Expires: January 4, 2013 Alcatel-Lucent Expires: April 22, 2013 Alcatel-Lucent
V. Manral V. Manral
Hewlett-Packard Co. Hewlett-Packard Co.
July 03, 2012 October 19, 2012
Authenticating BFD using HMAC-SHA-2 procedures Authenticating BFD using HMAC-SHA-2 procedures
draft-ietf-bfd-hmac-sha-01 draft-ietf-bfd-hmac-sha-02
Abstract Abstract
This document describes the mechanism to authenticate Bidirectional This document describes the mechanism to authenticate Bidirectional
Forwarding Detection (BFD) protocol packets using Hashed Message Forwarding Detection (BFD) protocol packets using Hashed Message
Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512
algorithms. The mechanism described uses the Generic Cryptographic algorithms. The described mechanism uses the Generic Cryptographic
Authentication and Generic Meticulous Cryptographic Authentication Authentication and Generic Meticulous Cryptographic Authentication
sections to carry the authentication data. This document updates, sections to carry the authentication data. This document updates,
but does not supercede, the cryptographic authentication mechanism but does not supercede, the cryptographic authentication mechanism
specified in RFC 5880. specified in RFC 5880.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2013. This Internet-Draft will expire on April 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . . 3
3. Procedures at the Sending Side . . . . . . . . . . . . . . . . 5 3. Procedures at the Sending Side . . . . . . . . . . . . . . . . 5
4. Procedure at the Receiving Side . . . . . . . . . . . . . . . . 5 4. Procedure at the Receiving Side . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The cryptographic authentication mechanisms specified in BFD The cryptographic authentication mechanisms specified in [RFC5880]
[RFC5880] defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) algorithms to
algorithms to authenticate BFD packets. The recent escalating series authenticate BFD packets. The recent escalating series of attacks on
of attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise concerns about
concerns about their remaining useful lifetime [RFC6151] [RFC6194]. their remaining useful lifetime [RFC6151] [RFC6194].
These attacks may not necessarily result in direct vulnerabilities These attacks may not necessarily result in direct vulnerabilities
for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes
because the colliding message may not correspond to a syntactically because the colliding message may not correspond to a syntactically
correct BFD protocol packet. Regardless, there is a need felt to correct BFD protocol packet. Regardless, there is a need felt to
deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor
of stronger digest algorithms. of stronger digest algorithms.
This document adds support for Secure Hash Algorithms (SHA) defined This document adds support for Secure Hash Algorithms (SHA) defined
in the US NIST Secure Hash Standard (SHS), which is defined by NIST in the US NIST Secure Hash Standard (SHS), which is defined by NIST
FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA- FIPS 180-2 [FIPS-180-2]. [FIPS-180-2] includes SHA-1, SHA-224, SHA-
256, SHA-384, and SHA-512. The HMAC authentication mode defined in 256, SHA-384, and SHA-512. The HMAC authentication mode defined in
NIST FIPS 198 is used [FIPS-198]. NIST FIPS 198 is used [FIPS-198].
It is believed that [RFC2104] is mathematically identical to It is believed that the HMAC algorithms defined in [RFC2104] is
[FIPS-198] and it is also believed that algorithms in [RFC6234] are mathematically identical to their counterparts in [FIPS-198] and it
mathematically identical to [FIPS-180-2]. is also believed that algorithms in [RFC6234] are mathematically
identical to those defined in [FIPS-180-2].
It should be noted that if SHA-1 is used in the HMAC construction It should be noted that the collision attacks currently known against
then collision attacks currently known against SHA-1 do not apply. SHA-1 do not apply when SHA-1 is used in the HMAC construction. NIST
The new attacks on SHA-1 have no impact on the security of will be supporting HMAC-SHA-1 even after 2010 [NIST-HMAC-SHA] ,
HMAC-SHA-1. NIST will be supporting HMAC-SHA-1 even after 2010 whereas it would be dropping support for SHA-1 in digital signatures.
[NIST-HMAC-SHA] , whereas it would be dropping support for SHA-1 in
digital signatures.
[I-D.ietf-bfd-generic-crypto-auth] defines new authentication types - [I-D.ietf-bfd-generic-crypto-auth] defines new authentication types -
Generic Cryptographic Authentication and Generic Meticulous Generic Cryptographic Authentication and Generic Meticulous
Cryptographic Authenticationan extension that can be used for Cryptographic Authentication that can be used for carrying the
carrying the authentication digests defined in this document. authentication digests defined in this document.
Implementations of this specification must include support for at Implementations of this specification must include support for at
least HMAC-SHA-256 and may include support for either of HMAC-SHA-384 least HMAC-SHA-256 and may include support for either of HMAC-SHA-384
or HMAC-SHA-512. or HMAC-SHA-512.
2. Cryptographic Aspects 2. Cryptographic Aspects
In the algorithm description below, the following nomenclature, which In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used: is consistent with [FIPS-198], is used:
skipping to change at page 4, line 36 skipping to change at page 4, line 36
If the Authentication Key (K) is L octets long, then Ko is equal to 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 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 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 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 appended to the end of the Authentication Key (K) such that Ko is L
octets long. octets long.
(2) First Hash (2) First Hash
First, the Authentication Data field in the Generic Authentication First, the Authentication Data field in the Generic Authentication
Section is filled with the value Apad and the Authentication Type Section is filled with the value of Apad and the Authentication Type
field is set to 6 or 7 depending upon which Authentication Type is field is set to 6 or 7 depending upon which Authentication Type is
being used. The Sequence Number field MUST be set to being used. The Sequence Number field MUST be set to
bfd.XmitAuthSeq. bfd.XmitAuthSeq.
Then, a first hash, also known as the inner hash, is computed as Then, a first hash, also known as the inner hash, is computed as
follows: follows:
First-Hash = H(Ko XOR Ipad || (BFD Packet)) First-Hash = H(Ko XOR Ipad || (BFD Packet))
(3) Second Hash T (3) Second Hash T
skipping to change at page 5, line 29 skipping to change at page 5, line 29
select an appropriate BFD SA from its local key table if a keyed select an appropriate BFD SA from its local key table if a keyed
digest for the packet is required. If no appropriate SA is digest for the packet is required. If no appropriate SA is
avaliable, the BFD packet MUST be discarded. avaliable, the BFD packet MUST be discarded.
If an appropriate SA is avaliable, the device then derives the key If an appropriate SA is avaliable, the device then derives the key
and the associated authentication algorithm (HMAC-SHA-256, HMAC-SHA- and the associated authentication algorithm (HMAC-SHA-256, HMAC-SHA-
384 or HMAC-SHA-512) from the SA. 384 or HMAC-SHA-512) from the SA.
The device then start performing the operations illustrated in The device then start performing the operations illustrated in
Section 2. Before the authentication data is computed, the device Section 2. Before the authentication data is computed, the device
MUST fill the Auth Type and the Auth length . The Sequence Number MUST fill the Auth Type field and the Auth length field. The
field MUST be set to bfd.XmitAuthSeq. Sequence Number field MUST be set to bfd.XmitAuthSeq.
The value of Auth Length in the generic authentication section is The value of Auth Length in the generic authentication section is
various according to different authentication algorithms being used. various according to different authentication algorithms being used.
Specifically, the value is 40 for HMAC-SHA-256, 56 for HMAC-SHA-384 Specifically, the value is 40 for HMAC-SHA-256, 56 for HMAC-SHA-384,
and 72 for HMAC- SHA-512. and 72 for HMAC- SHA-512.
The Key ID is then filled. The Key ID is then filled.
After that, the authentication data is computed as illustrated in After that, the authentication data is computed as illustrated in
Section 3. Section 2.
The result of the authentication algorithm is placed in the The result of the authentication algorithm is placed in the
Authentication data, following the Key ID. Authentication data, following the Key ID.
4. Procedure at the Receiving Side 4. Procedure at the Receiving Side
Upon receiving a BFD packet with an generic authentication section Upon receiving a BFD packet with an generic authentication section
appended, the receiving device needs to find an appropriate BFD SA appended, a device needs to find an appropriate BFD SA from its local
from its local key table to verify the packet. The SA is located by key table to verify the packet. The SA is located by the Key ID in
the Key ID in the authentication section of the packet. the authentication section of the packet.
If there is no SA is associated with the Key ID, the received packet If there is no SA is associated with the Key ID, the received packet
MUST be discarded. MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For If bfd.AuthSeqKnown is 1, the Sequence Number field is examined. For
Cryptographic Authentication, if the Sequence Number lies outside of Cryptographic Authentication, if the Sequence Number lies outside of
the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)
inclusive (when treated as an unsigned 32 bit circular number space), inclusive (when treated as an unsigned 32 bit circular number space),
the received packet MUST be discarded. For Meticulous Cryptographic the received packet MUST be discarded. For Meticulous Cryptographic
Authentication, if the Sequence Number lies outside of the range of Authentication, if the Sequence Number lies outside of the range of
bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space, the received treated as an unsigned 32 bit circular number space, the received
packet MUST be discarded. packet MUST be discarded.
Authentication Algorithm dependent processing, needs to be performed, An authentication Algorithm dependent process then needs to be
using the algorithm specified by the appropriate BFD SA for the performed by using the algorithm specified by the appropriate BFD SA
received packet. for the received packet.
Before the device performs any processing, it needs to save the Before the device performs any processing, it needs to save the
values of the Authentication Value field. content of the Authentication Value field and set the Authentication
Value field with Apad.
The device then needs to set the Authentication Value field with Apad The device then computes the authentication data as illustrated in
before the authentication data is computed. The calculated data is Section 2. The calculated data is compared with the received
compared with the received authentication data in the packet. authentication data in the packet.
The packet MUST be discarded if the calculated data and the received The packet MUST be discarded if the calculated and the received
authentication data do not match each other. In such a case, an authentication data do not match. In this case, an error event
error event SHOULD be logged. SHOULD be logged.
A BFD implementation MAY be in a transition mode where it includes A BFD implementation MAY be in a transition mode where it includes
CRYPTO_AUTH or the MET_CRYPTO_AUTH information in packets but never CRYPTO_AUTH or the MET_CRYPTO_AUTH information in packets but never
verifies it. This is provided as a transition aid for networks in verifies it. This is provided as a transition aid for networks in
the process of migrating to the new CRYPTO_AUTH and MET_CRYPTO_AUTH the process of migrating to the new CRYPTO_AUTH and MET_CRYPTO_AUTH
based authentication schemes. based authentication schemes.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
skipping to change at page 8, line 40 skipping to change at page 8, line 43
draft-ietf-karp-design-guide-10 (work in progress), draft-ietf-karp-design-guide-10 (work in progress),
December 2011. December 2011.
[MD5-attack] [MD5-attack]
Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for
Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", Hash Functions MD4, MD5, HAVAL-128 and RIPEMD",
August 2004. August 2004.
[NIST-HMAC-SHA] [NIST-HMAC-SHA]
National Institute of Standards and Technology, Available National Institute of Standards and Technology, Available
online at online at http://csrc.nist.gov/groups/ST/hash/policy.html,
http://csrc.nist.gov/groups/ST/hash/policy.html, "NIST's "NIST's Policy on Hash Functions", 2006.
Policy on Hash Functions", 2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
 End of changes. 21 change blocks. 
44 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/