Network Working Group T. Li
Internet-Draft Procket Networks
Category: Standards Track R. Atkinson
draft-ietf-isis-hmac-01.txt 10 April 2000
IS-IS Cryptographic Authentication
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026. This document is a
submission to the IETF IS-IS Working Group.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF) 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 6 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/ietf/shadow.html
ABSTRACT
This document specifies an algorithm-independent cryptographic
authentication mechanism for use with the IS-IS routing protocol.
1. Use of Imperatives
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words
have the meaning defined in RFC-2119, which is hereby incorporated by
reference. [7]
Li & Atkinson IS-IS Working Group [Page 1]
Internet-Draft April 2000
2. Introduction
Growth in the Internet has made us aware of the need for improved
authentication of routing information. Other routing protocols are
known to have been the subject of both active and passive attacks.
At present, IS-IS provides for unauthenticated service or password
authentication. Both are vulnerable to passive attacks currently
widespread in the Internet. Well-understood security issues exist in
routing protocols [3]. Clear text passwords, currently specified for
use with IS-IS, are no longer considered sufficient [4] in the
Internet.
If authentication is disabled, then only simple misconfigurations
are detected. Simple passwords transmitted in the clear will further
protect against the honest neighbor, but are useless in the general
case. By simply capturing information on the wire - straightforward
even in a remote environment - a hostile process can learn the
password and overcome the network. While IS-IS packets aren't
themselves routed, anyone with access to a system on the physical
link can inject forged packets (unless a cryptographic authentication
method is in use).
We propose that IS-IS use an authentication algorithm, as was
originally proposed for SNMP Version 2. Keyed MD5 is proposed as the
standard authentication algorithm for IS-IS, but the authentication
mechanism is believed to be algorithm-independent.
While this mechanism is not unbreakable (no known mechanism
is), it provides a greatly enhanced probability that a system being
attacked will detect and ignore hostile messages. This is because we
transmit the output of an authentication algorithm (e.g., Keyed MD5)
rather than the secret IS-IS Authentication Key. This output is a
one-way function of a message and a secret IS-IS Authentication Key.
This IS-IS Authentication Key is never sent over the network in the
clear, thus providing protection against the passive attacks now
commonplace in the Internet.
In this way, protection is afforded against forgery or message
modification. It is possible to replay a LSP until the LSP sequence
number changes, but the normal dynamics of the protocol make LSP
replay less of an issue in the long-term. The mechanism does not
afford confidentiality, since messages stay in the clear; however,
the mechanism is also exportable from most countries, which test a
privacy algorithm would fail.
Other relevant rationales for the approach are that Keyed MD5 is
being used for RIPv2 and OSPF cryptographic authentication, and is
Li & Atkinson IS-IS Working Group [Page 2]
Internet-Draft April 2000
therefore present in routers already, as is some form of password
management. In the interest of code reuse, this IS-IS extension
specifies Keyed-MD5 as the mandatory-to-implement algorithm. There
are no specific known vulnerabilities in Keyed-MD5 as used in this
context. A similar approach has been standardized for use in IP-
layer authentication. [6]
This document is a publication of the IS-IS Working Group
within the IETF. It is also a contribution to ISO IEC JTC1/SC6, for
eventual inclusion with ISO 10589.
3. Implementation Approach
Implementation requires three issues to be addressed:
(1) TLV format for use with cryptographic authentication,
(2) Authentication procedures, and
(3) Management controls.
3.1. IS-IS PDU Format
The IS-IS protocol, as specified in ISO 10589, provides for the
authentication of Link-State PDUs (LSPs) through the inclusion of
authentication information as part of the LSP. This authentication
information is encoded as a Type-Length-Value triple.
The type of the Authentication TLV is 10. The length of the
TLV is variable. The value of the TLV depends on the Authentication
Type being used.
The first octet of the value field indicates the
Authentication Type. Authentication Type 0 is reserved. Type 1
indicates a clear-text password, and Type 255 is used for routing
domain private authentication methods.
This document specifies an extension for cryptographic
authentication. When cryptographic authentication is in use, the
Authentication Type in the first octet of the Value field is set to
54 and the second octet of the Value field contains a Key Identifier
(Key-ID). The Key Identifier is used by the recipient to select the
particular IS-IS Security Association in use for this PDU. The
remainder of the Value field contains the Authentication Data itself.
Thus, the Length of the TLV is (2 + sizeof(authentication data)),
when the Authentication Type is cryptographic authentication.
Li & Atkinson IS-IS Working Group [Page 3]
Internet-Draft April 2000
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
+---------------+---------------+---------------+---------------+
| TLV Type=10 | TLV Length | AuthType = 54 | Key Identifier|
+---------------+---------------+---------------+---------------+
| Authentication Data (Length varies with Crypto Algorithm) |
+---------------+---------------+---------------+---------------+
Figure 1: Authentication TLV Format,
when Cryptographic Authentication is in use
Li & Atkinson IS-IS Working Group [Page 4]
Internet-Draft April 2000
3.2 Authentication Procedures
Conforming or compliant implementations MUST implement the
HMAC-MD5 cryptographic algorithm with this extension. The
algorithm-dependent details of HMAC-MD5 are specified in Appendix A.
A fundamental concept of IS-IS Cryptographic Authentication
is the "IS-IS Security Association". An IS-IS Security Association
contains a Key Identifier, the Cryptographic Authentication Algorithm
(e.g. HMAC-MD5) to use, a Lifetime, and the Cryptographic
Authentication Key to use. The Cryptographic Authentication Key is
also the password for the PDU Type, as specified in ISO 10589.
An implementation MAY include cryptographic authentication
information in PDUs even if it does not fully implement cryptographic
authentication. This allows an implementation to generate
authentication information without verifying the authentication
information as a transition aid for networks in the process of
deploying authentication.
An implementation that does not implement cryptographic
authentication MAY accept a PDU that contains the cryptographic
authentication type.
The remainder of this section describes the algorithm-
independent processing for IS-IS Cryptographic Authentication.
The Type, Length, Authentication Type, and Key Identifier
fields are filled with their final values prior to calculation of the
cryptographic Authentication Data. The Authentication Data field,
the Checksum field, and the Remaining Lifetime fields are all filled
with all zeros for the calculation of the cryptographic
Authentication Data for a given LSP. Sending systems calculate the
Checksum value after the Authentication Data field has been filled
in. After the Checksum value has been calculated, it is placed in
the IS-IS packet.
[New paragraph discussing how contents are dealt with for non-LSPs
(e.g. CSNPs, IIHs) coming here soon.]
When multiple valid IS-IS Security Associations exist for a
given IS-IS system, sending systems SHOULD pick an IS-IS Security
Association that is not about to expire in order to facilitate smooth
key rollover.
Receiving systems first check the Key-ID field and use its
value to locate the appropriate IS-IS Security Association. If no
Li & Atkinson IS-IS Working Group [Page 5]
Internet-Draft April 2000
IS-IS Security Association exists, the packet is discarded as not
authentic, without any further processing. If the matching IS-IS
Security Association is located, then the receiving system
independently computes the cryptographic Authentication Data using
the key contained in that IS-IS Security Association and the values
in the received IS-IS packet. For receive-side authentication
computations, the Authentication Data field itself, the Checksum
field, and the Remaining Lifetime fields are each assumed to be zero.
If the computed cryptographic Authentication Data is identical to the
received Authentication Data, the packet is accepted as authentic and
undergoes normal IS-IS receive-side processing. If there is any
difference, the packet is discarded as not authentic, without any
further processing.
An implementation SHOULD log authentication failures of
received IS-IS PDUs if this can be done without creating a denial of
service attack on the Intermediate System. Details of this are
unspecified here.
Intermediate Systems (i.e. routers) that implement
cryptographic authentication and initiating LSP purges MUST remove
the body of the LSP and add the authentication TLV. Intermediate
Systems MUST NOT accept unauthenticated purges. Intermediate Systems
MUST NOT accept purges that contain TLVs other than the
Authentication TLV. These restrictions are necessary to prevent a
hostile system from receiving an LSP, setting the Remaining Lifetime
field to zero, and flooding it, thereby initiating a purge without
knowing any authentication information.
Li & Atkinson IS-IS Working Group [Page 6]
Internet-Draft April 2000
3.3. Key Management Requirements
It is strongly desirable that a hypothetical security breach in
one Internet protocol not automatically compromise other Internet
protocols. The Cryptographic Authentication Key of this
specification SHOULD NOT be stored or transmitted using protocols or
algorithms that have known flaws.
Implementations MUST support the storage and use of at least two
IS-IS Security Associations at the same time. During normal
operation, only one IS-IS Security Association (i.e. one key) will
usually be active in a given IS-IS system. However, during the key
change period, both the old IS-IS Security Association and the new
IS-IS Security Association (i.e. two keys) will be active in the same
system at the same time.
An IS-IS Security Association MUST contain at least the
lifetime of the IS-IS Security Association (e.g. date/time first
valid and date/time no longer valid), the Key Identifier, the
Cryptographic Authentication Algorithm, and the Cryptographic Key
itself. The IS-IS Security Association lifetime MAY be infinite or
MAY have a specific date/time for start and end.
Implementations MUST support manual key distribution (e.g.,
the privileged user manually typing in the parameters for the IS-IS
Security Association (i.e. key, key lifetime, and key identifier) on
the router console. If more than one algorithm is supported, then
the implementation MUST require that the algorithm be specified for
each IS-IS Security Association at the time the other IS-IS Security
Association information is entered. IS-IS Security Associations that
are out of date MAY be deleted at will by the implementation without
requiring human intervention. Manual deletion of active IS-IS
Security Associations by the privileged operator SHOULD also be
supported.
It is desirable to use a key management protocol to
distribute IS-IS Authentication Keys among communicating IS-IS
implementations. Such a protocol would provide scalability and
significantly reduce the human administrative burden. The Key ID can
be used as a hook between IS-IS and such a future protocol. Key
management protocols have a long history of subtle flaws that are
often discovered long after the protocol was first described in
public. To avoid having to change all IS-IS implementations should
such a flaw be discovered, integrated key management protocol
techniques were deliberately omitted from this specification.
Li & Atkinson IS-IS Working Group [Page 7]
Internet-Draft April 2000
4.0. Key Management Procedures
As with all security methods using keys, it is necessary to
change the IS-IS Authentication Key on a regular basis. To maintain
routing stability during such changes, implementations MUST be able
to store and use at least two IS-IS Security Associations (hence:
authentication keys) in any given system at the same time.
Each IS-IS Security Association has its own Key Identifier,
which is stored locally. The Key Identifier uniquely identifies the
IS-IS Security Association in use.
The intermediate system creating the IS-IS message will
select a valid key from the set of valid keys for that interface.
The receiver will use the Key Identifier to determine which IS-IS
Security Association to use for authentication of the received
message. The receiver MUST NOT ignore the Key Identifier and try all
known keys on an incoming packet as this creates an easily prevented
denial-of-service attack on the IS-IS implementation. More than one
IS-IS Security Association (hence: more than one key) MAY be
associated with an interface at the same time.
Hence it is possible to have fairly smooth IS-IS
Authentication Key rollovers without losing legitimate LSPs because
the stored authentication key is incorrect and without requiring
people to change all the keys at once. To ensure a smooth rollover,
each communicating IS-IS system must be updated with the new key
several minutes before the current key will expire and several
minutes before the new key lifetime begins. The new key should have a
lifetime that starts several minutes before the old key expires. This
gives time for each system to learn of the new IS-IS Authentication
Key before that key will be used. It also ensures that the new key
will begin being used and the current key will go out of use before
the current key's lifetime expires. For the duration of the overlap
in key lifetimes, a system may receive messages using either key and
authenticate the message as indicated by the Key ID.
4.3. Pathological Cases
Two pathological cases exist which must be handled, which are
failures of the network manager. Both of these should be exceedingly
rare.
During key rollover, devices may exist which have not yet been
successfully configured with the new key. Therefore, routers SHOULD
implement (and would be well advised to implement) an algorithm that
detects the set of keys being used by its neighbors, and transmits
Li & Atkinson IS-IS Working Group [Page 8]
Internet-Draft April 2000
its messages using both the new and old keys until all of the
neighbors are using the new key or the lifetime of the old key
expires. Under normal circumstances, this elevated transmission rate
will exist for a single update interval.
In the event that the last key associated with a system, it is
unacceptable to revert to an unauthenticated condition, and not
advisable to disrupt routing. Therefore, the router should send a
"last authentication key expiration" notification to the network
manager and treat the key as having an infinite lifetime until the
lifetime is extended, the key is deleted by network management, or a
new key is configured.
5. Conformance Requirements
To conform to this specification, an implementation MUST support
all of its aspects. The HMAC-MD5 authentication algorithm MUST be
implemented by all conforming implementations. MD5 is defined in
RFC-1321. A conforming implementation MAY also support other
authentication algorithms such as Keyed Secure Hash Algorithm (SHA).
Manual key distribution as described above MUST be supported
by all conforming implementations. All conforming implementations
MUST support the smooth key rollover described under "Key Change
Procedures."
6. Acknowledgments
This work is derived directly from RFC-2082 and the similar work
done for OSPFv2 Cryptographic Authentication.
7. References
[1] ISO-10589
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[3] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
ACM Computer Communications Review, Volume 19, Number 2,
pp.32-48, April 1989.
[4] Haller, N., and R. Atkinson, "Internet Authentication
Guidelines", RFC 1704, October 1994.
Li & Atkinson IS-IS Working Group [Page 9]
Internet-Draft April 2000
[5] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Security in the Internet Architecture",
RFC 1636, June 1994.
[6] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[7] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC-2119, March 1997.
8. Security Considerations
This entire memo describes and specifies an authentication
mechanism for the IS-IS routing protocol that is believed to be
reasonably secure against active and passive attacks. Passive attacks
are clearly widespread in the Internet at present. Protection
against active attacks is also needed because active attacks are
becoming more common.
Users need to understand that the quality of the security provided
by this mechanism depends completely on the strength of the
implemented authentication algorithms, the strength of the key being
used, and the correct implementation of the security mechanism in all
communicating IS-IS implementations. This mechanism also depends on
the IS-IS Cryptographic Authentication Key being kept confidential by
all parties. If any of these incorrect or insufficiently secure,
then no real security will be provided to the users of this
mechanism.
Specifically with respect to the use of SNMP, compromise of SNMP
security has the necessary result that the various IS-IS
configuration parameters (e.g. routing table, IS-IS Authentication
Key) manageable via SNMP could be compromised as well. Changing
Authentication Keys using non-encrypted SNMP is no more secure than
sending passwords in the clear.
Confidentiality is not provided by this mechanism. Protection
against traffic analysis is also not provided. Mechanisms such as
bulk link encryption might be used when protection against traffic
analysis is required. Finally, this technique does not prevent
replay attacks. Appropriate use of key management can reduce the
residual risk associated with replay attacks if desired by the
operator.
10. Authors' Addresses
Tony Li
Li & Atkinson IS-IS Working Group [Page 10]
Internet-Draft April 2000
Procket Networks
San Jose, CA
Email: tli@procket.com
Randall Atkinson
Engineer at large
Li & Atkinson IS-IS Working Group [Page 11]