Subject: [Secdispatch] Controller-IKE

From: "David Carrel (carrel)" <[email-masked]>
Date: Sat, 20 Jul 2019 02:20:35 +0000

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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 21 Jul 2019 10:19:16 -0400

Hi Dave,

Thanks for sharing this work.  This seems like an interesting problem to
compare with IKE/TLS and MLS -- where IKE and TLS are about configuring a
1-1 security context and MLS is about establishing a single security
context across N participants, the goal here seems to be to maintain a full
matrix of N^2 security contexts with sub-linear messaging to update a
row/column.

Given that different shape, it seems like the association with IKE is
pretty tenuous.  It might be clearer to consider this an alternative to IKE
for this mesh case, in the sense of being an external key exchange protocol
that results in the production of IPsec SAs.

It would be helpful to have a clearer idea of the security objectives here,
especially around things like forward security and post-compromise
security.  The obvious objective of providing equivalent assurances to a
collection of N^2 individually negotiated SAs seems unlikely to be feasible
here.  In particular, the protocol in the current document doesn't provide
it, since multiple SAs are "fate shared" due to key reuse -- if an attacker
compromises one peer's DH key, then a whole "row" of SAs are compromised.

--Richard

On Fri, Jul 19, 2019 at 10:20 PM David Carrel (carrel) <[email-masked]>
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
>
>
>
> BESS, Secure EVPN:
> https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-02
>
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 22 Jul 2019 10:28:31 -0400

Hi David,

Could you please explain how this is different from the adopted work in
I2NSF,
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
 ?

This is referenced in your draft along with one another, but there is no
analysis on why they don't fit the need.  The draft in I2NSF pulled in the
IPsecMe working group and underwent significant revisions as a result to
deal with several initial security issues.  If there 's a gap that can be
solved with that draft, could that be a way forward or is this needed for
some specific reason?  It would be helpful to understand this.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jul 2019 07:31:52 -0700

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

---

From: "David Carrel (carrel)" <[email-masked]>
Date: Mon, 22 Jul 2019 14:59:18 +0000

Kathleen,

I have discussed Controller-IKE in the I2NSF meetings and I follow it closely.  I2NSF flow protection draft discusses two ways to configure the device for key management.  You can configure it for IKE and send all the static IKE configuration to the device, or you can configure it for NO key exchange and have the control station push the IPsec keys to the device.  The IKE option is pretty straightforward and standard.  The static key option is … what it is.

Contoller-IKE would also fit into the I2NSF framework.  If Controller-IKE moves forward, then I would want to see additions to the I2NSF flow protection to allow it to configure a 3rd key management option.  I2NSF flow protection would not carry the Controller-IKE messages, but it would configure the device to do Controller-IKE.  The actual Controller-IKE exchange would be with the RR.

Dave

From: Kathleen Moriarty <[email-masked]>
Date: Monday, July 22, 2019 at 10:29 AM
To: "David Carrel (carrel)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Secdispatch] Controller-IKE

Hi David,

Could you please explain how this is different from the adopted work in I2NSF, https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ ?

This is referenced in your draft along with one another, but there is no analysis on why they don't fit the need.  The draft in I2NSF pulled in the IPsecMe working group and underwent significant revisions as a result to deal with several initial security issues.  If there 's a gap that can be solved with that draft, could that be a way forward or is this needed for some specific reason?  It would be helpful to understand this.

Thank you,
Kathleen

On Fri, Jul 19, 2019 at 10:20 PM David Carrel (carrel) <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Comments appreciated.

Dave

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

--

Best regards,
Kathleen

---

From: "David Carrel (carrel)" <[email-masked]>
Date: Mon, 22 Jul 2019 15:42:44 +0000

Ekr,

Thanks!  Responses inline …

From: Eric Rescorla <[email-masked]>
Date: Monday, July 22, 2019 at 10:32 AM
To: "David Carrel (carrel)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Secdispatch] Controller-IKE

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

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.

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.

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) <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Comments appreciated.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jul 2019 09:12:46 -0700

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

> *From: *Eric Rescorla <[email-masked]>
> *Date: *Monday, July 22, 2019 at 10:32 AM
> *To: *"David Carrel (carrel)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Secdispatch] Controller-IKE
>
>
>
> 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.

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

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

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

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

> 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

---

From: "David Carrel (carrel)" <[email-masked]>
Date: Mon, 22 Jul 2019 17:09:53 +0000

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

OK, I think this is where you misunderstood something or we didn’t explain well enough.  There are no long-term DH keys in Controller-IKE.  All are ephemeral.  It is true that due to synchronization, you will likely keep them a little longer, but never more than 2 key lifetimes.  If you re-key every 2 hours, then the worst case is that your DH values are kept for 4 hours.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jul 2019 10:27:21 -0700

Thanks for clarifying. With that said, it's possible to do better than this
if you use a conventional AKE and time out associations somewhat
aggressively.

-Ekr

On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carrel) <[email-masked]>
wrote:

