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

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Jul 2010 08:35:23 -0400

Hi.  I've been working with the authors of
draft-dong-savi-cga-header-03. The basic idea is that you can use
cryptographically-generated IPv6 addresses for a reasonably secure form
of IP-based access control. The main advantage of this is 
administrative simplicity.  I've asked Nico Williams and Jeff Hutzelman
to take a look and have had a discussion with both of them about the
proposal. Julieng Loganier has also done previous work in this
space. The authors have also been talking to the internet ADs and
int-area chairs about the work.  Comments so far definitely suggest that
this is something worth discussing.

So, we'd like to briefly introduce the proposal and solicit comments and
see if we can get a group of people interested in working on this sort
of thing together.  I realize the SAAG agenda is reasonably full, but
would it be possible to get five minutes and say three slides to briefly
introduce the proposal?

Also, I'd like to encourage people on this list to read and comment on
the proposal. At this point, the basic idea is more important than the
specific mechanism described in the draft.

As I mentioned, the authors are working with the int-area to introduce
the proposal there; we believe input is required from both areas.

Thanks for your consideration and comments,

--Sam

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Jul 2010 21:03:08 -0400

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.

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

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.

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.

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.

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.

Steve

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Jul 2010 10:35:46 -0700

Steve,

> 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.
 
> because it would (I assume) call for the CGAs to be static (for ease

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 address. this is a very big deviation from the much more limited,

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Jul 2010 20:45:49 -0400

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

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

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

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

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

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

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

Steve

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 22 Jul 2010 08:50:16 -0400

Hi Steve,

Thanks for your feedback!

On Jul 21, 2010, at 8:45 PM, Stephen Kent wrote:
> 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.

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.

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

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.

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

I agree.  :-)

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

Margaret

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Jul 2010 04:43:44 -0400

Margaret,

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

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.

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

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

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 27 Jul 2010 08:23:06 -0700

Hi Steve,

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

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

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

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

[JL] Understood.

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.

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

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.

[JL] 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?

[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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 27 Jul 2010 11:36:15 +0200

Hi Steve,

Thanks for your additional feedback!  I am finding this discussion  
very useful.

On Jul 27, 2010, at 10:43 AM, Stephen Kent wrote:
>> control is mutually exclusive with their use for privacy by the  
>> same node.
>

In the IETF privacy address work (so far) this is not so much a matter  
of having a UI (accessed by users) as having an API where applications  
that want temporary/privacy addresses can select that option for a  
specific application (as a socket option, for example).  Applications  
that don't request privacy addresses don't get them.

Generating ones addresses as CGAs doesn't really change this  
picture...  If an application does not specify a privacy socket  
option, it could use a static CGA, while applications that do request  
privacy could use CGAs that are generated for a particular session or  
a given time period.

>> CGAs or IPv6 Privacy Addresses for temporary use when anonymity/ 
>> privacy is desired.
>

Actually, I think that privacy addresses should be the common case for  
outgoing client/server applications (e.g. web browsers).  However, I  
believe that systems will continue to have static addresses (which may  
be static CGAs) if they need to run servers that can be reached at a  
particular address, if they are using referrals that should remain  
valid over a longer period of time, or if they are using applications  
where the source IP address is used as part of an access control  
system or any other mechanism that uses the source IP address to  
identify the source of the traffic for any reason.
> with current processors and most, reasonable scenarios.

I agree with you that RFC 4991 could use some improvements in this  
area.  If we do decide to charter a separate cgasec WG, I think it  
would make sense to include an update to this section of RFC 4991 in a  
charter for that group.  Otherwise, it could potentially be done in an  
existing WG, such as 6man or intarea.

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

I have not proposed that we disallow CGAs for privacy purposes, and I  
agree that we shouldn't do that.  I don't believe, however, that using  
static CGAs for secure access control (where identifying the source is  
explicitly desired) is incompatible with using other CGAs for privacy  
(for applications where privacy is desired) on the same node.  I think  
this would work quite well within the existing APIs that we have  
designed for privacy addresses.

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

There is also the possibility (that a few other people have raised  
with me this week) that we could design an IKEv2 SPI type (I apologize  
if that isn't quite the right terminology) that contains a CGA and CGA  
parameters, and that information could be used to set-up an IPsec SA.

I am not sure if a transition to IPsec is the best choice for very  
short flows, though, such as the syslog or SNMP trap/inform use cases  
in the draft.  I would be interested in your opinion about the trade- 
offs involved.

I am not, personally, focusing on the exact details of our specific  
proposal at this point.  I am interested in discussing how/if CGAs are  
a suitable mechanism to do one or both of the following things:

1) Produce viable security mechanisms that are simpler to configure  
than existing solutions.  In many cases, this may only involve minor  
extensions or tweaks to existing mechanisms (e.g. the new IKE SPI type  
described above).

2) Offer a practical alternative to the insecure Access Control Lists  
(ACLs) that are still in wide use today.  Part of being a practical  
alternative (that will actually get deployed) is that configuring the  
new solution cannot require considerably more work or expertise than  
configuring an insecure ACL.

