Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

[Yaron Sheffer <[e-mail]>]

Hi Manav, thanks for your response. Please see clarifications below.

	Yaron

On 05/19/2014 03:17 AM, Bhatia, Manav (Manav) wrote:
> Hi Yaron,
>
> Thanks for the comments. My comments inline.
>
>>
>> • The main issue is that only a symmetric crypto option is defined.
>> IMHO, adding a public-key based scheme would be invaluable. Public keys
>> do not necessarily imply certificates, and can be used with little
>> added
>> complexity compared to the current proposal. As far as I can see, the
>> current use is not so performance constrained to preclude public key
>> operations. And public keys would enable much easier and more secure
>> deployment in many cases:
>> 	∘ Different organizations can accept messages from one another,
>> without
>> needing to share the same keys. So even if groups keys are used (which
>> is certainly not the best practice), public keys have an advantage.
>> 	∘ Revocation is much simpler: to be able to revoke each
>> individual
>> sender (e.g. when a router is decomissioned), you need N**2 SAs in the
>> symmetric case, vs. N keys when public keys are used.
>
> The idea behind this draft is to bring LDP HELLO's security to at least the same level as the routing protocols running in the same networks today. All IGPs are currently using a symmetric crypto option and we think it is ok at this point in time to continue with the same for LDP.
>
> With SDN principles its possible that the key distribution becomes quite simple with a central controller distributing the keys to all the nodes in the network along with the other information. This also seems to be one of the thoughts behind not pursuing an automated key management protocol for IGPs (something that we were supposed to take up as part of the Phase 2 in the KARP WG -- you can look at RFC 6518 for more details).
>
> Given this I would like to continue with what we have and look at other mechanisms once we have more clarity on the direction which we seem to be heading towards.
>
> Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations.
>

I understand the statement "we do not know where we're going, so let's 
not over-design now". But note that even with SDN and even with a key 
management protocol, public keys have an advantage over symmetric keys 
for this scenario. And if you have automated key 
management/distribution, the simplicity of symmetric keys actually 
becomes less important.

>> • Managing the 32-bit SAID manually in a large network is extremely
>> onerous. So in practice keys would be rarely on never changed.
>
> Ok, so whats the point?

That you need automated key management, otherwise this mechanism is an 
overkill.

>
>>
>> • 2.2: the authentication algorithm and the authentication key are not
>> "independent", because the algorithm normally determines the key
>> length.
>
> This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo.
>

Sure, this is a nit.

> Authentication Key
>
>        This value denotes the cryptographic authentication key associated
>        with the LDP SA.  The length of this key is variable and depends
>        upon the authentication algorithm specified by the LDP SA.

Good.

>
>>
>> • 2.2: the various time values included in the SA essentially require
>> (rough) time synchronization between the nodes. If this is the case,
>> time values could have been used for replay protection, which would
>> have
>> been much simpler to implement than the 64-bit sequence number which
>> needs to persist across reboots.
>
> The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti replay protection.

Note that the timer values are optional (the draft says they can be left 
"unspecified"), but the draft doesn't say what value should be in the 
field if the values are to be omitted. I *guess* it should be "0", 
please clarify it.

>
> Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862)

That really depends on what data is signed by the key. But I see your point.

>
>>
>> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This
>> reviewer does not have the appropriate background to critique the
>> proposed solution, but there must be an overwhelming reason to reopen
>> cryptographic primitives.
>
> This is a decision that was taken by Sec Ads when we were doing the crypto protection for the IGPs based on some feedback from NIST. This mathematics is not new and has been done for all IGPs and has been approved and rather encouraged by the Security ADs.
>

Then I guess I disagree, but I am not familiar with the background for 
this decision.

>>
>> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too
>> short for others. In general, the recommended key length is not
>> constant. It depends on the algorithm.
>
> This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough?

Personally, I think 128 bits are great :-) Seriously, if people are 
using HMAC-SHA-512 then 128 is not appropriate. You can argue that you 
don't need more than 128 bits of entropy, but then I would suggest to 
remove SHA-512 from the draft. The general point is that different 
algorithms require different key lengths.

>>
>> • "The mechanism described herein is not perfect and does not need to
>> be
>> perfect." This is kind of vague, and would be better replaced by your
>> security goals.
>
> I think we can just delete this! :-)

Please do.

>
> Cheers, Manav
>
>>
>> Thanks,
>> 	Yaron