Paul Wouters writes: > 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
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. > 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. > 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> 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> > 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> 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 protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