Do those seem like reasonable goals to you?  Do you think there is  
some potential that we could accomplish these things using CGAs?

>> 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?
>
> CGA of any intermediary system that might want to challenge the  
> host. Maybe the scenarios in the proposal need to be scaled back.

I'm not sure which use cases would need to be scaled back in this case  
and why.  Could you explain a bit more?
>> 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.

> much more reasonable as a way of identifying the destination.

I am not creative/imaginative enough to believe that CGA access  
control will replace TLS!  :-)
> 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.

CGAs have similar properties in this regard.  They don't require  
configuring certificates on end nodes, and they don't require sending  
anyone any money.  I share your preferences in this area. :-)

Using DNSSEC to resolve this problem is an interesting idea...  Is  
there a draft, paper or other published document that describes how to  
do this?  Or could you flesh it out a bit?  I would be interested in  
understanding this approach better, so that I could understand the  
trade-offs between these two approaches.

Margaret

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Jul 2010 03:40:35 -0400

At 11:36 AM +0200 7/27/10, Margaret Wasserman wrote:
>Hi Steve,
>>,,,
>
>In the IETF privacy address work (so far) this is not so much a 
>matter of having a UI (accessed by users) as having an API where 
>applications that want temporary/privacy addresses can select that 
>option for a specific application (as a socket option, for example). 
>Applications that don't request privacy addresses don't get them.

Thanks; I didn't know what the model was. I do see possible problems 
with this model. It's somewhat reminiscent of the model we had in 
mind for how to use the TOS field in IP, back in the late 70's and 
early 80's. That didn't work because apps generally didn't make API 
calls to invoke TOS, and didn't offer a UI to enable users to sya TOS 
they thought they needed, ...

>option, it could use a static CGA, while applications that do 
>request privacy could use CGAs that are generated for a particular 
>session or a given time period.

Again, I agree in principle, but I worry that in practice the default 
will be static CGAs with no real user controls to invoke privacy 
features.

>
>>...
>
>Actually, I think that privacy addresses should be the common case 
>for outgoing client/server applications (e.g. web browsers).

that's an interesting case, which may illustrate why this strikes me 
as a hard problem. Folks visit a range of web sites, some of which 
require user auth (for access control), and others that do not. If 
CGAs were to be used for access control, users might if confusing 
managing switching between static and dynamic CGAs depending on the 
sites being visited.

>However, I believe that systems will continue to have static 
>addresses (which may be static CGAs) if they need to run servers 
>that can be reached at a particular address, if they are using 
>referrals that should remain valid over a longer period of time, or 
>if they are using applications where the source IP address is used 
>as part of an access control system or any other mechanism that uses 
>the source IP address to identify the source of the traffic for any 
>reason.

I've been focusing on the user side of this issue.  Servers need 
static DNS names, irrespective of whether their addresses are static 
or dynamic (with dynamic DNS). But, I agree that most servers (not 
use by phishers ans spammers) don't need addresses that vary for 
privacy purposes.

>would make sense to include an update to this section of RFC 4991 in 
>a charter for that group.  Otherwise, it could potentially be done 
>in an existing WG, such as 6man or intarea.

Sure.

>>...
>
>I have not proposed that we disallow CGAs for privacy purposes, and 
>I agree that we shouldn't do that.  I don't believe, however, that 
>using static CGAs for secure access control (where identifying the 
>source is explicitly desired) is incompatible with using other CGAs 
>for privacy (for applications where privacy is desired) on the same 
>node.  I think this would work quite well within the existing APIs 
>that we have designed for privacy addresses.

My concern is that, in advocating use of CGAs for access control, we 
will effectively kill CGA use for privacy, for the reasons cited 
above. I don't mean to suggest that you are trying to preclude use of 
CGAs for privacy; I just see this as a likely, unintended side-efect.

>with me this week) that we could design an IKEv2 SPI type (I 
>apologize if that isn't quite the right terminology) that contains a 
>CGA and CGA parameters, and that information could be used to set-up 
>an IPsec SA.

Not the right terminology, but let's not focus on that. I saw that 
Julien published an I-D that seems to have this flavor, although I 
have not read it.

>short flows, though, such as the syslog or SNMP trap/inform use 
>cases in the draft.  I would be interested in your opinion about the 
>trade-offs involved.

Maybe. But one can establish an SA and reuse it over time, to 
amortize the SA establishment overhead. So, it depends.

>proposal at this point.  I am interested in discussing how/if CGAs 
>are a suitable mechanism to do one or both of the following things:
>
>extensions or tweaks to existing mechanisms (e.g. the new IKE SPI 
>type described above).
>
>2) Offer a practical alternative to the insecure Access Control 
>Lists (ACLs) that are still in wide use today.  Part of being a 
>practical alternative (that will actually get deployed) is that 
>configuring the new solution cannot require considerably more work 
>or expertise than configuring an insecure ACL.
>

