Re: [Secdispatch] Controller-IKE

Document: draft-carrel-ipsecme-controller-ike-01.txt

I took a quick look at this document, and I have a few thoughts,
in no particular order.

* I understand the desire to think of this as an extension
of IKE, but it's actually pretty different, and I'm not sure
how much leverage you are getting from trying to make them
similar.

* I think it would be useful to be a little clearer about what
resource you are trying to conserve here. I get that using straight
IKE would require N^2 associations, but this does as well. It doesn't
require N^2 protocol exchanges, but it requires N^2 DH operations (if
everyone wants to talk to everyone else). So, the main value seems
to be that you can send to someone in 0-RTT without exchanging
any messages beforehand. Is that correct?

* The PFS story here seems pretty bad: I'm assuming that people
aren't going to change their DH keys very often (as it's extremely
expensive for everyone else).

* What happens if node A takes node B's DH key and nonce and
advertises them as its own? If I understand the draft correctly,
C will end up with the same SPKI and keys between C-B and C-A.
Is that right? If so, that sounds at minimum like an identity
misbinding attack, but if you are using implicit IVs
(https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-07),
then wouldn't you get nonce reuse, which would be quite bad.

* You also seem to have a KCI problem, where if your keys is
compromised, an attacker can impersonate anyone to you.

ISTM that you would be in a better position if you adopted a 0-RTT DH
flow in the style of OPTLS. I.e., A and B each have keys g^a, g^b and
you mix them in with ephemeral DH keys g^x and g^y. This kind of
exchange is reasonably well studied, and has good PFS and key
confirmation properties. You can piggyback the key establishment
messages along with the data you want to send, so you'll still get
data on the first message.

-Ekr

On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) <carrel@cisco.com>
wrote:

> Folks,
>
>
>
> I would like to present Controller-IKE in the Montreal Security Dispatch
> meeting.  There is growing interest from routing folks, and I strongly feel
> we should evaluate and progress this in the security area.  I’ll have some
> slides to share shortly.  For now, please do read the draft.  Also there
> are some drafts referencing this:
>
>
>
> Controller-IKE:
> https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-01
>
>
>
> Also some docs referencing this form of key management:
>
> BESS, Secure EVPN:
> https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02
>
> And: https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-01
>
>
>
> Comments appreciated.
>
>
>
> Dave
>
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>