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

Margaret Wasserman <margaretw42@gmail.com> Tue, 27 July 2010 09:36 UTC

Return-Path: <margaretw42@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02FA3A6A55; Tue, 27 Jul 2010 02:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJzw00mMKnMR; Tue, 27 Jul 2010 02:36:16 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 489283A67E5; Tue, 27 Jul 2010 02:36:15 -0700 (PDT)
Received: by ewy22 with SMTP id 22so1301773ewy.31 for <multiple recipients>; Tue, 27 Jul 2010 02:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=yUUhfgIW/XCUHlV5R0zii8XdsUG/G1wbdhyUUXnDoi4=; b=VuEFvKGXnVCiTWu5TtlPhsEZvQM3X4REFOL6ySpO3dqdq1bJgoONylzJ4wP5uhBsfO 2KyxuL+/pnTma4bBC8LX7D1X3W8dXb1fsNa2OQFYdO4Ni6Pd338rBv2g3UPHHj0fdipx R7PWDnE/JhNZ1/In9YohQ70ZfZ086DhSzh+eQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=CIWwbxq8LOJTsl30DyDKBXulPpSoZklLNZiERAuLucBp6Lgk/91j16D9T9n19HavIY hhKBcswCh2C8E7CVXEMIFtUL57jjhDUubNH4gNxIXotMCIU9zQ7E0jkSnuWPZ4kc2hFe jF4yrSB4F8SO4d5lKxZCHbiyP+0W/7/UKcvps=
Received: by 10.213.45.194 with SMTP id g2mr4440373ebf.0.1280223396269; Tue, 27 Jul 2010 02:36:36 -0700 (PDT)
Received: from dhcp-716e.meeting.ietf.org (dhcp-716e.meeting.ietf.org [130.129.113.110]) by mx.google.com with ESMTPS id a48sm7248730eei.19.2010.07.27.02.36.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 02:36:35 -0700 (PDT)
Message-Id: <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com>
From: Margaret Wasserman <margaretw42@gmail.com>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <p06240804c87440b32b9f@[130.129.114.216]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 27 Jul 2010 11:36:15 +0200
References: <tsl630fmwok.fsf@mit.edu> <p06240805c86a38f57df9@[128.89.89.72]> <BF345F63074F8040B58C00A186FCA57F1F66885082@NALASEXMB04.na.qualcomm.com> <p06240801c86d39d160ab@[192.168.9.234]> <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> <p06240804c87440b32b9f@[130.129.114.216]>
X-Mailer: Apple Mail (2.936)
X-Mailman-Approved-At: Wed, 28 Jul 2010 08:02:02 -0700
Cc: Dong Zhang <zhangdong_rh@huawei.com>, "secdir@ietf.org" <secdir@ietf.org>, PaddyNallur <paddy@huaweisymantec.com>, "saag@ietf.org" <saag@ietf.org>, Margaret Wasserman <mrw@painless-security.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [secdir] [saag] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2010 09:36:18 -0000

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

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.

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

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

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.

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

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?

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

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

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

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