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

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

Hi Steve,

Please see some comments below, marked with [JL].

From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, July 22, 2010 2:46 AM
To: Laganier, Julien
Cc: Sam Hartman; Margaret Wasserman; PaddyNallur; [e-mail]; Dong Zhang; [e-mail]
Subject: RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?

At 10:35 AM -0700 7/21/10, Laganier, Julien wrote:
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.

Section 7.3 of RFC 3792 (the original CGA RFC) says:

7.3.  Privacy Considerations

   CGAs can give the same level of pseudonymity as the IPv6 address
   privacy extensions defined in RFC 3041 [RFC3041].  An IP host can
   generate multiple pseudo-random CGAs by executing the CGA generation
   algorithm of Section 4 multiple times and by using a different random
   or pseudo-random initial value for the modifier every time.  The host
   should change its address periodically as in [RFC3041].  When privacy
   protection is needed, the (pseudo)random number generator used in
   address generation SHOULD be strong enough to produce unpredictable
   and unlinkable values.  Advice on random number generation can be
   found in [RFC1750].
This text  motivates my characterization of the privacy aspects of CGAs, which depends on the ability of a hos to use different CGAs, either serially or in parallel.  I think of the CGA mechanism as a way to enable use of varried address by a host, but to also enable a first hop router, to have confidence that an address of this sort (generated in an auto-config fashion) is not being hijacked by another local host.

[JL] I read the above RFC 3972 text as not negating the privacy feature that can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus a CGA might or might not have privacy feature, and privacy is thus a feature that is orthogonal to CGAs. The central feature of a CGA is that one can verify that host "owns" the address (own in the sense that it's the one that generated in the first place, i.e., it's not hijacked.)
>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.

I think the text above, and the cited text in RFC 3041 explains the rationale for privacy assertions re CGAs.

[JL] Understood.

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

yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.

[JL] I think we agree but differ on how we're expressing it. I'd say that the use of static addresses in ACLs is in conflict with the privacy afforded by being able to periodically regenerate an address, as per 3041.

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

I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.

[JL] The use of CGA in the mobile IP context was documented later, in RFC 4866 "Enhanced Route Optimization for Mobile IPv6".
 > 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.

yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-).

[JL] Well that could be all done based on IPsec, as you note below.
 > 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.

and IPsec would be a good idea here too :-).

[JL] Agree

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

Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?

[JL] if there's execution of a key establishment protocol based on the public keys bound to the CGAs, the opportunity for a DoS attack is reduced and more in line with what's been done in the context of BTNS.

[JL] All of that being said, I agree that the requirement to use static CGAs is a bad thing. That requirement could be removed if the ACLs were based on the public keys generating the CGAs, rather than the CGAs themselves. But if that were the case, coupled with the use of a key establishment protocol, then it becomes dubious what is the additional value provided by CGAs as IPsec seems to afford the required security service: access control, integrity protection.

--julien