draft-ietf-bfd-hmac-sha-02.txt   draft-ietf-bfd-hmac-sha-03.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: April 22, 2013 Alcatel-Lucent Expires: October 20, 2013 Alcatel-Lucent
V. Manral V. Manral
Hewlett-Packard Co. Hewlett-Packard Co.
October 19, 2012 April 18, 2013
Authenticating BFD using HMAC-SHA-2 procedures Authenticating BFD using HMAC-SHA-2 procedures
draft-ietf-bfd-hmac-sha-02 draft-ietf-bfd-hmac-sha-03
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 described mechanism 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].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 22, 2013. This Internet-Draft will expire on October 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 3
3. Procedures at the Sending Side . . . . . . . . . . . . . . . . 5 3. Procedures at the Sending Side . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The cryptographic authentication mechanisms specified in [RFC5880] The cryptographic authentication mechanisms specified in [RFC5880]
defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) algorithms to defines MD5 [RFC1321] and Secure Hash Algorithm (SHA-1) algorithms to
authenticate BFD packets. The recent escalating series of attacks on authenticate BFD packets. The recent escalating series of attacks on
MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise concerns about MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise 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,
256, SHA-384, and SHA-512. The HMAC authentication mode defined in SHA-256, SHA-384, and SHA-512. The HMAC authentication mode defined
NIST FIPS 198 is used [FIPS-198]. in NIST FIPS 198 is used [FIPS-198].
It is believed that the HMAC algorithms defined in [RFC2104] is It is believed that the HMAC algorithms defined in [RFC2104] is
mathematically identical to their counterparts in [FIPS-198] and it mathematically identical to their counterparts in [FIPS-198] and it
is also believed that algorithms in [RFC6234] are mathematically is also believed that algorithms in [RFC6234] are mathematically
identical to those defined in [FIPS-180-2]. identical to those defined in [FIPS-180-2].
It should be noted that the collision attacks currently known against It should be noted that the collision attacks currently known against
SHA-1 do not apply when SHA-1 is used in the HMAC construction. NIST SHA-1 do not apply when SHA-1 is used in the HMAC construction. NIST
will be supporting HMAC-SHA-1 even after 2010 [NIST-HMAC-SHA] , will be supporting HMAC-SHA-1 even after 2010 [NIST-HMAC-SHA] ,
whereas it would be dropping support for SHA-1 in digital signatures. whereas it would be dropping support for SHA-1 in digital signatures.
skipping to change at page 4, line 27 skipping to change at page 4, line 6
Ipad is the hexadecimal value 0x36 repeated B times. Ipad is the hexadecimal value 0x36 repeated B times.
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times. Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
(1) Preparation of the Key (1) Preparation of the Key
In this application, Ko is always L octets long. In this application, Ko is always L octets long.
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 of 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
skipping to change at page 5, line 24 skipping to change at page 5, line 6
wire. wire.
3. Procedures at the Sending Side 3. Procedures at the Sending Side
Before a BFD device sends a BFD packet out, the device needs to Before a BFD device sends a BFD packet out, the device needs to
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-
384 or HMAC-SHA-512) from the SA. SHA-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 field and the Auth length field. The MUST fill the Auth Type field and the Auth length field. The
Sequence Number 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.
skipping to change at page 8, line 4 skipping to change at page 7, line 28
180-2, "The Keyed-Hash Message Authentication Code 180-2, "The Keyed-Hash Message Authentication Code
(HMAC)", August 2002. (HMAC)", August 2002.
[FIPS-198] [FIPS-198]
National Institute of Standards and Technology, FIPS PUB National Institute of Standards and Technology, FIPS PUB
198, "The Keyed-Hash Message Authentication Code (HMAC)", 198, "The Keyed-Hash Message Authentication Code (HMAC)",
March 2002. March 2002.
[I-D.ietf-bfd-generic-crypto-auth] [I-D.ietf-bfd-generic-crypto-auth]
Bhatia, M., Manral, V., and D. Zhang, "BFD Generic Bhatia, M., Manral, V., and D. Zhang, "BFD Generic
Cryptographic Authentication", Cryptographic Authentication", draft-ietf-bfd-generic-
draft-ietf-bfd-generic-crypto-auth-02 (work in progress), crypto-auth-03 (work in progress), October 2012.
June 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010. Protocols", RFC 6039, October 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
skipping to change at page 8, line 32 skipping to change at page 8, line 7
7.2. Informative References 7.2. Informative References
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996.
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes", 1996. CryptoBytes", 1996.
[I-D.ietf-karp-design-guide] [I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", Routing Protocols (KARP) Design Guidelines", draft-ietf-
draft-ietf-karp-design-guide-10 (work in progress), 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
August 2004. 2004.
[NIST-HMAC-SHA] [NIST-HMAC-SHA]
National Institute of Standards and Technology, Available National Institute of Standards and Technology, Available
online at http://csrc.nist.gov/groups/ST/hash/policy.html, online at http://csrc.nist.gov/groups/ST/hash/policy.html,
"NIST's Policy on Hash Functions", 2006. "NIST's 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
February 1997. 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.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007. Authentication", RFC 4822, February 2007.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
skipping to change at page 9, line 37 skipping to change at page 9, line 11
Full SHA-1", 2005. Full SHA-1", 2005.
[SHA-1-attack2] [SHA-1-attack2]
Wang, X., Yao, A., and F. Yao, "New Collision Search for Wang, X., Yao, A., and F. Yao, "New Collision Search for
SHA-1", 2005. SHA-1", 2005.
Authors' Addresses Authors' Addresses
Dacheng Zhang Dacheng Zhang
Huawei Huawei
Beijing, Beijing
China China
Email: zhangdacheng@huawei.com Email: zhangdacheng@huawei.com
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore 560045 Bangalore 560045
India India
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
 End of changes. 15 change blocks. 
35 lines changed or deleted 33 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/