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

[Stephen Kent <[e-mail]>]

Margaret,


>...
>>>
>>>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.
>
>There may be an inherent incompatibility between access control and 
>anonymity, but that does not mean that the use of CGAs for access 
>control is mutually exclusive with their use for privacy by the same 
>node.

I agree, in principle, but in practice I think there may serious 
problems. Hosts would have to support both modes of operation and 
offer a decent UI to enable users to choose which type of CGA they 
want in a given context.  I worry that the latter will be hard to do 
well, and thus users may, in reality, be deprived of the anonymity 
that CGAs can offer, because hosts don't offer a UI that is 
manageable.

>A node could have a CGA (or a set of CGAs) that it uses to access 
>certain resources.  Those  address(es) could be used in access 
>control lists, etc.  However, the same node could still generate 
>CGAs or IPv6 Privacy Addresses for temporary use when 
>anonymity/privacy is desired.

see my comment above. also, your text here assumes that privacy is 
the rare case, which prejudices the discussion :-).

>I would argue that the use of CGAs for privacy, as you have cited 
>it, is under-specified.  There is mention of the concept that hosts 
>could use CGAs for privacy, but there is no explanation of how those 
>addresses would be managed, how long they should live, how 
>application-level programs should request them, etc.  IPv6 Privacy 
>Addresses (as defined in RFC 4941) are much better specified for 
>this purpose.

I agree that 4941 provides a more concrete discussion of privacy for 
IPv6 addresses. But the discussion in section 2.4 of that RFC 
describes the simple notion of changing IIDs over time, and it 
suggests selecting the IIDs in a pseudo random fashion.  CGAs meet 
these criteria. I think the authors of 4941 erred in dismissing the 
use of CGAs (in section 3.2.3). The authors of 4991 seem to assume 
that the public key used with CGAs is fixed, even though 3792 does 
not require/suggest that. Also, while I agree that the MD5-based 
randomization process in 4991 is faster than the analogous hash 
computation for 3972, I don't think the difference is significant 
with current processors and most, reasonable scenarios.

As I noted in my message, RFC 3972 makes a number of references to 
privacy, so it was clearly a major consideration in the CGA design. I 
see CGAs as balancing the option of privacy with a need for local 
address use validation. The local address use validation is a good 
secruity practice, with minimal, adverse privacy concerns.  If we say 
that CGAs are not to be used when  privacy is desired, and if local 
net managers demand CGAs for local address use validation, then we 
have deprived users of all address privacy options.  I'd not like to 
see that outcome.

>>...
>
>There is also a possibility that the use of CGAs and a CGA extension 
>in the early packets of an exchange could be used to set-up an IPsec 
>SA for the remainder of the flow.  In cases where a flow will 
>consist of more than a few packets, this would probably be a better 
>approach than signing all of the packets in an exchange.

I agree.

>...
>
>>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?
>
>As we discuss in the security considerations section, this is an 
>open issue with the specification.  There are some possibilities for 
>how to deal with this issue -- perhaps we could require that the 
>requester generate it's own CGA, sign the request and include an CGA 
>extension header on the request?

I don' think that is a viable approach for all of these cases cited 
in the proposal, e.g.,  it would require a host to be aware of the 
CGA of any intermediary system that might want to challenge the host. 
Maybe the scenarios in the proposal need to be scaled back.

>  Or perhaps it would be better for the requester to do some other 
>costly operation to make this attack as expensive for the attacker 
>as it would be for the target?  There may be other possibilities for 
>how to address this issue...  it is one of the things that we should 
>work out in the IETF before publishing this document.

If the CGA challenge comes from a destination (not an intermediate 
system) and the host has a relationship with that destination, there 
probably are ways to alleviate this concern. But, if we look at 
scenarios like web server access, the TLS server cert model seems 
much more reasonable as a way of identifying the destination.

Given the rising interest in issuing and publishing certs using 
DNSSEC, I think that model may be more appropriate for 
source/destination access control.  We have a number of security 
protocols that know how to use certs, but we have had a hard time 
overcoming the hurdles  associated with the issuance and distribution 
of certs in a very large scale fashion. DNSSEC provides an ideal 
basis for certifying the binding between a DNS name and a public key, 
in a fashion that does not require handing $ over to a trusted third 
party.

Steve