[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identifiers

On 23-mrt-04, at 18:17, Francis Dupont 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. Would it be useful to add an authorization step to this process? 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. But then the question becomes: who grants authorization?

   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.

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.

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. 

=> 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?

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.

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. 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.

However, there are some things we can do to make it easier to support X.509 certificates in the future. 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.