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

["Bound, Jim" <Jim.Bound@hp.com>]

also performance of IPsec has much to do with the encrypt algorithm such as use with AES has different capabilities from test results from different suppliers.
/jim 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, July 19, 2006 9:40 AM
> To: Iljitsch van Beijnum
> Cc: shim6-wg
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> 
> 
> 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
> 
> 
> 
>