draft-ietf-opsec-igp-crypto-requirements-04.txt | rfc6094.txt | |||
---|---|---|---|---|
OPSEC Working Group M. Bhatia | Internet Engineering Task Force (IETF) M. Bhatia | |||
Internet-Draft Alcatel-Lucent | Request for Comments: 6094 Alcatel-Lucent | |||
Intended status: Informational V. Manral | Category: Informational V. Manral | |||
Expires: April 15, 2011 IP Infusion | ISSN: 2070-1721 IP Infusion | |||
October 12, 2010 | February 2011 | |||
Summary of Cryptographic Authentication Algorithm Implementation | Summary of Cryptographic Authentication Algorithm Implementation | |||
Requirements for Routing Protocols | Requirements for Routing Protocols | |||
draft-ietf-opsec-igp-crypto-requirements-04 | ||||
Abstract | Abstract | |||
The routing protocols Open Shortest Path First version 2 (OSPFv2), | The routing protocols Open Shortest Path First version 2 (OSPFv2), | |||
Intermediate System to Intermediate System (IS-IS) and Routing | Intermediate System to Intermediate System (IS-IS), and Routing | |||
Information Protocol (RIP) currently define cleartext and MD5 | Information Protocol (RIP) currently define cleartext and MD5 | |||
(Message Digest 5) methods for authenticating protocol packets. | (Message Digest 5) methods for authenticating protocol packets. | |||
Recently effort has been made to add support for the SHA (Secure Hash | Recently, effort has been made to add support for the SHA (Secure | |||
Algorithm) family of hash functions for the purpose of authenticating | Hash Algorithm) family of hash functions for the purpose of | |||
routing protocol packets for RIP, IS-IS and OSPF. | authenticating routing protocol packets for RIP, IS-IS, and OSPF. | |||
To encourage interoperability between disparate implementations, it | To encourage interoperability between disparate implementations, it | |||
is imperative that we specify the expected minimal set of algorithms | is imperative that we specify the expected minimal set of algorithms, | |||
thereby ensuring that there is at least one algorithm that all | thereby ensuring that there is at least one algorithm that all | |||
implementations will have in common. | implementations will have in common. | |||
Similarly RIPng and OSPFv3 support IPSec algorithms for | Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms | |||
authenticating their protocol packets. | for authenticating their protocol packets. | |||
This document examines the current set of available algorithms with | This document examines the current set of available algorithms, with | |||
interoperability and effective cryptographic authentication | interoperability and effective cryptographic authentication | |||
protection being the principle considerations. Cryptographic | protection being the principal considerations. Cryptographic | |||
authentication of these routing protocols requires the availability | authentication of these routing protocols requires the availability | |||
of the same algorithms in disparate implementations. It is desirable | of the same algorithms in disparate implementations. It is desirable | |||
that newly specified algorithms should be implemented and available | that newly specified algorithms should be implemented and available | |||
in routing protocol implementations because they may be promoted to | in routing protocol implementations because they may be promoted to | |||
requirements at some future time. | requirements at some future time. | |||
Status of this Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This document is not an Internet Standards Track specification; it is | |||
Task Force (IETF). Note that other groups may also distribute | published for informational purposes. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are a candidate for any level of Internet | ||||
Standard; see Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on April 15, 2011. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6094. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction ....................................................3 | |||
2. Intermediate System to Intermediate System (IS-IS) ..............4 | ||||
2. Intermediate System to Intermediate System (IS-IS) . . . . . . 6 | 2.1. Authentication Scheme Selection ............................4 | |||
2.1. Authentication Scheme Selection . . . . . . . . . . . . . 6 | 2.2. Authentication Algorithm Selection .........................5 | |||
2.2. Authentication Algorithm Selection . . . . . . . . . . . . 6 | 3. Open Shortest Path First Version 2 (OSPFv2) .....................5 | |||
3.1. Authentication Scheme Selection ............................6 | ||||
3. Open Shortest Path First Version 2(OSPFv2) . . . . . . . . . . 8 | 3.2. Authentication Algorithm Selection .........................6 | |||
3.1. Authentication Scheme Selection . . . . . . . . . . . . . 8 | 4. Open Shortest Path First Version 3 (OSPFv3) .....................7 | |||
3.2. Authentication Algorithm Selection . . . . . . . . . . . . 8 | 5. Routing Information Protocol Version 2 (RIPv2) ..................7 | |||
5.1. Authentication Scheme Selection ............................7 | ||||
4. Open Shortest Path First Version 3 (OSPFv3) . . . . . . . . . 10 | 5.2. Authentication Algorithm Selection .........................8 | |||
6. Routing Information Protocol for IPv6 (RIPng) ...................8 | ||||
5. Routing Information Protocol Version 2 (RIPv2) . . . . . . . . 11 | 7. Security Considerations .........................................9 | |||
5.1. Authentication Scheme Selection . . . . . . . . . . . . . 11 | 8. Acknowledgements ................................................9 | |||
5.2. Authentication Algorithm Selection . . . . . . . . . . . . 11 | 9. References .....................................................10 | |||
9.1. Normative References ......................................10 | ||||
6. Routing Information Protocol for IPv6 (RIPng) . . . . . . . . 13 | 9.2. Informative References ....................................10 | |||
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 | 1. Introduction | |||
Most routing protocols include three different types of | Most routing protocols include three different types of | |||
authentication schemes: Null authentication, cleartext Password and a | authentication schemes: Null authentication, cleartext password, and | |||
Cryptographic Authentication scheme. Null authentication is | cryptographic authentication. Null authentication is equivalent to | |||
equivalent to having no authentication scheme at all. | having no authentication scheme at all. | |||
In a cleartext scheme, also known as, simple password scheme, the | In a cleartext scheme, also known as a "simple password" scheme, the | |||
password is exchanged completely unprotected and anyone with physical | password is exchanged completely unprotected, and anyone with | |||
access to the network can learn the password and compromise the | physical access to the network can learn the password and compromise | |||
integrity of the routing domain. The simple password scheme protects | the integrity of the routing domain. The simple password scheme | |||
from accidental establishment of routing sessions in a given domain, | protects against accidental establishment of routing sessions in a | |||
but beyond that it offers no additional protection. | given domain, 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 | that is used to generate a message authentication code for each of | |||
the protocol packets. Today, routing protocols that implement | the protocol packets. Today, routing protocols that implement | |||
message authentication codes often use a keyed MD5 [RFC1321] digest. | message authentication codes often use a Keyed-MD5 [RFC1321] digest. | |||
The recent escalating series of attacks on MD5 raise concerns about | The recent escalating series of attacks on MD5 raise concerns about | |||
its remaining useful lifetime. | its remaining useful lifetime. | |||
These attacks may not necessarily result in direct vulnerabilities | These attacks may not necessarily result in direct vulnerabilities | |||
for keyed MD5 digests as message authentication codes because the | for Keyed-MD5 digests as message authentication codes because the | |||
colliding message may not correspond to a syntactically correct | colliding message may not correspond to a syntactically correct | |||
protocol packet. The known collision, pre-image, and second pre- | protocol packet. The known collision, pre-image, and second | |||
image attacks [RFC4270] on MD5 may not increase the effectiveness of | pre-image attacks [RFC4270] on MD5 may not increase the effectiveness | |||
the key recovery attacks on HMAC-MD5. Regardless, there is a need | 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 | felt to deprecate MD5 [RFC1321] as the basis for the Hashed Message | |||
in favor of stronger digest algorithms. | Authentication Code (HMAC) algorithm in favor of stronger digest | |||
algorithms. | ||||
In light of these considerations, there are proposals to replace | In light of these considerations, there are proposals to replace | |||
HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is | HMAC-MD5 with keyed HMAC-SHA [SHS] digests where HMAC-MD5 is | |||
currently mandated in RIPv2 [RFC2453] and IS-IS [ISO] [RFC1195] and | currently mandated in RIPv2 [RFC2453] IS-IS [ISO] [RFC1195], and | |||
keyed-MD5 in OSPFv2 [RFC2328]. | Keyed-MD5 in OSPFv2 [RFC2328]. | |||
OSPFv3 [RFC5340] and RIPng [RFC2080] rely on the IPv6 Authentication | OSPFv3 [RFC5340] and RIPng [RFC2080] rely on the IPv6 Authentication | |||
Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) | Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload (ESP) | |||
[RFC4303] in order to provide integrity, authentication, and/or | [RFC4303] in order to provide integrity, authentication, and/or | |||
confidentiality. | confidentiality. | |||
However, the nature of cryptography is that algorithmic improvement | However, the nature of cryptography is that algorithmic improvement | |||
is an ongoing process and as is the exploration and refinement of | is an ongoing process, as is the exploration and refinement of attack | |||
attack vectors. An algorithm believed to be strong today may be | vectors. An algorithm believed to be strong today may be | |||
demonstrated to be weak tomorrow. Given this, the choice of | demonstrated to be weak tomorrow. Given this, the choice of | |||
preferred algorithm should favor the minimization of the likelihood | preferred algorithm should favor the minimization of the likelihood | |||
of it being compromised quickly. | 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. At any particular time, the | time to adapt to the evolving threats. At any particular time, the | |||
mandatory to implement algorithm(s) might not be specified in the | mandatory-to-implement algorithm(s) might not be specified in the | |||
base protocol specification. As protocols are extended the | base protocol specification. As protocols are extended, the | |||
preference for presently stronger algorithms presents a problem both | preference for presently stronger algorithms presents a problem | |||
on the question of interoperability of existing and future | regarding the question of interoperability of existing and future | |||
implementations with respect to standards and operational preference | implementations with respect to standards, and also regarding | |||
for the configuration as deployed. | operational preference for the configuration as deployed. | |||
It is expected an implementation should support changing of security | It is expected that an implementation should support the changing of | |||
(authentication) keys. Changing the symmetric key used in any HMAC | security (authentication) keys. Changing the symmetric key used in | |||
algorithm on a periodic basis is good security practice. Operators | any HMAC algorithm on a periodic basis is good security practice. | |||
need to plan for this. | 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 an in-service/in-band key change more than | 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 | one key can be active for receiving packets for a session. Some | |||
protocols support a key identifier which allows the two peers of a | protocols support a key identifier that allows the two peers of a | |||
session to have multiple keys simultaneously for a session. | session to have multiple keys simultaneously for a session. | |||
However, these protocols currently manage keys manually (i.e., | However, these protocols currently manage keys manually (i.e., via | |||
operator intervention) or dynamically based on some timer or security | operator intervention) or dynamically based on some timer or security | |||
protocol. | protocol. | |||
2. Intermediate System to Intermediate System (IS-IS) | 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. | Data Units (PDUs) via the authentication TLV (TLV 10) in the PDU. | |||
The base specification [ISO] had provisions only for cleartext | The base specification [ISO] had provisions only for cleartext | |||
passwords. [RFC5304] extends the authentication capabilities by | passwords. [RFC5304] extends the authentication capabilities by | |||
providing cryptographic authentication for IS-IS PDUs. It mandates | providing cryptographic authentication for IS-IS PDUs. It mandates | |||
support for HMAC-MD5. | support for HMAC-MD5. | |||
[RFC5310] adds support for the use of any cryptographic hash function | [RFC5310] adds support for the use of any cryptographic hash function | |||
for authenticating IS-IS PDUs. It in addition to this, also details | for authenticating IS-IS PDUs. In addition to this, [RFC5310] also | |||
how IS-IS can use HMAC construct along with the Secure Hash Algorithm | details how IS-IS can use the HMAC construct along with the Secure | |||
(SHA) family of cryptographic hash functions to secure IS-IS PDUs. | 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 securely interoperate, they | In order for IS-IS implementations to securely interoperate, they | |||
must support one or more authentication schemes in common. This | must support one or more authentication schemes in common. This | |||
section specifies the preference for standards conformant IS-IS | section specifies the preference for standards-conformant IS-IS | |||
implementations, which desire to utilize the security feature. | implementations that use accepted authentication schemes. | |||
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 a | |||
cleartext 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. Operators should not use this scheme as it | broadcast domain. Operators should not use this scheme, as it | |||
provides no protection against an attacker with access to the | provides no protection against an attacker with access to the | |||
broadcast domain as anyone can determine the secret password through | broadcast domain: anyone can determine the secret password through | |||
inspection of the PDU. This mechanism does not provide any | 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] defined the cryptographic authentication scheme for IS-IS. | [RFC5304] defined the cryptographic authentication scheme for IS-IS. | |||
HMAC-MD5 was the only algorithm specified, hence it is mandated. | HMAC-MD5 was the only algorithm specified; hence, it is mandated. | |||
[RFC5310] defined a generic cryptographic scheme and added support | [RFC5310] defined a generic cryptographic scheme and added support | |||
for additional algorithms. Implementations should support [RFC5310] | for additional algorithms. Implementations should support [RFC5310], | |||
as it defines the generic cryptographic authentication scheme. | as it defines the generic cryptographic authentication scheme. | |||
2.2. Authentication Algorithm Selection | 2.2. Authentication Algorithm Selection | |||
For IS-IS implementations to securely interoperate, they must have | For IS-IS implementations to securely interoperate, they must have | |||
support for one or more authentication algorithms in common. | support for one or more authentication algorithms in 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. | |||
The following are the available options for authentication | The following are the available options for authentication | |||
algorithms: | algorithms: | |||
o [RFC5304] mandates the use of HMAC-MD5. | o [RFC5304] mandates the use of HMAC-MD5. | |||
o [RFC5310] does not require a particular algorithm but instead | o [RFC5310] does not require a particular algorithm but instead | |||
supports any digest algorithm (i.e., cryptographic hash function). | supports any digest algorithm (i.e., cryptographic hash | |||
functions). | ||||
As noted earlier, there is a desire to deprecate the use of MD5. | As noted earlier, there is a desire to deprecate MD5. IS-IS | |||
IS-IS implementations will likely migrate to an authentication scheme | implementations will likely migrate to an authentication scheme | |||
supported by [RFC5310] because it is algorithm agnostic. Possible | supported by [RFC5310], because it is algorithm agnostic. Possible | |||
digest algorithms included: SHA-1, SHA-256, SHA-384, and SHA-512. | digest algorithms include SHA-1, SHA-224, SHA-256, SHA-384, and | |||
Picking at least one mandatory-to-implement algorithms is imperative | SHA-512. Picking at least one mandatory-to-implement algorithm is | |||
to ensuring interoperability. | imperative to ensuring interoperability. | |||
3. Open Shortest Path First Version 2(OSPFv2) | 3. Open Shortest Path First Version 2 (OSPFv2) | |||
[RFC2328] includes three different types of authentication schemes: | [RFC2328] includes three different types of authentication schemes: | |||
Null authentication, cleartext password (defined as simple password | Null authentication, cleartext password (defined as "simple password" | |||
in [RFC2328]) and cryptographic authentication. Null authentication | in [RFC2328]), and cryptographic authentication. Null authentication | |||
is semantically equivalent to no 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 that 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. | |||
[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 securely interoperate, they must have one | For OSPF implementations to securely interoperate, they must have one | |||
or more authentication schemes in common. | or more authentication schemes in common. | |||
While all implementations will have NULL auth since it's mandated by | While all implementations will have Null authentication since it's | |||
[RFC2328], its use is not appropriate in any context where the | mandated by [RFC2328], its use is not appropriate in any context | |||
operator wishes to authenticate OSPFv2 packets in their network. | where the operator wishes to authenticate OSPFv2 packets in their | |||
network. | ||||
While all implementations will also have Cleartext Password since | While all implementations will also support a cleartext password | |||
it's mandated by [RFC2328], its use is only appropriate for use when | since it's mandated by [RFC2328], its use is only appropriate when | |||
the operator wants to preclude the accidental introduction of a | the operator wants to preclude the accidental introduction of a | |||
router into the domain. This scheme is patently not useful when an | router into the domain. This scheme is patently not useful when an | |||
operator wants to authenticate the OSPFv2 packets. | operator wants to authenticate the OSPFv2 packets. | |||
Cryptographic Authentication is a mandatory scheme 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 securely interoperate, they must | For OSPFv2 implementations to securely interoperate, they must | |||
support one or more cryptographic authentication algorithms in | support one or more cryptographic authentication algorithms in | |||
common. | common. | |||
The following are the available options for authentication | The following are the available options for authentication | |||
algorithms: | algorithms: | |||
o [RFC2328] specifies the use of HMAC-MD5. | o [RFC2328] specifies the use of Keyed-MD5. | |||
o [RFC5709] specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC- | o [RFC5709] specifies the use of HMAC-SHA-1, HMAC-SHA-256, | |||
SHA256, HMAC-SHA384, and HAMC-512 and mandates support for HMAC- | HMAC-SHA-384, and HMAC-SHA-512, and also mandates support for | |||
SHA256 (HMAC-SHA1 is optional). | HMAC-SHA-256 (HMAC-SHA-1 is optional). | |||
As noted earlier, there is a desired to deprecate the use MD5. Some | As noted earlier, there is a desire to deprecate MD5. Some | |||
alternatives for MD5 are listed in [RFC5709]. | alternatives for MD5 are listed in [RFC5709]. | |||
Possible digest algorithms included: SHA-1, SHA-224, SHA-256, SHA- | Possible digest algorithms include SHA-1, SHA-256, SHA-384, and | |||
384, and SHA-512. Picking one mandatory-to-implement algorithms is | SHA-512. Picking one mandatory-to-implement algorithm is imperative | |||
imperative to ensuring interoperability. | to ensuring interoperability. | |||
4. Open Shortest Path First Version 3 (OSPFv3) | 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. | [RFC4552] 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] | |||
as follows: | as follows: | |||
o [RFC2404] mandates HMAC-SHA1-96. | o [RFC2404] mandates HMAC-SHA-1-96. | |||
o [RFC3566] indicates AES-XCBC-MAC-96 as a should, but its likely | o [RFC3566] indicates AES-XCBC-MAC-96 as a "should", but it's likely | |||
that this will be mandated at some future time. | that this will be mandated at some future time. | |||
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] and then in [RFC1723], has | |||
updated and published as STD56 [RFC2453]. If the Address Family | been updated and published as STD 56, [RFC2453]. If the Address | |||
Identifier of the first (and only the first) entry in the RIPv2 | Family Identifier of the first (and only the first) entry in the | |||
message is 0xFFFF, then the remainder of the entry contains the | RIPv2 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 cleartext password | provides for authenticating packets using a cleartext password | |||
(defined as "simple password" in [RFC2453]) not more than 16 octets | (defined as "simple password" in [RFC2453]) not more than 16 octets | |||
in length. | in length. | |||
[RFC2082] added support for Keyed MD5 authentication, where a digest | [RFC2082] added support for Keyed-MD5 authentication, where a digest | |||
is appended to the end of the RIP packet. [RFC4822] obsoleted | is appended to the end of the RIP packet. [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 securely interoperate they must support | For RIPv2 implementations to securely interoperate, they must support | |||
one or more authentication schemes in common. | one or more authentication schemes in common. | |||
While all implementations will support cleartext password since it's | While all implementations will support a cleartext password since | |||
mandated by [RFC2453], its use is only appropriate for use when the | it's mandated by [RFC2453], its use is only appropriate when the | |||
operator wants to preclude the accidental introduction of a router | operator wants to preclude the accidental introduction of a router | |||
into the domain. This scheme is patently not useful when an operator | into the domain. This scheme is patently not useful when an operator | |||
wants to authenticate the RIPv2 packets. | wants to authenticate the RIPv2 packets. | |||
[RFC2082] mandates the use of an authentication scheme that uses | [RFC2082] mandates the use of an authentication scheme that uses | |||
Keyed MD5. However, [RFC2082] has been obsoleted by [RFC4822] | Keyed-MD5. However, [RFC2082] has been obsoleted by [RFC4822]. | |||
Cryptographic Authentication. Compliant implementations must provide | Compliant implementations must provide support for an authentication | |||
support for an authentication scheme that uses Keyed MD5 but should | scheme that uses Keyed-MD5 but should recognize that this is | |||
recognize that this is superseded by Cryptographic Authentication as | superseded by cryptographic authentication as defined in [RFC4822]. | |||
defined in [RFC4822]. | ||||
Implementations should provide support for [RFC4822] as it specifies | Implementations should provide support for [RFC4822], as it specifies | |||
the RIPv2 Cryptographic Authentication schemes. | the RIPv2 cryptographic authentication schemes. | |||
5.2. Authentication Algorithm Selection | 5.2. Authentication Algorithm Selection | |||
For RIPv2 implementations to securely interoperate they must support | For RIPv2 implementations to securely interoperate, they must support | |||
one or more authentication algorithms in common. | one or more authentication algorithms in common. | |||
The following are the available options for authentication | The following are the available options for authentication | |||
algorithms: | algorithms: | |||
o [RFC2082] specifies the use of keyed MD5. | o [RFC2082] specifies the use of Keyed-MD5. | |||
o [RFC4822] specifies the use of HMAC-MD5, HMAC-SHA1, HMAC-SHA224, | o [RFC4822] specifies the use of Keyed-MD5, HMAC-SHA-1, | |||
HMAC- SHA256, HMAC-SHA384 and HMAC-SHA512. | HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. | |||
As noted earlier, there is a desire to deprecate the use MD5. Some | As noted earlier, there is a desire to deprecate MD5. Some | |||
alternatives for MD5 are listed in [RFC4822]. Possible digest | alternatives for MD5 are listed in [RFC4822]. Possible digest | |||
algorithms included: SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. | algorithms include SHA-1, SHA-256, SHA-384, and SHA-512. Picking one | |||
Picking one mandatory-to-implement algorithms is imperative to | mandatory-to-implement algorithm is imperative to ensuring | |||
ensuring interoperability. | interoperability. | |||
6. Routing Information Protocol for IPv6 (RIPng) | 6. Routing Information Protocol for IPv6 (RIPng) | |||
RIPng [RFC2080] relies on the IPv6 Authentication Header (AH) | RIPng [RFC2080] 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. | |||
The algorithm requirements for AH and ESP are described in [RFC4835] | The algorithm requirements for AH and ESP are described in [RFC4835] | |||
as follows: | as follows: | |||
o [RFC2404] mandates HMAC-SHA1-96. | o [RFC2404] mandates HMAC-SHA-1-96. | |||
o [RFC3566] indicates AES-XCBC-MAC-96 as a should, but its likely | o [RFC3566] indicates AES-XCBC-MAC-96 as a "should", but it's likely | |||
that this will be mandated at some future time. | that this will be mandated at some future time. | |||
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 keyed digests may be significantly | protocol messages protected by keyed digests may be significantly | |||
more limited than that of other data, however preference for one | more limited than that of other data; however, preference for one | |||
family of algorithms over another may also change independently of | family of algorithms over another may also change independently of | |||
the 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 that various routing protocols should employ to ensure | |||
interoperability between disparate implementations. | interoperability between disparate implementations. | |||
8. IANA Considerations | 8. Acknowledgements | |||
This document has no actions for IANA. | ||||
9. Acknowledgements | ||||
We would like to thank Joel Jaeggli, Sean Turner and Adrian Farrel | We would like to thank Joel Jaeggli, Sean Turner, and Adrian Farrel | |||
for their comments and feedback on this draft that resulted in | for their comments and feedback on this document, which resulted in | |||
significant improvement of the same. | significant improvement of the same. | |||
10. References | 9. References | |||
10.1. Normative References | 9.1. Normative References | |||
[ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate | [ISO] "Intermediate system to Intermediate system routing | |||
system routeing information exchange protocol for use in | information exchange protocol for use in conjunction with | |||
conjunction with the Protocol for providing the | the protocol for providing the connectionless-mode | |||
Connectionless-mode Network Service (ISO 8473)". | network service", ISO/IEC 10589:1992 (ISO 8473). | |||
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and | |||
dual environments", RFC 1195, December 1990. | dual environments", RFC 1195, December 1990. | |||
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, | [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, | |||
January 1997. | January 1997. | |||
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | |||
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, | [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, | |||
November 1998. | November 1998. | |||
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic | [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic | |||
Authentication", RFC 4822, February 2007. | Authentication", RFC 4822, February 2007. | |||
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation | [RFC4835] Manral, V., "Cryptographic Algorithm Implementation | |||
Requirements for Encapsulating Security Payload (ESP) and | Requirements for Encapsulating Security Payload (ESP) and | |||
Authentication Header (AH)", RFC 4835, April 2007. | Authentication Header (AH)", RFC 4835, April 2007. | |||
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic | [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic | |||
Authentication", RFC 5304, October 2008. | Authentication", RFC 5304, October 2008. | |||
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | |||
and M. Fanto, "IS-IS Generic Cryptographic | and M. Fanto, "IS-IS Generic Cryptographic | |||
Authentication", RFC 5310, February 2009. | Authentication", RFC 5310, February 2009. | |||
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | |||
for IPv6", RFC 5340, July 2008. | for IPv6", RFC 5340, July 2008. | |||
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., | [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., | |||
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic | Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic | |||
Authentication", RFC 5709, October 2009. | Authentication", RFC 5709, October 2009. | |||
10.2. Informative References | 9.2. Informative References | |||
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |||
April 1992. | April 1992. | |||
[RFC1388] Malkin, G., "RIP Version 2 Carrying Additional | [RFC1388] Malkin, G., "RIP Version 2 Carrying Additional | |||
Information", RFC 1388, January 1993. | Information", RFC 1388, January 1993. | |||
[RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional | [RFC1723] Malkin, G., "RIP Version 2 - Carrying Additional | |||
Information", STD 56, RFC 1723, November 1994. | Information", RFC 1723, November 1994. | |||
[RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 | [RFC2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", | |||
Authentication", RFC 2082, January 1997. | RFC 2082, January 1997. | |||
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within | [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within | |||
ESP and AH", RFC 2404, November 1998. | ESP and AH", RFC 2404, November 1998. | |||
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm | [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 | |||
and Its Use With IPsec", RFC 3566, September 2003. | Algorithm and Its Use With IPsec", RFC 3566, | |||
September 2003. | ||||
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic | [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic | |||
Hashes in Internet Protocols", RFC 4270, November 2005. | Hashes in Internet Protocols", RFC 4270, November 2005. | |||
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, | [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, | |||
December 2005. | December 2005. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
RFC 4303, December 2005. | RFC 4303, December 2005. | |||
[RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP): | [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality | |||
The Binary Encoding Option", RFC 4522, June 2006. | for OSPFv3", RFC 4552, June 2006. | |||
[SHS] "National Institute of Standards and Technology (NIST), | [SHS] "Secure Hash Standard (SHS)", National Institute of | |||
FIPS Publication 180-3: Secure Hash Standard", | Standards and Technology (NIST) FIPS Publication 180-3, | |||
October 2008. | October 2008. | |||
Authors' Addresses | Authors' Addresses | |||
Manav Bhatia | Manav Bhatia | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Bangalore, | Bangalore | |||
India | India | |||
Phone: | EMail: manav.bhatia@alcatel-lucent.com | |||
Email: manav.bhatia@alcatel-lucent.com | ||||
Vishwas | Vishwas Manral | |||
IP Infusion | IP Infusion | |||
1188 E. Arques Ave. | ||||
Sunnyvale, CA 94089 | ||||
USA | USA | |||
Phone: | Phone: 408-400-1900 | |||
Email: vishwas@ipinfusion.com | EMail: vishwas@ipinfusion.com | |||
End of changes. 100 change blocks. | ||||
227 lines changed or deleted | 214 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/ |