[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.
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.
=> I disagree because the security, in this case a proper handling of
the authorization issue, must be included in the design from the
- From: Iljitsch van Beijnum <email@example.com>