Re: [Secdispatch] Controller-IKE

Ekr,

Thanks!  Responses inline …

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday, July 22, 2019 at 10:32 AM
To: "David Carrel (carrel)" <carrel@cisco.com>
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>
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.

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

* 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.  In addition, Controller-IKE does allow for resending the same DH public value with a new nonce.  This doesn’t improve PFS, but does allow for a more frequent re-keying without incurring the DH cost.

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

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

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

Dave

On Fri, Jul 19, 2019 at 7:20 PM David Carrel (carrel) <carrel@cisco.com<mailto: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<mailto:Secdispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/secdispatch