IS-IS for IP Internets                                             T. Li
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                             R. Atkinson
Expires: July 19, 2008                            Extreme Networks, Inc.
                                                        January 16, 2008

    Intermediate System to Intermediate System (IS-IS) Cryptographic

Status of this Memo

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


   This document describes the authentication of Intermediate System to
   Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
   Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
   algorithm as found in RFC 2104.  IS-IS is specified in International
   Standards Organization (ISO) 10589, with extensions to support
   Internet Protocol version 4 (IPv4) described in RFC 1195.  The base

Li & Atkinson             Expires July 19, 2008                 [Page 1]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

   specification includes an authentication mechanism that allows for
   multiple authentication algorithms.  The base 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
   conjunction with the existing authentication mechanisms.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Authentication Procedures . . . . . . . . . . . . . . . . . . . 3
     2.1.  Implementation Considerations . . . . . . . . . . . . . . . 4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Security Limitations  . . . . . . . . . . . . . . . . . . . 5
     3.2.  Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Other Considerations  . . . . . . . . . . . . . . . . . . . 6
     3.4.  Future Directions . . . . . . . . . . . . . . . . . . . . . 6
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Li & Atkinson             Expires July 19, 2008                 [Page 2]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

1.  Introduction

   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 (TLV) tuple.  The use
   of IS-IS for IPv4 networks is described in [RFC1195].

   The type of the 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 being used.  The first octet of the
   value is used to specify the authentication type.  Type 0 is
   reserved, type 1 indicates a cleartext password, and 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 for
   the computation of the Authentication Value.  This document also
   describes modifications to the base protocol to ensure that the
   authentication mechanisms described in this document are effective.

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  Authentication Procedures

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

   The HMAC-MD5 algorithm requires a key K and text T as input
   [RFC2104].  The key K is the password for the PDU type, as specified
   in ISO 10589.  The text T is the IS-IS PDU to be authenticated with
   the Authentication Value field inside of the Authentication
   Information 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.  When LSPs are authenticated, the
   Checksum and Remaining Lifetime fields are set to zero (0) before
   authentication is computed.  The result of the algorithm is placed in
   the Authentication Value field.

Li & Atkinson             Expires July 19, 2008                 [Page 3]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

   When calculating the HMAC-MD5 result for Sequence Number PDUs, Level
   1 Sequence Number PDUs SHALL use the Area Authentication string as in
   Level 1 Link State PDUs.  Level 2 Sequence Number PDUs shall use the
   domain authentication string as in Level 2 Link State PDUs.  IS-IS
   HELLO PDUs SHALL use the Link Level Authentication String, which MAY
   be different from that of Link State PDUs.  The HMAC-MD5 result for
   the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded
   to the MTU size, if padding is not disabled.  Implementations that
   support the optional checksum for the Sequence Number PDUs and IS-IS
   HELLO PDUs MUST NOT include the Checksum TLV.

   To authenticate an incoming PDU, a system should save the values of
   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.

   An implementation MAY have a transition mode where it includes HMAC-
   MD5 Authentication Information in PDUs but does not verify the HMAC-
   MD5 authentication information.  This is 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 authentication MAY
   accept a PDU that contains the HMAC-MD5 Authentication Type.  ISes
   (routers) that implement HMAC-MD5 authentication and initiate LSP
   purges MUST remove the body of the LSP and add the authentication
   TLV.  ISes implementing HMAC-MD5 authentication MUST NOT accept
   unauthenticated purges.  ISes 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 the authentication password.

2.1.  Implementation Considerations

   There is an implementation issue just after password rollover on an
   IS-IS router that might benefit from additional commentary.
   Immediately after password rollover on the router, the router or IS-
   IS process may restart.  If this happens, this causes the LSP
   Sequence Number restarts from the value 1 using the new password.
   However, neighbors will reject those new LSPs because the Sequence

Li & Atkinson             Expires July 19, 2008                 [Page 4]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

   Number is smaller.  The router can not increase its own LSP Sequence
   Number because it fails to authenticate its own old LSP that
   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
   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
   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
   increase its own LSP Sequence Number accordingly and re-flood the
   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
   on this case to mitigate the risk from such an active attack.

3.  Security Considerations

   This document enhances the security of the IS-IS routing protocol.
   Because a routing protocol contains information that need not be kept
   secret, privacy is not a requirement.  However, authentication of the
   messages within the protocol is of interest, to reduce the risk of an
   adversary compromising the routing system by deliberately injecting
   false information into the routing system.

