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

From: Matt Lepinski <[email-masked]>
Date: Sat, 29 Oct 2011 01:01:44 -0400

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.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 29 Oct 2011 14:54:55 +0530

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

---

From: Sam Hartman <[email-masked]>
Date: Sat, 29 Oct 2011 15:42:11 -0400

Hi.  The rationale behind the IANA registry is to avoid related protocol
attacks.  The intent is to have a registry for protocols (there are a
number in the routing area) that use similar layouts for authentication
information to avoid related protocol attacks when the same key is used
cross-protocol.el :So, anything sufficiently similar to this needs to be
registered.  I think the registry is the result of a fairly tight
compromise already and I would not recommend re-opening that discussion.
I'd be delighted if you want to propose better names for the registry or
the initial registration; I suspect we're not tied to those.

I do not support removing the key-strength indication.  Realistically I
think this application probably does require at least 64-bits of
security (assuming there are no hash collision issues, which would
double the security requirement). I don't actively support reducing the
key strength requirement below 128-bits, but I'm not opposed if someone
really wants to do that. Note that a 16-character password does not meet
the current requirement: passwords are typically not random drown from
the set of all binary values of a given size.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Oct 2011 22:48:17 +0100

+1 to what Sam said,
S

---

From: Matt Lepinski <[email-masked]>
Date: Sat, 29 Oct 2011 19:50:07 -0400

Manav,

I apologize for the confusion regarding the WESP (IPSECME) work, I had 
printed out two versions of your document (one somewhat old) and I got 
confused with regards to the relationship with the IPSECME ESP-NULL work.

Further comments in-line:

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

Okay, that makes sense.

<text removed>
> Ccing Sam, though he should be in the secdir list.
I have trouble seeing how the cryptographic protocol ID registry is 
going to work going forward (in particular, what type of protocols 
should be placed in this registry). However, if Stephen Farell and Sam 
Hartman are satisfied with the text describing the cryptographic 
protocol ID registry, then I defer to them in this matter.

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

I would very much like to see this statement appear in the Security 
Considerations section.

> 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.
Okay, what I found confusing is that you provide text from 4522 verbatim 
in the Introduction, but it is not clear to me how this text relates to 
the authentication trailer defined in the current document. It would 
make things more clear to me if you were to either remove the text from 
4522 or else provide a bit more context. (For example, you might say, 
that explicitly that a goal of the authentication trailer document is to 
provide replay protection which is not possible to provide with IPsec 
when manual keying is used.)

>                US National Institute of Standards&  Technology, "Secure
>                US National Institute of Standards&  Technology, "The
I would find it very helpful if you put references to these citations in 
Section 4.3 where you list the cryptographic authentication algorithms 
supported by the OSPFv3 authentication trailer.

> 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 a…
Okay, what you just said makes more sense to me than what is currently 
in the Security Considerations section. Personally (and this is just me) 
I would recommend not having an explicit key size recommendation in the 
security considerations and instead just keep the sentence "Deployments 
SHOULD use sufficiently long and random values for the authentication 
key so that guessing and other cryptographic attacks on the key are not 
feasible in their environments." and reference RFC 4086.

>> something a bit more specific. Finally, it is not clear to me
Hmm ... I'm not sure ... If you insert a specification pointer into the 
registry so that an implementer looking at the registry can clearly see 
that "cryptographic registration" is the mechanism in RFC XYZ (whatever 
number this draft becomes).

---

From: Acee Lindem <[email-masked]>
Date: Mon, 31 Oct 2011 10:15:00 -0400

See inline. 

> 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 a…

It is merely a recommendation (from Stephen Ferrell). Not everyone will follow it. At the next IETF, you'll notice at the afternoon break that many attendees do not follow the US FDA's or WHO's dietary recommendations. 

Thanks,
Acee