Re: Identifiers

[Brian E Carpenter <brc@zurich.ibm.com>]

Our problem is not ownership. It is surviving changes in existing connectivity
without opening the door to hijacking or DoS. All we need to authenticate
is that after a multihoming event, we are still talking to the same
entity at the other end.

   Brian

Iljitsch van Beijnum wrote:
> 
> 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.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM