[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc5310                               
Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   Network Working Group                                   Manav Bhatia
   Internet Draft                                        Alcatel-Lucent
   Expires: November 2007                                Vishwas Manral
                                                            IP Infusion
                                                              (Editors)


                IS-IS Generic Cryptographic Authentication

                      draft-ietf-isis-hmac-sha-03.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 HMAC
   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, et. al.     Expires November 2007             [Page 1]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 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]

   Contents

   1. Introduction...................................................2
   2. IS-IS Security Association.....................................3
   3. Authentication Procedures......................................4
      3.1 Authentication TLV.........................................4
   Figure 1..........................................................4
      3.2 Authentication Process.....................................4
      3.3 Cryptographic Aspects......................................4
      3.4 Procedures at the Sending Side.............................6
      3.5 Procedure at the Receiving Side............................6
   4. Security Considerations........................................7
   5. Acknowledgements...............................................8
   6. IANA Considerations............................................8
   7. References.....................................................9
      7.1 Normative References.......................................9
      7.2 Informative References.....................................9
   8. Author's Addresses............................................10


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 generic 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.



Bhatia, Manral, et. al.     Expires November 2007             [Page 2]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   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.

   While there are no openly published attacks on the HMAC-MD5
   mechanism, some reports [Dobb96a, Dobb96b] create concern about the
   ultimate strength of the MD5 cryptographic hash function.

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.

   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.







Bhatia, Manral, et. al.     Expires November 2007             [Page 3]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


3. Authentication Procedures

3.1 Authentication TLV

   A new authentication code, 0x3, 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 Authentication Process

   When calculating the CRYPTO_AUTH 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 CRYPTO_AUTH
   result for the IS-IS HELLO PDUs SHALL be calculated after the PDU 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.

3.3 Cryptographic Aspects

   In the algorithm description below, the following nomenclature, which
   is consistent with [FIPS-198], is used:

   H    is the specific hashing algorithm (e.g. SHA-256).
   K    is the password for the PDU type as per ISO 10589.
   Ko   is the cryptographic key used with the hash algorithm.

   B    is the block size of H, measured in octets rather than bits.

   Note that B is the internal block size, not the hash size.


Bhatia, Manral, et. al.     Expires November 2007             [Page 4]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


        For SHA-1 and SHA-256:   B == 64
        For SHA-384 and SHA-512: B == 128
   L    is the length of the hash, measured in octets rather than bits.

   XOR  is the exclusive-or operation.
   Opad is the hexadecimal value 0x5c repeated B times.
   Ipad is the hexadecimal value 0x36 repeated B times.
   Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.

   (1)Preparation of the Key

      In this application, Ko is always L octets long.

      If the Authentication Key (K) is L octets long, then Ko is equal
      to K.  If the Authentication Key (K) is more than L octets long,
      then Ko is set to H(K).  If the Authentication Key (K) is less
      than L octets long, then Ko is set to the Authentication Key (K)
      with zeros appended to the end of the Authentication Key (K) such
      that Ko is L octets long.

   (2)First Hash

      First, the IS-IS packet's Authentication Data field is filled with
      the value Apad and the Authentication Type field is set to 0x3.

      Then, a first hash, also known as the inner hash, is computed
      as follows:

              First-Hash = H(Ko XOR Ipad || (IS-IS PDU))

   (3)Second Hash

      Then a second hash, also known as the outer hash, is computed
      as follows:

              Second-Hash = H(Ko XOR Opad || First-Hash)

   (4)Result

      The result Second-Hash becomes the Authentication Data that is
      sent in the Authentication Data field of the IS-IS PDU. The length
      of the Authentication Data field is always identical to the
      message digest size of the specific hash function H that is being
      used.

      This also means that the use of hash functions with larger output
      sizes will also increase the size of the IS-IS PDU as transmitted
      on the wire.



Bhatia, Manral, et. al.     Expires November 2007             [Page 5]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


3.4 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.

   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 authentication data
   is computed as explained in the previous section. 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 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.5 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.

   It should then set the Authentication Value field with Apad and zero
   the Checksum and Remaining Life time fields before the authentication
   data is computed. The calculated data is compared with the received



Bhatia, Manral, et. al.     Expires November 2007             [Page 6]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   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.

   Similarly, implementations not supporting the CRYPTO_AUTH field MAY
   accept PDUs that contain this particular field in TLV 10.

4. 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 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.

   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.

   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.



Bhatia, Manral, et. al.     Expires November 2007             [Page 7]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   If a stronger authentication were believed to be required, then the
   use of a full digital signature [RFC-2154] 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.

