Re: Adding revised identities to IKEv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
   to IKEv2, but doesn't cover better use of identities and certificates.

=> I really prefer your way to deal with identities/certificates than
the traditional IKEv[12] one with its unspecified link between identities
and addresses. But it shows we have to understand exactly what could/should
be the usage of addresses in key management protocols too (see after).
 A little point: if the URL is to the initiating machine there can be
some bootstrap problems (to get it can need an IPsec-protected connection
to the initiator), so this case should be added to the unresolvable URLs.

Thanks

Francis.Dupont@enst-bretagne.fr

PS: according to IKEv2 drafts, IKE implicitly sets up IPsec SAs
for the same IP addresses it runs over, so these addresses are important:
 - they are not protected at all, this opens the door to Dos attacks
   (not against IKE, but using IKE to redirect traffic) and ables
   NAT traversal for IKE messages.
 - if they were protected or if the network is trust to keep them
   unchanged in route, the peer can be trusted or not to put its proper
   address.
 - the fact IKE needs more than a sigle exchange of two packets, one each
   way, gives a weak proof the peer is really at its address (this is
   the "return routability" proof).
 - if the address is bound to the authentication (for instance the address
   is an alternate subject name of the certificate) a strong proof is
   available but without a specified way to control its use.