Subject: Re: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes)

From: Pekka Nikander <[email-masked]>
Date: Wed, 06 Aug 2003 18:09:23 +0300

[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 [email-masked]
> 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