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

["Bhatia, Manav (Manav)" <[e-mail]>]

Hi Matt,

Really appreciate the detailed review.

> 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?

I am the co-author of RFC 5840 (WESP) and while it can be used to solve some issues that exist when using vanilla Ipsec, there will still be some issues that it will not address. IPsec works best in the point-to-point topologies and becomes increasingly complex to provision and unscalable when there are multiple routers in a broadcast domain and you need a full mesh of connectivity among all the routers. Providers will tell you that it is a nightmare managing and maintaining a full mesh of Ipsec tunnels and it just doesn't work. Then there are licensing issues with Ipsec (which will exist with WESP as well) and its not available on all platforms - the operators were thus not able to secure OSPFv3. We had included this point in this draft but had removed it since an IETF document shouldn't be discussing licensing and financial issues.

So there is enough support for adding an in-band security mechanism within OSPFv3.

> 
> 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.

You can google for product specs from the vendors and verify that not all platforms support Ipsec. We cant add references to their websites in an IETF doc. 

Moreover, even if you disregard the financial and political aspects of using Ipsec, there are technical reasons as explained above which require an alternate mechanism to be explored.

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

I could be missing something, but I really find no references to work done in IPSECME and WESP (rfc 5840). Are you sure you're looking at the -08 version?

> 
> 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.

The original draft did not consider cross-protocol replay attacks and this section was only added after a long, protracted discussion with Sam Hartman and Stephen Farell. It was only after they were satisfied with the provisions for cross protocol replay attacks that we progressed this draft. 

Ccing Sam, though he should be in the secdir list.

> 
> 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).

RFC 6039 cities the lack of replay protection in OSPFv3 as the reason for most attacks on OSPFv3. This draft adds support for replay protection and thus addresses all the issues raised in 6039.

> 
> 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.

Text from 4522 is not relevant here in this document. 4552 describes how Ipsec can be used to protect OSPFv3. This document describes a mechanism to protect OSPFv3 without Ipsec.


> 
> 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.) 

We have provided references to the following documents:

   [FIPS-180-3]
              US National Institute of Standards & Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-3 , October 2008.

   [FIPS-198]
              US National Institute of Standards & Technology, "The
              Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
              198 , March 2002.

Isnt this enough?

> 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.

I agree. 

> 
> 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).

The input key does not necessarily need to be that long. Please look at Sec 4.5 for more details. The key that's fed to HMAC can be 160 bits even if the input key is of a smaller size. We are recommending that the input key should be at least 128 bits long. 

HMAC requires a 160 bit key as the seed. However, for convenience to the administrators, a specification may not want to require the entry of a PSK of exactly 20 bytes. Instead, a specification may call for a key preparation routine that could handle a variable length PSK, one that might be less or more than 20 bytes (see [RFC4615], section 3, as an example). That key prep routine would derive a key of exactly the required length and thus suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys. Administrators are encouraged to follow [RFC4086] [NIST-800-118]. We are simply trying to play it safe by recommending that administrators should put a password that is at least 16 bytes in length. 

Actually, now that I think about this, specifying a key size of 16 bytes is also not practical. We could either delete that sentence or reduce the length of the recommended key size. I cant image all admins typing in a 16 byte password!

> 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 

Agree. This should be done.

> 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 

Any suggestions here?

> 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.

Yes, this is correct.

Cheers, Manav