Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?

["Laganier, Julien" <[e-mail]>]

Steve,

Stephen Kent wrote:
> 
> Sam,
> 
> Based on a quick reading, I am troubled by many aspects of this
> proposal.
> 
> CGAs were intended to afford privacy for IPv6 users, while allowing a
> first-hop router to verify the binding between the host asserting the
> address and the address in question.

My recollection is that a form of CGA were first proposed to secure the binding between a host asserting that a Mobile IPv6 home address is reachable at a care-of address (via a MIPv6 Binding Update) and the home address in question.

>From my perspective the key intent behind the use CGA's was the ability to verify the binding without recourse to an infrastructure, not privacy.

I also don't see how the use of CGA's would afford to an IPv6 user any better privacy than another IPv6 address given that it is uniquely bound to a long (1024+ bits) public key.
 
> The proposal to use CGAs in ACLs seems to negate the privacy feature,
> because it would (I assume) call for the CGAs to be static (for ease
> of ACL management).

I agree that if CGAs were to be used in ACLs they would need to be static (or long-term), but this does not negate a privacy feature that CGA's do not have.
 
> The proposal says that "any host along the path" can engage in an
> exchange to cause the subject host to verify itself as the "owner" of
> the address. this is a very big deviation from the much more limited,
> local SeND context.

As above, CGA use is not limited to a local context such as SEND. In particular, the use of CGA's for Mobile IPv6 security is in a _global_ context.
 
> The proposal also calls for the sender to generate the signature on
> the payload of the packet, ala IPsec in Transport mode.  The document
> cites RFC 3971 (the SeND) spec, which calls for sig generation is a
> very different context, i.e., NDP packets in the SeND exchange.
> 
> This proposal includes an example (from the wireless context)
> suggesting that the sig is to be generated for every packet sent by a
> host, a requirement that would place a substantial burden on a host.
> IPsec rejected solutions of this sort for performance reasons.

If there were to be only one intermediary on-path node going to verify that the packets were generated by the CGA owner, it would be possible to execute a key exchange protocol bound to the CGAs of the sending host and the verifying node, and use symmetric keying material derived from that exchange to afford integrity protection to every packet at a cost comparable to that of IPsec providing integrity protection.
 
> Conversely, if only an initial packet exchange, involves the signed
> packet from the host, the secruity offered is much lower, making it
> vulnerable to MITM attacks.

As above, an initial packet exchange could be used to derive symmetric keys bound to the CGA's of the parties involved.
 
> Also note that SeND requires a trust anchor to be shared between the
> host and its local router. This is a reasonable assumption for that
> local context, but it less viable in a more general source/destination
> context that may extend outside a local space, as many of the offered
> examples do.

The SEND trust anchor is used by hosts to verify a router certificates chain. The router public key being certified is used to sign the router advertisement messages of the router discovery function of ND. 

In contrast, hosts uses uncertified public keys that are used to generate CGA's and sign neighbor solicitations and advertisement messages of the address resolution function of ND.  

Thus the SEND requirement of hosts and router sharing a trust anchor is entirely orthogonal to the use and generation of CGA's.

--julien