Re: [Mipshop] comments on drafts using CGA

["James Kempf" <kempf at docomolabs-usa.com>]

Zhen,

A few years ago, some of us published some drafts on how to use ID crypto 
for address security. Basically it came down to using the address as the 
public key. The problem is the need for provisioning of the private key by 
the KDC. The two problems with this were 1) the KDC knows the private key 
and therefore could compromise it and 2) the KDC and the client need to 
support some other kind of cryptosystem to provide confidentiality during 
the key distribution. The first problem can be limited using a couple of 
techniques, like HIDE (Hierarchical Identity-based Encryption) but the 
second one seems insoluble. Given that RSA is a logical choice for the 
cryptosystem between the KDC and the client, why not simply use CGA in the 
first place? From a system perspective, ID crypto is like Kerberos, and it 
suffers from the same limitations when used for deployment scenerios that 
are open-ended, i.e. not limited to particular organizations or other 
groups. Possibly you have some new insights into solving these problems, I 
have not read your draft so I cannot say.

Regarding your other criticisms of the drafts that use CGAs, I haven't 
looked at the drafts with this perspective in mind, but if they are not 
abiding by the guidelines in RFC 3872, then they probably need some work. 
Also, there is IPR on CGAs, and the IPR holders only released it for SEND, 
so that issue would need to be addressed before the other drafts could 
become standards.

I'll send you the drafts under separate email.

           jak


----- Original Message ----- 
From: "CAO, ZHEN" <caozhenpku at gmail.com>
To: <mipshop at ietf.org>
Sent: Saturday, October 21, 2006 11:52 PM
Subject: [Mipshop] comments on drafts using CGA


> Hi everybody,
>
> CGA was proposed in RFC3972, and it was originally used in SEND related
> protocols. Recently it has witnessed the proliferation of taking 
> advantages
> of CGA in many protocols such as [draft-ietf-mipshop-cga-cba-00.txt] and [
> draft-haddad-mipshop-hmipv6-security-06.txt]. But unfortunately, CGA was
> originally designed for SEND related protocols, which means we should give
> more considerations than the original CGA if we apply it in other
> protocols.
>
> Actually it has already been suggested in section 7.4 of RFC3972:
>
> <snip>
>
>   Finally, a strong cautionary note has to be made about using CGA
>   signatures for purposes other than SEND.  First, the other protocols
>   MUST include a type tag and the sender address in all signed messages
>   in the same way that SEND does.  Each protocol MUST define its own
>   type tag values as explained in Section 8.  Moreover, because of the
>   possibility of related-protocol attacks, the public key MUST be used
>   only for signing, and it MUST NOT be used for encryption.  Second,
>   the minimum RSA key length of 384 bits may be too short for many
>   applications and the impact of key compromise on the particular
>   protocol must be evaluated.  Third, CGA-based authorization is
>   particularly suitable for securing neighbor discovery [RFC2461] and
>   duplicate address detection [RFC2462] because these are network-layer
>   signaling protocols for which IPv6 addresses are natural endpoint
>   identifiers.  In any protocol that uses other identifiers, such as
>   DNS names, CGA signatures alone are not a sufficient security
>   mechanism.  There must also be a secure way of mapping the other
>   identifiers to IPv6 addresses.  If the goal is not to verify claims
>   about IPv6 addresses, CGA signatures are probably not the right
>   solution.
>
> <snip>
>
>
>
> I do not think all the drafts meet the requirements above well. [
> draft-haddad-mipshop-hmipv6-security-06.txt] does not include a type tag 
> and
> makes use of the public key to distribute a shared key between MN and MAP; 
> [
> draft-ietf-mipshop-cga-cba-00.txt] does not give any consideration on the
> justification of using this short RSA key. As a result, I suggest that the
> draft using CGA for authentication or authorization add a subsection in 
> the
> Security Consideration section to address the problems mentioned above.
>
> What's more, by signing a message with the private key, the address owner
> can assert (a) that somebody owns this address and (b) that the message 
> was
> sent by the address owner. But it cannot assert whether the address owner 
> is
> a trusted entity. An attack can auto-configure a RSA public-private key 
> pair
> and then configure a CGA ipv6 address, cheating the receiver to trust him.
> If the keys are generated and distributed by a trusted entity in the
> network, this problem can be avoided. Identity-based Cryptosystem (IBC) 
> does
> the very thing for private/public keys generation binding with an IBC-ID,
> and it does not introduce a long chain of certificates as PKI does. The 
> CGA
> address is computed with the public key of IBC system, so by signing a
> message with private key, the address owner can assert three points: 
> (a)that
> somebody owns this address and (b) that the message was sent by the 
> address
> owner, and (c) the address owner is a trusted entity. This is what we have
> suggested in [draft-cao-mipshop-ibc-cga-00.txt] and it sounds better than
> what the CGA has guaranteed.
>
>
> Thanks,
> Zhen


--------------------------------------------------------------------------------


> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop


_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop