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

Stephen Kent <kent@bbn.com> Thu, 29 July 2010 07:53 UTC

Return-Path: <kent@bbn.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 95DB23A69C2; Thu, 29 Jul 2010 00:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 ijIKILZk3yrf; Thu, 29 Jul 2010 00:53:52 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 536C13A69AD; Thu, 29 Jul 2010 00:53:52 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:39281 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1OeNwU-0004U9-8S; Thu, 29 Jul 2010 03:54:14 -0400
Mime-Version: 1.0
Message-Id: <p06240807c876e0f794c1@[130.129.114.216]>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F6688540F@NALASEXMB04.na.qualcomm.com>
References: <tsl630fmwok.fsf@mit.edu> <p06240805c86a38f57df9@[128.89.89.72]> <BF345F63074F8040B58C00A186FCA57F1F66885082@NALASEXMB04.na.qualcomm.com> <p06240801c86d39d160ab@[192.168.9.234]> <BF345F63074F8040B58C00A186FCA57F1F6688540F@NALASEXMB04.na.qualcomm.com>
Date: Thu, 29 Jul 2010 03:53:34 -0400
To: "Laganier, Julien" <julienl@qualcomm.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-931732443==_ma============"
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: Thu, 29 Jul 2010 07:53:53 -0000

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

>...

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

Agreed.

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

OK.

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

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.

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

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