Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
Network Working Group Manav Bhatia
Internet Draft Lucent Technologies
Expires: August 2007 Vishwas Manral
IP Infusion
Russ White
Cisco Systems
IS-IS HMAC SHA Cryptographic Authentication
draft-ietf-isis-hmac-sha-01.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 to IS-IS to allow the use of any
cryptographic authentication algorithm in addition to the already
documented authentication schemes, described in the base
specification and RFC 3567.
Although this document has been written specifically for using MAC
construct along with the SHA family of cryptographic hash functions,
the method described in this document is generic and can be used to
extend IS-IS to support any cryptographic hash function in the
future.
Bhatia, Manral and White Expires August 2007 [Page 1]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
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]
1. Introduction
IS-IS [ISO] [RFC1195] specification allows for authentication of its
PDUs via the authentication TLV 10 that is carried as the part of the
PDU. The base spec has provision for only clear text passwords and
RFC 3567 [RFC3567] augments this to provide the capability to use
HMAC MD5 authentication for its PDUs.
The first octet of value field of TLV 10 specifies the type of
authentication to be carried out. Type 0 is reserved, Type 1
indicates a cleartext password, Type 54 indicates HMAC MD5 and Type
255 is used for routing domain private authentication methods. The
remainder of the value field contains the actual authentication data
determined by the value of the authentication type.
This document proposes a new authentication type to be carried in TLV
10, called the cryptographic authentication (CRYPTO_AUTH). This can
be used to specify any authentication algorithm for authenticating
and verifying IS-IS PDUs.
This document also explains how HMAC-SHA authentication can be used
in IS-IS.
By definition, HMAC [RFC2104] 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 IS-IS PDUs.
We propose to do away with the per interface keys and instead have
key IDs that map to unique IS-IS Security Associations.
2. IS-IS Security Association
An IS-IS Security Association (SA) contains a set of shared
parameters between any two legitimate IS-IS speakers.
Parameters associated with an IS-IS SA:
O Key ID – This is a one octet unsigned integer used to uniquely
identify an IS-IS SA, as manually configured by the network operator.
The receiver determines the active SA by looking at this field in the
incoming PDU. The sender puts this Key ID based on the active
configuration.
Bhatia, Manral and White Expires August 2007 [Page 2]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
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 IS-IS
peering, including the introduction of new authentication mechanisms.
o Authentication Algorithm – This signifies the authentication
algorithm to be used with the IS-IS SA. Valid values are 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
IS-IS SA. The length of this key is variable and depends upon the
authentication algorithm specified by the IS-IS SA.
3. Authentication Procedures
3.1 Authentication TLV
A new authentication code, [TB assigned by IANA], indicates the
CRYPTO_AUTH mechanism described in this document is in use, is
inserted in the first octet of the existing IS-IS Authentication TLV
(10).
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type 10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authentication Data (Variable)|
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
3.2 Procedures at the Sending Side
An appropriate IS-IS SA is selected for use with an outgoing IS-IS
PDU. This is done based on the active key at that instant. If IS-IS
is unable to find an active key, then the PDU is discarded.
Bhatia, Manral and White Expires August 2007 [Page 3]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
If IS-IS 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 PDU.
An implementation MUST fill the authentication type and the length
before the authentication data is computed. The length of the TLV is
set as per the authentication algorithm that is being used.
It’s set to 22 for HMAC-SHA-1, 30 for HMAC-SHA-224, 34 for HMAC-SHA-
256, 50 for HMAC-SHA-384 and 66 for HMAC-SHA-512. Note that one octet
has been added to account for the Key ID and one octet for the
authentication type. The authentication value field is set to Zero.
The key ID is filled.
The checksum and remaining life time fields are set to Zero for the
LSPs before authentication is calculated.
The result of the authentication algorithm is placed in the
Authentication data, following the key ID.
The authentication data for the IS-IS IIH PDUs MUST be computed after
the IIH has been padded to the MTU size, if padding is not explicitly
disabled.
3.3 Procedure at the Receiving Side
The appropriate IS-IS SA is identified by looking at the Key ID from
the Authentication TLV 10 from the incoming IS-IS PDU.
Authentication algorithm dependent processing, needs to be performed,
using the algorithm specified by the appropriate IS-IS SA for the
received packet.
Before an implementation performs any processing it needs to save the
values of the Authentication value field, the checksum and the
remaining life time.
These fields are set to Zero and the authentication data is computed.
The calculated data is compared with the received authentication data
in the PDU and the PDU 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 information in the PDUs 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 based authentication
schemes.
Bhatia, Manral and White Expires August 2007 [Page 4]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
Similarly, implementations not supporting the CRYPTO_AUTH field MAY
accept PDUs that contain this particular field in TLV 10.
4. 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. HMAC can be used, without modifying any hash function, for
calculating and verifying the message authentication values. It thus
verifies both the data integrity and the authenticity of a message.
The HMAC algorithm takes key K and text T as the input. The block
size B is 64 for SHA-1, SHA-224 and SHA-256 and its 128 for SHA-384
and SHA-512
The Key K is the password that has been chosen and text T is the IS-
IS PDU that needs to be authenticated.
Because of the way the hash functions are used in HMAC construction,
the collision attacks currently known against MD5 [MD5-attack] and
SHA-1 [SHA-1-attack] do not apply.
5. Security Considerations
The document proposes extensions to IS-IS 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 PDUs which is of interest to us.
The mechanism detailed in this document does not protect IS-IS
against replay attacks. An adversary could in theory replay old IIHs
and bring down the adjacency [CRYPTO] or replay old CSNPs and PSNPs
that would cause a flood of LSPs in the network. Using some sort of
crypto sequence numbers in IS-IS IIHs and CSNP/PSNPs is an option to
solve this problem. Discussing this is beyond the scope of this
document and it’s a matter which needs to be followed in the WG.
This document states that the remaining lifetime of the LSP MUST be
set to zero before computing the authentication, thus this field is
not authenticated. This field is excluded so that the LSPs may be
aged by the ISes in between without requiring to recompute the
authentication data. This can be exploited by an attacker.
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.
Bhatia, Manral and White Expires August 2007 [Page 5]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
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.
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 life time,
checksum and the authentication value field of the TLV with some pre-
defined non zero random number.
6. Acknowledgements
We would like to thank Ran Atkinson and Tony Li for their comments
and their earlier work on IS-IS authentication from which this draft
has been derived.
Thanks to Hugo Krawczyk, Arjen K. Lenstra (Bell Labs), Eric Grosse
(Bell Labs) and Matthew J. Fanto (NIST) for educating us on some of
the finer points related to Crypto Mathematics.
7. IANA Considerations
IANA needs to give value for the CRYPTO_AUTH field in the
authentication TLV 10. This document currently defines a value of 2
to be used to denote CRYPTO_AUTH mechanism for authenticating IS-IS
PDUs.
8. References
8.1 Normative References
[ISO] "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:1992
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic Authentication",
RFC 3567, July 2003
[RFC2104] Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997
Bhatia, Manral and White Expires August 2007 [Page 6]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
[NIST] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002
8.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
[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
9. 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
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
Bhatia, Manral and White Expires August 2007 [Page 7]
Internet Draft IS-IS HMAC SHA Cryptographic Authentication February 2007
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, Manral and White Expires August 2007 [Page 8]