Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 19/07/2006, a las 16:02, Iljitsch van Beijnum escribió:

> On 19-jul-2006, at 14:39, marcelo bagnulo braun wrote:
>
> > server certificate are more widely used than client certificates 
> > indeed, but in the case of the shim6 we need certificates for both 
> > ends, so what do we do for securing the client?
>
> Why? If one end has a certificate the communication can be secure.

but you still can provide identifier ownership proof, right?

I mean, in order to avoid future attacks agaisnt the identity we need 
more than just a secure channel but a secure binding between the 
identifier and something that canbe used to prove ownership (like a 
public/private key pair)

so, such scheme would result in the posibilty of identity hijacking 
attacks

in order to avoid those, you need something else, like client 
certificates


> > besides, currently deployed certificates provide binding between 
> > FQDNs and public key.... while in the shim6 we need binding between 
> > IP addresses and public keys, meaning than currently deployed 
> > certificates are not good
>
> Yes, this involves a trip to the DNS...

so, now the cost is:
- public key crypto (for the locator set validation and the 
certificates)
- added overhead (because of the transmision of the cert chain)
- latency because of the dns query

> > in addition, using certificates and public key crypto is much more 
> > expensive than CGAs, since they would involve public key operations 
> > not only for the validation of the locator set (as in CGA) but also 
> > for the validation of the certificates themselves (and this costs 
> > grows if the certification chain is long). In addition, there is the 
> > overhead due to the transmission of the certificates in the protocol 
> > itself, including all the certificates in the cert chain, which may 
> > even not fit in a single packet so we may end up neededing to send 
> > multi-packet messages.
>
> > and all this for every shimmed communication....
>
> This is certainly true. On the other hand, if the communication is 
> already protected with TLS the _additional_ overhead isn't much.
>
> Also, I think it would make sense to do the shim negotiation inside a 
> TLS protected TCP session, which should handle all the packet size 
> issues.
>
> > i thought that one of the key goals in the shim6 design was 
> > efficiency.... such an approach would really move us apart from the 
> > efficiency path...
>
> HBA is much more efficient so that should stay security option #1, but 
> it would certainly be nice to have an alternative that allows easier 
> implementation of shim6 proxies

this would indeed be a nice feature, but i would still need to 
understand how it would work with certificates...

>  and lets people avoid the patent issues if they want.

but if the HBA is the defaut sec mechanism, then the IPR issues are 
still the same, since there is the need to implement it in any case

Regards, marcelo