Re: Shim6 proxies

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 14-jun-2006, at 16:24, Erik Nordmark wrote:

> > shim6 security could work much the same way by tying a certificate  
> > to a ULID, either with or without the intermediate step of an  
> > FQDN. Such a certificate allows a host to prove that it holds a  
> > certain identity, irrespective of the address it's actually using.

> I can see this working, but it can't securely recover a context  
> after a failure failure! This is because there is no trusted  
> relationship between the certificate for the server and the  
> alternate locators of the server.

Does there have to be? You don't have to authenticate the envelope if  
you know the letter is real. But let's see...

> The host (which doesn't have a cert) uses HBA. Looks up  
> www.example.com and gets some IP addresses. The shim6 layer on the  
> host is told the FQDN for the peer.

Really? I don't remember the FQDN playing a part in any shim mechanics.

> During the shim6 context establishment TLS is used, which verifies  
> the server's cert. If the server needs to use a different locator  
> it can use TLS to tell the client the new locator; the shim6 layer  
> needs to verify that the same cert is used for the locator update  
> as was used for the context establishment.

Ok.

> But that happens if the client looses the context and the server  
> needs to send it some data? One would have to fall back on  
> essentially return routability, since the client's shim doesn't  
> remember the FQDN of the server any more (perhaps the application  
> remembers the FQDN but that doesn't help unless we redo all the  
> socket APIs from scratch).

> The worst case is when the client has lost the context and the  
> server needs to contact the client but using a locator that is  
> different than its ULID; in this case even return routability can't  
> be used.

Ok, I see what you mean. One solution would be to forget the FQDN and  
work with ULIDs, but the downside of that is that people need new  
certificates. Alternatively, the FQDN can be recovered from the DNS,  
but without DNSSEC that's not the most secure thing in the world. In  
stuff like HTTPS the important relationship is betweeen the FQDN and  
the certificate, the addresses are mostly incidental. But for the  
shim the FQDN <-> ULID relationship is much more crucial.

I think it would be possible to repair this by having side A create a  
hash of some of side B's stuff along with a secret, and then transmit  
that hash to B. When A then garbage collects and B subsequently  
reconnects, B can say "I presented this to you earlier and you  
believed me then, this hash proves it".

With such a system in place we can also reduce the state that has to  
be kept for an inactive shim context to pretty much just one or more  
alternative locators and  a hash. All other information can be  
recovered from the other side when needed.