[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes)
[Slowly catching up some old e-mail]
Pekka Nikander wrote:
What comes to crypto binding, I am only aware of two possibilities:
Using asymmetric keys (or something similar) as primary identifiers,
or using CGA (or something similar). All the other solutions that
I know about require some kind of infrastructure, some kind of
an enrollment procedure, or both.
Erik Nordmark wrote:
> I guess I don't really understand your categorization.
Maybe I have to set up some context for the statement of mine above.
Firstly, my understanding is that we are still discussing the proposed
identifier/locator separation. There are certainly several possible
ways of achieving the separation, some of which involve existing
higher level identifiers. However, I tend to think more in the
line of just "splitting" the IP address roles, and perhaps
introducing a new name space for the identifiers.
Secondly, the question at hand was how to secure a binding between
a given identifier and a set of locators. (There are documents that
include descriptions of at least some of the threats involved, see
draft-nikander-mobileip-v6-ro-sec-01.txt and
draft-nikander-hip-mm-00.txt)
Now, for making secure the binding between the identifiers (entities
that applications use to denote their peers) and the locators (routing
location identifiers), I am aware of two basic mechanisms:
A. return routability (RR)
B. cryptographic binding between the locators and identifiers
Return routability, with its built in cryptographic challenge-
response protocol, basically provides assurance that a single party
is reachable with the given set of locators. From this point of
view, the reachable party remains anonymous. That is, the RR
procedure does not give the identifier any (other) semantic
meaning, e.g., there is no assurance that the party is the same
one than during the previous "session". The only assurance
gained is about the time-restricted "sameness" (identity)
of the peer.
Cryptographic binding, on the other hand, is able to create
something different. It provides assurance that the identifier
and the locator *somehow* belong together. Now, the very
question is the exact nature of that "somehow". There I am
aware of three options:
B1. CGA. In the case of CGA, the locator (IP address) acts
(still) as a primary "identifier" in some sense. That is,
given an IP address and a public key, one can be sure
that the holder of the private key corresponding to the
public key wants to use that particular IP address, and
that (with high probability) no-one else can claim the
same (i.e. the desire to use that IP address). CGA has the
drawback that it requires that everybody is using CGA, or
at least that those using CGA are given preference over
those that do not use CGA.
B2. Using asymmetric keys as primary identifiers (e.g. HIP).
Here the public key of an asymmetric key pair acts as
the primary identifier. It is fairly simple to check
that the private key corresponding to a given public key
is "reachable" at any given point of time.
Here it must be understood that a public key (or a crypto-
graphic hash of a public key) is a perfectly fine identifier
for computers. There is still a need to map human readable
names to public key identifiers, but that is a separate problem,
and IMHO outside the scope of this discussion.
B3. Relying on an external public key infrastructure, providing
external assurance for the binding between the identifier
and the locators. There are two subcases: Firstly, one can
bind the identifier to a public key (as in a PKI), and then
use procedures similar to B2. Secondly, one can bind the
identifier directly to a set of locators. The properties of
these are fairly well understood in the general case, and
there is no need to repeat them here.
It is noteworthy that in B1 and B2 the publicly known identifier
(IP address or public key) is constructed in such a way
- that there is a corresponding secret piece of information,
- that deriving the secret piece of information from the
public identifier is believed to be computationally
infeasible, and
- that it is (fairly) easy to prove the possession of the
secret information without revealing it.
CGA and using PKs as primary identifiers are not the only
possibilities; there are others. However, as far as I know
they all rely on the same computational principles, and are
structurally more or less similar.
The biggest difference is between B1/2 vs. B3. In the B3 case
the primary identifier has no cryptograhic properties. In both
B1 and B2 it *is* cryptographically constructed.
Erik Nordmark wrote:
If one wants to have the IP packets be bound to some existing identity
(like something one would find in a PKI: subject-name erik.nordmar@sun.com
with some particular trust anchor) then one would always need something
at least approximating a PKI.
As I tried to explain above, all depends on the nature of the
identifier. If the identifier itself carries cryptographic
properties, we can do without any external infrastructure.
We just rely on the computational complexity of someone
being able to construct the necessary secret piece of information.
In my view, identity is independent of the identifier.
Hence, even if we want to identify existing identities, we
can fabricate a new set of primary identifiers for them.
That would turn the currently used identifiers as plain names
(or secondary identifiers), and there is certainly a need to
securely provide the new primary identifier for every existing
name. However, that could be a one-time operation, and all new
identities could be primarily identified with the new identifiers.
Returning to the context set up in the beginning, any existing
(upper layer) identifiers are mostly beyond the scope. Even
today we need a secure mapping from the upper layer identifiers
to IP addresses. If we replace that mapping with a mapping
from upper layer identifiers to primary, cryptographic identifiers,
the change is small. The real problem is the binding from the
primary identifiers to the locators. That is something new,
and needs to be secured.
If one is only concerned about the IP packets be bound to some ephemeral
(and meaningless to higher level protocols?) identity than one can either
have the primary identifier be variable length (e.g. a public key;
a (self-signed) certificate), or fixed length (e.g. a hash of a public key
or a hash of a (self-signed) certificate).
That still allows the identifiers to be long-term stable, as well as new
identifiers being fabricated on the fly to get "anonymity".
Well, I don't see why the identity identified by such a primary
identifier needs to be somehow ephemeral. I do agree that it is
then easy to fabricate identifiers, but if one uses a given identifier
consistently over a long period of time, I would not call it ephemeral.
Secondly, it is always possible to use any given external infrastructure
to provide additional semantics for the identifiers. That is, one
can (and probably should) use a PKI (or secure DNS) to provide
additional properties for the primary identifiers. However, any
such infrastructure could be (and should be) architecturally
distinct from the binding between the primary identifier and
the locators.
Finally, if one only is concerned about being able to verify that some IP
packet is sent by the same entity that sent some previous IP packet, then
PBK type approaches would seem to fit (e.g. do an anonymous DH exchange up
front and use the resulting key to protect changes to the id/loc mapping.)
Overall, I think that we need to understand here the temporal
and spatial (topological) properties of various (weak)
cryptographic protocols. Our 2002 Cambridge Security Protocols
Workshop paper discusses that point-of-view in some length.
We are currently turning that paper into an Internet-Draft for
easier access.
--Pekka Nikander