Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols
draft-ietf-opsec-igp-crypto-requirements-04

[Ballot comment]
Moved one small point from my previous Discuss. WOuld be nice to get it fixed.

You have caught most cases of ...

  In order for ... implementations to interoperate, they must support
  one or more authentication schemes in common.

... with good change to include "with the use of security"

However, I still see issues in sections 2.2 (first line), 3.2 (first line), 5.2 (first line)

[Ballot discuss]
[updated to remove one issue]

In section 4.2, Authentication Algorithm Selection (in the OSPFv2 section) states:

    Implementations must provide support for
  HMAC-SHA-256 as this will become the algorithm of choice.

I think this should really be HMAC-SHA-1.  This would be consistent with the guidance for all other protocols.
However, the remainder of 4.2 is consistent with the cited text.  Is there a good reason that OSPFv2 would
jump directly to HMAC-SHA-256 when all the other protocols are migrating to HMAC-SHA-1?

[Ballot discuss]
Discuss-Discuss:

I could not sort out the real goals of this document.  I am unsure whether we are setting the stage for a BCP,
or whether this was supposed to be a BCP.  The document reiterates MUSTs and SHOULDs from the various
documents, and collecting this information into one document is a useful exercise, but it did not seem to add
a lot of new guidance.  What is the core message?

Actionable:

In section 4.2, Authentication Algorithm Selection (in the OSPFv2 section) states:

    Implementations must provide support for
  HMAC-SHA-256 as this will become the algorithm of choice.

I think this should really be HMAC-SHA-1.  This would be consistent with the guidance for all other protocols.
However, the remainder of 4.2 is consistent with the cited text.  Is there a good reason that OSPFv2 would
jump directly to HMAC-SHA-256 when all the other protocols are migrating to HMAC-SHA-1?

[Ballot comment]
1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.  Keep the 2nd (that's where the RFC editor will put it).

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.

4) Sec 6: Is there something missing from the end of this sentence maybe "packet":

  If the Address Family Identifier of the
  first (and only the first) entry in the message is 0xFFFF, then the
  remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no

[Ballot discuss]
1) Is this draft supposed to be a BCP instead of informational?  In the title it has "Best Practices" and in the last sentence of the security considerations it has:

  We expect that new revisions of this document
  will be issued in the future to reflect current thinking on best
  practice in this area.

2) 2119 requirements language is used only to specify what's already in RFCs - shouldn't there be requirements about switching to a new algorithm?  If it's just listing what's out there now, then do that and remove all the talk about deprecating this or that algorithm.  If you're suggesting that algorithms be deprecated, then do that and use 2119 language.

3) Because there are no new recommendations this draft ought to called something like "A survey of IGP Crypto".  The purpose of this draft is very unclear to me.

4) If this document is in fact providing advice about the use of authentication in IGP implementations and deployments, ad the name of the document implies, then I agree with Adrian that the following issues need to be addressed:

- does an implementation support key change?
- how often is key change recommended?
- can key change be in-service?
- how many keys can be configured at once?
- how many keys can be active at once?
- can key change be dynamic (i.e. by a protocol)
- can dynamic key change be managed by the IGP or does it need a second protocol to manage the keys?

[Ballot discuss]
In section 4.2, Authentication Algorithm Selection (in the OSPFv2 section) states:

    Implementations must provide support for
  HMAC-SHA-256 as this will become the algorithm of choice.

I think this should really be HMAC-SHA-1

[Ballot comment]
These are drafty:

1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.  Keep the 2nd (that's where the RFC editor will put it).

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.

4) Sec 6: Is there something missing from the end of this sentence maybe "packet":

  If the Address Family Identifier of the
  first (and only the first) entry in the message is 0xFFFF, then the
  remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no

[Ballot discuss]
1) Is this draft supposed to be a BCP instead of informational?  In the title it has "Best Practices" and in the last sentence of the security considerations it has:

We expect that new revisions of this document
  will be issued in the future to reflect current thinking on best
  practice in this area.

2) 2119 requirements language is used only to specify what's already in RFCs - shouldn't there be requirements about switching?  If it's just listing what's out there now, then do that and remove all the talk about deprecating this or that algorithm.  If you're suggesting that algorithms be deprecated, then do that and use 2119 language.

3) Because there are no new recommendations this draft ought to called something like "A survey of IGP Crypto".  The purpose of this draft is very unclear to me.

