Re: [RRG] On "jack-down" models

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

> % This has obvious security implications which will, in effect,  
> require a
> % security association between hosts.  That security association  
> effectively
> % requires some security token ... so that the correspondent host  
> can be assured
> % that the component connections are indeed related.
>
> It is unclear to me that one needs to have a cryptographic security
> association in all cases, or indeed even in common deployments.
>
> For example, an unpredictable nonce present in control traffic ...   
> In such a model,
> the nonce would be the "security token", but it would not be  
> derived from any session key, from any public/private key, or from  
> any public/private key pair).

Alternatively, as a middle ground between a public key and a simple  
token would be various techniques based on reverse hash chains and  
other similar methods.  TESLA-like, if you will.  LHIP is one option  
in that space.

> % This security token is,  for all intents and purposes, a host  
> identifier.
> % ...
>
> It isn't obvious to me that the claim above is necessarily true.
> Using the example of a nonce, the nonce might be very short-lived
> (e.g. for the duration of a single IP session or flow) and hence
> not be suitable for use as a node identifier.

I agree.

> HIP makes the identity of a node a function of the public key of  
> the node.
> A corollary to that practice seems to be that if a node's public  
> key were
> compromised, and in my experience all cryptographic keys are  
> eventually
> compromised, then the node necessarily would lose its identity.

That is how the HIP architecture has been written today.

However, there is some work on using separate node-level or  
application-level identifiers (still preferably but not necessarily  
public keys), separate from the HIP-layer HI, and then using  
(delegation) certificates to bind these identities to the HIs, with  
channel bindings.  That work hasn't found its way to internet-drafts  
yet, though.  (I know a few people have talked about writing IDs in  
that space, but I haven't seen any published yet. But maybe I've just  
missed that.)

> So it seems distinctly undesirable (to me) for the identity of a node
> to be derived (directly or indirectly) from any cryptographic key used
> by that node.
>
> Instead, I'd prefer to have the cryptographic keys used by a node
> (if any) bound to the identity of the node using some other method.
> One example might be some sort of X.509v3 (PKIX) certificate, but
> other examples can be imagined.

But then you just shift the burden to the secrecy of the CA private  
key.  That is, if all keys are eventually compromised, what do you do  
when the CA private key gets compromised? You have to reconfigure all  
hosts, I guess.

To me, it would be better to not to concentrate the trust too much.   
If (manual) reconfiguration is inevitable, it might pay off to make  
sure that a) its probability is minimised and b) when it happens,  
only a small fraction of all hosts are affected.  Hence, maybe  
threshold certs at the top of the tree, or a forest instead of a  
single tree, or both?

--Pekka Nikander


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg