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

Stephen Kent <kent@bbn.com> Thu, 22 July 2010 11:15 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 89F6B3A6A90; Thu, 22 Jul 2010 04:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.064
X-Spam-Level:
X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 I3y5z9K81alK; Thu, 22 Jul 2010 04:15:37 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DBA8A3A6828; Thu, 22 Jul 2010 04:15:36 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:55735 helo=[192.168.9.234]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ObtkO-0005ZX-6d; Thu, 22 Jul 2010 07:15:28 -0400
Mime-Version: 1.0
Message-Id: <p06240801c86d39d160ab@[192.168.9.234]>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F66885082@NALASEXMB04.na.qualcomm.com>
References: <tsl630fmwok.fsf@mit.edu> <p06240805c86a38f57df9@[128.89.89.72]> <BF345F63074F8040B58C00A186FCA57F1F66885082@NALASEXMB04.na.qualcomm.com>
Date: Wed, 21 Jul 2010 20:45:49 -0400
To: "Laganier, Julien" <julienl@qualcomm.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-932325169==_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] 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, 22 Jul 2010 11:15:38 -0000

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

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

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

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

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

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