< draft-ietf-isis-hmac-03.txt   draft-ietf-isis-hmac-04.txt >
Network Working Group Tony Li
INTERNET DRAFT Procket Networks Network Working Group
draft-ietf-isis-hmac-03.txt RJ Atkinson Tony Li
Extreme Networks INTERNET DRAFT Procket Networks
4 July 2001 Atkinson RJ
Extreme Networks
draft-ietf-isis-hmac-04.txt 22 April 2003
IS-IS Cryptographic Authentication IS-IS Cryptographic Authentication
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is subject to all provisions
provisions of Section 10 of RFC2026 except that the right to produce of Section 10 of RFC2026.
derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six months
may be updated, replaced, or obsoleted by other documents at any time. It and may be updated, replaced, or obsoleted by other documents at any
is inappropriate to use Internet-Drafts as reference material or to cite time. It is inappropriate to use Internet-Drafts as reference material or to
them other than as "work in progress." cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
ABSTRACT ABSTRACT
This document describes the authentication of IS-IS PDUs using the This document describes the authentication of IS-IS PDUs using the
HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions HMAC-MD5 algorithm as found in RFC 2104. IS-IS is specified in ISO
to support IPv4 described in [3]. The base specification includes an 10589 and RFC 1142, with extensions to support IPv4 described in RFC
authentication mechanism that allows for multiple authentication 1195. The base specification includes an authentication mechanism
algorithms. The base specification only specifies the algorithm for that allows for multiple authentication algorithms. The base
cleartext passwords. specification only specifies the algorithm for cleartext passwords.
This document proposes an extension to that specification that
allows the use of the HMAC-MD5 authentication algorithm to be used in This document proposes an extension to that specification that allows
the use of the HMAC-MD5 authentication algorithm to be used in
conjunction with the existing authentication mechanisms. conjunction with the existing authentication mechanisms.
1. Introduction 1. Introduction
The IS-IS protocol, as specified in ISO 10589, provides for the The IS-IS protocol, as specified in ISO 10589 and RFC 1142[1],
authentication of Link State PDUs (LSPs) through the inclusion of provides for the authentication of Link State PDUs (LSPs) through the
authentication information as part of the LSP. This authentication inclusion of authentication information as part of the LSP. This
information is encoded as a Type-Length-Value (TLV) tuple. authentication information is encoded as a Type-Length-Value (TLV)
tuple. The use of IS-IS for IPv4 networks is described in [2].
The type of the TLV is specified as 10. The length of the TLV The type of the TLV is specified as 10. The length of the TLV is
is variable. The value of the TLV depends on the authentication variable. The value of the TLV depends on the authentication
algorithm and related secrets being used. The first octet of the algorithm and related secrets being used. The first octet of the
value is used to specify the authentication type. Type 0 is value is used to specify the authentication type. Type 0 is
reserved, type 1 indicates a cleartext password, and type 255 is used reserved, type 1 indicates a cleartext password, and type 255 is used
for routing domain private authentication methods. The remainder of for routing domain private authentication methods. The remainder of
the TLV value is known as the Authentication Value. the TLV value is known as the Authentication Value.
This document extends the above situation by allocating a new This document extends the above situation by allocating a new
authentication type for HMAC-MD5 and specifying the algorithms for authentication type for HMAC-MD5 and specifying the algorithms for
the computation of the Authentication Value. This document also the computation of the Authentication Value. This document also
describes modifications to the base protocol to insure that the describes modifications to the base protocol to insure that the
authentication mechanisms described in this document are effective. authentication mechanisms described in this document are effective.
This document is a publication of the IS-IS Working Group within This document is a publication of the IS-IS Working Group within the
the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual
inclusion with ISO 10589. inclusion with ISO 10589.
2. Authentication Procedures 2. Authentication Procedures
The authentication type used for HMAC-MD5 is 54 (0x36). The The authentication type used for HMAC-MD5 is 54 (0x36). The length
length of the Authentication Value for HMAC-MD5 is 16, and the length of the Authentication Value for HMAC-MD5 is 16, and the length field
field in the TLV is 17. in the TLV is 17.
The HMAC-MD5 algorithm requires a key K and text T as input. The HMAC-MD5 algorithm requires a key K and text T as input [3]. The
The key K is the password for the PDU type, as specified in ISO key K is the password for the PDU type, as specified in ISO 10589.
10589. The text T is the IS-IS PDU to be authenticated with the The text T is the IS-IS PDU to be authenticated with the
Authentication Value field inside of the Authentication Information Authentication Value field inside of the Authentication Information
TLV set to zero. Note that the Authentication Type is set to 54 and TLV set to zero. Note that the Authentication Type is set to 54 and
the length of the TLV is set to 17 before authentication is computed. the length of the TLV is set to 17 before authentication is computed.
When LSPs are authenticated, the Checksum and Remaining Lifetime When LSPs are authenticated, the Checksum and Remaining Lifetime
fields are set to zero (0) before authentication is computed. The fields are set to zero (0) before authentication is computed. The
result of the algorithm is placed in the Authentication Value field. result of the algorithm is placed in the Authentication Value field.
When calculating the HMAC-MD5 result for Sequence Number PDUs When calculating the HMAC-MD5 result for Sequence Number PDUs, Level
and IS-IS HELLO PDUs, Level 1 Sequence Number PDUs SHALL use the Area 1 Sequence Number PDUs SHALL use the Area Authentication string as in
Authentication string as in Level 1 Link State PDUs. Level 2 Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the
Sequence Number PDUs shall use the domain authentication string as in domain authentication string as in Level 2 Link State PDUs. IS-IS
Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level HELLO PDUs SHALL use the Link Level Authentication String, which MAY
Authentication String, which MAY be different from that of Link State be different from that of Link State PDUs. The HMAC-MD5 result for
PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded
calculated after the Packet is padded to the MTU size, if padding is to the MTU size, if padding is not disabled. Implementations that
not disabled. Implementations that support the optional checksum for support the optional checksum for the Sequence Number PDUs and IS-IS
the Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the HELLO PDUs MUST NOT include the Checksum TLV.
Checksum TLV.
An implementation that implements HMAC-MD5 authentication and To authenticate an incoming PDU, a system should save the values of
receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value field, the Checksum and the Remaining
Lifetime field, set these fields to zero, compute authentication, and
then restore the values of these fields.
An implementation that implements HMAC-MD5 authentication and
receives HMAC-MD5 Authentication Information MUST discard the PDU if
the Authentication Value is incorrect. the Authentication Value is incorrect.
An implementation MAY have a transition mode where it includes An implementation MAY have a transition mode where it includes HMAC-
HMAC-MD5 Authentication Information in PDUs but does not verify the MD5 Authentication Information in PDUs but does not verify the HMAC-
HMAC-MD5 authentication information. This is a transition aid for MD5 authentication information. This is a transition aid for
networks in the process of deploying authentication. networks in the process of deploying authentication.
An implementation MAY check a set of passwords when verifying the An implementation MAY check a set of passwords when verifying the
Authentication Value. This provides a mechanism for incrementally Authentication Value. This provides a mechanism for incrementally
changing passwords in a network. changing passwords in a network.
An implementation that does not implement HMAC-MD5 authentication An implementation that does not implement HMAC-MD5 authentication MAY
MAY accept a PDU that contains the HMAC-MD5 Authentication Type. accept a PDU that contains the HMAC-MD5 Authentication Type. ISes
ISes (routers) that implement HMAC-MD5 authentication and initiate (routers) that implement HMAC-MD5 authentication and initiate LSP
LSP purges MUST remove the body of the LSP and add the authentication purges MUST remove the body of the LSP and add the authentication
TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept
unauthenticated purges. ISes MUST NOT accept purges that contain unauthenticated purges. ISes MUST NOT accept purges that contain
TLVs other than the authentication TLV. These restrictions are TLVs other than the authentication TLV. These restrictions are
necessary to prevent a hostile system from receiving an LSP, setting necessary to prevent a hostile system from receiving an LSP, setting
the Remaining Lifetime field to zero, and flooding it, thereby the Remaining Lifetime field to zero, and flooding it, thereby
initiating a purge without knowing the authentication password. initiating a purge without knowing the authentication password.
2.1 Implementation Considerations 2.1 Implementation Considerations
There is an implementation issue just after password rollover on There is an implementation issue just after password rollover on an
an IS-IS router that might benefit from additional commentary. IS-IS router that might benefit from additional commentary.
Immediately after password rollover on the router, the router or IS- Immediately after password rollover on the router, the router or IS-
IS process may restart. If this happens, this causes the LSP IS process may restart. If this happens, this causes the LSP
Sequence Number restarts from the value 1 using the new password. Sequence Number restarts from the value 1 using the new password.
However, neighbors will reject those new LSPs because the Sequence However, neighbors will reject those new LSPs because the Sequence
Number is smaller. The router can not increase its own LSP Sequence Number is smaller. The router can not increase its own LSP Sequence
Number because it fails to authenticate its own old LSP that Number because it fails to authenticate its own old LSP that
neighbors keep sending to it. So the router can not update its LSP neighbors keep sending to it. So the router can not update its LSP
Sequence Number to its neighbors until all the neighbors time out all Sequence Number to its neighbors until all the neighbors time out all
of the original LSPs. One possible solution to this problem is for of the original LSPs. One possible solution to this problem is for
the IS-IS process to detect if any inbound LSP with an authentication the IS-IS process to detect if any inbound LSP with an authentication
failure has the local System ID and also has a higher Sequence Number failure has the local System ID and also has a higher Sequence Number
than the IS-IS process has. In this event, the IS-IS process SHOULD than the IS-IS process has. In this event, the IS-IS process SHOULD
increase its own LSP Sequence Number accordingly and re-flood the increase its own LSP Sequence Number accordingly and re-flood the
LSPs. However, as this scenario could also be triggered by an active LSPs. However, as this scenario could also be triggered by an active
attack by an adversary, it is recommended that a counter also be kept attack by an adversary, it is recommended that a counter also be kept
on this case to mitigate the risk from such an active attack. on this case to mitigate the risk from such an active attack.
3. Security Considerations 3. Security Considerations
This document enhances the security of the IS-IS routing This document enhances the security of the IS-IS routing protocol.
protocol. Because a routing protocol contains information that need Because a routing protocol contains information that need not be kept
not be kept secret, privacy is not a requirement. However, secret, privacy is not a requirement. However, authentication of the
authentication of the messages within the protocol is of interest, to messages within the protocol is of interest, to reduce the risk of an
reduce the risk of an adversary compromising the routing system by adversary compromising the routing system by deliberately injecting
deliberately injecting false information into the routing system. false information into the routing system.
The technology in this document provides an authentication
mechanism for IS-IS. 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 IS-IS protocol, while not causing undue implementation,
deployment, or operational complexity.
This mechanism does not prevent replay attacks, however such The technology in this document provides an authentication mechanism
attacks would trigger existing mechanisms in the IS-IS protocol that for IS-IS. The mechanism described here is not perfect and does not
would effectively reject old information. Denial of service attacks need to be perfect. Instead, this mechanism represents a significant
are not generally preventable in a useful networking protocol [4]. increase in the work function of an adversary attacking the IS-IS
protocol, while not causing undue implementation, deployment, or
operational complexity.
Changes to the authentication mechanism described here This mechanism does not prevent replay attacks, however, in most
(primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were cases, such attacks would trigger existing mechanisms in the IS-IS
considered at some length, but ultimately were rejected. The protocol that would effectively reject old information. Denial of
mechanism here was already widely implemented in 1999. As of this service attacks are not generally preventable in a useful networking
writing, this mechanism is fairly widely deployed within the users protocol [4].
interested in cryptographic authentication of IS-IS. The improvement
provided by the proposed revised mechanism was not large enough to
justify the change, given the installed base and lack of operator
interest in deploying the proposed revised mechanism.
If and when a key management protocol appears that is both Changes to the authentication mechanism described here (primarily: to
widely implemented and easily deployed to secure routing protocols add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at
such as IS-IS, a different authentication mechanism that is designed some length, but ultimately were rejected. The mechanism here was
for use with that key management schema could be added if desired. already widely implemented in 1999. As of this writing, this
mechanism is fairly widely deployed within the users interested in
cryptographic authentication of IS-IS. The improvement provided by
the proposed revised mechanism was not large enough to justify the
change, given the installed base and lack of operator interest in
deploying the proposed revised mechanism.
If a stronger authentication were believed to be required, then If and when a key management protocol appears that is both widely
implemented and easily deployed to secure routing protocols such as
IS-IS, a different authentication mechanism that is designed for use
with that key management schema could be added if desired.
the use of a full digital signature [5] would be an approach that If a stronger authentication were believed to be required, then the
should be seriously considered. It was rejected for this purpose at use of a full digital signature [5] would be an approach that should
this time because the computational burden of full digital signatures be seriously considered. It was rejected for this purpose at this
is believed to be much higher than is reasonable given the current time because the computational burden of full digital signatures is
believed to be much higher than is reasonable given the current
threat environment in operational commercial networks. threat environment in operational commercial networks.
ACKNOWLEDGMENTS ACKNOWLEDGMENTS
The author would like to thank (in alphabetical order) Ran The authors would like to thank (in alphabetical order) Dave Katz,
Atkinson, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their
and Henk Smit for their comments and suggestions on this document. comments and suggestions on this document.
REFERENCES NORMATIVE REFERENCES
[1] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for Message [1] ISO, "Intermediate System to Intermediate System Intra- Domain
Routing
Exchange Protocol for use in Conjunction with the Protocol for
Providing
the Connectionless-mode Network Service (ISO 8473)", International
Standard
10589 [Also republished as RFC 1142].
[3] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for
Message
Authentication", RFC-2104, February 1997 Authentication", RFC-2104, February 1997
[2] ISO, "Intermediate System to Intermediate System Intra- Domain Routing INFORMATIVE REFERENCES
Exchange Protocol for use in Conjunction with the Protocol for Providing
the Connectionless-mode Network Service (ISO 8473)", International Standard
10589 [Also republished as RFC 1142].
[3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual [2] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
environments", RFC-1195, December 1990. environments", RFC-1195, December 1990.
[4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital Signatures", [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital
RFC-2154, June 1997. Signatures",
RFC-2154,June 1997.
Author's Address Author's Address
Tony Li Tony Li
Procket Networks Procket Networks
1100 Cadillac Ct. 1100 Cadillac Ct.
Milpitas, California Milpitas, California
95035 USA 95035 USA
Email: tli@procket.net Email: tli@procket.net
 End of changes. 34 change blocks. 
136 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/