One document matched: draft-ietf-opsec-igp-crypto-requirements-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-ietf-opsec-igp-crypto-requirements-04"
ipr="trust200902">
<front>
<title abbrev="Crypto Reqs for Routing Protocols">Summary of Cryptographic Authentication
Algorithm Implementation Requirements for Routing Protocols</title>
<author fullname="Manav Bhatia" initials="M.B." surname="Bhatia">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<code></code>
<region></region>
<country>India</country>
</postal>
<phone></phone>
<email>manav.bhatia@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Vishwas" initials="V." surname="Manral">
<organization>IP Infusion</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country>USA</country>
</postal>
<phone></phone>
<email>vishwas@ipinfusion.com</email>
</address>
</author>
<date day="12" month="October" year="2010" />
<area> Operations and Management Area</area>
<workgroup>OPSEC Working Group</workgroup>
<abstract>
<t>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. </t>
<t> To encourage interoperability between disparate implementations, it is
imperative that we specify the expected minimal set of algorithms thereby ensuring that
there is at least one algorithm that all implementations will have in common. </t>
<t> Similarly RIPng and OSPFv3 support IPSec algorithms for authenticating their protocol packets. </t>
<t> This document examines the current set of available algorithms with interoperability
and effective cryptographic authentication protection being the principle considerations.
Cryptographic authentication of these routing protocols requires the availability of the
same algorithms in disparate implementations. It is desirable that newly specified algorithms
should be implemented and available in routing protocol implementations because they
may be promoted to requirements at some future time. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Most routing protocols include three different types of authentication schemes:
Null authentication, cleartext Password and a Cryptographic Authentication scheme.
Null authentication is equivalent to having no authentication scheme at all. </t>
<t> In a cleartext scheme, also known as, simple password scheme, the password is
exchanged completely unprotected and anyone with physical access to the network
can learn the password and compromise the integrity of the routing domain.
The simple password scheme protects from accidental establishment of routing sessions
in a given domain, but beyond that it offers no additional protection. </t>
<t> In a cryptographic authentication scheme, routers share a secret key which is
used to generate a message authentication code for each of the protocol packets.
Today, routing protocols that implement message authentication codes often use a keyed
MD5 <xref target="RFC1321"></xref> digest. The recent escalating series of attacks on
MD5 raise concerns about its remaining useful lifetime. </t>
<t> These attacks may not necessarily result in direct vulnerabilities for keyed MD5 digests as
message authentication codes because the colliding message may not correspond to a
syntactically correct protocol packet. The known collision, pre-image, and second pre-image
attacks <xref target="RFC4270"></xref> on MD5 may not increase the effectiveness of the key recovery attacks on HMAC-MD5.
Regardless, there is a need felt to deprecated MD5 <xref target="RFC1321"></xref> as the basis for the HMAC algorithm in
favor of stronger digest algorithms. </t>
<t> In light of these considerations, there are proposals to replace HMAC-MD5 with keyed HMAC-SHA <xref target="SHS"></xref>
digests where HMAC-MD5 is currently mandated in RIPv2 <xref target="RFC2453"></xref>
and IS-IS <xref target="ISO"></xref> <xref target="RFC1195"></xref> and
keyed-MD5 in OSPFv2 <xref target="RFC2328"></xref>. </t>
<t> OSPFv3 <xref target="RFC5340"></xref> and RIPng <xref target="RFC2080"></xref>
rely on the IPv6 Authentication Header (AH) <xref target="RFC4302"></xref> and
IPv6 Encapsulating Security Payload (ESP) <xref target="RFC4303"></xref>
in order to provide integrity, authentication, and/or confidentiality.</t>
<t> 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. </t>
<t> It should be recognized that preferred algorithm(s) will change over time to adapt to the evolving threats.
At any particular time, the mandatory to implement algorithm(s) might not be specified in the base protocol
specification. As protocols are extended the preference for presently stronger algorithms presents a problem
both on the question of interoperability of existing and future implementations with respect to standards and
operational preference for the configuration as deployed. </t>
<t> It is expected an implementation should support changing of security (authentication) keys.
Changing the symmetric key used in any HMAC algorithm on a periodic basis is good security practice.
Operators need to plan for this. </t>
<t> Implementations can support in-service key change so that no control packets are lost.
During an in-service/in-band key change more than one key can be active for receiving packets for a session.
Some protocols support a key identifier which allows the two peers of a session to have multiple keys
simultaneously for a session. </t>
<t> However, these protocols currently manage keys manually (i.e., operator intervention) or dynamically based on
some timer or security protocol.
</t>
</section>
<section title="Intermediate System to Intermediate System (IS-IS)">
<t>The IS-IS specification allows for authentication of its Protocol Data Units
(PDUs) via the authentication TLV (TLV 10) in the PDU.
The base specification <xref target="ISO"></xref> had provisions only for cleartext passwords.
<xref target="RFC5304"></xref> extends the authentication capabilities by providing
cryptographic authentication for IS-IS PDUs. It mandates support for HMAC-MD5. </t>
<t> <xref target="RFC5310"></xref> adds support for the use of any cryptographic hash
function for authenticating IS-IS PDUs. It in addition to this, also details how IS-IS can use
HMAC construct along with the Secure Hash Algorithm (SHA) family of
cryptographic hash functions to secure IS-IS PDUs. </t>
<section title="Authentication Scheme Selection">
<t>
In order for IS-IS implementations to securely interoperate, they must
support one or more authentication schemes in common. This section
specifies the preference for standards conformant IS-IS implementations,
which desire to utilize the security feature.
</t>
<t>
The earliest interoperability requirement for authentication as stated by
<xref target="ISO"></xref> <xref target="RFC1195"></xref>
required all implementations to support cleartext Password. This authentication
scheme's utility is limited to precluding the accidental introduction of a new IS into a
broadcast domain. Operators should not use this scheme as it
provides no protection against an attacker with access to the broadcast domain as
anyone can determine the secret password through inspection of the PDU. This
mechanism does not provide any significant level of security and should be avoided.
</t>
<t>
<xref target="RFC5304"></xref> defined the cryptographic authentication scheme for IS-IS.
HMAC-MD5 was the only algorithm specified, hence it is mandated.
<xref target="RFC5310"></xref> defined a generic cryptographic scheme and added support
for additional algorithms. Implementations should support <xref target="RFC5310"></xref>
as it defines the generic cryptographic authentication scheme.
</t>
</section>
<section title="Authentication Algorithm Selection">
<t>
For IS-IS implementations to securely interoperate, they must have support for one or more authentication algorithms in common.
</t>
<t>
This section details the authentication algorithm requirements for standards conformant IS-IS implementations.
</t>
<t>
The following are the available options for authentication algorithms:
</t>
<t><list style="symbols">
<t><xref target="RFC5304"></xref> mandates the use of HMAC-MD5. </t>
<t><xref target="RFC5310"></xref> does not require a particular algorithm but instead
supports any digest algorithm (i.e., cryptographic hash function). </t>
</list></t>
<t>
As noted earlier, there is a desire to deprecate the use of MD5. IS-IS implementations will
likely migrate to an authentication scheme supported by <xref target="RFC5310"></xref>
because it is algorithm agnostic. Possible digest algorithms included: SHA-1,
SHA-256, SHA-384, and SHA-512. Picking at least one mandatory-to-implement
algorithms is imperative to ensuring interoperability.
</t>
</section>
</section>
<section title="Open Shortest Path First Version 2(OSPFv2)">
<t>
<xref target="RFC2328"></xref> includes three different types of authentication schemes:
Null authentication, cleartext password (defined as simple password in <xref target="RFC2328"></xref>)
and cryptographic authentication. Null authentication is semantically equivalent to no authentication. </t>
<t> In the cryptographic authentication scheme, the OSPFv2 routers on a common network/subnet are
configured with a shared secret which is used to generate a keyed MD5 digest for each packet.
A monotonically increasing sequence number scheme is used to protect against replay attacks. </t>
<t> <xref target="RFC5709"></xref> adds support for the use of the SHA family of hash algorithms
for authentication of OSPFv2 packets. </t>
<section title="Authentication Scheme Selection">
<t> For OSPF implementations to securely interoperate, they must have one or more authentication schemes in common. </t>
<t> While all implementations will have NULL auth since it's mandated by <xref target="RFC2328"></xref>,
its use is not appropriate in any context where the operator wishes to authenticate OSPFv2 packets in their network. </t>
<t> While all implementations will also have Cleartext Password since it's mandated by <xref target="RFC2328"></xref>,
its use is only appropriate for use when the operator wants to preclude the accidental introduction of a
router into the domain. This scheme is patently not useful when an operator wants to authenticate the OSPFv2 packets. </t>
<t> Cryptographic Authentication is a mandatory scheme defined in <xref target="RFC2328"></xref>
and all conformant implementations must support this. </t>
</section>
<section title="Authentication Algorithm Selection">
</section>
<t>
For OSPFv2 implementations to securely interoperate, they must support one or more
cryptographic authentication algorithms in common. </t>
<t> The following are the available options for authentication algorithms: </t>
<t><list style="symbols">
<t><xref target="RFC2328"></xref> specifies the use of HMAC-MD5. </t>
<t><xref target="RFC5709"></xref> specifies the use of HMAC-SHA1, HMAC-SHA224, HMAC-
SHA256, HMAC-SHA384, and HAMC-512 and mandates support for
HMAC-SHA256 (HMAC-SHA1 is optional).
</t>
</list></t>
<t> As noted earlier, there is a desired to deprecate the use MD5. Some alternatives for MD5
are listed in <xref target="RFC5709"> </xref>. </t>
<t> 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. </t>
</section>
<section title="Open Shortest Path First Version 3 (OSPFv3)">
<t>
OSPFv3 <xref target="RFC5340"> </xref> relies on the IPv6 Authentication Header
(AH) <xref target="RFC4302"> </xref> and IPv6 Encapsulating Security Payload (ESP)
<xref target="RFC4303"> </xref> in order to provide integrity, authentication, and/or confidentiality. </t>
<t> <xref target="RFC4522"> </xref> mandates the use of ESP for authenticating OSPFv3 packets.
The implementations could also provide support for using AH to protect these packets. </t>
<t> The algorithm requirements for AH and ESP are described in
<xref target="RFC4835"> </xref> as follows: </t>
<t><list style="symbols">
<t><xref target="RFC2404"> </xref> mandates HMAC-SHA1-96. </t>
<t> <xref target="RFC3566"> </xref> indicates AES-XCBC-MAC-96 as a should, but
its likely that this will be mandated at some future time.</t>
</list></t>
</section>
<section title="Routing Information Protocol Version 2 (RIPv2)">
<t> RIPv2, originally specified in <xref target="RFC1388"> </xref>,
then <xref target="RFC1723"> </xref>, has been updated and published as
STD56 <xref target="RFC2453"> </xref>. If the Address Family Identifier of the
first (and only the first) entry in the RIPv2 message is 0xFFFF, then the remainder of the
entry contains the authentication information. The <xref target="RFC2453"> </xref>
version of the protocol provides for authenticating packets using a cleartext
password (defined as "simple password" in <xref target="RFC2453"> </xref>)
not more than 16 octets in length. </t>
<t> <xref target="RFC2082"> </xref> added support for Keyed MD5 authentication,
where a digest is appended to the end of the RIP packet. <xref target="RFC4822"> </xref>
obsoleted <xref target="RFC2082"> </xref> and added the SHA family of hash algorithms
to the list of cryptographic authentications that can be used to protect RIPv2,
whereas <xref target="RFC2082"> </xref> previously specified only the use of Keyed MD5. </t>
<section title="Authentication Scheme Selection">
<t> For RIPv2 implementations to securely interoperate they must support one or more authentication schemes in common. </t>
<t> While all implementations will support cleartext password since it's mandated by
<xref target="RFC2453"> </xref>, its use is only appropriate for use when the operator
wants to preclude the accidental introduction of a router into the domain.
This scheme is patently not useful when an operator wants to authenticate the RIPv2 packets. </t>
<t> <xref target="RFC2082"> </xref> mandates the use of an authentication scheme that
uses Keyed MD5. However, <xref target="RFC2082"> </xref> has been obsoleted by
<xref target="RFC4822"> </xref> Cryptographic Authentication. Compliant implementations must
provide support for an authentication scheme that uses Keyed MD5 but
should recognize that this is superseded by Cryptographic Authentication as defined in
<xref target="RFC4822"> </xref>. </t>
<t> Implementations should provide support for <xref target="RFC4822"> </xref>
as it specifies the RIPv2 Cryptographic Authentication schemes. </t>
</section>
<section title="Authentication Algorithm Selection">
<t> For RIPv2 implementations to securely interoperate they must support one or more authentication algorithms in common. </t>
<t> The following are the available options for authentication algorithms: </t>
<t><list style="symbols">
<t><xref target="RFC2082"></xref> specifies the use of keyed MD5. </t>
<t><xref target="RFC4822"></xref> specifies the use of HMAC-MD5, HMAC-SHA1, HMAC-SHA224, HMAC-
SHA256, HMAC-SHA384 and HMAC-SHA512. </t>
</list></t>
<t>
As noted earlier, there is a desire to deprecate the use MD5. Some alternatives for MD5 are listed in
<xref target="RFC4822"></xref>. 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.
</t>
</section>
</section>
<section title="Routing Information Protocol for IPv6 (RIPng)">
<t> RIPng <xref target="RFC2080"></xref> relies on the IPv6 Authentication Header
(AH) <xref target="RFC4302"> </xref> and IPv6 Encapsulating Security Payload (ESP)
<xref target="RFC4303"> </xref> in order to provide integrity, authentication, and/or confidentiality.
</t>
<t> The algorithm requirements for AH and ESP are described in
<xref target="RFC4835"> </xref> as follows: </t>
<t><list style="symbols">
<t><xref target="RFC2404"> </xref> mandates HMAC-SHA1-96. </t>
<t> <xref target="RFC3566"> </xref> indicates AES-XCBC-MAC-96 as a should, but
its likely that this will be mandated at some future time.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The cryptographic mechanisms referenced in this document provide only
authentication algorithms. These algorithms do not provide confidentiality.
Encrypting the content of the packet and thereby providing confidentiality is not
considered in the definition of the routing protocols.
</t>
<t>
The cryptographic strength of the HMAC depends upon the cryptographic strength
of the underlying hash function and on the size and quality of the key. The feasibility
of attacking the integrity of routing protocol messages protected by keyed digests
may be significantly more limited than that of other data, however preference for
one family of algorithms over another may also change independently of the
perceived risk to a particular protocol.
</t>
<t>
To ensure greater security, the keys used should be changed periodically
and implementations must be able to store and use more than one key at
the same time. Operational experience suggests that the lack of periodic rekeying
is a source of significant exposure and that the lifespan of shared keys in the
network is frequently measured in years.
</t>
<t>
While simple password schemes are well represented in the document
series and in conformant implementations of the protocols, the inability to
offer either integrity or identity protection are sufficient reason to strongly discourage their use.
</t>
<t>
This document concerns itself with the selection of cryptographic algorithms for use in the
authentication of routing protocol packets being exchanged between adjacent routing
processes. The cryptographic algorithms identified in this document are not
known to be broken at the current time, and ongoing cryptographic research so
far leads us to believe that they will likely remain secure in the foreseeable future.
We expect that new revisions of this document will be issued in the future to reflect current
thinking on the algorithms various routing protocols should employ to ensure interoperability
between disparate implementations.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
We would like to thank Joel Jaeggli, Sean Turner and Adrian Farrel for their
comments and feedback on this draft that
resulted in significant improvement of the same.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc ?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.1195'?>
<?rfc include='reference.RFC.2453'?>
<?rfc include='reference.RFC.4822'?>
<?rfc include='reference.RFC.5304'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.4835'?>
<?rfc include='reference.RFC.2080'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.5709'?>
<reference anchor="ISO">
<front>
<title>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)
</title>
<author fullname="" initials="" surname="">
<organization>
ISO/IEC 10589:1992
</organization>
</author>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc ?>
<?rfc include='reference.RFC.1321'?>
<?rfc include='reference.RFC.4302'?>
<?rfc include='reference.RFC.4303'?>
<?rfc include='reference.RFC.4522'?>
<?rfc include='reference.RFC.1388'?>
<?rfc include='reference.RFC.1723'?>
<?rfc include='reference.RFC.2082'?>
<?rfc include='reference.RFC.4270'?>
<?rfc include='reference.RFC.2404'?>
<?rfc include='reference.RFC.3566'?>
<reference anchor="SHS">
<front>
<title>National Institute of Standards and Technology (NIST),
FIPS Publication 180-3: Secure Hash Standard </title>
<date month="October" year="2008" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:33:26 |