Subject: [IPsec] draft-carrel-ipsecme-controller-ike-00.txt

From: "David Carrel (carrel)" <[email-masked]>
Date: Mon, 2 Jul 2018 20:53:46 +0000

Folks,

Brian and I posted the following draft this morning:

URL:        https://www.ietf.org/internet-drafts/draft-carrel-ipsecme-controller-ike-00.txt
Htmlized:   https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike

We would appreciate any discussion and feedback.  The motivation for this work began in very large SD-WAN network implementations where there is full-mesh, multi-path IPsec connections between 10s of thousands of nodes, and where bi-directional peer-to-peer connectivity is not always present.  In these networks, centralized controllers do actively manage all IPsec endpoints.  With this approach, we are looking to reduce session establishment time, improve scalability and preserve confidentiality of IPsec keys.  Without direct peer-to-peer key messages, synchronization becomes a key challenge and we have also provided a solution for that.

This method would be compatible with an I2NSF controller based approach.  Additionally, we have had interest from other use cases for a controller based key management scheme.  So we are proposing this as a method that can be used within multiple controller based management protocols to provide endpoint key management.

David Carrel
[email-masked]<mailto:[email-masked]>

---

From: Daniel Harkins <[email-masked]>
Date: Tue, 17 Jul 2018 11:56:52 -0700

Hey Dave,

   I like your draft, and I have a few comments...

1. It seems both A and B are trusting their receipt of each other's
public key because it comes from the controller. That would imply that
the message from Controller --> [A|B] needs to be protected with some
key shared between the Controller and the recipient. Might I suggest
a deterministic key-wrapping technique like RFC 5297? So if A gets
B's public key (and some identity of B) all wrapped in a message
secured with a secret known only by the Controller, then A can
assume that the trusted third party (Controller) actually sent it
and therefore its contents can be trusted.

2. there's no proof of possession of the secret before it's use in a
protocol that requires trust of the key (ESP). It's a Diffie-Hellman
exchange and then direct use of a resultant key. Is this a problem?
If not, you should explain why (e.g. in Security Considerations).

3. there is a lot of text covering the various scenarios-- initial
keying, rekeying, asymmetric rekeying-- that make this kind of
complicated. What if you made a simple peer-to-peer state machine
for each peer (A and B) ala what I did for IKEv3? So you send a
DH public value or receive a DH public value and are in an awaiting
state, you get a DH public value or send a DH public value, respectively,
and advance state. That way every keying, including rekeying, is done
the same way. It might make for a simpler description too. It would
be a simple key derivation tree based on time starting at n=0:

If An and Bn are the nth Diffie-Hellman values sent by A and B,
respectively, and NAn and NBn are the nth nonces sent by A and B,
respectively, then it becomes:

   Sn = DH(An, Bn)
   rxn | txn | kn = HKDF(min(NAn, NBn) | max(NAn, NBn),
                         Sn, "Controller IKE Key Derivation")

where rxn and txn are used in the ESP SAs and kn is used for
subsequent key management. Then for n = 0, you have NULL nonces and
A0 and B0 are the initial DH public values received from the Controller.
Each n > 0 uses n-1 for protection of the nth exchange.

Then to rekey, either side initiates. For example, assume Bob initiates
at time n where {N}m indicates RFC 5297 encryption of plaintext N using
key m:

   <-- { Bn, NBn }kn-1

then he waits for Alice (or really they could both "initiate"
simultaneously, it would work just fine):

   ---> {An, NAn }kn-1

Their ability to unwrap the new public key and nonce using the previously
authenticated secret provides the necessary authentication to the current,
nth, key exchange. Then they generate new rxn, txn, and kn and continue.

   regards,

   Dan.

