[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


El 19/07/2006, a las 17:13, Bound, Jim escribió:


You can also assume the security is already protected with Ipsec.
please note that having a secure channel with the other end is not enough to prevent hijacking attacks as described in the threat analysis RFC
in order to prevent identity hijacking attacks, you need to provide a secure binding between the identifier and the alternative locators, which can only be provided by IPSec either by administrative means (i.e. preshared keys) or with certificates (PKI) on both ends of the communication
In other words, independently if the fact that the communication is previously secured by IPSec, you still need or PKI or preshared keys 

Regards, marcelo



/jim


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

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.


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...


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 and lets people avoid the patent issues if they want.