Hi Paul, > 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.
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... > 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 :) My preference is quite the opposite :-) Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
