Subject: [IPsec] Key rollover and IDr payload(s)

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Nov 2017 09:54:11 -0500 (EST)

Hi,

We are looking at Opportunistic IPsec and supporting key rollover
support. In IKEv1, the initiator used the responder's key first,
and the responder could figure out which of its multiple keys the
initiator used. But in IKEv2, the responder uses one of their keys
and it does not really know which ones the initiator knows about.

So we would like the initiator to indicate which key it is expecting
the peer to use.

We could use the IDr payload in IKE_AUTH for that, using an ID_KEY_ID
type. But we would also really like to use the IDr payload on the
initiator to convey to the responder which FQDN we are expecting, so a
responder could use a different key for each FQDN it is responsible for.

While the responder could map ID_KEY_ID to FQDN's, it would be nice if
we could send both pieces of information from the initiator. I can see
a few ways of doing this:

1) Allow sending two IDr payloads in IKE_AUTH request

2) Add a new NOTIFY type that takes an IDr payload, then send the real
    IDr payload and the NOTIFY containing the second IDr payload.

3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr
    payload with that.

4) No change, use IDr ID_KEY_ID and leave it the implementer's problem
to figure out keyid -> FQDN.

I've ordered these according to my preference. I'd like to hear other
people's view on this :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 30 Nov 2017 11:03:55 +0300

Hi Paul,

> responder could use a different key for each FQDN it is responsible for.

Doesn't ID_KEY_ID unambiguously determine the FQDN?
I presume that you may have several keys for each FQDN (for key rollover),
but each key is used for a single FQDN. If this is the case, then
sending FQDN along with ID_KEY_ID in IDr looks superfluous - 
you should be able to always map ID_KEY_ID to FQDN.

Moreover, while ID_KEY_ID is often an opaque data, an FQDN
reveals perceived responder identity to an active attacker,
so there are some privacy concerns...

> I've ordered these according to my preference. I'd like to hear other

My preference is quite the opposite :-)

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Nov 2017 08:52:18 -0500 (EST)

> Doesn't ID_KEY_ID unambiguously determine the FQDN?

Yes, but indirectly and incoveniently.

> so there are some privacy concerns...

Any internet-wide opportunistic method depends on some public method to
find public keys, so that information, FQDN or opaque, is available
to the attacker anyway.

However, come to think of it, the IDr payload could help David for his
hidden-in-TLS feature so it would not depend on PPK.

Paul

---

From: David Schinazi <[email-masked]>
Date: Thu, 30 Nov 2017 08:50:57 -0800

Hi Paul,

Regarding the original email, I'm not a fan of (1) as then implementations
have to handle receiving two different FQDN IDr's for example.
Having something like (2) where the new notify can only appear once
and it explicitly is there to select the key sounds best IMHO.

Regarding the hidden-in-TLS feature (I like that name, thanks Paul),
I don't think this would help as the goal is to not reply to SA_INIT from an
untrusted party so changing the AUTH is too late.

David

> On Nov 30, 2017, at 05:52, Paul Wouters <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Nov 2017 11:56:47 -0500 (EST)

> and it explicitly is there to select the key sounds best IMHO.

Thanks :)

> untrusted party so changing the AUTH is too late.

Ohh, that's correct....

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 1 Dec 2017 01:43:05 +0200

> 1) Allow sending two IDr payloads in IKE_AUTH request

This will most likely break lots of implementations, and as this
happens before peer is authenticated, some of the will silently just
drop packets with generate INVALID_SYNTAX, i.e., which do not match
the payload patterns expected by recipient. This would mean there
would need to be yet another negotiation before this feature could be
used. 

>     IDr payload and the NOTIFY containing the second IDr payload.

I think this is bad idea. Hiding information in notify is bad idea. 

> 3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr

This is better option, as implementations should ignore IDr payload
they do not understand and fall back as their normal use.

On the other hand as you are talking about OE here, you could simply
reuse the ID_RFC822_ADDR type, and send

<keyid>@<fqdn.example.net>

identities in there. Or if you might also have real users in addition
to OE users, add suitable prefix to email address, for example:

oe-keyid+<keyid>@<fqdn.example.net>

> to figure out keyid -> FQDN.

ID_KEY_ID can have also have structure, it is opaque string which is
interpreted as the vendor feels like to interpret it. This means you
can format the ID_KEY_ID in whatever format you like, examples being:

<xml><version>01</version><keyid>keyid</keyid><fqdn>fqdn.example.net</fqdn></xml>

or

<version_byte><keyid_in_16_octets><fqdn>

od

<version_byte><keyid_len_byte><keyid><fqdn_len_byte><fqdn>

or use json, asn.1, or whatever format is suitable for you. It all
depends how your client gets this. If it just gets this from the
server as binary blob, and reflects it back on IKE_AUTH, the only end
which needs to know how to interpret the ID_KEY_ID blob is the server.

If the client needs to construct this from separate pieces, i.e., then
it needs to know the format. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Nov 2017 18:49:39 -0500 (EST)

> would need to be yet another negotiation before this feature could be

True....

> I think this is bad idea. Hiding information in notify is bad idea.

Yes, but...

> <keyid>@<fqdn.example.net>

Ohh, keyid@fqdn is actually a nice idea. I like it!

> oe-keyid+<keyid>@<fqdn.example.net>

hmmmm.

> <xml><version>01</version><keyid>keyid</keyid><fqdn>fqdn.example.net</fqdn></xml>

But this is as bad as using private values and hoping for interop. Any
structures used that are not defined in an RFC won't interop.

> depends how your client gets this.

We want to leave that open. Right now this is for when using DNSSEC,
but if people want to pull stuff from a blockchain or whatever is
sexy tomorrow, that should be possible too. For CERT based OE, this
is not a problem unless you want to roll your CA, but I can't think
about that scenario right now :)

Thanks for the feedback!

Paul