[Mipshop] comments on drafts using CGA

["CAO, ZHEN" <caozhenpku at gmail.com>]

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