[Ballot discuss]
Amplifying others' discusses on the use of 2119 language in this document - as written, this document appears to be profiling other protocols, relaxing MUSTs. For example, section 4.1 calls out three MUSTs in 2328 and says that you only need implement one of them to be conformant. If something else formally changed the requirements for the other two, please provide a reference. If that hasn't happened yet, either this document needs to be on an entirely different track, or the language needs to be reworded to report on deployment and perhaps future standards work.

[Ballot comment]
These are drafty:

1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.

4) Can we add in the intro that picking/having one algorithm is normally a bad idea.  Protocols should support algorithm negotiation so they can support more than one algorithm.

5) Sec 6: Is there something missing from the end of this sentence maybe "packet":

  If the Address Family Identifier of the
  first (and only the first) entry in the message is 0xFFFF, then the
  remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no

[Ballot comment]
For consistency, add citations to the defining RFCs that define the use of
HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 in the various routing protocols; e.g.,

  Implementations may start providing support for HMAC-SHA-256/HMAC-
  SHA-384/HMAC-SHA-512 [RFC5310] as these algorithms may be necessary in the
  future.

at the end of section 3.2

[Ballot comment]
For consistency, add citations to the defining RFCs that define the use of HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 in the various routing protocols; e.g.,

  Implementations may start providing support for HMAC-SHA-256/HMAC-
  SHA-384/HMAC-SHA-512 [RFC5310} as these algorithms may be necessary in the
  future.

at the end of section 3.2

[Ballot comment]
INTRODUCTION, paragraph 3:
>            Cryptographic Authentication Algorithm Implementation
>                    Best Practices for Routing Protocols

  It is odd to see the term "best practices" in the title of a document
  that is not actually targeted as a BCP. Plus, the contents of the
  document aren't best practices, they are rather suggestions to
  implementors to avoid potential future interoperability issues.
  Suggest to reword the title.


Section 4.1, paragraph 4:
>    all conformant implentations MUST support this.

  Nit: s/implentations/implementations/


Section 11.1, paragraph 2:
>    [ISO]      "Intermediate system to Intermediate system routeing

  Nit: s/routeing/routing/

[Ballot comment]
Nit: Section 1

  It should be recognized that preferred algorithm(s) will change over
  time in to adapt to the evolving threats.

s/time in/time/

---

Nit: Sections 3 and 4

s/use of SHA family/use of the SHA family/
                                                                                         
---

Nit: Section 3.1

s/scheme as provides/scheme as it provides/

---

Section 6

  RIPv2, originally specified in [RFC1388], then [RFC1723], has been
  finalized in STD56 [RFC2453].

For some definition of "final". Can you:
s/finalized in/updaed and published as/

[Ballot discuss]
I would like to  "Yes" on this document because I think it is a
valuable and important piece of work, but there is a bunch of
issues that I think need to be addressed in a revision.

When these have been addressed, I will move to "Yes".

---

I agree with Sean's Comment about 2119 language. Not only is this an
Informational I-D, but it is referencing other sources to inherit
the use of this language. I recommend changing this to normal English
usage throughout, and dropping the (duplicated) 2119 boilerplate.

---

Section 3.1

  In order for IS-IS implementations to interoperate, they must support
  one or more authentication schemes in common.

This is not true as written! IS-IS implementations interoperate
perfectly well with the use of no authentication. It is possible that
you are assuming that "no authentication" *is* an authentication scheme,
but that sounds a little pedantica and rather confusing. So probably you
mean the "In order for IS-IS implementations to interoperate with the
use of security, they must..."

This subtle change in language should be applied throughout the
document (e.g. sections 4.1 and 4.2 - although, why is this text
duplicated in 4.1 and 4.2?)

---
                 
Section 3.1 observes that there is a use for cleartext passwords, but
then says that the IETF believes the use should be deprecated. Would it
not be better to say "this mechanism does not provide any significant
level of security." This language has the additional benefit that it
avoids the discussion of whether this document is a BCP or PS rather
than Informational.

The language in the OSPF section (4.1) to cover the same point is much
better.

Section 6.1 manages to be better and worse :-)

  Simple Password defined as a MUST in [RFC2453] should only be used
  when the operator wishes to preclude the accidental introduction of a
  RIP router into the domain. This authentication scheme is useful, but
  not when the operator wants to protect RIPv2 message exchange in a
  potentially hostile environment.
   
  Implementations MUST provide support for Simple Password, but its
  operational use is deprecated.