> OK, I think this is where you misunderstood something or we didn’t explain
> well enough.  There are no long-term DH keys in Controller-IKE.  All are
> ephemeral.  It is true that due to synchronization, you will likely keep
> them a little longer, but never more than 2 key lifetimes.  If you re-key
> every 2 hours, then the worst case is that your DH values are kept for 4
> hours.
>
>
>
> Dave
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Jul 2019 11:13:24 -0700

David,

At the mic today, you said that C-IKE was 2N complexity rather than N^2
complexity in terms of messages. Here's what confuses me.

Just for simplicity, imagine that we do this in two phases: everyone
registers their key with the controller and then the controller
disseminates them. At this point, the controller has N keys and it needs to
send them to N endpoints. If you are able to broadcast to all the nodes at
once, then the controller will send N keys, so the total overhead is 2N (N
uploads + N downloads). However, if the controller has point to point
links, then the controller has to send ~N^2 keys (N-1 keys down N links).
So those might be bundled into a single message, but you still have to send
N^2 keys. Or am I missing something?

-Ekr

On Mon, Jul 22, 2019 at 10:27 AM Eric Rescorla <[email-masked]> wrote:

> Thanks for clarifying. With that said, it's possible to do better than
> this if you use a conventional AKE and time out associations somewhat
> aggressively.
>
> -Ekr
>
>
>
>
>> 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.
>>
>> OK, I think this is where you misunderstood something or we didn’t
>> explain well enough.  There are no long-term DH keys in Controller-IKE.
>> All are ephemeral.  It is true that due to synchronization, you will likely
>> keep them a little longer, but never more than 2 key lifetimes.  If you
>> re-key every 2 hours, then the worst case is that your DH values are kept
>> for 4 hours.
>>
>>
>>
>> Dave
>>
>>
>>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 Jul 2019 13:18:59 -0500

> N^2 keys. Or am I missing something?

I'm p robably missing something too, but there's a couple potential
differences from what you describe -- the flow down from the controller to
the endpoints can be a P2MP flow, and also if the controller knows the
overlay network, it knows that it only has to send each endpoint (a specific)
10 keys for that endpoint to talk to the other endpoints it needs to.  That
is, each endpoint may not need (or be able to!) store the keys for all N
endpoints.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Jul 2019 19:24:26 +0000

Additional question: If you use DH you often want to use an ephemeral DH key with each communication partner. Is this also the case in your deployment?

From: Secdispatch <[email-masked]> On Behalf Of Eric Rescorla
Sent: Montag, 22. Juli 2019 14:13
To: David Carrel (carrel) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Secdispatch] Controller-IKE

David,

At the mic today, you said that C-IKE was 2N complexity rather than N^2 complexity in terms of messages. Here's what confuses me.

Just for simplicity, imagine that we do this in two phases: everyone registers their key with the controller and then the controller disseminates them. At this point, the controller has N keys and it needs to send them to N endpoints. If you are able to broadcast to all the nodes at once, then the controller will send N keys, so the total overhead is 2N (N uploads + N downloads). However, if the controller has point to point links, then the controller has to send ~N^2 keys (N-1 keys down N links). So those might be bundled into a single message, but you still have to send N^2 keys. Or am I missing something?

-Ekr

On Mon, Jul 22, 2019 at 10:27 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for clarifying. With that said, it's possible to do better than this if you use a conventional AKE and time out associations somewhat aggressively.

-Ekr

On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carrel) <[email-masked]<mailto:[email-masked]>> wrote:

Dave

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Jul 2019 01:35:22 +0300

> > N^2 keys. Or am I missing something?

I was pointing out that this is actually N^3 keys you need to
transport if you you start building the network with one node at time.

In the beginning there is only C (controller) and it has no keys. This
was good, but then there was light. Key count over wire 0.

Node 1 came up, sent its key to C and saw this is still good, as there
is nobody for him to talk to. KCOW 1.

Node 2 came up, sent its key to C and C saw that it needs to send the
Node 2's key to Node 1, and Node 1's key to Node 2, it did so. KCOW +=
1 + 2*1 = 4

Node 3 came up, sent its key to C, and C sent other keys it has to
everybody else. KCOW += 1 + 3*2 = 11.

Node n came up, sent its keys to C, and C sent other keys (n-1) it has
to everybody else (n) KCOW += 1 + n*(n-1).

The final count of key count over wire is n + n * (n-1) * (n-1)...

Of course you could remember in C which keys you have already sent
out, so in that case the key count over wire drops down to n + n * (n-1). 

When you compare this to the IKE case, where the node n coming up, it
just needs to send diffie-hellman public keys out for 2 * m times,
where m is the number of nodes it wants to talk. In general cases m <<
n.

Also one node rekeying requires C to send its new key to every n-1
node in the network. In the IKE case rekeying just does sends keys out
2 * m times.

It seems that you assumed that messages between the controller and
node are free, but peer to peer messages between nodes are not. I do
not belive in that. 

> is, each endpoint may not need (or be able to!) store the keys for all N

The whole idea in the controller IKE seemed to be that m == n-1, i.e.,
each node wants to talk to everybody else, otherwise normal IKE where
nodes bring up SAs when they need it is much more efficient.
-- 
[email-masked]