wdiff draft-ietf-isis-hmac-00.txt draft-ietf-isis-hmac-01.txt

Network Working Group Tony T. Li
INTERNET DRAFT Juniper
Internet-Draft Procket Networks
January 1999
Category: Standards Track R. Atkinson
draft-ietf-isis-hmac-01.txt 10 April 2000

IS-IS HMAC-MD5 Cryptographic Authentication

<draft-ietf-isis-hmac-00.txt>

Status of this Memo

This document is an Internet-Draft. 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), its areas, (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 six 6 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts Internet-Drafts as reference
material or to cite them other than as "work in progress."

To view the entire progress".

The list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

1.0 Abstract can be accessed at
http://www.ietf.org/ietf/shadow.html

ABSTRACT

This document describes 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]

2. Introduction

Growth in the Internet has made us aware of the need for improved
authentication of IS-IS PDUs using routing information. Other routing protocols are
known to have been the
HMAC-MD5 algorithm [1]. subject of both active and passive attacks.
At present, IS-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 [2], 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 extensions access to support IPv4 described a system on the physical
link can inject forged packets (unless a cryptographic authentication
method is in [3]. The base specification includes use).

We propose that IS-IS use an authentication mechanism that allows algorithm, as was
originally proposed for multiple authentication
algorithms. The base specification only specifies SNMP Version 2. Keyed MD5 is proposed as the
standard authentication algorithm for
cleartext passwords. 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 document proposes is because we
transmit the output of an extension 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 specification that allows Keyed MD5 is
being used for RIPv2 and OSPF cryptographic authentication, and is
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 HMAC-MD5 authentication algorithm 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 used in
conjunction addressed:

(1) TLV format for use with the existing authentication mechanisms.

2.0 Introduction 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 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 (TLV) tuple. triple.

The type of the Authentication TLV is specified as 10. The length of the
TLV is variable. The value of the TLV depends on the authentication algorithm and
related secrets Authentication
Type being used.

The first octet of the value is used to
specify field indicates the authentication type.
Authentication Type. Authentication Type 0 is reserved, type reserved. Type 1
indicates a cleartext clear-text password, and type Type 255 is used for routing
domain private authentication methods. The remainder of the TLV
value is known as the Authentication Value.

This document extends the above situation by allocating a new
authentication type for HMAC-MD5 and specifying the algorithms specifies an extension for
the computation of cryptographic
authentication. When cryptographic authentication is in use, the
Authentication Value. This document also
describes modifications to the base protocol to insure that the
authentication mechanisms described Type in this document are effective.

This document is a publication of the IS-IS Working Group within first octet of the
IETF, and Value field is a contribution set to ISO IEC JTC1/SC6, for eventual
inclusion with ISO 10589.

3.0 Authentication Procedures

The authentication type used for HMAC-MD5 is
54 (0x36). The length and the second octet of the Authentication Value for HMAC-MD5 is 16, and the length field
in the TLV is 17.

The HMAC-MD5 algorithm requires contains a key K and text T as input. Key Identifier
(Key-ID). The key
K Key Identifier is used by the password for recipient to select the PDU type, as specified
particular IS-IS Security Association in ISO 10589. use for this PDU. The
text T is the PDU to be authenticated with
remainder of the Authentication Value field inside of contains the Authentication Information TLV set to zero. Note
that Data itself.
Thus, the Authentication Type is set to 54 and the length Length of the TLV is set to 17 before authentication is computed. When LSPs are
authenticated, (2 + sizeof(authentication data)),
when the Checksum and Remaining Lifetime fields are set to
zero (0) before authentication Authentication Type is computed. The result of the
algorithm 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
+---------------+---------------+---------------+---------------+
| 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 placed in the use

3.2 Authentication Value field.

An Procedures

Conforming or compliant implementations that implements MUST implement the
HMAC-MD5 authentication and
receives 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 Information MUST discard
is the PDU if "IS-IS Security Association". An IS-IS Security Association
contains a Key Identifier, the Cryptographic Authentication Value Algorithm
(e.g. HMAC-MD5) to use, a Lifetime, and the Cryptographic
Authentication Key to use. The Cryptographic Authentication Key is incorrect.
also the password for the PDU Type, as specified in ISO 10589.

An implementation MAY include HMAC-MD5 Authentication Information cryptographic authentication
information in PDUs even if it does not fully implement HMAC-MD5 cryptographic
authentication. This allows an implementation to generate
authentication information without verifying the authentication information. This is
information as a transition aid for networks in the process of
deploying authentication.

An implementation MAY check a set of passwords when verifying the
Authentication Value. This provides a mechanism for incrementally
changing passwords in a network.

An implementation that does not implement HMAC-MD5 cryptographic
authentication MAY accept a PDU that contains the HMAC-MD5 cryptographic
authentication type.

The remainder of this section describes the algorithm-
independent processing for IS-IS Cryptographic Authentication.

The Type, Length, Authentication Type.

ISes (routers) 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
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 HMAC-MD5
cryptographic authentication and initiating LSP purges MUST remove
the body of the LSP and add the authentication TLV. ISes Intermediate
Systems MUST NOT accept unauthenticated purges. ISes Intermediate Systems
MUST NOT accept purges that contain TLVs other than the authentication
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 the any authentication password.

4.0 information.

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 Considerations

This document enhances Associations at the security 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 routing protocol.
Because 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 routing protocol contains information 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 not entered. IS-IS Security Associations that
are out of
significant value, privacy 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 not desirable to use a requirement. However,
authentication of key management protocol to
distribute IS-IS Authentication Keys among communicating IS-IS
implementations. Such a protocol would provide scalability and
significantly reduce the messages within 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.

4.0. Key Management Procedures

As with all security methods using keys, it is of interest. 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 technology 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 document provides 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 mechanism
for IS-IS. This mechanism does not prevent replay attacks, however
such attacks would trigger mechanisms in key is incorrect and without requiring
people to change all the protocol 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 would
effectively reject starts several minutes before the old information. key expires. This document does
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 address
denial-of-service attacks.

5.0 Acknowledgments

The author yet been
successfully configured with the new key. Therefore, routers SHOULD
implement (and would like be well advised to thank Henk Smit, Dave Katz implement) an algorithm that
detects the set of keys being used by its neighbors, and Tony
Przygienda transmits
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 their comments on 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 work.

6.0 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] RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", H.
Krawczyk, M. Bellare, R. Canetti, February 1997 ISO-10589

[2] ISO 10589, "Intermediate System to Intermediate System Intra-
Domain Routeing Exchange Protocol for use Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.

[3] S. Bellovin, "Security Problems in Conjunction with the TCP/IP Protocol for Providing 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.

[5] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Security in the Connectionless-mode Network Service (ISO
8473)" [Also republished as Internet Architecture",
RFC 1142]

[3] 1636, June 1994.

[6] Atkinson, R., "IP Authentication Header", RFC 1195, "Use of OSI IS-IS 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 TCP/IP 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 dual
environments", R.W. Callon, Dec. 1990

10.0 Author's Address 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
Juniper Networks, Inc.
385 Ravendale Dr.
Mountain View,
Procket Networks
San Jose, CA 94043

Email: tli@juniper.net
Fax: +1 650 526 8001
Voice: +1 650 526 8006 tli@procket.com

Randall Atkinson
Engineer at large