draft-ietf-opsec-igp-crypto-requirements-01.txt   draft-ietf-opsec-igp-crypto-requirements-02.txt 
Internet Draft September 2010 Internet Draft October 2010
Network Working Group Manav Bhatia Network Working Group Manav Bhatia
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Expires: March 28, 2011 Vishwas Manral Expires: April 2011 Vishwas Manral
Intended Status: Informational IP Infusion Intended Status: Informational IP Infusion
September 27, 2010 October 2010
Cryptographic Authentication Algorithm Implementation Cryptographic Authentication Algorithm Implementation
Requirements for Routing Protocols Requirements for Routing Protocols
draft-ietf-opsec-igp-crypto-requirements-01.txt draft-ietf-opsec-igp-crypto-requirements-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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 may 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, so new
implementations should support this scheme. implementations should support this scheme.
2.2 Authentication Algorithm Selection 2.2 Authentication Algorithm Selection
For IS-IS implementations to interoperate, they must have support for For IS-IS implementations to interoperate with the use of security,
one or more authentication algorithms in common. they must have 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.
[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 may get
deprecated in favor of HMAC-SHA-1 as defined in [RFC5310] in the deprecated in favor of HMAC-SHA-1 as defined in [RFC5310] in the
future deployments, so new implementations should support this future deployments, so new implementations should support this
algorithm. algorithm.
skipping to change at page 5, line 49 skipping to change at page 5, line 50
RFC 5709 [RFC5709] adds support for the use of the SHA family of hash RFC 5709 [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 interoperate with the use of security,
they must have one or more authentication schemes in common. This they must have one or more authentication schemes in common. This
section specifies the preference for standards conformant OSPFv2 section specifies the preference for standards conformant OSPFv2
implementations, which desire to utilize the security feature. implementations, which desire to utilize the security feature.
While [RFC2328] mandates the use of NULL Authentication, its use is While all implementations will have NULL auth since it's mandated by
deprecated in any context where the operator wishes to authenticate [RFC2328], its use is not appropriate in any context where the
the OSPFv2 packets in their network. operator wishes to authenticate OSPFv2 packets in their network.
Similarly Simple Password, also mandatory per [RFC2328], should be Similarly Simple Password, also mandatory per [RFC2328], should be
used when the operator only wants to preclude the accidental used when the operator only wants to preclude the accidental
introduction of a router into the domain. This scheme is not useful introduction of a router into the domain. This scheme is not useful
when the operator wants to authenticate the OSPFv2 packets. when the operator wants to authenticate the OSPFv2 packets.
Cryptographic Authentication is a mandatory scheme as defined in Cryptographic Authentication is a mandatory scheme as 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, they must support one or For OSPFv2 implementations to interoperate with the use of security,
more cryptographic authentication algorithms in common. they must support one or more cryptographic authentication algorithms
in common.
[RFC2328] states that implementations must offer keyed MD5 [RFC2328] states that implementations must offer keyed MD5
authentication. It is likely that this will be deprecated in favor of authentication. It is likely that this will be deprecated in favor of
HMAC-SHA-1 and HMAC-SHA-256 [RFC5709] in future deployments, so new HMAC-SHA-1 and HMAC-SHA-256 [RFC5709] in future deployments, so new
implementations should support these algorithms. implementations should support these algorithms.
Operators should consider migration to HMAC-SHA-256 if they desire a Operators should consider migration to HMAC-SHA-256 if they desire a
stronger cryptographic algorithm for authentication of OSPFv2 stronger cryptographic algorithm for authentication of OSPFv2
packets. packets.
skipping to change at page 7, line 38 skipping to change at page 7, line 40
implementations must provide support for Keyed-MD5 but should implementations must provide support for 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] Cryptographic
Authentication as it will likely be the preferred authentication Authentication as it will likely be the preferred authentication
method in the future. method in the future.
5.2 Authentication Algorithm Selection 5.2 Authentication Algorithm Selection
For RIPv2 implementations to interoperate, one or more authentication For RIPv2 implementations to interoperate with the use of security,
algorithms must be supported in common that can be used for one or more authentication algorithms must be supported in common
authentication. that can be used for authentication.
The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be The keyed MD5 algorithm in [RFC2082] and [RFC4822] must be
implemented. It is our belief that it will be superseded by HMAC-SHA- implemented. It is our belief that it will be superseded by HMAC-SHA-
1 also available in [RFC4822]. Keyed MD5 must be implemented for 1 also available in [RFC4822]. Keyed MD5 must be implemented for
interoperability purposes, but its use may be deprecated in the interoperability purposes, but its use may be deprecated in the
future. future.
Implementations should provide support for HMAC-SHA-1 used in Implementations should provide support for HMAC-SHA-1 used in
preference to keyed MD5 the future. preference to keyed MD5 the future.
 End of changes. 8 change blocks. 
14 lines changed or deleted 16 lines changed or added

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