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

Margaret Wasserman <> Thu, 22 July 2010 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E72C63A6835; Thu, 22 Jul 2010 05:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BT43vhY3qtdZ; Thu, 22 Jul 2010 05:50:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DFF053A67B8; Thu, 22 Jul 2010 05:50:37 -0700 (PDT)
Received: by qwe5 with SMTP id 5so3229076qwe.31 for <multiple recipients>; Thu, 22 Jul 2010 05:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=4FJn+5kUVVjkXsZvPqF9SncU6OX6irUvr0Fx5Tw1J48=; b=NS5vHE5xadbj9XGGigQkwILxujitxFul5TDmbOSWZWKD5drJi/ppJlcD8dLJ8/TlXF kMsstSyY5gRdGWXnozauxWG/2Phd6EiFNJAt5NapYkDNy9XE9z1a1a5xaKmDEbZyZoOI Zkc3lQCvse6/ImKKLBgtACEgM1p8El4ECH+zk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=KCFg3KF7DsXgfkw0VxkI7zGxBa0BE/KAmRpo0kk/rZ7VfFZhAbK+zQ1wWQHok/tG3k a8RInJ7T7NxE4JydJiBqB6xrYnUNaQjG6zSn+S1xCoVg0YmjxeYBI1ZIiYtz2V2yIEoZ IgyM0BVq59yhZQ43+fxregc1DiSkp4endkoB0=
Received: by with SMTP id p38mr1138388qaj.270.1279803054330; Thu, 22 Jul 2010 05:50:54 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id h20sm30457839qcm.33.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 05:50:43 -0700 (PDT)
Message-Id: <>
From: Margaret Wasserman <>
To: Stephen Kent <>
In-Reply-To: <p06240801c86d39d160ab@[]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 22 Jul 2010 08:50:16 -0400
References: <> <p06240805c86a38f57df9@[]> <> <p06240801c86d39d160ab@[]>
X-Mailer: Apple Mail (2.936)
X-Mailman-Approved-At: Thu, 22 Jul 2010 06:47:38 -0700
Cc: "Laganier, Julien" <>, Dong Zhang <>, "" <>, PaddyNallur <>, "" <>, Margaret Wasserman <>, Sam Hartman <>
Subject: Re: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jul 2010 12:50:40 -0000

Hi Steve,

Thanks for your feedback!

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

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

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.

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

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