Re: Identifiers

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

 In your previous mail you wrote:

   The main reason to forego having identifiers is that it is hard to 
   determine if a correspondent is rightfully using an identifier. 

=> can I translate this statement into a generic "authorization" issue.

   However, this is not the case for two classes of potential identifiers:
   
   1. Identifiers with a cryptographic nature, such as the ones proposed 
   for HIP. Since the identifier is a hash of a public key, proving 
   ownership is trivial given a few round trips and CPU cycles.
   
=> note that ownership is not authentication.

   2. FQDNs with a certificate that leads back to a trusted authority. 
   These are in relative wide use today for SSL.
   
=> this implies some kind of PKI but provides strong authentication.
We can get both: in HIP "anonymous identifiers" are 1 and other
identifiers are 1+2, at most one identifier (the initiator's one)
can be anonymous.

   It stands to reason that future developments will lead to new types of 
   verifyable identifiers. I think this invalidates the assumption that 
   verifying the authenticity of identifiers is too hard a priori. Rather, 
   the question should be whether we are willing to accept the necessary 
   complexity to allow extensible identifier authentication in our multi6 
   solution of choice. In this regard, it should be interesting to see 
   what the MOBIKE people are up to.
   
=> IPsec/IKE requires strong authentication (i.e., 2) by default.
IMHO it can be lowered to what HIP requires, i.e., at least 1 for
the initiator and at least 2 for the responder in some contexts.

   Personally, I think the best choice would be to remain agnostic about 
   the identifier issue for now, but build our negotiation protocol such 
   that they can be added easily later. For now, we build a "no 
   identifier" type solution. Solving the problem of how a correspondent 
   proves ownership of an identifier can then be deferred until such time 
   that someone actually wants to extend the multi6 solution to support 
   identifiers. So the only thing we have to do now is make sure the 
   protocols are flexible enough to allow such extensions.
   
   Thoughts?
   
=> I disagree because the security, in this case a proper handling of
the authorization issue, must be included in the design from the
beginning.

Regards

Francis.Dupont@enst-bretagne.fr