5. Acknowledgements

   The authors would like to thank Hugo Krawczyk, Arjen K. Lenstra (Bell
   Labs) and Eric Grosse (Bell Labs) for educating us on some of the
   finer points related to Crypto Mathematics.

   We would also like to thank Bill Burr, Tim Polk, John Kelsey, and
   Morris Dworkin of (US) NIST for review of portions of this document
   that are directly derived from the closely related work on RIPv2
   Cryptographic Authentication [RFC-4822].

6. IANA Considerations

   This document requests that IANA create a new code point registry to
   administer the Authentication Type code points for TLV 10. This
   registry would be part of the existing IS-IS code points registry as
   established by [RFC-3563] and [RFC-3359].  This registry should be
   managed using the Designated Expert policy as described in [RFC-
   2434bis] and will be called IS-IS Authentication Type Codes.

   The values in the IS-IS Authentication Type Codes registry should be
   recorded in decimal and should only be approved after a designated
   expert, appointed by the IESG area director, has been consulted.
   The intention is that any allocation will be accompanied by a
   published RFC.  However, the Designated Expert can approve
   allocations once it seems clear that an RFC will be published,
   allowing for the allocation of values prior to the document being
   approved for publication as an RFC. New items should be documented in
   a publicly and freely available specification. We should also have
   the provision of allowing external specifications to allocate and use
   the IS-IS Authentication Type Codes maintained by this registry.

   Initial values for the IS-IS Authentication Type Codes registry are
   given below; future assignments are to be made through Expert Review.
   Assignments consist of an authentication type name and its associated
   value.








Bhatia, Manral, et. al.     Expires November 2007             [Page 8]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   Authentication Type Code                        Value      Reference
   ------------------------                        ------     ---------

   Reserved                                          0        [ISO]
   Cleartext Password                                1        [ISO]
   ISO 10589 Reserved                                2        [ISO]
   Cryptographic Authentication                      3
   HMAC-MD5 Authentication                           54       [RFC3567]
   Routeing Domain private authentication method     255      [ISO]

   This document currently defines and uses the value 3 to foster
   prestandard implementations.

7. References

7.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 Atkinson, R. "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

   [NIST]     National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-2, August 2002

   [FIPS-198] US National Institute of Standards & Technology, "The
              Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
              198, March 2002.

7.2 Informative References

   [Dobb96a]  Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical
              Report, 2 May 1996. (Presented at the Rump Session of
              EuroCrypt 1996.)

   [Dobb96b]  Dobbertin, H, "The Status of MD5 After a Recent Attack",


Bhatia, Manral, et. al.     Expires November 2007             [Page 9]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


              CryptoBytes, Vol. 2, No. 2, Summer 1996.


   [CRYPTO]   Manral, V. et al., "Issues with existing Cryptographic
              Protection Methods for Routing Protocols", Work in
              Progress, February 2006

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

   [RFC-4822] R. Atkinson, M. Fanto, "RIPv2 Cryptographic
              Authentication", RFC 4822, February 2007.

   [RFC-3359] Przygienda, T., "Reserved Type, Length and Value (TLV)
              Codepoints in Intermediate System to Intermediate System",
              RFC 3359, August 2002.

   [RFC-3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF
              and ISO/IEC Joint Technical Committee 1/Sub Committee 6
              (JTC1/SC6) on IS-IS Routing Protocol Development",
              RFC 3563, July 2003.

   [RFC-2434bis]  Narten, T. and Alvestrand, H., "Guidelines for Writing
                  an IANA Considerations Section in RFCs", Work in
                  Progress, March 2007


8. Author's Addresses

   Manav Bhatia
   Alcatel-Lucent
   Bangalore, India
   Email: manav@alcatel-lucent.com

   Tony Li
   Cisco Systems
   San Jose, CA
   USA
   EMail: tli@cisco.com

   Vishwas Manral
   IP Infusion
   Almora, Uttarakhand
   India
   Email: vishwas@ipinfusion.com

   Russ White
   Cisco Systems
   RTP North Carolina


Bhatia, Manral, et. al.     Expires November 2007             [Page 10]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   USA
   Email: riw@cisco.com


   Randall J. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA 95051
   USA
   Email: rja@extremenetworks.com

   Matthew J. Fanto
   Ciber Inc.
   Dearborn, Mi
   USA
   Email: mfanto@ciber.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
   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



Bhatia, Manral, et. al.     Expires November 2007             [Page 11]


Internet Draft   IS-IS Generic Cryptographic Authentication   May 2007


   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, et. al.     Expires November 2007             [Page 12]