Internet DRAFT - draft-bhatia-manral-white-ospf-hmac-sha
draft-bhatia-manral-white-ospf-hmac-sha
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
Network Working Group Manav Bhatia
Internet Draft Alcatel-Lucent
Expires: August 2007 Vishwas Manral
IP Infusion
Russ White
Michael Barnes
Cisco Systems
OSPF HMAC Cryptographic Authentication
draft-bhatia-manral-white-ospf-hmac-sha-03.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 describes a mechanism for authenticating OSPF packets
by making use of the HMAC algorithm in conjunction with the SHA
family of cryptographic hash functions. Because of the way the hash
functions are used in HMAC construction, the collision attacks
currently known against SHA-1 do not apply.
This will be done in addition to the already documented
authentication schemes described in the base specification.
Conventions used in this document
Bhatia, Manral and White [Page 1]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
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]
Table of Contents
1. Introduction...................................................2
2. Standard OSPF Authentication...................................3
3. OSPF Security Association......................................4
4. Using New Algorithms for OSPF Authentication...................5
5. Authentication Procedures......................................5
5.1 Message Generation at the Sending Side.....................5
5.2 Message Verification at the Receiving Side.................6
6. Algorithm Dependent Processing.................................7
7. Security Considerations........................................7
8. Backwards Compatibility Considerations.........................8
9. IANA Considerations............................................8
10. Acknowledgements..............................................8
11. References....................................................8
11.1 Normative References......................................8
11.2 Informative References....................................8
12. Author's Addresses............................................9
1. Introduction
OSPF as defined in [RFC2328] includes three different types of
authentication schemes: Null authentication, simple password and
cryptographic authentication. NULL authentication is akin to having
no authentication at all. 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 OSPF domain.
In the cryptographic authentication scheme, the OSPF routers on a
common network/subnet 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 isn't good enough as there have recently been reports about
attacks on the collision resistance properties of MD5 [MD5-attack]
and SHA-1 [RFC3174][SHA-1-attack] hash functions. MD5CRK, was a
distributed computing project to break the MD5 hash algorithm in a
short period of time. The project closed down with the publication of
the paper [MD5-attack].
It was discovered that collisions can be found in MD5 algorithm in
less than 24 hours, making MD5 very insecure. Further research has
verified this result and shown other ways to find collisions in MD5
Bhatia, Manral and White [Page 2]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
hashes. We thus need to move away from MD5 towards more complex and
difficult to break hash algorithms.
This document therefore adds support for HMAC [RFC2104] construction
to be used for authenticating OSPF packets. 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. Because of the way the hash
functions are used in HMAC construction, the collision attacks
currently known against MD5 and SHA-1 do not apply.
By definition, HMAC requires a cryptographic hash function. We
propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and
SHA-512 [NIST] for this purpose to authenticate the OSPF packets.
This document explains how HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256,
HMAC-SHA-384 and HMAC-SHA-512 shall work with OSPF.
2. Standard OSPF Authentication
Figure 1 shows the standard 24 byte OSPF header as specified in
[RFC2328]. The header includes an authentication type field (AuType)
that identifies the authentication procedure to be used for the
packet. Authentication is a 64 bit field of data to be used by the
appropriate authentication scheme (determined by the type field).
Authentication types 0, 1 and 2 are defined by [RFC2328] to be used
for Null Authentication, Simple Password and Cryptographic
authentication.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Bhatia, Manral and White [Page 3]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Figure 2 shows the way the authentication data MUST be filled in the
OSPF header if the AuType is set to 2. The first 16 bits are set
reserved to zero.
Cryptographic authentication as specified in [RFC2328] allows for
algorithms other than MD5 to be used without altering the protocol
packets. Note the original definition of the Key ID field:
This field identifies the algorithm and secret key used to create
the message digest appended to the OSPF packet. Key Identifiers are
unique per-interface (or equivalently, per-subnet).
Also note step (6) in section D.4.3 "The authentication algorithm to
be used in calculating the digest is indicated by the key itself."
It is clear that the fields defined in section D.3 of [RFC2328] are
adequate for the use of cryptographic algorithms other than MD5. The
only actual difference in the OSPF protocol packets is that the HMAC
is appended to the original OSPF packet instead of the MD5 digest.
3. OSPF Security Association
This document defines an OSPF Security Association (SA) as a set of
shared parameters between any two legitimate OSPF speakers.
Parameters associated with an OSPF SA:
Key ID – This is an 8 bit unsigned value which is used to uniquely
identify an OSPF SA and would be configured by the administrator. 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 the key rollover convenient and an implementation
can choose to associate an age with each Key ID and can automatically
use the next key when the former expires. Discussion of how this
should be done is beyond the scope of this document.
Bhatia, Manral and White [Page 4]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
When doing a key rollover the sender will use a different Key ID
(which is shared with the receiver). As the receiver will have the
key with the same Key ID it can use that key for calculating the
hash. The receiver does not need to compute the hash with multiple
keys which are valid at that instant. Thus using the Key ID can
safeguard against potential DoS attacks during the key rollover.
Authentication Algorithm – This information is never sent over the
wire and it signifies the authentication algorithm to be used with
the OSPF SA. Valid values are MD5, HMAC-SHA-1, HMAC-SHA-224, HMAC-
SHA-256, HMAC-SHA-384 and HMAC-SHA-512
Authentication Key – This value is never sent on the wire and denotes
the key associated with the OSPF SA. The length of this key is
variable and depends upon the authentication algorithm specified by
the OSPF SA.
4. Using New Algorithms for OSPF Authentication
The use of the cryptographic authentication fields as specified in
[RFC2328] is essentially unchanged, but the definitions are updated
in this document.
The Key ID uniquely identifies an OSPF SA which gives the algorithm
and the secret key used to create the HMAC appended to the OSPF
packet.
Auth Data Len is the length in octets of the HMAC appended to the
OSPF packet. It is set to 20 for HMAC-SHA-1, 28 for HMAC-SHA-224, 32
for HMAC-SHA-256, 48 for HMAC-SHA-384 and 64 for HMAC-SHA-512.
The HMAC is not considered a part of the OSPF message, and is not
accounted for in the Packet Length field of the OSPF header. But as a
part of the overall IP packet payload, it is accounted for in the
Total Length field of the IP packet header
Cryptographic sequence number is an unsigned 32 bit non-decreasing
sequence number, which is used to protect against replay attacks.
5. Authentication Procedures
This section details the procedures to be followed by the OSPF
sending and the receiving sides.
5.1 Message Generation at the Sending Side
When using HMAC cryptographic authentication the sender chooses the
secret key by looking at the active SA and modifies the OSPF packet
as follows:
Bhatia, Manral and White [Page 5]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
[1] The AuType field in the OSPF header is set to 2.
[2] The checksum field in the standard OSPF header is set to 0.
[3] The Key ID is set to the current active key.
[4] The Auth Data Len is set to the length in bytes of the HMAC that
will be appended to the OSPF packet. This value depends upon the
authentication algorithm that is being used. Refer to Section 3
for these values.
[5] The non decreasing Cryptographic sequence number is filled.
[6] The HMAC is then calculated and appended to the OSPF packet. The
authentication algorithm is given by the active SA. Input to the
authentication algorithm consists of the OSPF packet and the
secret key. Refer to section 5 for algorithm dependent
processing.
5.2 Message Verification at the Receiving Side
All OSPF packets received on an interface must be authenticated. The
following steps are followed:
[1] The receiver determines the active SA by looking at the Key ID
field from the standard OSPF packet header.
Authentication algorithm dependent processing needs to be
performed, using the algorithm specified by the appropriate OSPF
SA for the received packet.
[2] The packet is rejected if the cryptographic sequence number is
less than the cryptographic sequence number stored in the sending
neighbor's data structure.
[3] Before performing any processing an implementation MUST save the
value of the received HMAC.
[4] The HMAC is calculated based on the authentication algorithm and
the secret key that was derived from the active SA (derived from
the incoming key). Refer to section 5 for algorithm dependent
processing.
[5] The calculated and the received HMACs are compared. The packet is
only accepted if the two match. If there is a mismatch then the
packet is discarded and a security even SHOULD be logged.
Bhatia, Manral and White [Page 6]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
An implementation MAY have a transition mode where it includes HMAC-
SHA authentication information in the OSPF packets but does not
verify the HMAC-SHA information. This is provided as a transition aid
for networks in the process of migrating to HMAC-SHA1, HMAC-224,
HMAC-256, HMAC-SHA-384 and HMAC-SHA-512 based authentication schemes.
Similarly, implementations not supporting these authentication
schemes MAY accept packets that contain HMAC-SHA authentication data.
6. Algorithm Dependent Processing
HMAC is a mechanism for message authentication using cryptographic
hash functions and has been explained in depth in [RFC2104]. The
reader is suggested to go through it to clearly understand how it
works.
The HMAC algorithm takes key K and text T as the input. The block
size B is 64 octets for SHA-1, SHA-224 and SHA-256 and is 128 octets
for SHA-384 and SHA-512
The Key K is the secret key that has been chosen and text T is the
OSPF packet that needs to be authenticated.
[HMAC-SHA] provides open source code to perform these hash functions
for the internet community. The sample code supports input strings of
arbitrary bit length, as opposed to [RFC2104] which assumes the text
T to be a multiple of 8 octets. Similarly, the SHA-1 sample code from
[RFC3174] has been updated to handle input strings of arbitrary bit
lengths.
7. Security Considerations
The document proposes extensions to OSPF which would make it more
secure than what it is today. It does not provide confidentiality as
a routing protocol contains information that does not need to be kept
secret. It does, however, provide means to authenticate the sender of
the packets which is of interest to us.
The cryptographic sequence numbers used to prevent replay attacks can
be exploited. These are initialized to zero when forming an adjacency
with a newly discovered neighbor, or when a router comes up. A
malicious router can store the OSPF packets from the previous session
and can replay them. This can lead to loops and blackholes [CRYPTO].
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.
Bhatia, Manral and White [Page 7]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
To ensure greater security, the keys used must be changed
periodically and implementations MUST be able to store and use more
than one key at the same time.
There are certain hash functions that require all the fields of the
message text T to be filled with non-zero values. Any extension using
such hash functions to calculate the HMAC MUST fill the checksum
field with some predefined non-zero random number.
8. Backwards Compatibility Considerations
No changes are made to the operation of the OSPF protocol to
implement cryptographic authentication algorithms as described in
this document. Additionally, cryptographic authentication using MD5
is unchanged. So no backward compatibility issues are introduced by
this document.
9. IANA Considerations
This document includes no request to IANA.
10. Acknowledgements
We would like to thank Acee Lindem for his comments on the draft.
11. References
11.1 Normative References
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119
[RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997
[NIST] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002
[HMAC-SHA] Eastlake 3rd, D., Hansen, T., “US Secure Hash Algorithms
(SHA and HMAC-SHA)”, Work in Progress
11.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
Bhatia, Manral and White [Page 8]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
[RFC3174] Eastlake 3rd, D.,Jones, P., "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[SHA-1-attack] Wang, X. et al., "Collision Search Attacks on SHA1",
February 2005,
http://theory.csail.mit.edu/~yiqun/shanote.pdf
[CRYPTO] Manral, V. et al., "Issues with existing Cryptographic
Protection Methods for Routing Protocols", Work in
Progress, February 2006
12. 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
Russ White
Cisco Systems
RTP North Carolina
USA
Email: riw@cisco.com
Michael Barnes
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
Email: mjbarnes@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
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
Bhatia, Manral and White [Page 9]
Internet Draft OSPF HMAC Cryptographic Authentication February 2007
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, Manral and White [Page 10]
