draft-ietf-opsec-igp-crypto-requirements-02.txt   draft-ietf-opsec-igp-crypto-requirements-03.txt 
Internet Draft October 2010
Network Working Group Manav Bhatia OPSEC Working Group M. Bhatia
Internet Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Expires: April 2011 Vishwas Manral Intended status: Informational V. Manral
Intended Status: Informational IP Infusion Expires: April 13, 2011 IP Infusion
October 2010 October 10, 2010
Cryptographic Authentication Algorithm Implementation Summary of Cryptographic Authentication Algorithm Implementation
Requirements for Routing Protocols 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 To encourage interoperability between disparate implementations, it
the provisions of BCP 78 and BCP 79. 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 Similarly RIPng and OSPFv3 support IPSec algorithms for
Task Force (IETF), its areas, and its working groups. Note that authenticating their protocol packets.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document examines the current set of available algorithms with
months and may be updated, replaced, or obsoleted by other interoperability and effective cryptographic authentication
documents at any time. It is inappropriate to use Internet-Drafts protection being the principle considerations. Cryptographic
as reference material or to cite them other than as "work in authentication of these routing protocols requires the availability
progress." 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 Status of this Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This Internet-Draft is submitted in full conformance with the
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Table of Contents
The routing protocols Open Shortest Path First version 2 (OSPFv2), 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
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.
To encourage interoperability between disparate implementations, it 2. Intermediate System to Intermediate System (IS-IS) . . . . . . 6
is imperative that we specify the expected minimal set of algorithms 2.1. Authentication Scheme Selection . . . . . . . . . . . . . 6
thereby ensuring that there is at least one algorithm that all 2.2. Authentication Algorithm Selection . . . . . . . . . . . . 6
implementations will have in common.
This document examines the current set of available algorithms with 3. Open Shortest Path First Version 2(OSPFv2) . . . . . . . . . . 8
interoperability and effective cryptographic authentication 3.1. Authentication Scheme Selection . . . . . . . . . . . . . 8
protection being the principle considerations. Cryptographic 3.2. Authentication Algorithm Selection . . . . . . . . . . . . 8
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.
Table of Contents 4. Open Shortest Path First Version 3 (OSPFv3) . . . . . . . . . 10
1. Introduction...................................................3 5. Routing Information Protocol Version 2 (RIPv2) . . . . . . . . 11
2. Intermediate System to Intermediate System (IS-IS).............4 5.1. Authentication Scheme Selection . . . . . . . . . . . . . 11
2.1 Authentication Scheme Selection............................4 5.2. Authentication Algorithm Selection . . . . . . . . . . . . 11
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
1. Introduction 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 Most routing protocols include three different types of
authentication schemes: Null authentication, Clear Text Password and authentication schemes: Null authentication, cleartext Password and a
a Cryptographic Authentication scheme. Null authentication is Cryptographic Authentication scheme. Null authentication is
equivalent to having no authentication scheme at all. equivalent to having no authentication scheme at all.
In a clear text scheme, also known as, simple password scheme, the In a cleartext scheme, also known as, simple password scheme, the
password is exchanged in the clear on the network and anyone with password is exchanged completely unprotected and anyone with physical
physical access to the network can learn the password and compromise access to the network can learn the password and compromise the
the integrity of the routing domain. While the Password scheme integrity of the routing domain. The simple password scheme protects
protects from accidental establishment of routing session in a given from accidental establishment of routing sessions in a given domain,
domain, it offers little additional protection. but beyond that it offers no additional protection.
In a cryptographic authentication scheme, routers share a secret key In a cryptographic authentication scheme, routers share a secret key
which is used to generate a message authentication code for each of which is used to generate a message authentication code for each of
the protocol packets. Today, message authentication codes often use the protocol packets. Today, routing protocols that implement
a keyed MD5 digest. The recent escalating series of attacks on MD5 message authentication codes often use a keyed MD5 [RFC1321] digest.
raise concerns about its remaining useful lifetime. These attacks may The recent escalating series of attacks on MD5 raise concerns about
not necessarily result in direct vulnerabilities for keyed MD5 its remaining useful lifetime.
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.
In light of these considerations there have been proposals for adding These attacks may not necessarily result in direct vulnerabilities
support of the SHA [SHS] family of hash algorithms for authenticating for keyed MD5 digests as message authentication codes because the
routing protocol packets in RIP [RFC2453], IS-IS [ISO] [RFC1195] and colliding message may not correspond to a syntactically correct
OSPF [RFC2328]. 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 In light of these considerations, there are proposals to replace
improvement is an ongoing process and as is the exploration and HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is
refinement of attack vectors. An algorithm believed to be strong currently mandated in RIPv2 [RFC2453] and IS-IS [ISO] [RFC1195] and
today may be demonstrated to be weak tomorrow. Given this, the choice keyed-MD5 in OSPFv2 [RFC2328] .
of preferred algorithm should favor the minimization of the
likelihood of it being compromised quickly. 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 It should be recognized that preferred algorithm(s) will change over
time to adapt to the evolving threats. The selection of preferred time to adapt to the evolving threats. At any particular time, the
algorithms may well not be reflected in the base protocol mandatory to implement algorithm(s) might not be specified in the
specification. As protocols are extended the preference for presently base protocol specification. As protocols are extended the
stronger algorithms presents a problem both on the question of preference for presently stronger algorithms presents a problem both
interoperability of existing and future implementations with respect on the question of interoperability of existing and future
to standards and operational preference for the configuration as implementations with respect to standards and operational preference
deployed. This document intends to provide guidance to implementers for the configuration as deployed.
in anticipation of operational preference.
It is expected an implementation should support changing of Security It is expected an implementation should support changing of security
(Authentication) Keys. Changing Keys periodically is a good security (authentication) keys. Changing the symmetric key used in any HMAC
practice. 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 Implementations can support in-service key change so that no control
packets are lost. During such Key change more than one key can be packets are lost. During an in-service/in-band key change more than
active for receiving packets for a session. Some protocols support one key can be active for receiving packets for a session. Some
Key ID which allows the two ends of a session to have multiple keys protocols support a key identifier which allows the two peers of a
simultaneously for a session. Key change however is managed outside session to have multiple keys simultaneously for a session.
the scope of the protocols themselves and can be done manually via
operator intervention, or dynamically based on some timer or a
security protocol.
2. Intermediate System to Intermediate System (IS-IS) 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 The IS-IS specification allows for authentication of its Protocol
Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. The Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU.
base specification had provisions only for clear text passwords. RFC The base specification [ISO] had provisions only for cleartext
5304 [RFC5304] extends the authentication capabilities by providing passwords. [RFC5304] extends the authentication capabilities by
HMAC-MD5 authentication for IS-IS PDUs. 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 [RFC5310] adds support for the use of any cryptographic hash function
algorithms for authenticating IS-IS PDUs. 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 In order for IS-IS implementations to securely interoperate, they
security, they must support one or more authentication schemes in must support one or more authentication schemes in common. This
common. This section specifies the preference for standards section specifies the preference for standards conformant IS-IS
conformant IS-IS implementations, which desire to utilize the implementations, which desire to utilize the security feature.
security feature.
The earliest interoperability requirement for authentication as The earliest interoperability requirement for authentication as
stated by [ISO] [RFC1195] required all implementations to support 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 to precluding the accidental introduction of a new IS into a
broadcast domain. We believe that operators should not use this broadcast domain. We believe that operators should not use this
scheme as it provides no protection against an attacker with access scheme as it provides no protection against an attacker with access
to the broadcast domain as anyone can determine the secret password to the broadcast domain as anyone can determine the secret password
through inspection of the PDU. This mechanism does not provide any through inspection of the PDU. This mechanism does not provide any
significant level of security and should be avoided. significant level of security and should be avoided.
[RFC5304] mandates the use of HMAC-MD5 for cryptographically [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 deprecated in favor of the generic cryptographic authentication
scheme defined in [RFC5310] in the future deployments, so new scheme defined in [RFC5310] in the future deployments.
implementations should support this scheme.
2.2 Authentication Algorithm Selection 2.2. Authentication Algorithm Selection
For IS-IS implementations to interoperate with the use of security, For IS-IS implementations to securely interoperate, they must have
they must have support for one or more authentication algorithms in support for one or more authentication algorithms in common.
common.
This section details the authentication algorithm requirements for This section details the authentication algorithm requirements for
standards conformant IS-IS implementations. standards conformant IS-IS implementations.
[RFC5304] mandates the use of HMAC-MD5 for cryptographically The following are the available options for authentication
authenticating the IS-IS PDUs. It is likely that this may get algorithms:
deprecated in favor of HMAC-SHA-1 as defined in [RFC5310] in the
future deployments, so new implementations should support this
algorithm.
Implementations may start providing support for HMAC-SHA-256/HMAC- o [RFC5304] mandates the use of HMAC-MD5.
SHA-384/HMAC-SHA-512 as these algorithms may be necessary in the
future.
3. Open Shortest Path First Version 2(OSPFv2) o [RFC5310] does not require a particular algorithm but instead
supports any digest algorithm (i.e., cryptographic hash function).
OSPFv2 as defined in [RFC2328] includes three different types of As noted earlier, there is a desire to deprecate the use of MD5.
authentication schemes: Null authentication, simple password and IS-IS implementations will likely migrate to an authentication scheme
cryptographic authentication. Null authentication is semantically supported by [RFC5310] because it is algorithm agnostic. Possible
equivalent to no authentication. In the simple password scheme of digest algorithms included: SHA-1, SHA-256, SHA-384, and SHA-512.
authentication, the passwords are exchanged in the clear on the Picking at least one mandatory-to-implement algorithms is imperative
network. Anyone with physical access to the network can learn the to ensuring interoperability.
password and compromise the security of the OSPFv2 domain.
3. Open Shortest Path First Version 2(OSPFv2)
[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 In the cryptographic authentication scheme, the OSPFv2 routers on a
common network/subnet are configured with a shared secret which is common network/subnet are configured with a shared secret which is
used to generate a keyed MD5 digest for each packet. A monotonically used to generate a keyed MD5 digest for each packet. A monotonically
increasing sequence number scheme is used to protect against replay increasing sequence number scheme is used to protect against replay
attacks. 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. 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, For OSPF implementations to securely interoperate, they must have one
they must have one or more authentication schemes in common. This or more authentication schemes in common.
section specifies the preference for standards conformant OSPFv2
implementations, which desire to utilize the security feature.
While all implementations will have NULL auth since it's mandated by While all implementations will have NULL auth since it's mandated by
[RFC2328], its use is not appropriate in any context where the [RFC2328], its use is not appropriate in any context where the
operator wishes to authenticate OSPFv2 packets in their network. operator wishes to authenticate OSPFv2 packets in their network.
Similarly Simple Password, also mandatory per [RFC2328], should be While all implementations will also have Cleartext Password since
used when the operator only wants to preclude the accidental it's mandated by [RFC2328] , its use is only appropriate for use when
introduction of a router into the domain. This scheme is not useful the operator wants to preclude the accidental introduction of a
when the operator wants to authenticate the OSPFv2 packets. 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. [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, For OSPFv2 implementations to securely interoperate, they must
they must support one or more cryptographic authentication algorithms support one or more cryptographic authentication algorithms in
in common. common.
[RFC2328] states that implementations must offer keyed MD5 The following are the available options for authentication
authentication. It is likely that this will be deprecated in favor of algorithms:
HMAC-SHA-1 and HMAC-SHA-256 [RFC5709] in future deployments, so new
implementations should support these algorithms.
Operators should consider migration to HMAC-SHA-256 if they desire a o [RFC2328] specifies the use of HMAC-MD5.
stronger cryptographic algorithm for authentication of OSPFv2
packets.
Implementations may start providing support for HMAC-SHA-1/HMAC-SHA- o [RFC5304] specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC-
384/HMAC-SHA-512 [RFC5709] as these algorithms may be preferred in SHA256, HMAC-SHA384, and HAMC-512 and mandates support for HMAC-
the future. SHA256 (HMAC-SHA1 is optional).
4. Open Shortest Path First Version 3 (OSPFv3) 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) OSPFv3 [RFC5340] relies on the IPv6 Authentication Header (AH)
[RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in [RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303] in
order to provide integrity, authentication, and/or confidentiality. order to provide integrity, authentication, and/or confidentiality.
[RFC4522] mandates the use of ESP for authenticating OSPFv3 packets. [RFC4522] mandates the use of ESP for authenticating OSPFv3 packets.
The implementations could also provide support for using AH to The implementations could also provide support for using AH to
protect these packets. protect these packets.
The algorithm requirements for AH and ESP are described in [RFC4835] The algorithm requirements for AH and ESP are described in [RFC4835]
and are not discussed here. and are not discussed here.
5. Routing Information Protocol Version 2 (RIPv2) 5. Routing Information Protocol Version 2 (RIPv2)
RIPv2, originally specified in [RFC1388], then [RFC1723], has been RIPv2, originally specified in [RFC1388], then [RFC1723], has been
updated and published as STD56 [RFC2453]. If the Address Family updated and published as STD56 [RFC2453]. If the Address Family
Identifier of the first (and only the first) entry in the RIPv2 Identifier of the first (and only the first) entry in the RIPv2
message is 0xFFFF, then the remainder of the entry contains the message is 0xFFFF, then the remainder of the entry contains the
authentication information. The [RFC2453] version of the protocol authentication information. The [RFC2453]. version of the protocol
provides for authenticating packets using a simple password of not provides for authenticating packets using a cleartext password
more than 16 octets, in which the password is sent in clear. (defined as "simple password" in [RFC2453]) not more than 16 octets
in length.
"RIP-2 MD5 Authentication" [RFC2082] added support for Keyed-MD5 [RFC2082] added support for Keyed MD5 authentication, where a digest
authentication, where a digest is appended to the end of the RIP is appended to the end of the RIP packet. [RFC4822] obsoleted
packet. "RIPv2 Cryptographic Authentication" [RFC4822] obsoleted
[RFC2082] and added the SHA family of hash algorithms to the list of [RFC2082] and added the SHA family of hash algorithms to the list of
cryptographic authentications that can be used to protect RIPv2, cryptographic authentications that can be used to protect RIPv2,
whereas [RFC2082] previously specified only the use of Keyed MD5. 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, For RIPv2 implementations to securely interoperate they must support
one or more authentication schemes must be supported in common. This one or more authentication schemes in common.
section specifies the preference for standards conformant RIPv2
implementations, which desire to utilize the security feature.
Simple Password is a mandatory to implement scheme as defined in While all implementations will support cleartext password since it's
[RFC2453] and should only be used when the operator wishes to mandated by [RFC2453], its use is only appropriate for use when the
preclude the accidental introduction of a RIP router into the domain. operator wants to preclude the accidental introduction of a router
This authentication scheme is useful, but not when the operator wants into the domain. This scheme is patently not useful when an operator
to protect RIPv2 message exchange in a potentially hostile wants to authenticate the RIPv2 packets.
environment.
[RFC2082] mandates the use of Keyed-MD5. However, [RFC2082] has been [RFC2082] mandates the use of an authentication scheme that uses
obsoleted by [RFC4822] Cryptographic Authentication. Compliant Keyed MD5. However, [RFC2082] has been obsoleted by [RFC4822]
implementations must provide support for Keyed-MD5 but should 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 recognize that this is superseded by Cryptographic Authentication as
defined in [RFC4822]. defined in [RFC4822].
Implementations should provide support for [RFC4822] Cryptographic Implementations should provide support for [RFC4822] as it specifies
Authentication as it will likely be the preferred authentication the RIPv2 Cryptographic Authentication schemes.
method in the future.
5.2 Authentication Algorithm Selection 5.2. Authentication Algorithm Selection
For RIPv2 implementations to interoperate with the use of security, For RIPv2 implementations to securely interoperate they must support
one or more authentication algorithms must be supported in common one or more authentication algorithms in common.
that can be used for authentication.
The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be The following are the available options for authentication
implemented. It is our belief that it will be superseded by HMAC-SHA- algorithms:
1 also available in [RFC4822]. Keyed MD5 must be implemented for
interoperability purposes, but its use may be deprecated in the
future.
Implementations should provide support for HMAC-SHA-1 used in o [RFC2082] specifies the use of keyed MD5.
preference to keyed MD5 the future.
Operators should consider migration to HMAC-SHA-1 if they want to use o [RFC4822] specifies the use of HMAC-MD5, HMAC-SHA1, HMAC-SHA224,
stronger cryptographic algorithms for authenticating RIPv2 packets. HMAC- SHA256, HMAC-SHA384 and HMAC-SHA512.
Implementations should consider providing support for HMAC-SHA- As noted earlier, there is a desire to deprecate the use MD5. Some
256/HMAC-SHA-384/HMAC-SHA-512 as these algorithms may be preferred in alternatives for MD5 are listed in [RFC4822]. Possible digest
the future. 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) 6. Routing Information Protocol for IPv6 (RIPng)
RIPng [RFC2080] relies on the IPv6 AH and IPv6 ESP to provide RIPng [RFC2080] relies on the IPv6 Authentication Header (AH)
integrity, authentication, and/or confidentiality. [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] The algorithm requirements for AH and ESP are described in [RFC4835]
and are not discussed here. and are not discussed here.
7. Security Considerations 7. Security Considerations
The cryptographic mechanisms referenced in this document provide only The cryptographic mechanisms referenced in this document provide only
authentication algorithms. These algorithms do not provide authentication algorithms. These algorithms do not provide
confidentiality. Encrypting the content of the packet and thereby confidentiality. Encrypting the content of the packet and thereby
providing confidentiality is not considered in the definition of the providing confidentiality is not considered in the definition of the
routing protocols. routing protocols.
The cryptographic strength of the HMAC depends upon the cryptographic The cryptographic strength of the HMAC depends upon the cryptographic
strength of the underlying hash function and on the size and quality strength of the underlying hash function and on the size and quality
of the key. The feasibility of attacking the integrity of routing of the key. The feasibility of attacking the integrity of routing
protocol messages protected by Digests may be significantly more protocol messages protected by keyed digests may be significantly
limited than that of other data, however preference for one family of more limited than that of other data, however preference for one
algorithms over another may also change independently of the family of algorithms over another may also change independently of
perceived risk to a particular protocol. the perceived risk to a particular protocol.
To ensure greater security, the keys used should be changed To ensure greater security, the keys used should be changed
periodically and implementations must be able to store and use more periodically and implementations must be able to store and use more
than one key at the same time. Operational experience suggests that than one key at the same time. Operational experience suggests that
the lack of periodic rekeying is a source of significant exposure and the lack of periodic rekeying is a source of significant exposure and
that the lifespan of shared keys in the network is frequently that the lifespan of shared keys in the network is frequently
measured in years. measured in years.
While simple password schemes are well represented in the document While simple password schemes are well represented in the document
series and in conformant implementations of the protocols, the series and in conformant implementations of the protocols, the
inability to offer either integrity or identity protection are inability to offer either integrity or identity protection are
sufficient reason to strongly discourage their use. sufficient reason to strongly discourage their use.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for use in the authentication of routing protocol packets algorithms for use in the authentication of routing protocol packets
being exchanged between adjacent routing processes. The being exchanged between adjacent routing processes. The
cryptographic algorithms identified in this document are not known to cryptographic algorithms identified in this document are not known to
be broken at the current time, and ongoing cryptographic research so be broken at the current time, and ongoing cryptographic research so
far leads us to believe that they will likely remain secure in the far leads us to believe that they will likely remain secure in the
foreseeable future. We expect that new revisions of this document foreseeable future. We expect that new revisions of this document
will be issued in the future to reflect current thinking on the will be issued in the future to reflect current thinking on the
algorithms various routing protocols should employ to ensure algorithms various routing protocols should employ to ensure
interoperability between disparate implementations. interoperability between disparate implementations.
8. Acknowledgements 8. IANA Considerations
This document has no actions for IANA.
9. Acknowledgements
We would like to thank Joel Jaeggli for this comments and feedback on We would like to thank Joel Jaeggli for this comments and feedback on
this draft that resulted in significant improvement of the same. this draft that resulted in significant improvement of the same.
9. IANA Considerations 10. References
This document places no requests to IANA.
10. References 10.1. Normative References
10.1 Normative References [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)".
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[ISO] "Intermediate system to Intermediate system routeing [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
information exchange protocol for use in conjunction with January 1997.
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 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC4822] R. Atkinson and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007 Authentication", RFC 4822, February 2007.
[RFC5304] Li, T. and R. Atkinson, "Intermediate System to [RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Intermediate System (IS-IS) Cryptographic Requirements for Encapsulating Security Payload (ESP) and
Authentication", RFC 5304, October 2008 Authentication Header (AH)", RFC 4835, April 2007.
[RFC5340] Coltun, R., et. al, "OSPF for IPv6", RFC 5340, July [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
2008. Authentication", RFC 5304, October 2008.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
Requirements for Encapsulating Security Payload (ESP) and and M. Fanto, "IS-IS Generic Cryptographic
Authentication Header (AH)", RFC 4835, April 2007 Authentication", RFC 5310, February 2009.
[RFC2080] Malkin, G. and Minnear, R., "RIPng for IPv6", RFC 2080, [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
January 1997 for IPv6", RFC 5340, July 2008.
[RFC5310] Bhatia, M., et. al., "IS-IS Generic [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Cryptographic Authentication", RFC 5310, February 2009 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009.
[RFC5709] Bhatia, M., Manral, V., et al., "OSPF HMAC-SHA 10.2. Informative References
Cryptographic Authentication", RFC 5709, October 2009
10.2 Informative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional
1321, April 1992 Information", RFC 1388, January 1993.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional
2005. Information", STD 56, RFC 1723, November 1994.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5
4303, December 2005. Authentication", RFC 2082, January 1997.
[RFC4522] Gupta, M. and Melam, N.,"Authentication/Confidentiality [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
for OSPFv3", RFC 4522, June 2006 Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
Information", RFC 1388, January 1993. December 2005.
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
Information", STD 56, RFC 1723, November 1994. RFC 4303, December 2005.
[RFC2082] Baker, F. and Atkinson, R., "RIP-2 MD5 [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Authentication", RFC 2082, January 1997 The Binary Encoding Option", RFC 4522, June 2006.
[SHS] National Institute of Standards and Technology (NIST), [SHS] "National Institute of Standards and Technology (NIST),
FIPS Publication 180-3: Secure Hash Standard, October FIPS Publication 180-3: Secure Hash Standard",
2008. October 2008.
Author's Addresses Authors' Addresses
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore, India Bangalore,
India
Phone:
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Vishwas Manral Vishwas
IP Infusion IP Infusion
Almora, Uttarakhand USA
India
Phone:
Email: vishwas@ipinfusion.com Email: vishwas@ipinfusion.com
 End of changes. 106 change blocks. 
286 lines changed or deleted 309 lines changed or added

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