The first paragraph puts it nicely. The second paragraph:
- repeats the "MUST" which it does not need to do
- makes a deprecation statement that contradicts the utility stated in
  the first paragraph.

---

Section 4.1 and 6.1

  This section specifies the
  requirements for standards conformant OSPFv2 implementations, which
  desire to utilize the authentication feature.

The language used here is very different from that in section 3.1.
Why? Can you use the same advisory text that you have in 3.1?

---

Section 4.2

  Keyed MD5 as defined in [RFC2328] is a MUST. It is our belief that
  HMAC-SHA-1 and HMAC-SHA-256 as defined in [RFC5709] will likely be
  preferred in the future. Keyed MD5 MUST be implemented, but its use
  may be deprecated in future. Implementations must provide support for
  HMAC-SHA-256 as this will become the algorithm of choice.

1. There is some duplication of the MUST implement keyed MD5.

2. Is the final sentence a statement that can be referenced, or are
  you defining it here?                                               
  If you are defining it, then this is not an Informational I-D and
  becomes PS with review needed by the OSPF WG.
  I would prefer you to change this to be an observation.           

For example:                                                   

  [RFC2328] states that implementations must offer keyed MD5
  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
  implementations should support these algorithms.

---

Section 5 on OSPFv3

  The algorithm requirements for AH and ESP are described in [RFC4835]
  and are not discussed here.

This is true, but why not discuss them here? After all, the
requirements for OSPFv2 security are described in other documents, but
you still discuss them in this document. I think you should state what
the required algorithm support is, and observe that you think this is
sufficient (or not).

Ditto Section 7 on RIPng.

---

Section 6.1

  Keyed-MD5 as defined in [RFC2082] is a MUST. However, [RFC2082] has
  been obsoleted by [RFC4822] Cryptographic Authentication. Compliant
  implementations MUST provide support for Keyed-MD5 as described in
  [RFC2082] but should recognize that this is superseded by
  Cryptographic Authentication as defined in [RFC4822]. 

This is a bit mixed up! RFC 2082 is obsolete so implementation should
not do anything as defined in that spec. They must conform to RFC 4822
which is quite clear on the requirements for MD5 and SHA, and which
also indicates the preferences between the schmes.

---

Dynamic key management is important and you cover it in Section 8.

  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.

But this does not indicate whether the protocols actually support
changing keys. Shouldn't this be something covered in each of the
main sections 3 through 7?

What about automated key management?

Probably have a look at RFC 4107, and write some cosiderations of the
IGPs based on what it says.

[Ballot comment]
These are drafty:

1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST),
            FIPS Publication 180-3: Secure Hash Standard, October
            2008.

4) Can we add in the intro that picking/having one algorithm is normally a bad idea.  Protocols should support algorithm negotiation so they can support more than one algorithm.

5) Sec 6: Is there something missing from the end of this sentence maybe "packet":

  If the Address Family Identifier of the
  first (and only the first) entry in the message is 0xFFFF, then the
  remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no

[Ballot discuss]
These are drafty:

1) Not entirely sure of this draft's point.  2119 requirements language is used only to specify what's already in RFCs - shouldn't there be requirements about switching?

2) This is on the informational track, but the last sentence of the security consideration says:

We expect that new revisions of this document
  will be issued in the future to reflect current thinking on best
  practice in this area.

So is this a BCP cast as an informational document?

[Ballot discuss]
This is draft:

1) Not entirely sure of this drafts point.  2119 requirements language is used only to specify what's already in RFCs - shouldn't there be requirements about switching?

2) This is on the informational track, but the last sentence of the security consideration says:

We expect that new revisions of this document
  will be issued in the future to reflect current thinking on best
  practice in this area.

So is this a BCP cast as an informational document?

[Ballot comment]
These are drafts

1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Just move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST),
            FIPS Publication 180-3: Secure Hash Standard, October
            2008.

4) Can we add in the intro that picking one algorithm is normally a bad idea.  Protocols should support algorithm negotiation so they can support more than one.

5) Sec 6: Is there something missing from the end of this sentence maybe "packet":

  If the Address Family Identifier of the
  first (and only the first) entry in the message is 0xFFFF, then the
  remainder of the entry contains the authentication.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no

