Re: opportunistic IPsec interoperability

Here are some additional observations on IBE:

IBE requires that the public parameters for a group of users be made 
available in an integrity secure and authentic fashion. This is 
equivalent to having to distribute a public key cert for the CA for 
these users. There is also the problem that the enity who acts as a 
CA in an IBE context must be trusted to create the private keys for 
the users it represents, not an ideal security model in general.

IF one managed to align CAs with DNS domains, THEN this might be a 
more manageable problem. But, note the failure to perform such 
alignment for traditional (cert-based) PKIs. Thus one needs to 
explain why we expect to create an IBE infrastructure that aligns 
with DNS and does not become a trusted third party (e.g., 
VeriSign-style) infrastructure, given the lack of success in doing 
this for traditional PKIs.

Also, IBE was initial proposed as a way to address the problem of 
e-mail encryption, where the sender has to retrieve the cert of each 
recipient before being able to send encrypted mail. In IPsec, the 
real time connection between two parties provides a ready means to 
exchange certs, so the underlying problems are not the same. In fact, 
certs are used for authentication in the Ipsec context, not 
encryption, so IBE is literally not the ideal term for what one would 
like here.  It would be IBS (identity based signature), since IKEv2 
uses only signatures for authentication (a simplification relative to 
IKEv1, where either signatures or encryption was used for 
authentication).

Steve