draft-ietf-opsec-igp-crypto-requirements-03.txt   draft-ietf-opsec-igp-crypto-requirements-04.txt 
OPSEC Working Group M. Bhatia OPSEC Working Group M. Bhatia
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational V. Manral Intended status: Informational V. Manral
Expires: April 13, 2011 IP Infusion Expires: April 15, 2011 IP Infusion
October 10, 2010 October 12, 2010
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-03 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 Hash
Algorithm) family of hash functions for the purpose of authenticating Algorithm) family of hash functions for the purpose of authenticating
routing protocol packets for RIP, IS-IS and OSPF. routing protocol packets for RIP, IS-IS and OSPF.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2011. This Internet-Draft will expire on April 15, 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
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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 pre-
image attacks [RFC4270] on MD5 may not increase the effectiveness of image attacks [RFC4270] on MD5 may not increase the effectiveness of
the key recovery attacks on HMAC-MD5. Regardless, there is a need 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 deprecated MD5 [RFC1321] as the basis for the HMAC algorithm
in favor of stronger digest algorithms. 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] and 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 and as is the exploration and refinement of
attack vectors. An algorithm believed to be strong today may be attack 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
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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, which desire to utilize the 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
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. We believe that operators should not use this broadcast domain. Operators should not use this scheme as it
scheme as it provides no protection against an attacker with access provides no protection against an attacker with access to the
to the broadcast domain as anyone can determine the secret password broadcast domain as anyone can determine the secret password through
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] mandates the use of HMAC-MD5 for cryptographically [RFC5304] defined the cryptographic authentication scheme for IS-IS.
authenticating the IS-IS PDUs. It is likely that this will get HMAC-MD5 was the only algorithm specified, hence it is mandated.
deprecated in favor of the generic cryptographic authentication [RFC5310] defined a generic cryptographic scheme and added support
scheme defined in [RFC5310] in the future deployments. for additional algorithms. Implementations should support [RFC5310]
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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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 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.
While all implementations will also have Cleartext Password since While all implementations will also have Cleartext Password since
it's mandated by [RFC2328] , its use is only appropriate for use when it's mandated by [RFC2328], its use is only appropriate for use 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 HMAC-MD5.
o [RFC5304] specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC- o [RFC5709] specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC-
SHA256, HMAC-SHA384, and HAMC-512 and mandates support for HMAC- SHA256, HMAC-SHA384, and HAMC-512 and mandates support for HMAC-
SHA256 (HMAC-SHA1 is optional). SHA256 (HMAC-SHA1 is optional).
As noted earlier, there is a desired to deprecate the use MD5. Some As noted earlier, there is a desired to deprecate the use MD5. Some
alternatives for MD5 are listed in [RFC5304] alternatives for MD5 are listed in [RFC5709].
Possible digest algorithms included: SHA-1, SHA-224, SHA-256, SHA- Possible digest algorithms included: SHA-1, SHA-224, SHA-256, SHA-
384, and SHA-512. Picking one mandatory-to-implement algorithms is 384, and SHA-512. Picking one mandatory-to-implement algorithms is
imperative to ensuring interoperability. imperative 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. [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. as follows:
o [RFC2404] mandates HMAC-SHA1-96.
o [RFC3566] indicates AES-XCBC-MAC-96 as a should, but its likely
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], 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 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.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
Picking one mandatory-to-implement algorithms is imperative to Picking one mandatory-to-implement algorithms is imperative to
ensuring interoperability. ensuring 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]
and are not discussed here. as follows:
o [RFC2404] mandates HMAC-SHA1-96.
o [RFC3566] indicates AES-XCBC-MAC-96 as a should, but its likely
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
skipping to change at page 16, line 7 skipping to change at page 16, line 7
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. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Acknowledgements 9. Acknowledgements
We would like to thank Joel Jaeggli for this comments and feedback on We would like to thank Joel Jaeggli, Sean Turner and Adrian Farrel
this draft that resulted in significant improvement of the same. for their comments and feedback on this draft that resulted in
significant improvement of the same.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate
system routeing information exchange protocol for use in system routeing information exchange protocol for use in
conjunction with the Protocol for providing the conjunction with the Protocol for providing the
Connectionless-mode Network Service (ISO 8473)". Connectionless-mode Network Service (ISO 8473)".
skipping to change at page 18, line 11 skipping to change at page 18, line 11
[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", STD 56, RFC 1723, November 1994.
[RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 [RFC2082] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5
Authentication", RFC 2082, January 1997. Authentication", RFC 2082, January 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 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): [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP):
 End of changes. 14 change blocks. 
21 lines changed or deleted 39 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/