3.1.  Security Limitations

   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.  It is believed secure against passive
   attacks, as defined in [RFC1704], unlike cleartext password

   This mechanism does not prevent replay attacks; however, in most
   cases, such attacks would trigger existing mechanisms in the IS-IS
   protocol that would effectively reject old information.  Denial of
   service attacks are not generally preventable in a useful networking
   protocol [DoS].

3.2.  Assurance

   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 Authentication Key being kept confidential by all parties.

Li & Atkinson             Expires July 19, 2008                 [Page 5]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

   If any of these are incorrect or insufficiently secure, then no real
   security will be provided to the users of this mechanism.

   Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were
   first published a dozen years ago, there have been growing concerns
   about the effectiveness of the compression function within MD5.  More
   recent work by Wang and Yu [WY05] accentuates these concerns.
   However, despite these research results, there are no published
   attacks at present on either Keyed-MD5 or HMAC-MD5.  A recent paper
   by Bellare [Bell06a] [Bell06b] provides new proofs for the security
   of HMAC that require fewer assumptions than previous published proofs
   for HMAC.  Those proofs indicate that the published issues with MD5
   (and separately with SHA-1) do not create an attack on HMAC-MD5 (or
   HMAC SHA-1).  Most recently, Fouque and others [FLN07] have published
   new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5.  However, their
   attacks are non-trivial computationally and they have not found an
   equivalent attack on HMAC-MD5.  So, despite the published issues with
   the MD5 algorithm, there is no currently published attack that
   applies to HMAC-MD5 as used in this IS-IS specification.  As with any
   cryptographic technique, there is the possibility of the discovery of
   future attacks against this mechanism.

3.3.  Other Considerations

   Changes to the authentication mechanism described here (primarily: to
   add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at
   some length, but ultimately were rejected.  The mechanism here was
   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 tnough to justify the
   change, given the installed base and lack of operator interest in
   deploying a revised mechanism.

   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.

3.4.  Future Directions

   If a stronger authentication were believed to be required, then the
   use of a full digital signature [RFC2154] would be an approach that
   should be seriously considered.  It was rejected for this purpose at
   this 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.

Li & Atkinson             Expires July 19, 2008                 [Page 6]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

4.  Acknowledgements

   The authors would like to thank (in alphabetical order) Dave Katz,
   Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their
   comments and suggestions on this document.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  References

6.1.  Normative References

              ISO, "Intermediate System to Intermediate System Intra-
              Domain Routeing Exchange Protocol for use in Conjunction
              with the Protocol for Providing the Connectionless-mode
              Network Service (ISO 8473)", International Standard 10589:
              2002, Second Edition, 2002.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [Bell06a]  Bellare, M., "New Proofs for NMAC and HMAC: Security
              without Collision-Resistance", Preliminary Version, in
              Proceedings of Crypto 2006, Lecture Notes in Computer
              Science Vol. 4117, August 2006.

   [Bell06b]  Bellare, M., "New Proofs for NMAC and HMAC: Security
              without Collision-Resistance", August 2006,

   [DoS]      Voydock, V. and S. Kent, "Security Mechanisms in High-
              level Networks", ACM Computing Surveys Vol. 15, No. 2,
              June 1983.

   [Dobb96a]  Dobbertin, H., "Cryptanalysis of MD5 Compress", EuroCrypt
              Rump Session 1996, May 1996.

Li & Atkinson             Expires July 19, 2008                 [Page 7]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

   [Dobb96b]  Dobbertin, H., "The Status of MD5 After a Recent Attack",
              CryptoBytes Vol. 2, No. 2, 1996.

   [Dobb98]   Dobbertin, H., "Cryptanalysis of MD4", Journal of
              Cryptology Vol. 11, No. 4, 1998.

   [FLN07]    Fouque, P., Leurent, G., and P. Nguyen, "Full Key-Recovery
              Attacks on HMAC/NMAC-MD5 and NMAC-MD5", Proceedings of
              Crypto 2007, August 2007.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
              RFC 1704, October 1994.

   [RFC2154]  Murphy, S., Badger, M., and B. Wellington, "OSPF with
              Digital Signatures", RFC 2154, June 1997.

   [WY05]     Wang, X. and H. Yu, "How to Break MD5 and Other Hash
              Functions", Proceedings of EuroCrypt 2005, Lecture Notes
              in Computer Science Vol. 3494, 2005.

Authors' Addresses

   Tony Li
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134

   Phone: +1 408 853 1494

   Ran J. Atkinson
   Extreme Networks, Inc.
   3585 Monroe St.
   Santa Clara, CA  95051

   Phone: +1 408 579 2800

Li & Atkinson             Expires July 19, 2008                 [Page 8]

Internet-Draft     IS-IS Cryptographic Authentication       January 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Li & Atkinson             Expires July 19, 2008                 [Page 9]