[Ballot discuss]
This is draft:

1) Not entirely sure of this drafts point.  2119 requirements language is used only to specify what's already in RFCs - shouldn't there be requirements about switching?

[Ballot comment]
These are drafts

1) The RFC editor will make you scrub the references (i.e., [RFCXYZ]) from the abstract.  Just move them to the Introduction.

2) Section 2 and the "conventions used in this document" section are the same.

3) It's probably worth adding a reference to SHS (for the SHA family):

[SHS]  National Institute of Standards and Technology (NIST),
            FIPS Publication 180-3: Secure Hash Standard, October
            2008.

4) Can we add in the intro that picking one algorithm is normally a bad idea.  Protocols should support algorithm negotiation so they can support more than one.

5) Sec 3.1: r/scheme as provides no/scheme as it provides no

[Ballot comment]
Two spellings are used: "Null authentication" and "NULL
  authentication".  Please pick one.

  In the Introduction, I think it is better to talk about the overall
  technique before particular algorithms like MD5.  Below I suggest
  rewording for 3rd and 4th and 5th paragrahs of the introduction.
 
    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, message authentication codes
    often use a keyed MD5 digest.  The recent escalating series of
    attacks on MD5 raise concerns about its remaining useful lifetime.
    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.  There is a however a need felt to deprecate MD5
    in favor of stronger message authentication code algorithms.

1.a

The Document Shepherd is Joel Jaeggli, Opsec WG co-chair. The Document
Shepherd has reviewed Draft 00 of
draft-ietf-opsec-igp-crypto-requirements and concluded that the
document is prepared for IESG review and publication as an
informational document.

1.b

The document was widely socialized within the routing area working
groups where protocol maintenance is being performed prior to
being brought to the opsec working group. With opsec working group input
the focus has changed somewhat for altering the cryptogrphica protocal
usage of igp protocols to enumerating what the likely requirements
should be and the basis for those recommendations.

1.c

Insofar as the the doucument shepherd is concerned, further review of
future changes in state of cryptogrphic protection for IGP and EGP
protocols should be performed in working groups tasked with the protocol
maintenance activities or in working groups chartered to solve the
cyrpto-problem, such as the karp working group. This document represents
the consensus view of the authors and the working group on what the
requirements for such protocols should be.

1.d

One concern of the shepherd is that the working title while accurate at
the inception of the document somewhat overstates the fairly modest
goals of the document in it's present form. The long form title is
altogether more representative of the goals of the document.

Cryptographic Authentication Algorithm Implementation
Best Practices for Routing Protocols

1.e

Working group consensus has been solidly behind this draft following
revision is it's current form. Since presentation of the Updated draft
in Aanuary the document has been accepted as a working group document
and subsequently lasted called. Serious objections were not raised in
either case.

Prior to the revision, the draft have been presented in the working
group meeting, discussed on the list, and had received contributions
from working-group participants, however concern with the scope and the
goal of changing protocol specifications in an ops area working group
had precluded acceptance.

1.f

No appeals or discontent are noted in the working group regarding the
current draft at this time.

1.g

IDnits notes the existence of several dated references many of which are
required for historical treatment of the subject matter. Not major nits
are noted.

1.h

The draft divides references between normative and informative. This
document's advancement is not blocked on the advancement of normatively
referenced material.

1.i

The draft makes no requests of IANA. Authentication methods (example
OSPFv2 RFC 2328 Appendix D) are typically reserved through an IANA
registry, so documents referencing this document or subsequent work will
make IANA requests as a product of recommendations made in this document.

1.j

No formal language schema is in use in this document.

1.k

Document Announcement Write-up

Summary:

The routing protocols Open Shortest Path First version 2 (OSPFv2)
[RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO]
[RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently
define Clear Text and MD5 (Message Digest 5) [RFC1321] 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
[RFC4822], IS-IS [RFC5310] and OSPF [RFC5709].

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.

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.

Working Group Summary:

The document was accepted as a workring group item on the mailing list
on 1/24/2010.Working Group last call was performed for two weeks, ending
on 5/29/2010. With no objections.

Document Quality:

The document covers the use of cryptographic protections in five igp
protocols while it's is likely that the utility of recommendations made
in this document will age or be rendered obsolete at different rates.
Recommendations conveyed by the document are both informational in
nature and temporally limited.