[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
=> 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
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
=> 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
=> 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.