[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 6094

Internet Draft                                            January 2010


   Network Working Group                                   Manav Bhatia
   Internet Draft                                        Alcatel-Lucent
   Expires: July 31, 2010                                Vishwas Manral
   Intended Status: Informational                           IP Infusion
                                                       January 30, 2010

           Cryptographic Authentication Algorithm Implementation
                   Best Practices for Routing Protocols

              draft-ietf-opsec-igp-crypto-requirements-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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.

   This Internet-Draft will expire on July 31, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Bhatia and Manral                                              [Page 1]


Internet Draft                                            January 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   The routing protocols Open Shortest Path First version 2 (OSPFv2)
   [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO]
   [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently
   define Clear Text and MD5 (Message Digest 5) [RFC1321] methods for
   authenticating protocol packets. Recently effort has been made to add
   support for the SHA (Secure Hash Algorithm) family of hash functions
   for the purpose of authenticating routing protocol packets for RIP
   [RFC4822], IS-IS [RFC5310] and OSPF [RFC5709].

   To encourage interoperability between disparate implementations, it
   is imperative that we specify the expected minimal set of algorithms
   thereby ensuring that there is at least one algorithm that all
   implementations will have in common.

   This document examines the current set of available algorithms with
   interoperability and effective cryptographic authentication
   protection being the principle considerations. Cryptographic
   authentication of these routing protocols requires the availability
   of the same algorithms in disparate implementations. It is desirable
   that newly specified algorithms should be implemented and available
   in routing protocol implementations because they may be promoted to
   requirements at some future time.

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. [RFC2119]

Table of Contents

   1. Introduction...................................................3
   2. Requirements Terminology.......................................4
   3. Intermediate System to Intermediate System (IS-IS).............4
      3.1 Authentication Scheme Selection............................4
      3.2 Authentication Algorithm Selection.........................5
   4. Open Shortest Path First Version 2(OSPFv2).....................5


Bhatia and Manral                                              [Page 2]


Internet Draft                                            January 2010


      4.1 Authentication Scheme Selection............................6
      4.2 Authentication Algorithm Selection.........................6
   5. Open Shortest Path First Version 3 (OSPFv3)....................6
   6. Routing Information Protocol Version 2 (RIPv2).................7
      6.1 Authentication Scheme Selection............................7
      6.2 Authentication Algorithm Selection.........................7
   7. Routing Information Protocol for IPv6 (RIPng)..................8
   8. Security Considerations........................................8
   9. Acknowledgements...............................................9
   10. IANA Considerations...........................................9
   11. References....................................................9
      11.1 Normative References......................................9
      11.2 Informative References...................................10
   Author's Addresses...............................................10


1. Introduction

   Most routing protocols include three different types of
   authentication schemes: Null authentication, Clear Text Password and
   a Cryptographic Authentication scheme. NULL authentication is
   equivalent to having no authentication scheme at all.

   In a clear text scheme, also known as, simple password scheme, the
   password is exchanged in the clear on the network and anyone with
   physical access to the network can learn the password and compromise
   the integrity of the routing domain. While the Password scheme
   protects from accidental establishment of routing session in a given
   domain, it offers little additional protection.

   In a cryptographic authentication scheme, routers share a secret key
   which is used to generate a keyed MD5 (or other) digest which is used
   for authenticating the protocol packets.

   There have been an escalating series of attacks on MD5 which raises
   concerns about the remaining useful lifetime of this hash algorithm.

   It should be noted that these attacks may not necessarily result in
   direct vulnerabilities in Keyed-MD5 as used in the routing protocols
   for authentication purposes, because the colliding message may not
   necessarily be a syntactically correct protocol packet. There is a
   however a need felt to deprecate MD5 in favor of stronger hash
   algorithms.

   In light of these considerations there have been proposals for adding
   support of the SHA family of hash algorithms for authenticating
   routing protocol packets in RIP, IS-IS and OSPF.




Bhatia and Manral                                              [Page 3]


Internet Draft                                            January 2010


   However, the nature of cryptography is that algorithmic
   improvement is an ongoing process and as is the exploration and
   refinement of attack vectors. An algorithm believed to be strong
   today may be demonstrated to be weak tomorrow. Given this, the choice
   of preferred algorithm should favor the minimization of the
   likelihood of it being compromised quickly.

   It should be recognized that preferred algorithm(s) will change over
   time in to adapt to the evolving threats. The selection of preferred
   algorithms may well not be reflected in the base protocol
   specification. As protocols are extended the preference for presently
   stronger algorithms presents a problem both on the question of
   interoperability of existing and future implementations with respect
   to standards and operational preference for the configuration as
   deployed. This document intends to provide guidance to implementors
   in anticipation of operational preference.

2. Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in RFC2119. [RFC2119]

3. Intermediate System to Intermediate System (IS-IS)

   The IS-IS specification allows for authentication of its Protocol
   Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The
   base specification had provisions only for clear text passwords. RFC
   5304 [RFC5304] extends the authentication capabilities by providing
   HMAC-MD5 authentication for IS-IS PDUs.

   RFC 5310 [RFC5310] adds support for the use of SHA family of hash
   algorithms for authenticating IS-IS PDUs.

3.1 Authentication Scheme Selection

   In order for IS-IS implementations to interoperate, they must support
   one or more authentication schemes in common. This section specifies
   the preference for standards conformant IS-IS implementations, which
   desire to utilize the security feature.

   The earliest interoperability requirement for authentication as
   stated by [ISO] [RFC1195] required all implementations to support
   Clear Text Password.  This authentication scheme's utility is limited
   to precluding the accidental introduction of a new IS into a
   broadcast domain. We believe that operators should not use this
   scheme as provides no protection against an attacker with access to
   the broadcast domain as anyone can determine the secret password



Bhatia and Manral                                              [Page 4]


Internet Draft                                            January 2010


   through inspection of the PDU. It MUST presently be implemented but
   its use should be deprecated.

   [RFC5304] defines HMAC-MD5 implementation as a MUST for
   cryptographically authenticating the IS-IS PDUs. HMAC-MD5 is
   currently the preferred algorithm for IS-IS deployments and it may
   be superseded by the generic cryptographic authentication scheme
   defined in [RFC5310]. HMAC-MD5 MUST be implemented, but its use may
   be deprecated in future.

   IS-IS implementations SHOULD provide support for the generic
   cryptographic authentication scheme [RFC5310] and it is our
   understanding that interoperability considerations will require
   change to a MUST as operators migrate to this authentication scheme.

3.2 Authentication Algorithm Selection

   For IS-IS implementations to interoperate, they must have support for
   one or more authentication algorithms in common.

   This section details the authentication algorithm requirements for
   standards conformant IS-IS implementations.

   HMAC-MD5 is a MUST as defined in [RFC5304]. It is our belief that
   this will be superseded by HMAC-SHA-1 as defined in [RFC5310]. HMAC-
   MD5 MUST be implemented, but its use may be deprecated in future.
   Operators should consider migration to HMAC-SHA-1.

   Implementations may start providing support for HMAC-SHA-256/HMAC-
   SHA-384/HMAC-SHA-512 as these algorithms may be necessary in the
   future.

4. Open Shortest Path First Version 2(OSPFv2)

   OSPFv2 as defined in [RFC2328] includes three different types of
   authentication schemes: Null authentication, simple password and
   cryptographic authentication. NULL authentication is semantically
   equivalent to no authentication. In the simple password scheme of
   authentication, the passwords are exchanged in the clear on the
   network. Anyone with physical access to the network can learn the
   password and compromise the security of the OSPFv2 domain.

   In the cryptographic authentication scheme, the OSPFv2 routers on a
   common network/subnet are configured with a shared secret which is
   used to generate a keyed MD5 digest for each packet. A monotonically
   increasing sequence number scheme is used to protect against replay
   attacks.




Bhatia and Manral                                              [Page 5]


Internet Draft                                            January 2010


   RFC 5709 [RFC5709] adds support for the use of SHA family of hash
   algorithms for authentication of OSPFv2 packets.


4.1 Authentication Scheme Selection

   For OSPF implementations to interoperate, they must have one or more
   authentication schemes in common. This section specifies the
   requirements for standards conformant OSPFv2 implementations, which
   desire to utilize the authentication feature.

   Null Authentication is a MUST as defined in [RFC2328], its use is
   deprecated in any context where the operator wishes to authenticate
   the OSPFv2 packets in their network.

   Simple Password defined as a MUST in [RFC2328] should only be used
   when the operator is seeking only to preclude the accidental
   introduction of a router into the domain. This scheme is not useful
   when the operator wants to authenticate the OSPFv2 packets.

   Cryptographic Authentication is a MUST as defined in [RFC2328] and
   all conformant implentations MUST support this.

4.2 Authentication Algorithm Selection

   For OSPFv2 implementations to interoperate, they must support one or
   more cryptographic authentication algorithms in common.

   Keyed MD5 as defined in [RFC2328] is a MUST. It is our belief that
   HMAC-SHA-1 and HMAC-SHA-256 as defined in [RFC5709] will likely be
   preferred in the future. Keyed MD5 MUST be implemented, but its use
   may be deprecated in future. Implementations must provide support for
   HMAC-SHA-256 as this will become the algorithm of choice.

   Operators should consider migration to HMAC-SHA-256 if they desire a
   stronger cryptographic algorithm for authentication of OSPFv2
   packets.

   Implementations may start providing support for HMAC-SHA-1/HMAC-SHA-
   384/HMAC-SHA-512 as these algorithms may be preferred in the future.

5. Open Shortest Path First Version 3 (OSPFv3)

   OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH)
   [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in
   order to provide integrity, authentication, and/or confidentiality.

   The algorithm requirements for AH and ESP are described in [RFC4835]
   and are not discussed here.


Bhatia and Manral                                              [Page 6]


Internet Draft                                            January 2010



6. Routing Information Protocol Version 2 (RIPv2)

   RIPv2, originally specified in [RFC1388], then [RFC1723], has been
   finalized in STD56 [RFC2453]. If the Address Family Identifier of the
   first (and only the first) entry in the message is 0xFFFF, then the
   remainder of the entry contains the authentication. The [RFC2453]
   version of the protocol provides for authenticating packets using a
   simple password of not more than 16 octets, in which the password is
   sent in clear.

   "RIP-2 MD5 Authentication" [RFC2082] added support for Keyed-MD5
   authentication, where a digest is appended to the end of the RIP
   packet. "RIPv2 Cryptographic Authentication" [RFC4822] obsoleted
   [RFC2082] and added the SHA family of hash algorithms to the list of
   cryptographic authentications that can be used to protect RIPv2,
   whereas [RFC2082] previously specified only the use of Keyed MD5.

6.1 Authentication Scheme Selection

   For RIPv2 implementations to interoperate, one or more authentication
   schemes must be supported in common. This section specifies the
   requirements for standards conformant RIPv2 implementations, which
   utilize the authentication feature.

   Simple Password defined as a MUST in [RFC2453] should only be used
   when the operator wishes to preclude the accidental introduction of a
   RIP router into the domain. This authentication scheme is useful, but
   not when the operator wants to protect RIPv2 message exchange in a
   potentially hostile environment.

   Implementations MUST provide support for Simple Password, but its
   operational use is deprecated.

   Keyed-MD5 as defined in [RFC2082] is a MUST. However, [RFC2082] has
   been obsoleted by [RFC4822] Cryptographic Authentication. Compliant
   implementations MUST provide support for Keyed-MD5 as described in
   [RFC2082] but should recognize that this is superseded by
   Cryptographic Authentication as defined in [RFC4822].

   Implementations should provide support for [RFC4822] Cryptographic
   Authentication as it will likely be the preferred authentication
   method in the future.

6.2 Authentication Algorithm Selection

   For RIPv2 implementations to interoperate, one or more authentication
   algorithms must be supported in common that can be used for
   authentication.


Bhatia and Manral                                              [Page 7]


Internet Draft                                            January 2010


   The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be
   implemented. It is our belief that it will be superseded by HMAC-SHA-
   1 also available in [RFC4822]. Keyed MD5 MUST be implemented for
   interoperability purposes, but its use may be deprecated in future.

   Implementations should provide support for HMAC-SHA-1 used in
   preference to keyed MD5 the future.

   Operators should consider migration to HMAC-SHA-1 if they want to use
   stronger cryptographic algorithms for authenticating RIPv2 packets.

   Implementations should consider providing support for HMAC-SHA-
   256/HMAC-SHA-384/HMAC-SHA-512 as these algorithms may be preferred in
   the future.

7. Routing Information Protocol for IPv6 (RIPng)

   RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide
   integrity, authentication, and/or confidentiality.

   The algorithm requirements for AH and ESP are described in [RFC4835]
   and are not discussed here.

8. Security Considerations

   The cryptographic mechanisms referenced in this document provide only
   authentication algorithms. These algorithms do not provide
   confidentiality. Encrypting the content of the packet and thereby
   providing confidentiality is not considered in the definition of the
   routing protocols.

   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. The feasibility of attacking the integrity of routing
   protocol messages protected by Digests may be significantly more
   limited than that of other data, however preference for one family of
   algorithms over another may also change independently of the
   perceived risk to a particular protocol.

   To ensure greater security, the keys used should be changed
   periodically and implementations MUST be able to store and use more
   than one key at the same time. Operational experience suggests that
   the lack of periodic rekeying is a source of significant exposure and
   that the lifespan of shared keys in the network is frequently
   measured in years.

   While simple password schemes are well represented in the document
   series and in conformant implementations of the protocols, the



Bhatia and Manral                                              [Page 8]


Internet Draft                                            January 2010


   inability to offer either integrity or identity protection are
   sufficient reason to strongly discourage their use.

   This document concerns itself with the selection of cryptographic
   algorithms for use in the authentication of routing protocol packets
   being exchanged between adjacent routing processes.  The
   cryptographic algorithms identified in this document are not known to
   be broken at the current time, and ongoing cryptographic research so
   far leads us to believe that they will likely remain secure in the
   foreseeable future. We expect that new revisions of this document
   will be issued in the future to reflect current thinking on best
   practice in this area.

9. Acknowledgements

   We would like to thank Joel Jaeggli for this comments and feedback on
   this draft that resulted in significant improvement of the same.

10. IANA Considerations

   This document places no requests to IANA.

11. References

11.1 Normative References

   [RFC2328]   Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998

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

   [RFC2453]   Malkin, G., "RIP Version 2", RFC 2453, November 1998

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

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

   [RFC5304]   Li, T. and R. Atkinson, "Intermediate System to
               Intermediate System (IS-IS) Cryptographic
               Authentication", RFC 5304, October 2008

   [RFC5340]   Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July


Bhatia and Manral                                              [Page 9]


Internet Draft                                            January 2010


               2008.

   [RFC4835]   Manral, V., "Cryptographic Algorithm Implementation
               Requirements for Encapsulating Security Payload (ESP) and
               Authentication Header (AH)", RFC 4835, April 2007

   [RFC2080]   Malkin, G. and Minnear, R., "RIPng for IPv6", RFC 2080,
               January 1997

   [RFC5310]   Bhatia, M., et. al., "IS-IS Generic
               Cryptographic Authentication", RFC 5310, February 2009

   [RFC5709]   Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA
               Cryptographic Authentication", RFC 5709, October 2009

11.2 Informative References

   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC
               1321, April 1992

   [RFC4302]   Kent, S., "IP Authentication Header", RFC 4302, December
               2005.

   [RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
               4303, December 2005.

   [RFC1388]   Malkin, G., "RIP Version 2 Carrying Additional
               Information", RFC 1388, January 1993.

   [RFC1723]   Malkin, G., "RIP Version 2 - Carrying Additional
               Information", STD 56, RFC 1723, November 1994.

   [RFC2082]   Baker, F. and Atkinson, R., "RIP-2 MD5
               Authentication", RFC 2082, January 1997

   Author's Addresses

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

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




Bhatia and Manral                                              [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/