I agree that address-based ACLs are insecure, and it would be nice to 
have better alternatives. Whether CGAs are a good choice for this 
depends on the the context in which the ACL is being used, since the 
context determines what alternatives are viable.

For IPsec, we'll have to sees the detail of the proposal. We have 
seen a lot of interest in using the DNS, now that DNESEC is being 
more widely deployed, as a way to ease the configuration burden for 
secruity protocols like TLS and IPsec.  So CGAs are not the only game 
in town, in this context.

>>...
>
>I'm not sure which use cases would need to be scaled back in this 
>case and why.  Could you explain a bit more?

Sorry if I was not clear. I think that having an intermediate node 
challenge a host may be problematic.  The host might not have a way 
to know the ID of an intermediate node, which creates the sort of DoS 
concern I cited. In contrast, a host can be expected to know the ID 
of the destination that it is attempting to reach, making these two 
cases potentially very different.

>control will replace TLS!  :-)

agreed.

>configuring certificates on end nodes, and they don't require 
>sending anyone any money.  I share your preferences in this area. :-)

good.

>there a draft, paper or other published document that describes how 
>to do this?  Or could you flesh it out a bit?  I would be interested 
>in understanding this approach better, so that I could understand 
>the trade-offs between these two approaches.

There was a bar BoF this week.  We'll see what comes from that.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Jul 2010 03:53:34 -0400

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

I agree that the primary motivation for CGAs arose in the SeND 
context, and that privacy is an independent feature. But, the context 
in which CGAs were intended to provide an ability to establish a 
binding to an IPv6 address was local. When one moves beyond this 
local context, and one advocates having more distant nodes challenge 
a host, this creates privacy questions.

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

Agreed.

>[JL] The use of CGA in the mobile IP context was documented later, 
>in RFC 4866 "Enhanced Route Optimization for Mobile IPv6".

OK.

>....

Glad to see that we agree on this point. But, note that IKE 
specifically passes credentials (e.g., certs) only after establishing 
an encrypted channel. This was done to protect the user's asserted 
ID. Thus, if one uses a CGA as an ID (i.e., and input to an access 
control decision) with IPsec, one is undermining that privacy 
(traffic analysis countermeasure) feature of IPsec.

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

I'll have to think about that.

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

I think I agree with your observation, which seems to undercut the 
"CGAs as inputs to ACLs" argument :-).

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Jul 2010 04:14:13 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> I agree that the primary motivation for CGAs arose in the
    Stephen> SeND context, and that privacy is an independent
    Stephen> feature. But, the context in which CGAs were intended to
    Stephen> provide an ability to establish a binding to an IPv6
    Stephen> address was local. When one moves beyond this local
    Stephen> context, and one advocates having more distant nodes
    Stephen> challenge a host, this creates privacy questions.

I think we've been looking at CGAs that have non-local scope for a
while.  Section 7.4 of RFC 3972 seems to anticipate CGAs used with other
protocols.  It's my understanding that shim6 supports both HBAs and CGAs
for non-local contexts.  I also believe the MIP6 context for CGA use is
non-local.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 29 Jul 2010 10:28:34 +0200

The thing I'm struggling with here is what value a CGA provides over a  
bare public key.  The use of a CGA as a source address doesn't prove  
anything except that the entity that generated it had access to a  
given public key, which is nothing special.  If you're going to get  
any security benefit, you either need

1. Out-of-band knowledge that SEND was applied in the relevant subnet,  
or
2. Some interaction that proves ownership of the private key

In the second case, you might as well just use existing protocols for  
proving ownership of a key (IPsec, TLS); the first case is just a  
special case of the second, where the entity applying access control  
has a special relationship with the layer-2 network (kind of fragile).

Either way, what you end up doing is validating that the entity holds  
a given private key, at which point the source address has nothing to  
do with the security of communications.

tl;dr: CGAs don't have any security benefit without another protocol.   
What's the use case?

--Richard

On Jul 29, 2010, at 10:14 AM, Sam Hartman wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 29 Jul 2010 14:04:18 +0200

On 07/29/2010 10:28 AM, Richard L. Barnes wrote:
> bare public key.

My understanding MAY be incomplete, but...

It looks like CGA generation binds the prefix to the key, thus there is 
a trust that the prefix has not been altered.

I don't do that in HIT generation. Don't know if I should change HIT 
generation or not. I would need to look at the IPR around CGAs.

> The use of a CGA as a source address doesn't prove anything except 
> that the entity that generated it had access to a given public key, 
> which is nothing special. If you're going to get any security benefit, 
> you either need
>
> 1. Out-of-band knowledge that SEND was applied in the relevant subnet, or