--- 1/draft-ietf-opsec-igp-crypto-requirements-02.txt 2010-10-10 08:12:17.000000000 +0200 +++ 2/draft-ietf-opsec-igp-crypto-requirements-03.txt 2010-10-10 08:12:17.000000000 +0200 @@ -1,378 +1,392 @@ -Internet Draft October 2010 - Network Working Group Manav Bhatia - Internet Draft Alcatel-Lucent - Expires: April 2011 Vishwas Manral - Intended Status: Informational IP Infusion - October 2010 +OPSEC Working Group M. Bhatia +Internet-Draft Alcatel-Lucent +Intended status: Informational V. Manral +Expires: April 13, 2011 IP Infusion + October 10, 2010 - Cryptographic Authentication Algorithm Implementation + Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols + draft-ietf-opsec-igp-crypto-requirements-03 - draft-ietf-opsec-igp-crypto-requirements-02.txt +Abstract -Status of this Memo + The routing protocols Open Shortest Path First version 2 (OSPFv2), + Intermediate System to Intermediate System (IS-IS) and Routing + Information Protocol (RIP) currently define cleartext and MD5 + (Message Digest 5) 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, IS-IS and OSPF. - This Internet-Draft is submitted to IETF in full conformance with - the provisions of BCP 78 and BCP 79. + 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. - 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. + Similarly RIPng and OSPFv3 support IPSec algorithms for + authenticating their protocol packets. - 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." + 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. - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html +Status of this Memo - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. - This Internet-Draft will expire on March 28, 2011. + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + 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." + + This Internet-Draft will expire on April 13, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 +Table of Contents - The routing protocols Open Shortest Path First version 2 (OSPFv2), - Intermediate System to Intermediate System (IS-IS) and Routing - Information Protocol (RIP) currently define Clear Text and MD5 - (Message Digest 5) 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, IS-IS and OSPF. + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 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. + 2. Intermediate System to Intermediate System (IS-IS) . . . . . . 6 + 2.1. Authentication Scheme Selection . . . . . . . . . . . . . 6 + 2.2. Authentication Algorithm Selection . . . . . . . . . . . . 6 - 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. + 3. Open Shortest Path First Version 2(OSPFv2) . . . . . . . . . . 8 + 3.1. Authentication Scheme Selection . . . . . . . . . . . . . 8 + 3.2. Authentication Algorithm Selection . . . . . . . . . . . . 8 -Table of Contents + 4. Open Shortest Path First Version 3 (OSPFv3) . . . . . . . . . 10 - 1. Introduction...................................................3 - 2. Intermediate System to Intermediate System (IS-IS).............4 - 2.1 Authentication Scheme Selection............................4 - 2.2 Authentication Algorithm Selection.........................5 - 3. Open Shortest Path First Version 2(OSPFv2).....................5 - 3.1 Authentication Scheme Selection............................5 - 3.2 Authentication Algorithm Selection.........................6 - 4. Open Shortest Path First Version 3 (OSPFv3)....................6 - 5. Routing Information Protocol Version 2 (RIPv2).................6 - 5.1 Authentication Scheme Selection............................7 - 5.2 Authentication Algorithm Selection.........................7 - 6. Routing Information Protocol for IPv6 (RIPng)..................8 - 7. Security Considerations........................................8 - 8. Acknowledgements...............................................9 - 9. IANA Considerations............................................9 - 10. References....................................................9 - 10.1 Normative References......................................9 - 10.2 Informative References...................................10 - Author's Addresses...............................................10 + 5. Routing Information Protocol Version 2 (RIPv2) . . . . . . . . 11 + 5.1. Authentication Scheme Selection . . . . . . . . . . . . . 11 + 5.2. Authentication Algorithm Selection . . . . . . . . . . . . 11 + + 6. Routing Information Protocol for IPv6 (RIPng) . . . . . . . . 13 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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 + authentication schemes: Null authentication, cleartext 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. + password is exchanged completely unprotected and anyone with physical + access to the network can learn the password and compromise the + integrity of the routing domain. The simple password scheme protects + from accidental establishment of routing sessions in a given domain, + but beyond that it offers no additional protection. In a cryptographic authentication scheme, routers share a secret key which is used to generate a message authentication code for each of - the protocol packets. Today, message authentication codes often use - a keyed MD5 digest. The recent escalating series of attacks on MD5 - raise concerns about its remaining useful lifetime. These attacks may - not necessarily result in direct vulnerabilities for keyed MD5 - digests as message authentication codes because the colliding message - may not correspond to a syntactically correct protocol packet. There - is a however a need felt to deprecate MD5 [RFC1321] in favor of - stronger message authentication code algorithms. + the protocol packets. Today, routing protocols that implement + message authentication codes often use a keyed MD5 [RFC1321] digest. + The recent escalating series of attacks on MD5 raise concerns about + its remaining useful lifetime. - In light of these considerations there have been proposals for adding - support of the SHA [SHS] family of hash algorithms for authenticating - routing protocol packets in RIP [RFC2453], IS-IS [ISO] [RFC1195] and - OSPF [RFC2328]. + These attacks may not necessarily result in direct vulnerabilities + for keyed MD5 digests as message authentication codes because the + colliding message may not correspond to a syntactically correct + protocol packet. The known collision, pre-image, and second pre- + image attacks [RFC4270] on MD5 may not increase the effectiveness of + the key recovery attacks on HMAC-MD5. Regardless, there is a need + felt to deprecated MD5 [RFC1321] as the basis for the HMAC algorithm + in favor of stronger digest algorithms. - 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. + In light of these considerations, there are proposals to replace + HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is + currently mandated in RIPv2 [RFC2453] and IS-IS [ISO] [RFC1195] and + keyed-MD5 in OSPFv2 [RFC2328] . + + OSPFv3 [RFC5340] and RIPng [RFC2080] rely on the IPv6 Authentication + Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) + [RFC4303] in order to provide integrity, authentication, and/or + confidentiality. + + 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 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 implementers - in anticipation of operational preference. + time to adapt to the evolving threats. At any particular time, the + mandatory to implement algorithm(s) might not be specified 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. - It is expected an implementation should support changing of Security - (Authentication) Keys. Changing Keys periodically is a good security - practice. + It is expected an implementation should support changing of security + (authentication) keys. Changing the symmetric key used in any HMAC + algorithm on a periodic basis is good security practice. Operators + need to plan for this. Implementations can support in-service key change so that no control - packets are lost. During such Key change more than one key can be - active for receiving packets for a session. Some protocols support - Key ID which allows the two ends of a session to have multiple keys - simultaneously for a session. Key change however is managed outside - the scope of the protocols themselves and can be done manually via - operator intervention, or dynamically based on some timer or a - security protocol. + packets are lost. During an in-service/in-band key change more than + one key can be active for receiving packets for a session. Some + protocols support a key identifier which allows the two peers of a + session to have multiple keys simultaneously for a session. + + However, these protocols currently manage keys manually (i.e., + operator intervention) or dynamically based on some timer or security + protocol. 2. 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. + Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. + The base specification [ISO] had provisions only for cleartext + passwords. [RFC5304] extends the authentication capabilities by + providing cryptographic authentication for IS-IS PDUs. It mandates + support for HMAC-MD5. - RFC 5310 [RFC5310] adds support for the use of the SHA family of hash - algorithms for authenticating IS-IS PDUs. + [RFC5310] adds support for the use of any cryptographic hash function + for authenticating IS-IS PDUs. It in addition to this, also details + how IS-IS can use HMAC construct along with the Secure Hash Algorithm + (SHA) family of cryptographic hash functions to secure IS-IS PDUs. -2.1 Authentication Scheme Selection +2.1. Authentication Scheme Selection - In order for IS-IS implementations to interoperate with the use of - security, 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. + In order for IS-IS implementations to securely 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 + cleartext 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 it provides no protection against an attacker with access to the broadcast domain as anyone can determine the secret password through inspection of the PDU. This mechanism does not provide any significant level of security and should be avoided. [RFC5304] mandates the use of HMAC-MD5 for cryptographically - authenticating the IS-IS PDUs. It is likely that this may get + authenticating the IS-IS PDUs. It is likely that this will get deprecated in favor of the generic cryptographic authentication - scheme defined in [RFC5310] in the future deployments, so new - implementations should support this scheme. + scheme defined in [RFC5310] in the future deployments. -2.2 Authentication Algorithm Selection +2.2. Authentication Algorithm Selection - For IS-IS implementations to interoperate with the use of security, - they must have support for one or more authentication algorithms in - common. + For IS-IS implementations to securely 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. - [RFC5304] mandates the use of HMAC-MD5 for cryptographically - authenticating the IS-IS PDUs. It is likely that this may get - deprecated in favor of HMAC-SHA-1 as defined in [RFC5310] in the - future deployments, so new implementations should support this - algorithm. + The following are the available options for authentication + algorithms: - Implementations may start providing support for HMAC-SHA-256/HMAC- - SHA-384/HMAC-SHA-512 as these algorithms may be necessary in the - future. + o [RFC5304] mandates the use of HMAC-MD5. + + o [RFC5310] does not require a particular algorithm but instead + supports any digest algorithm (i.e., cryptographic hash function). + + As noted earlier, there is a desire to deprecate the use of MD5. + IS-IS implementations will likely migrate to an authentication scheme + supported by [RFC5310] because it is algorithm agnostic. Possible + digest algorithms included: SHA-1, SHA-256, SHA-384, and SHA-512. + Picking at least one mandatory-to-implement algorithms is imperative + to ensuring interoperability. 3. 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. + [RFC2328] includes three different types of authentication schemes: + Null authentication, cleartext password (defined as simple password + in [RFC2328]) and cryptographic authentication. Null authentication + is semantically equivalent to no authentication. 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. - RFC 5709 [RFC5709] adds support for the use of the SHA family of hash + [RFC5709] adds support for the use of the SHA family of hash algorithms for authentication of OSPFv2 packets. -3.1 Authentication Scheme Selection +3.1. Authentication Scheme Selection - For OSPF implementations to interoperate with the use of security, - they must have one or more authentication schemes in common. This - section specifies the preference for standards conformant OSPFv2 - implementations, which desire to utilize the security feature. + For OSPF implementations to securely interoperate, they must have one + or more authentication schemes in common. While all implementations will have NULL auth since it's mandated by [RFC2328], its use is not appropriate in any context where the operator wishes to authenticate OSPFv2 packets in their network. - Similarly Simple Password, also mandatory per [RFC2328], should be - used when the operator only wants 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. + While all implementations will also have Cleartext Password since + it's mandated by [RFC2328] , its use is only appropriate for use when + the operator wants to preclude the accidental introduction of a + router into the domain. This scheme is patently not useful when an + operator wants to authenticate the OSPFv2 packets. - Cryptographic Authentication is a mandatory scheme as defined in + Cryptographic Authentication is a mandatory scheme defined in [RFC2328] and all conformant implementations must support this. -3.2 Authentication Algorithm Selection +3.2. Authentication Algorithm Selection - For OSPFv2 implementations to interoperate with the use of security, - they must support one or more cryptographic authentication algorithms - in common. + For OSPFv2 implementations to securely interoperate, they must + support one or more cryptographic authentication algorithms in + common. - [RFC2328] states that implementations must offer keyed MD5 - authentication. It is likely that this will be deprecated in favor of - HMAC-SHA-1 and HMAC-SHA-256 [RFC5709] in future deployments, so new - implementations should support these algorithms. + The following are the available options for authentication + algorithms: - Operators should consider migration to HMAC-SHA-256 if they desire a - stronger cryptographic algorithm for authentication of OSPFv2 - packets. + o [RFC2328] specifies the use of HMAC-MD5. - Implementations may start providing support for HMAC-SHA-1/HMAC-SHA- - 384/HMAC-SHA-512 [RFC5709] as these algorithms may be preferred in - the future. + o [RFC5304] specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC- + SHA256, HMAC-SHA384, and HAMC-512 and mandates support for HMAC- + SHA256 (HMAC-SHA1 is optional). + + As noted earlier, there is a desired to deprecate the use MD5. Some + alternatives for MD5 are listed in [RFC5304] + + Possible digest algorithms included: SHA-1, SHA-224, SHA-256, SHA- + 384, and SHA-512. Picking one mandatory-to-implement algorithms is + imperative to ensuring interoperability. 4. 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. [RFC4522] mandates the use of ESP for authenticating OSPFv3 packets. The implementations could also provide support for using AH to protect these packets. The algorithm requirements for AH and ESP are described in [RFC4835] and are not discussed here. 5. Routing Information Protocol Version 2 (RIPv2) RIPv2, originally specified in [RFC1388], then [RFC1723], has been updated and published as STD56 [RFC2453]. If the Address Family Identifier of the first (and only the first) entry in the RIPv2 message is 0xFFFF, then the remainder of the entry contains the - authentication information. 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. + authentication information. The [RFC2453]. version of the protocol + provides for authenticating packets using a cleartext password + (defined as "simple password" in [RFC2453]) not more than 16 octets + in length. - "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] added support for Keyed MD5 authentication, where a digest + is appended to the end of the RIP packet. [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. -5.1 Authentication Scheme Selection +5.1. Authentication Scheme Selection - For RIPv2 implementations to interoperate with the use of security, - one or more authentication schemes must be supported in common. This - section specifies the preference for standards conformant RIPv2 - implementations, which desire to utilize the security feature. + For RIPv2 implementations to securely interoperate they must support + one or more authentication schemes in common. - Simple Password is a mandatory to implement scheme as defined in - [RFC2453] and 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. + While all implementations will support cleartext password since it's + mandated by [RFC2453], its use is only appropriate for use when the + operator wants to preclude the accidental introduction of a router + into the domain. This scheme is patently not useful when an operator + wants to authenticate the RIPv2 packets. - [RFC2082] mandates the use of Keyed-MD5. However, [RFC2082] has been - obsoleted by [RFC4822] Cryptographic Authentication. Compliant - implementations must provide support for Keyed-MD5 but should + [RFC2082] mandates the use of an authentication scheme that uses + Keyed MD5. However, [RFC2082] has been obsoleted by [RFC4822] + Cryptographic Authentication. Compliant implementations must provide + support for an authentication scheme that uses Keyed MD5 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. + Implementations should provide support for [RFC4822] as it specifies + the RIPv2 Cryptographic Authentication schemes. -5.2 Authentication Algorithm Selection +5.2. Authentication Algorithm Selection - For RIPv2 implementations to interoperate with the use of security, - one or more authentication algorithms must be supported in common - that can be used for authentication. + For RIPv2 implementations to securely interoperate they must support + one or more authentication algorithms in common. - 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 the - future. + The following are the available options for authentication + algorithms: - Implementations should provide support for HMAC-SHA-1 used in - preference to keyed MD5 the future. + o [RFC2082] specifies the use of keyed MD5. - Operators should consider migration to HMAC-SHA-1 if they want to use - stronger cryptographic algorithms for authenticating RIPv2 packets. + o [RFC4822] specifies the use of HMAC-MD5, HMAC-SHA1, HMAC-SHA224, + HMAC- SHA256, HMAC-SHA384 and HMAC-SHA512. - Implementations should consider providing support for HMAC-SHA- - 256/HMAC-SHA-384/HMAC-SHA-512 as these algorithms may be preferred in - the future. + As noted earlier, there is a desire to deprecate the use MD5. Some + alternatives for MD5 are listed in [RFC4822]. Possible digest + algorithms included: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. + Picking one mandatory-to-implement algorithms is imperative to + ensuring interoperability. 6. Routing Information Protocol for IPv6 (RIPng) - RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide - integrity, authentication, and/or confidentiality. + RIPng [RFC2080] 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. 7. 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. + protocol messages protected by keyed 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 @@ -383,97 +397,106 @@ 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 the algorithms various routing protocols should employ to ensure interoperability between disparate implementations. -8. Acknowledgements +8. IANA Considerations - We would like to thank Joel Jaeggli for this comments and feedback on - this draft that resulted in significant improvement of the same. + This document has no actions for IANA. -9. IANA Considerations +9. Acknowledgements - This document places no requests to IANA. + We would like to thank Joel Jaeggli for this comments and feedback on + this draft that resulted in significant improvement of the same. 10. References -10.1 Normative References - - [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998 +10.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 + [ISO] ISO/IEC 10589:1992, "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)". [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 + [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, + January 1997. - [RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic - Authentication", RFC 4822, February 2007 + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. - [RFC5304] Li, T. and R. Atkinson, "Intermediate System to - Intermediate System (IS-IS) Cryptographic - Authentication", RFC 5304, October 2008 + [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, + November 1998. - [RFC5340] Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July - 2008. + [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic + Authentication", RFC 4822, February 2007. [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 + Authentication Header (AH)", RFC 4835, April 2007. - [RFC5709] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA - Cryptographic Authentication", RFC 5709, October 2009 + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, October 2008. -10.2 Informative References + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, February 2009. - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC - 1321, April 1992 + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008. - [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December - 2005. + [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., + Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic + Authentication", RFC 5709, October 2009. - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC - 4303, December 2005. +10.2. Informative References - [RFC4522] Gupta, M. and Melam, N.,"Authentication/Confidentiality - for OSPFv3", RFC 4522, June 2006 + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. [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 + [RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 + Authentication", RFC 2082, January 1997. - [SHS] National Institute of Standards and Technology (NIST), - FIPS Publication 180-3: Secure Hash Standard, October - 2008. + [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic + Hashes in Internet Protocols", RFC 4270, November 2005. - Author's Addresses + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP): + The Binary Encoding Option", RFC 4522, June 2006. + + [SHS] "National Institute of Standards and Technology (NIST), + FIPS Publication 180-3: Secure Hash Standard", + October 2008. + +Authors' Addresses Manav Bhatia Alcatel-Lucent - Bangalore, India + Bangalore, + India + + Phone: Email: manav.bhatia@alcatel-lucent.com - Vishwas Manral + Vishwas IP Infusion - Almora, Uttarakhand - India + USA + + Phone: Email: vishwas@ipinfusion.com