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

[Matt Lepinski <[e-mail]>]

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:

On 10/29/2011 5:24 AM, Bhatia, Manav (Manav) wrote:
> 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.

Okay, that makes sense.

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

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

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

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

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

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

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