draft-ietf-bfd-hmac-sha-00.txt   draft-ietf-bfd-hmac-sha-01.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: July 14, 2012 Alcatel-Lucent Expires: January 4, 2013 Alcatel-Lucent
V. Manral V. Manral
Hewlett-Packard Co. Hewlett-Packard Co.
January 11, 2012 July 03, 2012
Authenticating BFD using HMAC-SHA-2 procedures Authenticating BFD using HMAC-SHA-2 procedures
draft-ietf-bfd-hmac-sha-00 draft-ietf-bfd-hmac-sha-01
Abstract Abstract
This document describes how Hashed Message Authentication Mode (HMAC) This document describes the mechanism to authenticate Bidirectional
in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can Forwarding Detection (BFD) protocol packets using Hashed Message
be used for authenticating Bidirectional Forwarding Detection (BFD). Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512
It uses the Generic Cryptographic Authentication and Generic algorithms. The mechanism described uses the Generic Cryptographic
Meticulous Cryptographic Authentication sections to carry the Authentication and Generic Meticulous Cryptographic Authentication
authentication data. This updates, but does not supercede, the sections to carry the authentication data. This document updates,
cryptographic authentication mechanism specified in RFC 5880. but does not supercede, the cryptographic authentication mechanism
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
skipping to change at page 1, line 45 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 July 14, 2012. This Internet-Draft will expire on January 4, 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
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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 [FIPS- It is believed that [RFC2104] is mathematically identical to
198] and it is also believed that algorithms in [RFC6234] are [FIPS-198] and it is also believed that algorithms in [RFC6234] are
mathematically identical to [FIPS-180-2]. mathematically identical to [FIPS-180-2].
It should be noted that if SHA-1 is used in the HMAC construction It should be noted that if SHA-1 is used in the HMAC construction
then collision attacks currently known against SHA-1 do not apply. then collision attacks currently known against SHA-1 do not apply.
The new attacks on SHA-1 have no impact on the security of The new attacks on SHA-1 have no impact on the security of
HMAC-SHA-1. NIST will be supporting HMAC-SHA-1 even after 2010 HMAC-SHA-1. NIST will be supporting HMAC-SHA-1 even after 2010
[NIST-HMAC-SHA] , whereas it would be dropping support for SHA-1 in [NIST-HMAC-SHA] , whereas it would be dropping support for SHA-1 in
digital signatures. digital signatures.
[I-D.ietf-bfd-generic-crypto-auth] defines new authentication types - [I-D.ietf-bfd-generic-crypto-auth] defines new authentication types -
skipping to change at page 4, line 22 skipping to change at page 4, line 22
the hash, measured in octets rather than bits. the hash, measured in octets rather than bits.
XOR is the exclusive-or operation. XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times. Opad is the hexadecimal value 0x5c repeated B times.
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 Apad and the Authentication Type Section is filled with the value 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
Then a second hash, also known as the outer hash, is computed as Then a second hash, also known as the outer hash, is computed as
follows: follows:
Second-Hash = H(Ko XOR Opad || First-Hash) Second-Hash = H(Ko XOR Opad || First-Hash)
(4)Result (4) Result
The resultant Second-Hash becomes the Authentication Data that is The resultant Second-Hash becomes the Authentication Data that is
sent in the Authentication Data field of the BFD Authentication sent in the Authentication Data field of the BFD Authentication
Section. The length of the Authentication Data field is always Section. The length of the Authentication Data field is always
identical to the message digest size of the specific hash function H identical to the message digest size of the specific hash function H
that is being used. that is being used.
This also means that the use of hash functions with larger output This also means that the use of hash functions with larger output
sizes will also increase the size of BFD Packet as transmitted on the sizes will also increase the size of BFD Packet as transmitted on the
wire. wire.
skipping to change at page 7, line 29 skipping to change at page 7, line 29
by the cryptographic authentication option depends completely on the by the cryptographic authentication option depends completely on the
strength of the cryptographic algorithm and cryptographic mode in strength of the cryptographic algorithm and cryptographic mode in
use, the strength of the key being used, and the correct use, the strength of the key being used, and the correct
implementation of the security mechanism in all communicating BFD implementation of the security mechanism in all communicating BFD
implementations. Accordingly, the use of high assurance development implementations. Accordingly, the use of high assurance development
methods is recommended. It also requires that all parties maintain methods is recommended. It also requires that all parties maintain
the secrecy of the shared secret key. [RFC4086] provides guidance on the secrecy of the shared secret key. [RFC4086] provides guidance on
methods for generating cryptographically random bits. methods for generating cryptographically random bits.
The value Apad is used here primarily for consistency with IETF The value Apad is used here primarily for consistency with IETF
specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822], specifications for HMAC-SHA authentication for RIPv2 [RFC4822], IS-IS
IS-IS SHA and OSPF SHA [RFC5709]. [RFC5310] and OSPFv2 [RFC5709].
7. References 7. References
7.1. Normative References 7.1. Normative References
[FIPS-180-2] [FIPS-180-2]
National Institute of Standards and Technology, FIPS PUB National Institute of Standards and Technology, FIPS PUB
180-3, "Secure Hash Standard (SHS)", October 2008. 180-2, "The Keyed-Hash Message Authentication Code
(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-crypto-auth-00 (work in progress), draft-ietf-bfd-generic-crypto-auth-02 (work in progress),
October 2011. 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 9, line 41 skipping to change at page 9, line 41
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 Bangalore 560045
India India
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Vishwas Manral Vishwas Manral
Hewlett-Packard Co. Hewlett-Packard Co.
19111 Pruneridge Ave. 19111 Pruneridge Ave.
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Email: vishwas.manral@hp.com Email: vishwas.manral@hp.com
 End of changes. 15 change blocks. 
24 lines changed or deleted 25 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/