Re: [Secdispatch] Controller-IKE

[Eric Rescorla <[e-mail]>]

On Mon, Jul 22, 2019 at 8:42 AM David Carrel (carrel) <[e-mail]>
wrote:

> Ekr,
>
>
>
> Thanks!  Responses inline …
>
>
>
> *From: *Eric Rescorla <[e-mail]>
> *Date: *Monday, July 22, 2019 at 10:32 AM
> *To: *"David Carrel (carrel)" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *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.
>
> This isn’t an extension of IKE.  It is an alternative.  It provides the
> functionality that a standard IKE process provides.  Basically it creates
> pairwise keys and creates IPsec SAs.  For example, you can remove a Linux
> userspace IKE daemon and replace it with Controller-IKE and still utilize
> the unmodified kernel IPsec.
>

Yes. My point is that it's not clear to me why you are calling it
"Controller IKE" or using the IKE crypto functions, which aren't really
what we usually pick for new protocols.

>
>
> * 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?
>
> You are right that there continues to be N^2 associations and this does
> not reduce the DH calculations, but (as you note) this does reduce the
> number of peer-to-peer messages and does reduce the RTT.  Depending on the
> size of the full mesh SD-WAN, and the bandwidth costs, the reduction of
> messages is definitely a positive.  There are other benefits such as
> allowing for the use of “secure” provisioned networks for control, while
> utilizing lower security (public) networks for IPsec traffic.  And in fact
> there are applications where the data connection between peers is NOT
> 2-way, meaning traditional IKE will not establish between the peers, but
> the SD-WAN does come up.
>

Thanks. This is helpful.


> * 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).
>
> True, the DH load can be expensive, but no more so than an equivalent mesh
> of traditional IKE.  We would not need to re-key any less often.  I believe
> this makes the PFS story equivalent.
>
This doesn't seem correct to me. Consider the case where you do pairwise
IKE and then delete the SA and the DH ephemerals. At this point, compromise
doesn't leak the traffic keys at all. By contrast, in Controller-IKE
because I need to store my DH share indefinitely in case a new peer comes
online, then that represents a long-term source of compromise.



> * 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.
>
> This is a very good observation.  The straightforward answer is to mix the
> controller validated identity into the keymat to ensure that someone else
> using my DH/nonce will not generate the identical keys with a 3rd peer.
> Thanks!!
>
That's probably enough, but I'd want to see some kind of analysis that
shows that this is true.

>
>
> * You also seem to have a KCI problem, where if your keys is
> compromised, an attacker can impersonate anyone to you.
>
> I don’t see this?  Can you explain further?  If my DH private is
> compromised, then an attacker can impersonate me to anyone else (until I
> re-key).  Presumably if you get my private DH, I have been compromised
> fully.  But this is the same situation with any key management protocol.
>
Not exactly. Consider a protocol like TLS 1.3 where you have both short and
long term keys. Compromise of your long-term key (e.g., it's leaked but
your machine isn't still compromised) allows someone to impersonate you to
other people but not to impersonate other people to you, because they can't
forge a signature you will accept. However, that's not the case with
Controller-IKE. I don't believe that it's possible to achieve KCI
resistance with a static-static DH protocol like Controller-IKE but you can
with a combined ephemeral/static protocol like OPTLS.


>
> 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.
>
> Definitely worth looking at.  I can’t give you a quick response on this,
> but I will crunch on this.  Of course, this would involve modifying ESP.  I
> wouldn’t want to make that a requirement to this moving forward, but it
> could be separately considered as an ESP extension that any KMP could avail
> themselves of.
>
Well, you don't *need* to piggyback: you can send the key establishment
messages in separate packets. Piggybacking just gives you fate sharing so
there's no way for the ESP messages to arrive in the opposite order.

QUIC is a worked example of this style of protocol.

-Ekr

-Ekr
>
>
>
> Dave
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch
>
>