On Fri, 1 Dec 2017, Tero Kivinen wrote:
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.
True....
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.
I think this is bad idea. Hiding information in notify is bad idea.
Yes, but...
3) Add a new ID type that encodes both ID_FQDN and ID_KEY_ID, send 1 IDr
payload with that.
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>
Ohh, keyid@fqdn is actually a nice idea. I like it!
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>
hmmmm.
4) No change, use IDr ID_KEY_ID and leave it the implementer's problem
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>
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.
or use json, asn.1, or whatever format is suitable for you. It all
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
