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.
   
   > => note that ownership is not authentication.
   
   Hm, I was working on the assumption that we only need authentication, 
   as the owner/holder of an identifier or a locator can do with it what 
   he or she pleases.

=> obviously we don't share the meaning of the word "authentication" here.

   Would it be useful to add an authorization step to this process?

=> yes, and the authorization is the real thing!

   I.e., despite the fact that I know you are indeed the 
   legitimate holder of your identifier, I may still refuse to interact 
   with you because you haven't been authorized to use the identifier for 
   this particular purpose.

=> this question is another form of "authentication doesn't imply
authorization".

   But then the question becomes: who grants authorization?

=> some kind of trust system including local policy, PKIs, ...
   
   >    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
   
   Yes. My point is that there is something that can be called a PKI for 
   SSL.
   
=> the current SSL/TLS heavily uses X.509 PKIs.

   > 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.
   
   Indeed. The initiator doesn't even have to use an identifier.
   
=> I disagree: without an identifier remote redirection is insecure.
An "anonymous identifier" is an identifier because it has ownership,
it is anonymous because it can't be bound to a name.

   > => I disagree because the security, in this case a proper handling of
   > the authorization issue, must be included in the design from the
   > beginning.
   
   Good point, building something first and then trying to plug the holes 
   doesn't work very well. However, what is "the beginning" here?
   
=> IMHO any kind of proposal which can be implemented (things which can't
be implemented can be a waste of time but should not endanger security :-).

   There are two claims that we want to check when a correspondent claims 
   that it is reachable at additional addresses: the "who" part and the 
   "reachable" part. (We don't want someone else to claim that their 
   addresses belong to our correspondent, but we also don't want our 
   correspondent to claim that someone else's addresses are theirs.) The 
   the "reachable" part is universal: once we create a protocol, this part 
   shouldn't change. However, the "who" part depends on the nature of the 
   identifiers. Without actual identifiers we only check whether we're 
   talking to the same entity, regardless of who this entity is. But with 
   cryptographic identifiers, we can actually check whether someone who 
   claims to be the holder of the identifier has the secret key. With a 
   PKI the procedure is different, with DNSSEC different again.
   
=> DNSSEC can be used as a PKI, i.e., some PKIs are not based on X.509.

   Now what I'm saying is that we should build a "no identifiers" type 
   solution *now* but recognize that we may want to have identifiers 
   later.

=> perhaps you mean we need only ownership and not strong authentication?
In anycase we need identifiers, the question should be about the needed
properties of these identifiers.

   At some point, the protocol is extended to make it possible to 
   use a certain type of identifiers. Since this is the beginning of the 
   use of these identifiers, this is also the beginning of or security 
   efforts with regards to using these identifiers. In other words, it 
   makes no sense to include X.509 handling _now_ if we are building an 
   identifier-less solution.
   
=> do I catch your idea?

   However, there are some things we can do to make it easier to support 
   X.509 certificates in the future.

=> when I disagree with the "no global PKI" of some people at the IETF,
I agree that a global X.509 PKI is not possible and even not desirable.

   For instance, use length fields that 
   are more than 8 bits. In practice there may not be a huge difference 
   between building a general purpose system that supports just option X 
   at this time and a special purpose system that only supports option X, 
   but philosophically there is a world of difference. "When the only tool 
   you have is a hammer, every problem looks like a nail." So taking the 
   hammer first and then consider the problem limits our view of the 
   solution space. Considering the problem, then determining that we can 
   solve most of it with a hammer and deciding that we can only afford a 
   toolbox with a hammer in it at this time is very different.
   
Thanks

Francis.Dupont@enst-bretagne.fr