Internet Draft BFD Generic Cryptographic Authentication November 2009
Network Working Group Manav Bhatia
Internet Draft Alcatel-Lucent
Intended Status: Proposed Standard Vishwas Manral
Expires: April 2009 IP Infusion
BFD Generic Cryptographic Authentication
draft-bhatia-bfd-crypto-auth-00.txt
Status of this Memo
Distribution of this memo is unlimited.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes an extension for Bidirectional Forwarding
Detection (BFD) to allow the use of any cryptographic authentication
algorithm in addition to the already documented authentication
schemes, described in the base specification.
Although this document has been written specifically to introduce two
new Authentication types it describes how BFD can use Hashed Message
Authentication Code (HMAC) construct along with the Secure Hash
algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions
to authenticate the control packets.
The method described in this document is generic and can be used to
extend BFD to support any cryptographic hash function in the future.
Bhatia and Manral Expires April 2009 [Page 1]
Internet Draft BFD Generic Cryptographic Authentication November 2009
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [KEYWORDS]
Contents
1. Introduction...................................................2
2. BFD Security Association.......................................3
3. Authentication Procedures......................................4
3.1 Cryptographic Authentication and Meticulous Cryptographic
Authentication.................................................4
3.2 Packet Encoding............................................5
3.3 Cryptographic Aspects......................................6
3.4 Procedures at the Sending Side.............................7
3.5 Procedure at the Receiving Side............................8
4. Security Considerations........................................8
5. Acknowledgements...............................................9
6. IANA Considerations............................................9
7. References.....................................................9
7.1 Normative References.......................................9
7.2 Informative References....................................10
8. Author's Addresses............................................10
1. Introduction
Bidirectional Forwarding Detection (BFD) [BFD-BASE] specification
includes five different types of authentication schemes: Simple
Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1 and
Meticulous SHA-1. In the simple password scheme of authentication,
the passwords are exchanged in the clear text on the network and
anyone with physical access to the network can learn the password and
compromise the security of the BFD domain.
In Keyed MD5 and Meticulous Keyed MD5, the BFD routers share a secret
key which is used to generate a keyed MD5 digest for each packet and
a monotonically increasing sequence number scheme is used to prevent
replay attacks.
This isnt good enough as there have been recent reports about attacks
on MD5 which raises concerns about the remaining useful lifetime of
this scheme. Specifically, the researchers have been able to develop
algorithms that can compute hash collisions for some applications of
MD5 [MD5-attack] [Dobb96a, Dobb96b].
Bhatia and Manral Expires April 2009 [Page 2]
Internet Draft BFD Generic Cryptographic Authentication November 2009
It was discovered that collisions can be found in MD5 algorithm in
less than 24 hours, making MD5 insecure. Further research has
verified this result and shown other ways to find collisions in MD5
hashes.
It should however be noted that these attacks may not necessarily
result in direct vulnerabilities in Keyed-MD5 as used in BFD
authentication purposes, because the colliding message may not
necessarily be a syntactically correct protocol packet. However,
there is a need felt to move away from MD5 towards more complex and
difficult to break hash algorithms.
In Keyed SHA-1 and Meticulous SHA-1, the BFD routers share a secret
key which is used to generate a keyed SHA-1 digest for each packet
and a monotonically increasing sequence number scheme is used to
prevent replay attacks.
Like MD5 there have been reports of attacks on SHA-1 [SHA-1-attack1]
[SHA-1-attack2]. Such attacks do not mean that all the protocols
using SHA-1 for authentication are at risk. However, it does mean
that SHA-1 should be replaced as soon as possible and should not be
used for new applications.
However, if SHA-1 is used in the HMAC [RFC2104] construction then
collision attacks currently known against SHA-1 do not apply. The new
attacks on SHA-1 have no impact on the security of HMAC-SHA-1.
HMAC can be used, without modifying any hash function, for
calculating and verifying the message authentication values. It
verifies both the data integrity and the authenticity of a message.
This document proposes two new authentication types - the
cryptographic authentication (CRYPTO_AUTH) and the meticulous
cryptographic authentication (MET_ CRYPTO_AUTH). These can be used to
specify any authentication algorithm for authenticating and verifying
the BFD packets. In addition to this, this memo also explains how
HMAC-SHA authentication can be used for BFD.
By definition, HMAC requires a cryptographic hash function. We
propose to use any one of SHA-1, SHA-256, SHA-384 and SHA-512 for
this purpose to authenticate the BFD packets.
2. BFD Security Association
A BFD Security Association (SA) contains a set of shared parameters
between any two legitimate BFD routers.
Parameters associated with a BFD SA:
Bhatia and Manral Expires April 2009 [Page 3]
Internet Draft BFD Generic Cryptographic Authentication November 2009
O Authentication Key ID : This is a two octet unsigned integer used
to uniquely identify the BFD SA, as manually configured by the
network operator. The receiver determines the active SA by looking at
this field in the incoming packet. The sender puts this Key ID based
on the active configuration.
Using key IDs makes changing keys while maintaining protocol
operation convenient. Each key ID specifies two independent parts,
the authentication protocol and the authentication key, as explained
below. Normally, an implementation would allow the network operator
to configure a set of keys in a key chain, with each key in the chain
having fixed lifetime. The actual operation of these mechanisms is
outside the scope of this document.
Note that each key ID can indicate a key with a different
authentication protocol. This allows multiple authentication
mechanisms to be used at various times without disrupting BFD
sessions, including the introduction of new authentication
mechanisms.
o Authentication Algorithm : This signifies the authentication
algorithm to be used with the IS-IS SA. This information is never
sent in cleartext over the wire. Because this information is not sent
on the wire, the implementer chooses an implementation specific
representation for this information. At present, the following values
are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384
and HMAC-SHA-512.
o Authentication Key : This value denotes the key associated with the
BFD SA. The length of this key is variable and depends upon the
authentication algorithm specified by the BFD SA. Operators MUST
ensure that this is never sent over the network in clear-text via any
protocol. Care should also be taken to ensure that the selected key
is unpredictable, avoiding any keys known to be weak for the
algorithm in use. [RFC4086] contains helpful information on both
key generation techniques and cryptographic randomness.
3. Authentication Procedures
3.1 Cryptographic Authentication and Meticulous Cryptographic
Authentication
The Authentication section is only present in the BFD packet if the
Authentication Present (A) bit is set in the header. The Auth Type in
the Authentication section is set to 6 to indicate the Cryptographic
Authentication is in use, and is set to 7, to indicate that the
meticulous cryptographic authentication is in use.
Bhatia and Manral Expires April 2009 [Page 4]
Internet Draft BFD Generic Cryptographic Authentication November 2009
Both the authentication types use a monotonically increasing sequence
number to protect the BFD session against reply attacks. The only
difference between the two types is that the sequence number is
occasionally incremented in the Cryptographic Authentication mode, as
against the Meticulous Cryptographic Authentication mode, where it is
incremented on every packet.
As a result of this a replay attack is possible till the next
sequence number is sent in the Cryptographic Authentication scheme.
3.2 Packet Encoding
A new authentication type, 6 or 7, indicating the cryptographic
authentication mechanism in use, is inserted in the first octet of
Authentication Section of the BFD control packet.
If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 6 (Cryptographic Authentication)
or 7 (Meticulous Cryptographic Authentication), the Authentication
Section has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Type
The Authentication Type, which in this case is 6 (Cryptographic
Authentication) or 7 (Meticulous Cryptographic Authentication).
Auth Len
Length of the Authentication Section.
Auth Key ID
The Authentication Key ID in use for this packet. This allows
multiple keys to be active simultaneously.
Sequence Number
Bhatia and Manral Expires April 2009 [Page 5]
Internet Draft BFD Generic Cryptographic Authentication November 2009
The Sequence Number for this packet. For Cryptographic Authentication
this value is incremented occasionally. For Meticulous Cryptographic
Authentication, this value is incremented for each successive packet
transmitted for a session.
Authentication Data
This field carries the digest computed by whatever Cryptographic
Authentication algorithm is being used to authenticate the BFD
control packet.
3.3 Cryptographic Aspects
In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used:
H is the specific hashing algorithm (e.g. SHA-256).
K is the password for the BFD packet.
Ko is the cryptographic key used with the hash algorithm.
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
(1)Preparation of the 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.
(2)First Hash
First, the Authentication Data field in the BFD Auth Section is
filled with the value Apad and the Authentication Type field is
set to 6 or 7 depending upon which Authentication Type is being
Bhatia and Manral Expires April 2009 [Page 6]
Internet Draft BFD Generic Cryptographic Authentication November 2009
used. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
Then, a first hash, also known as the inner hash, is computed
as follows:
First-Hash = H(Ko XOR Ipad || (BFD Packet))
(3)Second Hash
Then a second hash, also known as the outer hash, is computed
as follows:
Second-Hash = H(Ko XOR Opad || First-Hash)
(4)Result
The resultant Second-Hash becomes the Authentication Data that is
sent in the Authentication Data field of the BFD Authentication
Section. The length of the Authentication Data field is always
identical to the message digest size of the specific hash function
H that is being used.
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 wire.
3.4 Procedures at the Sending Side
An appropriate BFD SA is selected for use with an outgoing BFD
packet. This is done based on the active key at that instant. If BFD
is unable to find an active key, the BFD packet is discarded.
If BFD is able to find the active key, then the key gives the
authentication algorithm (HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256,
HMAC-SHA-384 or HMAC-SHA-512) that needs to be applied on the packet.
An implementation MUST fill the Auth Type and the Auth length before
the authentication data is computed. The Sequence Number field MUST
be set to bfd.XmitAuthSeq.
The Auth length in the Authentication section is set as per the
authentication algorithm that is being used. It is set to 28 for
HMAC-SHA-1, 36 for HMAC-SHA-224, 40 for HMAC-SHA-256, 56 for HMAC-
SHA-384 and 72 for HMAC-SHA-512.
The key ID is filled.
Bhatia and Manral Expires April 2009 [Page 7]
Internet Draft BFD Generic Cryptographic Authentication November 2009
The authentication data is computed as explained in the previous
section.
The result of the authentication algorithm is placed in the
Authentication data, following the key ID.
3.5 Procedure at the Receiving Side
The appropriate BFD SA is identified by looking at the Key ID from
the Authentication Section from the incoming BFD packet.
If the Auth Key ID field does not match the ID of a configured
authentication key, the received packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Cryptographic Authentication, if the Sequence Number lies outside of
the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)
inclusive (when treated as an unsigned 32 bit circular number space),
the received packet MUST be discarded. For Meticulous Cryptographic
Authentication, if the Sequence Number lies outside of the range of
bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space, the received
packet MUST be discarded.
Authentication Algorithm dependent processing, needs to be performed,
using the algorithm specified by the appropriate BFD SA for the
received packet.
Before an implementation performs any processing it needs to save the
values of the Authentication Value field.
It should then set the Authentication Value field with Apad before
the authentication data is computed. The calculated data is compared
with the received authentication data in the packet and the packet is
discarded if the two do not match. In such a case, an error event
SHOULD be logged.
An implementation MAY have a transition mode where it includes
CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but
does not verify this information. This is provided as a transition
aid for networks in the process of migrating to the new CRYPTO_AUTH
and MET_CRYPTO_AUTH based authentication schemes.
4. Security Considerations
The document proposes extensions to BFD which would make it more
secure than what it is today. It does not provide confidentiality as
BFD contains information that does not need to be kept secret. It
Bhatia and Manral Expires April 2009 [Page 8]
Internet Draft BFD Generic Cryptographic Authentication November 2009
does however, provide means to authenticate the sender of the packets
which is of interest to us.
The technology in this document provides an authentication mechanism
for BFD. The mechanism described here is not perfect and does not
need to be perfect. Instead, this mechanism represents a significant
increase in the work function of an adversary attacking the BFD
protocol, while not causing undue implementation, deployment, or
operational complexity.
There is a transition mode suggested where routers can ignore the
CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the
packets. The operator must ensure that this mode is only used when
migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication
scheme as this leaves the router vulnerable to an attack.
To ensure greater security, the keys used should be changed
periodically and implementations MUST be able to store and use more
than one key at the same time.
It should be noted that the cryptographic strength of the HMAC
depends upon the cryptographic strength of the underlying hash
function and on the size and quality of the key.
5. Acknowledgements
TBD
6. IANA Considerations
This document currently defines a value of 6 to be used to denote
Cryptographic Authentication mechanism for authenticating BFD control
packets and 7 for Meticulous Cryptographic Authentication.
7. References
7.1 Normative References
[BFD-BASE] "Bidirectional Forwarding Detection", Katz, D. and Ward,
D., Work in Progress, March 2008
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992
[RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997
Bhatia and Manral Expires April 2009 [Page 9]
Internet Draft BFD Generic Cryptographic Authentication November 2009
[FIPS-180-3] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-3, October 2008
[FIPS-198] US National Institute of Standards & Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002.
7.2 Informative References
[MD5-attack] Wang, X. et al., "Collisions for Hash Functions MD4,
MD5, HAVAL-128 and RIPEMD", August 2004,
http://eprint.iacr.org/2004/199
[Dobb96a] Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical
Report, 2 May 1996. (Presented at the Rump Session of
EuroCrypt 1996.)
[Dobb96b] Dobbertin, H, "The Status of MD5 After a Recent Attack",
CryptoBytes, Vol. 2, No. 2, Summer 1996.
[SHA-1-attack1] Wang, X. et. al., "Finding Collisions in the Full
SHA-1", Advances in Cryptology CRYPTO 05, pp. 17-36
[SHA-1-attack2] Wang, X. et. al., "New Collision Search for SHA-1",
Technical Report, August 2005 (Presented in the Rump
Session of CRYPTO 05)
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
8. Author's Addresses
Manav Bhatia
Alcatel-Lucent,
Bangalore, India
Email: manav@alcatel-lucent.com
Vishwas Manral
IP Infusion
Almora, Uttarakhand, India
Email: vishwas@ipinfusion.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
Bhatia and Manral Expires April 2009 [Page 10]
Internet Draft BFD Generic Cryptographic Authentication November 2009
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Bhatia and Manral Expires April 2009 [Page 11]