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

[Stephen Kent <[e-mail]>]

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

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

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.

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

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.

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

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.

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

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

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

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.

>...
>I am not creative/imaginative enough to believe that CGA access 
>control will replace TLS!  :-)

agreed.

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

good.

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

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

Steve