[secdir] Secdir review of draft-ietf-ospf-auth-trailer-ospfv3-08

[Matt Lepinski <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies the use of the authentication trailer for OSPFv3. Previously this trailer was defined for use in OSPFv2, but not present in OSPFv3. Note that when OSPFv3 was originally specified it was anticipated that IPsec would be used to provide authentication for OSPFv3. The introduction of draft-ietf-ospf-auth-trailer-ospfv3 explains the limitations of IPsec that necessitate specifying the authentication trailer for OSPFv3. (However, I personally don't find the explanation in the introduction to be fully convincing, see below.)

---------------
Comments
---------------

A) Section 1.1 describes the work in the IPSECME working group to address the shortcomings of ESP-NULL as an authentication mechanism. However, it is not clear to me why this work in IPSECME (RFCs 5879 and 5840) is insufficient to resolve the issues (described in Section 1) that make ESP-NULL unsuitable for use as an authentication OSPFv3. That is, Section 1.1 describes what the IPSECME working group has done to solve the ESP-NULL issues in IPsec, but Section 1.1 doesn't answer the question of why in light of the recent IPSECME work that this specification is still needed?

Note: I assume the answer to the question in the previous paragraph is that the authors of this specification feel that RFC 5879 is
insufficient and that RFC 5840 will take too long to get deployed, and this might be a good justification for the current specification.
Additionally, since this document, is a new standards track extension to OSPFv3, I would like to see an explicit justification for why the
protocol described in this document will see deployment sooner than RFC 5840 (which solves the same problem that is solved by the OSPFv3 authentication trailer). There is also a statement in Section 1 that IPsec is not available on some platforms or environments, but the authors to do go into enough detail (or provide suitable references) for me to evaluate whether this claim justifies creating another standards track mechanism for solving authentication in OSPFv3.

This document should site RFC 5879 (Heuristics for detecting ESP-NULL) in Section 1.1 of the Introduction.

B) In order to prevent cross-protocol replay attacks, this document creates a general IANA registry for cryptographic protocols (both native IPv4/IPv6 protocols and UDP/TCP protocols). The registry is created with only a single entry, but the text describing the registry is sufficiently broad as to suggest that all protocols that use cryptographic keys should be registered. (My apologies if I am misinterpreting the IANA considerations text in Section 7 ... it is also possible that only a subset of cryptographic protocols need to be registered, but it is not clear to me from the text what subset this would be.) My understanding is that cross-protocol replay attacks are prevented by appending the registered protocol ID to the private key to obtain a subordinate key for use in the Message Authentication Code. However, I am not convinced that this is a good general-purpose approach for preventing cross-protocol replay attacks. (Perhaps the document could instead contain language that the private key for OSPFv3 authentication trailers MUST NOT be used in other protocol.) If creating such a general registry is a good approach to dealing with cross-protocol replay attacks, then I question whether this document is the right place to define such a registry. Such a registry seems much more likely to be successful if the community in the Security Area is involved in specifying the registry and populating it with an appropriate set of initial values.

C) The first paragraph of the Security Considerations for this document claim that the authentication trailer represents an increase in the security of OSPFv3. In the introduction of the document the authors cite RFC 6039 which identifies security issues with OSPFv3 (and other routing protocols). It would be helpful if the authors could indicate in the security considerations section to what extend (if any) the authentication trailer addresses the issues raised in RFC 6039 (and, similarly, to what extend the authentication trailer is providing increased security for OSPFv3).

The introduction cites RFC4552 for an explanation of why manual keying is used. This reference should be repeated in the Security considerations section. (I would even advocate copying the text from the Security Considerations of RFC 4552 that deals with the limitations of manual keying.) Additionally, RFC 4552 explicitly states that replay protection is not provided in OSPFv3. Text from RFC 4552 is included in the Introduction, which states that the use of manual keying limits the extent to which replay protection can be achieved. This authentication header specification attempts to provide a degree of replay protection. It would be nice if the security considerations section described in some detail the extent to which this specification prevents replays.

D) This document states (in Section 4.3) that the OSPFv3 authentication trailer supports the following four authentication algorithms: HMAC-SHA-1,
HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. However, in Section 3, it does not include references to a document where these
authentication algorithms are defined. (I believe the right documents to reference are RFC 2104 and RFC 4868.) Additionally, for
interoperability I would suggest that the authors specify at least one of these algorithms are mandatory to implement. (The goal is to avoid
a situation where an operator seeking to use OSPFv3 authentication trailer has two OSPFv3-speaking devices from different vendors, one
which only supports HMAC-SHA-1 and the other only supports HMAC-SHA-256). Note: Upon further reading of the document, it's not clear to me whether this specification works with symmetric-key authentication algorithms other than HMAC. If it is the case that the authentication trailer only works with HMAC, then the document should instead clearly state that authentication trailer makes use of HMAC and currently supports the four digest algorithms.

The Security Considerations for this document (Section 6) RECOMMEND that the deployments use a pseudo-random key of at least 128-bits. This strikes me as odd, because I believe that RFC 2104 which specifies HMAC recommends that the key be at least as long as the output size of the hash function (160 bits in the case of SHA-1).

E) This document creates a registry of Authentication Trailer types and populates it with one value "Cryptographic Authentication". First, I
believe that the Cryptographic Authentication that it is referring to is the mechanism described in this document, but this is not stated
clearly in Section 7. Also, having a specification pointer in the registry would be very helpful. Second, having the name "Cryptographic
Authentication" for the first value in the registry seems to suggest that there might be a future type of authentication which is "Not
Cryptographic" (which seems like a bad idea to me). I would suggest that the authors change the name of the first value in the registry to
something a bit more specific. Finally, it is not clear to me that this registry needs to exist. The existence of the type field in the
authentication trailer is not justified within this document. My belief is that the only reason that a type field is included is for
backwards compatibility with OSPFv2.