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

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

Hi Yaron,
 
> 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.

As per the KARP design guide (RFC 6518) we were taking this up in the subsequent phases of KARP work life cycle. The Phase I initially updates all protocols with the latest algorithms and key agility (rollover). Anything beyond that is the next step.

What we're doing here is updating LDP with stronger algos and ensuring that keys can be easily rolled over without disrupting the protocol.

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

Again, as per KARP design Phase I, we need to get all routing protocols to a certain minimum level. Redesigning the protocol for an automated key management protocol is Phase II.

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

We have the following text in the draft:

   In order to achieve smooth key transition, KeyStartAccept SHOULD be
   less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
   KeyStopAccept.  If KeyStartGenerate or KeyStartAccept are left
   unspecified, the time will default to 0 and the key will be used
   immediately.  If KeyStopGenerate or KeyStopAccept are left
   unspecified, the time will default to infinity and the key's lifetime
   will be infinite.

Can you suggest what else needs to be added to make it clearer?

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

Goody.

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

I am sure the Security and the Routing ADs can help you with the history. 

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

I think you missed the text in Sec 5.1 which says:

   The LDP Cryptographic Protocol ID is appended to the Authentication
   Key (K) yielding a Protocol Specific Authentication Key (Ks).  In
   this application, Ko is always L octets long.  While [RFC2104]
   supports a key that is up to B octets long, this application uses L
   as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
   [RFC7166].

In case of HMAC-SHA-512 the key size would be 512 bits.

We never restrict the key size to 128.

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

Consider it done.

Cheers, Manav