Re: addresses and IKEv2

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

 In your previous mail you wrote:

   The fundamental problem is how can we identify a host unambigously in
   real time in order to be able to automate the picking of the correct
   crypto key used to authenticate it and then bootstrap the SA?  I don't
   see the answer anywhere in the RFCs or IDs.  Certainly there are a lot
   of documents and maybe I've missed seeing it.  I know that X.509 certs
   are not the answer (the bound name/address is too static and can be 
   unreliable).
   
=> I have a different view of this problem: I believe the identity
is really the IKE phase one ID and X.509 certs are the answer. But
of course this is not enough because the problem moves to the relationship
between the identity and the IP address:
 - it must be flexible, i.e. I agree here X.509 certs are too static.
 - it must be reliable, i.e. if the identity is a FQDN then we have to go
   to DNSsec which is not ready and deployed.
 - it should be "agile" if we'd like to support mobility, i.e. the previous
   solution is not enough dynamic.
 - it should be broken if we'd like to support NAT traversal. Of course
   this opens the door to obvious security problems.
I'd like to see this WG decides what properties we'd like to get for
addresses, i.e. in the same order:
 - authenticated
 - indirectly authenticated
 - check for integrity
 - just pick up as they are got.
The trust is not the same, authentication relies on PKIs, integrity checks
on the peer, last property on ingress filtering and safe infrastructure.

As we use more and more IDs of not address types (as recommended by
the IAB in RFC 2956), this problem should be solved ASAP. IMHO it is
more important than SOI (or at least should be a critical point of SOI).

Thanks

Francis.Dupont@enst-bretagne.fr