On 7/2/18 1:53 PM, David Carrel (carrel) wrote:
> URL: 
> https://www.ietf.org/internet-drafts/draft-carrel-ipsecme-controller-ike-00.txt
>
> Htmlized: 
> https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00
>
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike
>
> We would appreciate any discussion and feedback.  The motivation for 
> this work began in very large SD-WAN network implementations where 
> there is full-mesh, multi-path IPsec connections between 10s of 
> thousands of nodes, and where bi-directional peer-to-peer connectivity 
> is not always present.  In these networks, centralized controllers do 
> actively manage all IPsec endpoints.  With this approach, we are 
> looking to reduce session establishment time, improve scalability and 
> preserve confidentiality of IPsec keys.  Without direct peer-to-peer 
> key messages, synchronization becomes a key challenge and we have also 
> provided a solution for that.
>
> This method would be compatible with an I2NSF controller based 
> approach.  Additionally, we have had interest from other use cases for 
> a controller based key management scheme.  So we are proposing this as 
> a method that can be used within multiple controller based management 
> protocols to provide endpoint key management.
>
> David Carrel
>
> [email-masked] <mailto:[email-masked]>
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "David Carrel (carrel)" <[email-masked]>
Date: Tue, 17 Jul 2018 22:35:59 +0000

Thanks or the comments Dan.  My responses are inline:

What we have documented is a method and not a protocol.  This method is suitable for embedding in other protocols.  We do specify that there is a requirement that the controller protocol provide authentication/integrity of suitable strength.  So if A receives B’s pub key from the controller, it will be over a secure connection which ensures it came from the controller.  The details of the connection security are out of scope for this method.
In the “next steps” category, we do raise the question of whether A (not the controller) should sign A’s public key so that B can verify that it truly came from A.  Your key wrapping suggestion could be used there.  But it isn’t clear yet that we even want this.

2. there's no proof of possession of the secret before it's use in a
protocol that requires trust of the key (ESP). It's a Diffie-Hellman
exchange and then direct use of a resultant key. Is this a problem?
If not, you should explain why (e.g. in Security Considerations).
Yes, there is no proof of possession directly from A to B.  Isn’t this the same as DH public values exchanged in an IKEv2 child SA?  However, in this method, each peer does establish a trust relationship with the controller.  In a network environment where a controller based key exchange is in use, this should suffice.  A controller based key exchange is not universally appropriate.
As for using the resultant key from the DH exchange: We do not recommend using it directly.  In the main body of the draft we do refer to DH keys rather loosely.  We will clarify.  We do specify Nonces be sent with the public keys, and in the Appendix we give a usage example where a KDF is used.

  Sn = DH(An, Bn)

  <-- { Bn, NBn }kn-1

  ---> {An, NAn }kn-1

There is a problem with your kn usage.  Kn would be a unique key known only to Alice and Bob.  But when Alice and Bob rekey, they do not rekey just with each other.  Instead they rekey with every peer in the network.  So you can’t wrap An in kn-1 because An is sent to the controller for distribution to everyone.
Thanks again
Dave

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Jul 2018 22:27:07 -0400

As discussed privately. I also like the draft.
Yours,
Daniel

On Tue, Jul 17, 2018 at 6:35 PM, David Carrel (carrel) <
carrel=[email-masked]> wrote:

> What we have documented is a method and not a protocol.  This method is
> suitable for embedding in other protocols.  We do specify that there is a
> requirement that the controller protocol provide authentication/integrity
> of suitable strength.  So if A receives B’s pub key from the controller, it
> will be over a secure connection which ensures it came from the
> controller.  The details of the connection security are out of scope for
> this method.
>
> In the “next steps” category, we do raise the question of whether A (not
> the controller) should sign A’s public key so that B can verify that it
> truly came from A.  Your key wrapping suggestion could be used there.  But
> it isn’t clear yet that we even want this.
>
>
> Yes, there is no proof of possession directly from A to B.  Isn’t this the
> same as DH public values exchanged in an IKEv2 child SA?  However, in this
> method, each peer does establish a trust relationship with the controller.
> In a network environment where a controller based key exchange is in use,
> this should suffice.  A controller based key exchange is not universally
> appropriate.
>
> As for using the resultant key from the DH exchange: We do not recommend
> using it directly.  In the main body of the draft we do refer to DH keys
> rather loosely.  We will clarify.  We do specify Nonces be sent with the
> public keys, and in the Appendix we give a usage example where a KDF is
> used.
>
>
>
> There is a problem with your kn usage.  Kn would be a unique key known
> only to Alice and Bob.  But when Alice and Bob rekey, they do not rekey
> just with each other.  Instead they rekey with every peer in the network.
> So you can’t wrap An in kn-1 because An is sent to the controller for
> distribution to everyone.
>
> Thanks again
>
> Dave
>
>
>