From alberto@it.uc3m.es Wed Sep 8 06:27:40 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34B63A68DE for ; Wed, 8 Sep 2010 06:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 Dc3683HKcd3v for ; Wed, 8 Sep 2010 06:27:34 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 48A573A689C for ; Wed, 8 Sep 2010 06:27:32 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 3069FBDF92A for ; Wed, 8 Sep 2010 15:27:59 +0200 (CEST) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: Date: Wed, 8 Sep 2010 15:27:56 +0200 Message-ID: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CB4F6A.6B12C130" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 thread-index: ActPWWPEdvNpE1H/ScyIlCzCx9T7dQ== X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17622.007 Subject: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 13:27:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01CB4F6A.6B12C130 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, During IESG evaluation of draft-ietf-csi-proxy-send-04, Sandra Murphy pointed out that "I believe that a discussion is needed of what messages require or allow each particular key purpose authorization". draft-ietf-csi-send-cert-06 has been updated (in section 7) to provide more detail regarding to this issue. However, in the process of addressing this comment, some authors of draft-ietf-csi-proxy-send and draft-ietf-csi-send-cert have arrived to a controversial point, which I refer to you, kindly requesting your opinion: In the current version of draft-ietf-csi-send-cert, 3 Key Purpose Id are defined: id-kp-sendRouter, id-kp-sendProxy and id-kp-sendOwner. The Key Purpose Id intended for proxy operation is id-kp-sendProxy. With the current wording, "The inclusion of the proxy authorization value (id-kp-sendProxy) indicates that the certificate has been issued for allowing the proxy to perform proxying of RA and Redirect messages for the prefix(es) that are mentioned in the X.509 extensions for IP addresses." it is not clear how a proxy requiring to proxy NA, NS and RS messages (in fact, the three application cases considered in draft-ietf-csi-proxy-send) would operate: a) Using id-kp-sendProxy for RA and Redirect, and id-kp-sendOwner for NA, NS, RS? My feeling is that id-kp-sendOwner should be reserved for hosts really owning the address, and not to be included in PS options. b) Modifying id-kp-sendProxy, extending the authorization to NA, NS and RS, so that id-kp-sendProxy authorizes ANY proxy operation However, another option, c) could be to have 2 Key Purpose Ids for proxy operation instead of one (therefore replacing id-kp-sendProxy), in which case the following text could be included in draft-ietf-csi-send-cert, section 7: "The inclusion of the proxied routing authorization value (id-kp-sendProxiedRouter) indicates that the certificate has been issued for allowing the proxy to perform proxying of RA and Redirect messages for the prefix(es) that are mentioned in the X.509 extensions for IP addresses. When a node's only certificate includes a prefix and only the id-kp-sendProxiedRouter authorization KeyPurposeId value, the node cannot perform proxying of NS, NA and RS messages. The inclusion of the proxied owner authorization value (id-kp-sendProxiedOwner) Indicates that the certificate has been issued for allowing the proxy to perform proxying of NS, NA and RS messages for any address in the prefix of such certificate. When a node's only certificate includes a prefix and only the id-kp-sendProxiedOwner authorization KeyPurposeId value, the node cannot advertise that prefix in an RA." The benefit of option c) is that proxy security is tailored to the proxy requirements, in the sense that different application scenarios may require one type of authorization, the other, or both. For example, MIPv6 would use a certificate with just id-kp-sendProxiedOwner, while PMIPv6 and RFC4389 would use a certificate with both id-kp-sendProxiedRouter and sendProxiedOwner. Compromising a MIPv6 HA would not allow an attacker to issue RA and Redirects. My personal opinion is that, to minimize security risks, authorization capabilities should not exceed the ones strictly required by the application scenario to be deployed, and two Key Purpose Ids for proxy operation provide appropriate granularity for this. (sorry if I fail to expose fairly the benefits of all options - feel free to comment, of course) For me, b) would acceptable, but I think c) should be better. What do you think? Regards, Alberto ------=_NextPart_000_0026_01CB4F6A.6B12C130 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

During IESG evaluation of = draft-ietf-csi-proxy-send-04, Sandra Murphy pointed out that “I believe that a discussion is = needed of what messages require or allow each particular key purpose = authorization”. draft-ietf-csi-send-cert-06 has been updated (in section 7) to provide = more detail regarding to this issue.

However, in the process of addressing this = comment, some authors of draft-ietf-csi-proxy-send and draft-ietf-csi-send-cert have = arrived to a controversial point, which I refer to you, kindly requesting your = opinion:

 

In the current version of draft-ietf-csi-send-cert, 3 =
Key Purpose Id are defined: =
id-kp-sendRouter, id-kp-sendProxy and id-kp-sendOwner. The =
Key Purpose =
Id intended =
for proxy operation is id-kp-sendProxy. With the current wording, =
=A0=A0=A0“The inclusion of the proxy =
authorization value =
(id-kp-sendProxy)
=A0=A0 indicates that the certificate has =
been issued for allowing the =
proxy
=A0=A0 to perform proxying of RA and Redirect =
messages for the prefix(es)
=A0=A0 that are mentioned in the X.509 =
extensions for IP =
addresses.”
 
it is not clear how a =
proxy requiring to proxy NA, NS and RS messages (in fact, the three =
application cases considered in draft-ietf-csi-proxy-send) would =
operate: 
a) Using id-kp-sendProxy =
for RA and Redirect, and id-kp-sendOwner for NA, NS, RS? My feeling is =
that id-kp-sendOwner should be reserved for hosts really owning the =
address, and not to be included in PS =
options.
b) Modifying =
id-kp-sendProxy, extending the authorization to NA, NS and RS, so that =
id-kp-sendProxy authorizes ANY proxy =
operation
 
However, another option, =
c) could be to have 2 Key =
Purpose Ids for proxy operation instead of one (therefore replacing =
id-kp-sendProxy), in which case the following text could be included in =
draft-ietf-csi-send-cert, section =
7:
 

“The inclusion of the proxied routing authorization value = (id-kp-sendProxiedRouter)

indicates that the certificate has been issued for allowing the = proxy

to = perform proxying of RA and Redirect messages for the = prefix(es)

that = are mentioned in the X.509 extensions for IP addresses. When = a

node's = only certificate includes a prefix and only the

id-kp-sendProxiedRouter authorization KeyPurposeId value, the node = cannot

perform proxying of NS, NA and RS messages.

 

The = inclusion of the proxied owner authorization value = (id-kp-sendProxiedOwner)

Indicates that the certificate has been issued for allowing the proxy = to

perform proxying of NS, NA and RS messages for any address in the prefix = of

such = certificate. When a node's only certificate includes a prefix and = only

the id-kp-sendProxiedOwner authorization KeyPurposeId value, the = node

cannot = advertise that prefix in an RA."

 
The benefit of option c) =
is that proxy security is tailored to the proxy requirements, in the =
sense that different application scenarios may require one type of =
authorization, the other, or both. For example, MIPv6 would use a =
certificate with just id-kp-sendProxiedOwner, while PMIPv6 and RFC4389 =
would use a certificate with both id-kp-sendProxiedRouter and =
sendProxiedOwner. Compromising a MIPv6 HA would not allow an attacker to =
issue RA and Redirects. My personal opinion is that, to minimize =
security risks, authorization capabilities should not exceed the ones =
strictly required by the application scenario to be deployed, and two =
Key Purpose Ids for proxy operation provide appropriate granularity for =
this.
 
(sorry if I fail to expose =
fairly the benefits of all options – feel free to comment, of =
course)
 
For me, b) would =
acceptable, but I think c) should be =
better.
What do you =
think?
 
Regards,<=
/font>
Alberto

=A0

------=_NextPart_000_0026_01CB4F6A.6B12C130-- From Ted.Lemon@nominum.com Tue Sep 14 14:20:57 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98873A6AA9; Tue, 14 Sep 2010 14:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 6I37pM5oUqCT; Tue, 14 Sep 2010 14:20:56 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 720073A696C; Tue, 14 Sep 2010 14:20:53 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTI/nRyhWI7ukBLXt7uJ2i3G4dUBQPrPo@postini.com; Tue, 14 Sep 2010 14:21:22 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B9C781B8284; Tue, 14 Sep 2010 14:21:11 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 14 Sep 2010 14:21:11 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> Date: Tue, 14 Sep 2010 17:21:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <57452427-8824-4736-A8EF-022B3157935A@nominum.com> References: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> To: "dhcwg@ietf.org Group" X-Mailer: Apple Mail (2.1081) Cc: cga-ext@ietf.org, Ralph, Droms Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:20:58 -0000 We've talked about the topics in this draft before at the DHC working = group. I just reread it, and the only thing I object to about it is = the thing I've always objected to about it when it's come up in DHC = meetings--the idea of offloading CGA generation work to the DHCP server. This idea doesn't make sense to me from a security perspective--based on = my probably naive understanding of CGA, it seems like this would mean = that the private key would have to be sent over the wire in the clear. I'd be happy to see this draft advance if the text about generating keys = on the DHCP server were taken out. From tony.cheneau@it-sudparis.eu Tue Sep 14 15:08:28 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585CE3A69A1; Tue, 14 Sep 2010 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 NWl+C2wcvOia; Tue, 14 Sep 2010 15:08:27 -0700 (PDT) Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 494A43A677C; Tue, 14 Sep 2010 15:08:27 -0700 (PDT) Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 3B01EFE0B50; Wed, 15 Sep 2010 00:08:52 +0200 (CEST) Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 813F440505B; Wed, 15 Sep 2010 00:05:13 +0200 (CEST) Received: from localhost (alf94-6-82-226-232-167.fbx.proxad.net [82.226.232.167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 18BD42C18A89; Wed, 15 Sep 2010 00:08:43 +0200 (CEST) Date: Wed, 15 Sep 2010 00:08:42 +0200 From: Tony Cheneau To: Ted Lemon Message-ID: <20100915000842.667d28ae@it-sudparis.eu> In-Reply-To: <57452427-8824-4736-A8EF-022B3157935A@nominum.com> References: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> <57452427-8824-4736-A8EF-022B3157935A@nominum.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner-ID: 813F440505B.A731E X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=2.319, requis 6.01, BAYES_00 -2.60, HELO_LOCALHOST 3.94, RCVD_IN_SORBS_DUL 0.88, RDNS_DYNAMIC 0.10) X-INT-MailScanner-SpamScore: ss X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu Cc: "dhcwg@ietf.org Group" , cga-ext@ietf.org, Droms , Ralph@core3.amsl.com Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 22:08:28 -0000 Hello Ted, > This idea doesn't make sense to me from a security perspective--based > on my probably naive understanding of CGA, it seems like this would > mean that the private key would have to be sent over the wire in the > clear. I apology for not speaking for this draft directly (I only read the draft a long time ago). However, for a CGA to be computed (remotely or locally), you only need few public parameters (subnet prefix, public key and such). Actually, the CGA document (RFC 3972) makes no use of the private key during the CGA generation and verification process. This is why you usually need SEND (or a similar mechanism) to achieve the proof of ownership (through a signature realized by the private key). So, as long as the public/private key are generated on the node, I would say that you will not need to communicate the private key (in clear or in a ciphered form). Hope it helps. Regards, Tony From Ted.Lemon@nominum.com Tue Sep 14 16:06:30 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66DA3A6A22; Tue, 14 Sep 2010 16:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 oQp3WVm8Rl7S; Tue, 14 Sep 2010 16:06:29 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 4EBA03A67FF; Tue, 14 Sep 2010 16:06:28 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTJAADE4hnIKUsx2AIT/o2HaOXqmyq5bI@postini.com; Tue, 14 Sep 2010 16:06:55 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 393661B829C; Tue, 14 Sep 2010 16:06:52 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 14 Sep 2010 16:06:51 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: <20100915000842.667d28ae@it-sudparis.eu> Date: Tue, 14 Sep 2010 19:06:46 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> <57452427-8824-4736-A8EF-022B3157935A@nominum.com> <20100915000842.667d28ae@it-sudparis.eu> To: Tony Cheneau X-Mailer: Apple Mail (2.1081) Cc: "dhcwg@ietf.org Group" , "cga-ext@ietf.org" , Droms , "Ralph@core3.amsl.com" Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 23:06:30 -0000 On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote: > So, as long as the public/private key are generated on the node, I > would say that you will not need to communicate the private key (in > clear or in a ciphered form). Actually, this is clear as mud to me. What is the big compute job = that's being done on the server, then? Can you point me to the RFC I = should be reading that explains all this? Sorry to be obtuse. :'} From shengjiang@huawei.com Tue Sep 14 18:47:00 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6517D3A6846; Tue, 14 Sep 2010 18:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 wm3JsMTAjL63; Tue, 14 Sep 2010 18:46:59 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 17B793A6838; Tue, 14 Sep 2010 18:46:59 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8R008W6MAQGK@szxga01-in.huawei.com>; Wed, 15 Sep 2010 09:47:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8R00DNXMAQ0S@szxga01-in.huawei.com>; Wed, 15 Sep 2010 09:47:14 +0800 (CST) Received: from j66104a ([10.110.98.171]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8R0090OMAPR3@szxml06-in.huawei.com>; Wed, 15 Sep 2010 09:47:14 +0800 (CST) Date: Wed, 15 Sep 2010 09:47:13 +0800 From: Sheng Jiang In-reply-to: To: 'Ted Lemon' , 'Tony Cheneau' Message-id: <003201cb5477$eba4d240$ab626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActUYZKz2XVmP9e3Qwij1kNQqR6WUAAEpgQg Cc: dhcwg@ietf.org, cga-ext@ietf.org, 'Droms' , Ralph@core3.amsl.com Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review ofdraft-ietf-csi-dhcpv6-cga-ps X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 01:47:00 -0000 Hi, Ted, There are actually two very different concerns you have. I reply below. Before that, I would like to state: as an informational document, draft-ietf-csi-dhcpv6-cga-ps aims to analyze the all possible interactions between cga and dhcpv6. Whether these possibilities are going to be defined as actual solutions in the future, it is another matter. In this draft, all we say is there are such possibilities, their benefits and issues (if you want, we can put more analysis regarding to potential issues of this possibility). You may notice in this 04 version, we have removed "Solution Requests" charpter, which was in previous version. We are not defining solutions, even not requesting to define such solutions. Your first concern is the security of this delegation operation. In all cases, the private key is not transported through the network. The private key is only kept and used by its owner. This does not say the delegation operation is security. Actually, other parameters and cga generation result also need protection. The existing security mechanism of DHCPv6 may be used. We can add more clarification into the draft. Your second concern is the big compute job may overload the server. True. Actaully, in this draft, we state "The DHCPv6 server could then either compute the Modifier by itself, or redirect the computation requirement to another server." The second server may be dedicated computational server. Again, this draft only lists the possibilities. If you want, we can add more analysis on the issues of this possibility. Regards, Sheng > -----Original Message----- > From: cga-ext-bounces@ietf.org > [mailto:cga-ext-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Wednesday, September 15, 2010 7:07 AM > To: Tony Cheneau > Cc: dhcwg@ietf.org Group; cga-ext@ietf.org; Droms; > Ralph@core3.amsl.com > Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review > ofdraft-ietf-csi-dhcpv6-cga-ps > > On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote: > > So, as long as the public/private key are generated on the node, I > > would say that you will not need to communicate the private key (in > > clear or in a ciphered form). > > Actually, this is clear as mud to me. What is the big > compute job that's being done on the server, then? Can you > point me to the RFC I should be reading that explains all > this? Sorry to be obtuse. :'} > > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext From julienl@qualcomm.com Wed Sep 15 08:55:45 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98613A698E; Wed, 15 Sep 2010 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Wru1N1DDHt+K; Wed, 15 Sep 2010 08:55:38 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2FCF73A69BB; Wed, 15 Sep 2010 08:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1284566162; x=1316102162; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Ted=20Lemon=20,=20Tony=20Ch eneau=0D=0A=09|CC:=20"dhcwg@ ietf.org=20Group"=20,=20"cga-ext@ietf.org "=0D=0A=09,=20Droms=20,=20"Ralph@core3.amsl.com"=0D=0A=09|Date:=20Wed,=2015=20Sep=202010=2008:56:01=20-0700 |Subject:=20RE:=20[CGA-EXT]=20[dhcwg]=20Follow=20up=20req uest=20for=20review=20of=0D=0A=09draft-ietf-csi-dhcpv6-cg a-ps|Thread-Topic:=20[CGA-EXT]=20[dhcwg]=20Follow=20up=20 request=20for=20review=20of=0D=0A=09draft-ietf-csi-dhcpv6 -cga-ps|Thread-Index:=20ActUYZcyQDNVkOOgToS0CVAZg2RW5gAi0 TNg|Message-ID:=20|References:=20<21C043C9 -FE72-44F4-97A9-4684384F013D@gmail.com>=0D=0A=09<57452427 -8824-4736-A8EF-022B3157935A@nominum.com>=0D=0A=09<201009 15000842.667d28ae@it-sudparis.eu>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=/PkszJa7Kfk67YLRjYNqZSWY5ao5hA6t4CJr/d0Uito=; b=S35dKR8yIX1WH+NeCepkk2OakaTX6q2x6277TCzAfo4SLk1zHa86a+pK F/MYJ0pFda7e+oni1HMsIYS7i2BhiAvhaireT7m8xjIed0oJM1QqHTYcs HOs0Z6MOs0st4oAencRKtkUlpLikES6Ss441B+3sOI/5TIS1621udtwvO U=; X-IronPort-AV: E=McAfee;i="5400,1158,6106"; a="54437869" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 15 Sep 2010 08:56:01 -0700 X-IronPort-AV: E=Sophos;i="4.56,371,1280732400"; d="scan'208";a="85721083" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 15 Sep 2010 08:56:01 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 15 Sep 2010 08:56:01 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Wed, 15 Sep 2010 08:56:01 -0700 From: "Laganier, Julien" To: Ted Lemon , Tony Cheneau Date: Wed, 15 Sep 2010 08:56:01 -0700 Thread-Topic: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps Thread-Index: ActUYZcyQDNVkOOgToS0CVAZg2RW5gAi0TNg Message-ID: References: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> <57452427-8824-4736-A8EF-022B3157935A@nominum.com> <20100915000842.667d28ae@it-sudparis.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org Group" , "cga-ext@ietf.org" , Droms , "Ralph@core3.amsl.com" Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:55:45 -0000 Ted, Some clarifications: Ted Lemon wrote: > Sent: Tuesday, September 14, 2010 4:07 PM > To: Tony Cheneau > Cc: dhcwg@ietf.org Group; cga-ext@ietf.org; Droms; Ralph@core3.amsl.com > Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft- > ietf-csi-dhcpv6-cga-ps >=20 > On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote: > > So, as long as the public/private key are generated on the node, I > > would say that you will not need to communicate the private key (in > > clear or in a ciphered form). >=20 > Actually, this is clear as mud to me. What is the big compute job > that's being done on the server, then? Can you point me to the RFC I > should be reading that explains all this? Sorry to be obtuse. :'} If you have a look at the CGA generation algorithm described in RFC 3972 yo= u will see that there are potentially two distinct computationally intensiv= e tasks: 1. generation of public-private (RSA) key pair 2. generation of a CGA modifier value for a given Security Parameter (Sec) = as per RFC 3972. (The Sec is used to harden the resistance of brute force a= ttacks on the 64-bits IIDs of CGAs.) #2 above might become computationally intensive for values of the Sec highe= r than zero (if it's zero any Modifier satisfies 3972). Back in 2002 I reme= mber running the algorithm on then standard personal computers (e.g., x86 /= ~1GhZ) and it would took ~20 seconds for Sec =3D 1 and a couple of minutes= for Sec =3D 2. I do not remember going higher... I understand the proposal is to offload #2 to the server while #1 would not= be.=20 IMHO it does not any make sense to offload when Sec is set to 0 because the= computational load is nil.=20 When Sec is set to 1 the computational load of #2 seems to be in the same o= rder of magnitude as for #1, which does not necessarily means that offloadi= ng is useless as #1 might not need to be done by the constrained device its= elf (e.g., it's been offload to someone else, and result is stored on a sma= rtcard.) That being set I have not been convinced yet that there's a real world use = case for Sec values higher than zero. HTH, --julien From Ted.Lemon@nominum.com Wed Sep 15 16:39:53 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3633A6999; Wed, 15 Sep 2010 16:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 j5mPMTGLmsXQ; Wed, 15 Sep 2010 16:39:51 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 18D663A6AAB; Wed, 15 Sep 2010 16:39:38 -0700 (PDT) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTJFZT4R8rJvss+quTXSPG9fvv8pbHgth@postini.com; Wed, 15 Sep 2010 16:40:07 PDT Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7079C1B82A2; Wed, 15 Sep 2010 16:39:59 -0700 (PDT) Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 15 Sep 2010 16:39:58 -0700 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Wed, 15 Sep 2010 19:39:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <31F050D1-8294-442F-B5B5-305772690BD3@nominum.com> References: <21C043C9-FE72-44F4-97A9-4684384F013D@gmail.com> <57452427-8824-4736-A8EF-022B3157935A@nominum.com> <20100915000842.667d28ae@it-sudparis.eu> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1081) Cc: "dhcwg@ietf.org Group" , cga-ext@ietf.org, Ralph Droms Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 23:39:53 -0000 On Sep 15, 2010, at 11:56 AM, Laganier, Julien wrote: > When Sec is set to 1 the computational load of #2 seems to be in the = same order of magnitude as for #1, which does not necessarily means that = offloading is useless as #1 might not need to be done by the constrained = device itself (e.g., it's been offload to someone else, and result is = stored on a smartcard.) >=20 > That being set I have not been convinced yet that there's a real world = use case for Sec values higher than zero. >=20 > HTH, This does help, thanks. I continue to think that the DHCP server is = not a good place to offload the work, but I see the logic in wanting to = do it, anyway, so I withdraw my objection. From rogaglia@cisco.com Thu Sep 16 02:15:34 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5293A6ACE for ; Thu, 16 Sep 2010 02:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=-3.919, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 ECjH-krMwZUs for ; Thu, 16 Sep 2010 02:15:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3A1283A6AF9 for ; Thu, 16 Sep 2010 02:15:28 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHt8kUyQ/khL/2dsb2JhbAChd3GlAJxDhUEEiiw X-IronPort-AV: E=Sophos;i="4.56,375,1280707200"; d="p7s'?scan'208";a="9544855" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 16 Sep 2010 09:15:51 +0000 Received: from dhcp-10-61-98-112.cisco.com (dhcp-10-61-98-112.cisco.com [10.61.98.112]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o8G9Fpuo000748; Thu, 16 Sep 2010 09:15:51 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-194--768810683; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> Date: Thu, 16 Sep 2010 11:15:50 +0200 Message-Id: <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> References: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1081) Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 09:15:34 -0000 --Apple-Mail-194--768810683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alberto, Please see inline. =20 > In the current version of draft-ietf-csi-send-cert, 3 Key Purpose Id = are defined: id-kp-sendRouter, id-kp-sendProxy and id-kp-sendOwner. The = Key Purpose Id intended for proxy operation is id-kp-sendProxy. With the = current wording,=20 > =93The inclusion of the proxy authorization value (id-kp-sendProxy) > indicates that the certificate has been issued for allowing the = proxy > to perform proxying of RA and Redirect messages for the prefix(es) > that are mentioned in the X.509 extensions for IP addresses.=94 > =20 > it is not clear how a proxy requiring to proxy NA, NS and RS messages = (in fact, the three application cases considered in = draft-ietf-csi-proxy-send) would operate:=20 Actually, the text you are referring is already a modified version of = the original text that got WGLC. That text represented your option b). > a) Using id-kp-sendProxy for RA and Redirect, and id-kp-sendOwner for = NA, NS, RS? My feeling is that id-kp-sendOwner should be reserved for = hosts really owning the address, and not to be included in PS options. > b) Modifying id-kp-sendProxy, extending the authorization to NA, NS = and RS, so that id-kp-sendProxy authorizes ANY proxy operation > =20 > However, another option,=20 > c) could be to have 2 Key Purpose Ids for proxy operation instead of = one (therefore replacing id-kp-sendProxy), in which case the following = text could be included in draft-ietf-csi-send-cert, section 7: I take option c). When I first thought about this, I remembered the old times of modem = access and Proxy-ARP in routers. I see now a use-case for = "id-kp-sendProxiedOwner" even without considering MIP6. I agree that we should go this path, it will make a better set of = documents. However, I believe that if we go this path, we need also to = make sure that there is a synchronization between this document and the = proxy document to reflect the correct sender/receiver behavior. Finally, I would like to clarify the validation behavior when listen = several EKUs in a certificate. At this time, the document states that = the existence of a particular EKU is a sufficient condition. This means = that if a certificate has a id-kp-sendProxiedRouter and a = id-kp-sendRouter EKU and I am validating a RA with or without the proxy = option, it will validate in either cases using the same key. I believe = this should be the correct behavior as it should be the operator to = decide how it want to configure its network. Regards, Roque > =20 > =93The inclusion of the proxied routing authorization value = (id-kp-sendProxiedRouter) > indicates that the certificate has been issued for allowing the proxy > to perform proxying of RA and Redirect messages for the prefix(es) > that are mentioned in the X.509 extensions for IP addresses. When a > node's only certificate includes a prefix and only the > id-kp-sendProxiedRouter authorization KeyPurposeId value, the node = cannot > perform proxying of NS, NA and RS messages. > =20 > The inclusion of the proxied owner authorization value = (id-kp-sendProxiedOwner) > Indicates that the certificate has been issued for allowing the proxy = to > perform proxying of NS, NA and RS messages for any address in the = prefix of > such certificate. When a node's only certificate includes a prefix and = only > the id-kp-sendProxiedOwner authorization KeyPurposeId value, the node > cannot advertise that prefix in an RA." > =20 > The benefit of option c) is that proxy security is tailored to the = proxy requirements, in the sense that different application scenarios = may require one type of authorization, the other, or both. For example, = MIPv6 would use a certificate with just id-kp-sendProxiedOwner, while = PMIPv6 and RFC4389 would use a certificate with both = id-kp-sendProxiedRouter and sendProxiedOwner. Compromising a MIPv6 HA = would not allow an attacker to issue RA and Redirects. My personal = opinion is that, to minimize security risks, authorization capabilities = should not exceed the ones strictly required by the application scenario = to be deployed, and two Key Purpose Ids for proxy operation provide = appropriate granularity for this. > =20 > (sorry if I fail to expose fairly the benefits of all options =96 feel = free to comment, of course) > =20 > For me, b) would acceptable, but I think c) should be better. > What do you think? > =20 > Regards, > Alberto > =20 > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext --Apple-Mail-194--768810683 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkxNjA5 MTU1MVowIwYJKoZIhvcNAQkEMRYEFHqmXWMG1eBMVAtu90El2E97ShKxMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAHB3vgtQE+lSguXIXAQRmpbe0V9GXe99s9seSwURao8CsZo5BCxK lS3nmXypejJ8iXpu2hkYGXstchpyZqfuU9U+GKZKe8Rh3BekwdCPSicA7m+LqKhiH54VhMcGb/LY iWcQRvpSuJ+2w9xW1yxe3stHxi6s/Rb3LRYYO9Ddqat/qfBuDzOJV61iAgV4ZJxrwIMrt9BW6G4r grbTHfn0ZH7xjpXU0O2MJBsbN9JjOaSityy/c/4GvKHOm5Ul4SZFvQH08V1dJa6IK3TJ0Ba4pxl7 FEInWlPjO6B8Avs/kxF+IzwlKdCDgIk51jviwyv+ziuVQmOhWS1Tn2I6odh/JYEAAAAAAAA= --Apple-Mail-194--768810683-- From alberto@it.uc3m.es Fri Sep 17 05:55:49 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D94E3A68B6 for ; Fri, 17 Sep 2010 05:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.62 X-Spam-Level: X-Spam-Status: No, score=-5.62 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 SjY6lI7qLlM0 for ; Fri, 17 Sep 2010 05:55:47 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2D5833A688C for ; Fri, 17 Sep 2010 05:55:46 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 0C715BF0BC3; Fri, 17 Sep 2010 14:56:08 +0200 (CEST) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Roque Gagliano'" References: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> Date: Fri, 17 Sep 2010 14:56:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> Thread-Index: ActVf8JY3AAj9T6ZRzqak2GIu20G1gA5EMWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17646.005 Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 12:55:49 -0000 Hi Roque, | -----Mensaje original----- | De: Roque Gagliano [mailto:rogaglia@cisco.com] | Enviado el: jueves, 16 de septiembre de 2010 11:16 | Para: Alberto Garc=EDa | CC: cga-ext@ietf.org | Asunto: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send | [...] | > c) could be to have 2 Key Purpose Ids for proxy operation instead = of one | (therefore replacing id-kp-sendProxy), in which case the following = text could be | included in draft-ietf-csi-send-cert, section 7: | =20 | I take option c). | =20 | When I first thought about this, I remembered the old times of modem access | and Proxy-ARP in routers. I see now a use-case for "id-kp-sendProxiedOwner" | even without considering MIP6. | =20 | I agree that we should go this path, it will make a better set of documents. | However, I believe that if we go this path, we need also to make sure that there | is a synchronization between this document and the proxy document to reflect | the correct sender/receiver behavior. Fine. Then, the main changes in draft-ietf-csi-proxy-send would be: CHANGE #1 -------------- "5.2.1. Processing rules for senders A Secure ND Proxy MUST NOT use a key to sign NDP message types which do not correspond to the authorization granted to the considered key. NA, NS and RS messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeID value [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source addresses of the messages MUST belong to the prefix associated to the certificate. RA and Redirect messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeID value of id-kp-sendProxiedRouter. The prefix included in the RA message for on-link determination and/or stateless address autoconfiguration, and the Target Address of the Redirect message, MUST be equal or be included into the prefix associated to that certificate. [...]" CHANGE #2 -------------- Rule #2 in "5.2.2. Processing rules for receivers" "2. The Key Hash field MUST indicate the use of a known public key. A valid certification path (see [RFC3971] Section 6.3) between the receiver's trust anchor and the sender's public key MUST be known. The Secure Proxy ND's X509v3 certificate MUST contain an extended key usage extension including the appropriate KeyPurposeId value and prefix for the message to validate: * For RA messages, a KeyPurposeId value of id-kp- sendProxiedRouter MUST exist for the certificate, and the prefix included in the RA message for on-link determination and/or stateless address autoconfiguration MUST be equal or be included into the prefix associated to that certificate. * For Redirect messages, a KeyPurposeId value of id-kp- sendProxiedRouter MUST exist for the certificate, and the prefix included in the Target Address of the Redirect message MUST belong to the prefix associated to that certificate. * For NA, NS and RS messages, a KeyPurposeId value of id-kp- sendProxiedOwner MUST exist for the certificate, and the source addresses of the messages MUST belong to the prefix associated to the certificate. If any of these tests fails, the verification fails." CHANGE #3 -------------- Modification of the application scenarios to detail how the certificates = are configured. For example, for PMIPv6: " To provide SEND protection, each MAG is configured to act as a proxy by means of a certificate associated to the PMIPv6 domain, authorizing each MAG to proxy securely NA and RS messages by means of a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the certificate must also authorize the MAG to advertise prefixes, by associating to the same certificate a KeyPurposeId value of id-kp- sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId values is supported by [I-D.ietf-csi-send-cert]." CHANGE #4 -------------- And finally, in the following paragraph would be included in the = security considerations section: " A compromised Secure ND Proxy provisioned with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is able, like a compromised router to siphon off traffic from the host, or mount a man-in-the-middle attack, for hosts communicating to off- link hosts. However, a Secure ND Proxy with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedOwner can also siphon off traffic or mount a man-in-the-middle attack for communication between on-link hosts, even if the hosts use SEND. Note that different application scenarios may require one type of authorization, the other, or both. To minimize security risks, authorization capabilities SHOULD NOT exceed the ones strictly required by the application scenario to be deployed." Do you think the new text is reasonable? | =20 | Finally, I would like to clarify the validation behavior when listen several EKUs in | a certificate. At this time, the document states that the existence = of a particular | EKU is a sufficient condition. This means that if a certificate has a id-kp- | sendProxiedRouter and a id-kp-sendRouter EKU and I am validating a RA with or | without the proxy option, it will validate in either cases using the = same key. I | believe this should be the correct behavior as it should be the = operator to decide | how it want to configure its network. I agree that a certificate could hold both id-kp-sendProxiedRouter and id-kp-sendRouter EKUs and validate RA or Redirect/RA proxying with the = same key.=20 I think the text provided above allows this behavior.=20 Thanks and regards, Alberto | =20 | =20 | =20 | Regards, | =20 | Roque | =20 | =20 | > | > "The inclusion of the proxied routing authorization value (id-kp- | sendProxiedRouter) | > indicates that the certificate has been issued for allowing the = proxy | > to perform proxying of RA and Redirect messages for the prefix(es) | > that are mentioned in the X.509 extensions for IP addresses. When a | > node's only certificate includes a prefix and only the | > id-kp-sendProxiedRouter authorization KeyPurposeId value, the node cannot | > perform proxying of NS, NA and RS messages. | > | > The inclusion of the proxied owner authorization value (id-kp- | sendProxiedOwner) | > Indicates that the certificate has been issued for allowing the = proxy to | > perform proxying of NS, NA and RS messages for any address in the prefix of | > such certificate. When a node's only certificate includes a prefix = and only | > the id-kp-sendProxiedOwner authorization KeyPurposeId value, the = node | > cannot advertise that prefix in an RA." | > | > The benefit of option c) is that proxy security is tailored to the proxy | requirements, in the sense that different application scenarios may require one | type of authorization, the other, or both. For example, MIPv6 would = use a | certificate with just id-kp-sendProxiedOwner, while PMIPv6 and = RFC4389 would | use a certificate with both id-kp-sendProxiedRouter and = sendProxiedOwner. | Compromising a MIPv6 HA would not allow an attacker to issue RA and Redirects. | My personal opinion is that, to minimize security risks, = authorization capabilities | should not exceed the ones strictly required by the application = scenario to be | deployed, and two Key Purpose Ids for proxy operation provide = appropriate | granularity for this. | > | > (sorry if I fail to expose fairly the benefits of all options - = feel free to comment, | of course) | > | > For me, b) would acceptable, but I think c) should be better. | > What do you think? | > | > Regards, | > Alberto | > | > _______________________________________________ | > CGA-EXT mailing list | > CGA-EXT@ietf.org | > https://www.ietf.org/mailman/listinfo/cga-ext From rogaglia@cisco.com Thu Sep 23 08:52:37 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660493A698F for ; Thu, 23 Sep 2010 08:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.961 X-Spam-Level: X-Spam-Status: No, score=-9.961 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 BWwKjdR-sov8 for ; Thu, 23 Sep 2010 08:52:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B5D993A67A3 for ; Thu, 23 Sep 2010 08:52:33 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8Um0yQ/khM/2dsb2JhbACiMnGqLJw4AoU/BIo4gn4 X-IronPort-AV: E=Sophos;i="4.57,224,1283731200"; d="p7s'?scan'208,217";a="65050864" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 23 Sep 2010 15:53:02 +0000 Received: from [144.254.21.40] ([144.254.21.40]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o8NFr2bb007679; Thu, 23 Sep 2010 15:53:02 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-404--140169086; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Thu, 23 Sep 2010 17:53:12 +0200 Message-Id: References: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1081) Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 15:52:37 -0000 --Apple-Mail-404--140169086 Content-Type: multipart/alternative; boundary=Apple-Mail-403--140169171 --Apple-Mail-403--140169171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alberto, see inline comments. I will then modify the text in the document and submit the changes. I = will also write to PKIX asking for the new EKU. Regards, Roque = --------------------------------------------------------------------------= -------------------------------------------------------------------- Roque Gagliano = Cisco Systems International S=E0rl=09 Software Engineer = Mailstop ROL01/2/ Corporate Development Technology Group = Avenue des Uttins 5 = 1180 Rolle rogaglia@cisco.com = Switzerland Phone: +41 21 823 2805 = =09 For corporate legal information go to: = http://www.cisco.com/web/about/doing_business/legal/cri/index.html On Sep 17, 2010, at 2:56 PM, Alberto Garc=EDa wrote: > Hi Roque, >=20 > | -----Mensaje original----- > | De: Roque Gagliano [mailto:rogaglia@cisco.com] > | Enviado el: jueves, 16 de septiembre de 2010 11:16 > | Para: Alberto Garc=EDa > | CC: cga-ext@ietf.org > | Asunto: Re: [CGA-EXT] Key Purpose Id specification and > draft-ietf-csi-proxy-send > | >=20 > [...] >=20 > | > c) could be to have 2 Key Purpose Ids for proxy operation instead = of > one > | (therefore replacing id-kp-sendProxy), in which case the following = text > could be > | included in draft-ietf-csi-send-cert, section 7: > | =20 > | I take option c). > | =20 > | When I first thought about this, I remembered the old times of = modem > access > | and Proxy-ARP in routers. I see now a use-case for > "id-kp-sendProxiedOwner" > | even without considering MIP6. > | =20 > | I agree that we should go this path, it will make a better set of > documents. > | However, I believe that if we go this path, we need also to make = sure > that there > | is a synchronization between this document and the proxy document = to > reflect > | the correct sender/receiver behavior. >=20 > Fine. Then, the main changes in draft-ietf-csi-proxy-send would be: >=20 > CHANGE #1 > -------------- > "5.2.1. Processing rules for senders >=20 > A Secure ND Proxy MUST NOT use a key to sign NDP message types which > do not correspond to the authorization granted to the considered = key. > NA, NS and RS messages MUST be signed with a key corresponding to a > Secure Proxy ND certificate with a KeyPurposeID value > [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source > addresses of the messages MUST belong to the prefix associated to = the > certificate. RA and Redirect messages MUST be signed with a key > corresponding to a Secure Proxy ND certificate with a KeyPurposeID > value of id-kp-sendProxiedRouter. The prefix included in the RA > message for on-link determination and/or stateless address > autoconfiguration, and the Target Address of the Redirect message, > MUST be equal or be included into the prefix associated to that > certificate. > [...]" >=20 (Roque) Why not use the terminology of draft-ietf-sidr-res-certs-18 = instead of "equal or included"? I believe the correct term is = "encompass".=20 > CHANGE #2 > -------------- > Rule #2 in "5.2.2. Processing rules for receivers" > "2. The Key Hash field MUST indicate the use of a known public key. > A valid certification path (see [RFC3971] Section 6.3) between > the receiver's trust anchor and the sender's public key MUST be > known. =20 (Roque) I would mention rather than RFC3971, the = draft-ietf-csi-send-cert-06 section 9. I would also use the word = "valid", which means that the validation process has been successful. > The Secure Proxy ND's X509v3 certificate MUST contain an > extended key usage extension including the appropriate > KeyPurposeId value and prefix for the message to validate: >=20 > * For RA messages, a KeyPurposeId value of id-kp- > sendProxiedRouter MUST exist for the certificate, and the > prefix included in the RA message for on-link determination > and/or stateless address autoconfiguration MUST be equal or = be > included into the prefix associated to that certificate. (Roque) again the term should be "encompass". > * For Redirect messages, a KeyPurposeId value of id-kp- > sendProxiedRouter MUST exist for the certificate, and the > prefix included in the Target Address of the Redirect message > MUST belong to the prefix associated to that certificate. (Roque) again the term should be "encompass". > * For NA, NS and RS messages, a KeyPurposeId value of id-kp- > sendProxiedOwner MUST exist for the certificate, and the > source addresses of the messages MUST belong to the prefix > associated to the certificate. (Roque) again the term should be "encompass". > If any of these tests fails, the verification fails." >=20 > CHANGE #3 > -------------- > Modification of the application scenarios to detail how the = certificates are > configured. For example, for PMIPv6: >=20 > " To provide SEND protection, each MAG is configured to act as a = proxy > by means of a certificate associated to the PMIPv6 domain, > authorizing each MAG to proxy securely NA and RS messages by means = of > a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the > certificate must also authorize the MAG to advertise prefixes, by > associating to the same certificate a KeyPurposeId value of id-kp- > sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId > values is supported by [I-D.ietf-csi-send-cert]." >=20 > CHANGE #4 > -------------- > And finally, in the following paragraph would be included in the = security > considerations section: >=20 > " A compromised Secure ND Proxy provisioned with an authorization > certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is > able, like a compromised router to siphon off traffic from the host, > or mount a man-in-the-middle attack, for hosts communicating to off- > link hosts. However, a Secure ND Proxy with an authorization > certificate with a KeyPurposeId value of id-kp-sendProxiedOwner can > also siphon off traffic or mount a man-in-the-middle attack for > communication between on-link hosts, even if the hosts use SEND. > Note that different application scenarios may require one type of > authorization, the other, or both. To minimize security risks, > authorization capabilities SHOULD NOT exceed the ones strictly > required by the application scenario to be deployed." >=20 >=20 > Do you think the new text is reasonable? Sounds good. Roque >=20 > | =20 > | Finally, I would like to clarify the validation behavior when = listen > several EKUs in > | a certificate. At this time, the document states that the existence = of a > particular > | EKU is a sufficient condition. This means that if a certificate has = a > id-kp- > | sendProxiedRouter and a id-kp-sendRouter EKU and I am validating a = RA > with or > | without the proxy option, it will validate in either cases using = the same > key. I > | believe this should be the correct behavior as it should be the = operator > to decide > | how it want to configure its network. >=20 > I agree that a certificate could hold both id-kp-sendProxiedRouter and > id-kp-sendRouter EKUs and validate RA or Redirect/RA proxying with the = same > key.=20 >=20 > I think the text provided above allows this behavior.=20 >=20 > Thanks and regards, > Alberto >=20 > | =20 > | =20 > | =20 > | Regards, > | =20 > | Roque > | =20 > | =20 > | > > | > "The inclusion of the proxied routing authorization value (id-kp- > | sendProxiedRouter) > | > indicates that the certificate has been issued for allowing the = proxy > | > to perform proxying of RA and Redirect messages for the = prefix(es) > | > that are mentioned in the X.509 extensions for IP addresses. When = a > | > node's only certificate includes a prefix and only the > | > id-kp-sendProxiedRouter authorization KeyPurposeId value, the = node > cannot > | > perform proxying of NS, NA and RS messages. > | > > | > The inclusion of the proxied owner authorization value (id-kp- > | sendProxiedOwner) > | > Indicates that the certificate has been issued for allowing the = proxy > to > | > perform proxying of NS, NA and RS messages for any address in the > prefix of > | > such certificate. When a node's only certificate includes a = prefix and > only > | > the id-kp-sendProxiedOwner authorization KeyPurposeId value, the = node > | > cannot advertise that prefix in an RA." > | > > | > The benefit of option c) is that proxy security is tailored to = the > proxy > | requirements, in the sense that different application scenarios may > require one > | type of authorization, the other, or both. For example, MIPv6 would = use a > | certificate with just id-kp-sendProxiedOwner, while PMIPv6 and = RFC4389 > would > | use a certificate with both id-kp-sendProxiedRouter and = sendProxiedOwner. > | Compromising a MIPv6 HA would not allow an attacker to issue RA and > Redirects. > | My personal opinion is that, to minimize security risks, = authorization > capabilities > | should not exceed the ones strictly required by the application = scenario > to be > | deployed, and two Key Purpose Ids for proxy operation provide = appropriate > | granularity for this. > | > > | > (sorry if I fail to expose fairly the benefits of all options - = feel > free to comment, > | of course) > | > > | > For me, b) would acceptable, but I think c) should be better. > | > What do you think? > | > > | > Regards, > | > Alberto > | > > | > _______________________________________________ > | > CGA-EXT mailing list > | > CGA-EXT@ietf.org > | > https://www.ietf.org/mailman/listinfo/cga-ext >=20 >=20 --Apple-Mail-403--140169171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 see inline = comments.
I will then = modify the text in the document and submit the changes. I will also = write to PKIX asking for the new EKU.
   =                     =          = Cisco Systems International S=E0rl
Software Engineer = Mailstop = ROL01/2/
Corporate Development  Technology Group = Avenue des Uttins 5
= 1180 = Rolle
rogaglia@cisco.com = Switzerland
Phone: +41 = 21 823 2805 = =

For corporate legal information go to: = http://www.cisco.com/web/about/doing_business/legal/cri/index.html

On Sep 17, 2010, at 2:56 PM, Alberto Garc=EDa = wrote:

Hi Roque,

|  -----Mensaje = original-----
|  De: Roque Gagliano = [mailto:rogaglia@cisco.com]
|  Enviado el: jueves, 16 de = septiembre de 2010 11:16
|  Para: Alberto Garc=EDa
| =  CC: cga-ext@ietf.org
| =  Asunto: Re: [CGA-EXT] Key Purpose Id specification = and
draft-ietf-csi-proxy-send
|

[...]

|  > = c) could be to have 2 Key Purpose Ids for proxy operation instead = of
one
|  (therefore replacing id-kp-sendProxy), in which = case the following text
could be
|  included in = draft-ietf-csi-send-cert, section 7:
|  
|  I take = option c).
|  
|  When I first thought about this, I = remembered the old times of modem
access
|  and Proxy-ARP in = routers. I see now a use-case for
"id-kp-sendProxiedOwner"
| =  even without considering MIP6.
|  
|  I agree that = we should go this path, it will make a better set of
documents.
| =  However, I believe that if we go this path, we need also to make = sure
that there
|  is a synchronization between this document = and the proxy document to
reflect
|  the correct = sender/receiver behavior.

Fine. Then, the main changes in = draft-ietf-csi-proxy-send would be:

CHANGE = #1
--------------
"5.2.1.  Processing rules for = senders

  A Secure ND Proxy MUST NOT use a key to sign = NDP message types which
  do not correspond to the = authorization granted to the considered key.
  NA, NS and = RS messages MUST be signed with a key corresponding to a
=   Secure Proxy ND certificate with a KeyPurposeID value
=   [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the = source
  addresses of the messages MUST belong to the = prefix associated to the
  certificate.  RA and = Redirect messages MUST be signed with a key
=   corresponding to a Secure Proxy ND certificate with a = KeyPurposeID
  value of id-kp-sendProxiedRouter.  The = prefix included in the RA
  message for on-link = determination and/or stateless address
=   autoconfiguration, and the Target Address of the Redirect = message,
  MUST be equal or be included into the prefix = associated to that
=   certificate.
[...]"


(Roque) Why not use the terminology = of draft-ietf-sidr-res-certs-18 instead of "equal or included"? I = believe the correct term is "encompass". =

CHANGE = #2
--------------
Rule #2 in "5.2.2.  Processing rules for = receivers"
"2.  The Key Hash field MUST indicate the use of a = known public key.
      A valid = certification path (see [RFC3971] Section 6.3) between
=       the receiver's trust anchor and the = sender's public key MUST be
=       known. =  

(Roque) I would mention = rather than RFC3971, the draft-ietf-csi-send-cert-06 section 9. I = would also use the word "valid", which means that the validation process = has been successful.


The Secure Proxy ND's X509v3 certificate MUST contain = an
      extended key usage extension = including the appropriate
=       KeyPurposeId value and prefix for = the message to validate:

      * =  For RA messages, a KeyPurposeId value of id-kp-
=          sendProxiedRouter = MUST exist for the certificate, and the
=          prefix included in = the RA message for on-link determination
=          and/or stateless = address autoconfiguration MUST be equal or be
=          included into the = prefix associated to that = certificate.

(Roque) again the = term should be "encompass".

=       *  For Redirect messages, a = KeyPurposeId value of id-kp-
=          sendProxiedRouter = MUST exist for the certificate, and the
=          prefix included in = the Target Address of the Redirect message
=          MUST belong to the = prefix associated to that = certificate.

(Roque) again the = term should be "encompass".


      *  For NA, = NS and RS messages, a KeyPurposeId value of id-kp-
=          sendProxiedOwner = MUST exist for the certificate, and the
=          source addresses = of the messages MUST belong to the prefix
=          associated to the = certificate.

(Roque) again = the term should be "encompass".

=       If any of these tests fails, the = verification fails."

CHANGE #3
--------------
Modification = of the application scenarios to detail how the certificates = are
configured. For example, for PMIPv6:

"  To provide = SEND protection, each MAG is configured to act as a proxy
=   by means of a certificate associated to the PMIPv6 = domain,
  authorizing each MAG to proxy securely NA and RS = messages by means of
  a KeyPurposeId value of = id-kp-sendProxiedOwner.  In addition, the
=   certificate must also authorize the MAG to advertise = prefixes, by
  associating to the same certificate a = KeyPurposeId value of id-kp-
  sendProxiedRouter. =  Note that the inclusion of multiple KeyPurposeId
=   values is supported by = [I-D.ietf-csi-send-cert]."

CHANGE #4
--------------
And = finally, in the following paragraph would be included in the = security
considerations section:

"  A compromised Secure = ND Proxy provisioned with an authorization
  certificate = with a KeyPurposeId value of id-kp-sendProxiedRouter is
=   able, like a compromised router to siphon off traffic from = the host,
  or mount a man-in-the-middle attack, for hosts = communicating to off-
  link hosts.  However, a = Secure ND Proxy with an authorization
  certificate with a = KeyPurposeId value of id-kp-sendProxiedOwner can
  also = siphon off traffic or mount a man-in-the-middle attack for
=   communication between on-link hosts, even if the hosts use = SEND.
  Note that different application scenarios may = require one type of
  authorization, the other, or both. =  To minimize security risks,
  authorization = capabilities SHOULD NOT exceed the ones strictly
=   required by the application scenario to be = deployed."


Do you think the new text is = reasonable?

Sounds = good.

Roque


|  
|  Finally, I would like to = clarify the validation behavior when listen
several EKUs in
| =  a certificate. At this time, the document states that the = existence of a
particular
|  EKU is a sufficient condition. = This means that if a certificate has a
id-kp-
| =  sendProxiedRouter and a id-kp-sendRouter EKU and I am validating a = RA
with or
|  without the proxy option, it will validate in = either cases using the same
key. I
|  believe this should be = the correct behavior as it should be the operator
to decide
| =  how it want to configure its network.

I agree that a = certificate could hold both id-kp-sendProxiedRouter = and
id-kp-sendRouter EKUs and validate RA or Redirect/RA proxying = with the same
key.

I think the text provided above allows = this behavior.

Thanks and regards,
Alberto

| =  
|  
|  
|  Regards,
|  
| =  Roque
|  
|  
|  >
|  > "The = inclusion of the proxied routing authorization value (id-kp-
| =  sendProxiedRouter)
|  > indicates that the certificate = has been issued for allowing the proxy
|  > to perform = proxying of RA and Redirect messages for the prefix(es)
|  > = that are mentioned in the X.509 extensions for IP addresses. When a
| =  > node's only certificate includes a prefix and only the
| =  > id-kp-sendProxiedRouter authorization KeyPurposeId value, the = node
cannot
|  > perform proxying of NS, NA and RS = messages.
|  >
|  > The inclusion of the proxied = owner authorization value (id-kp-
|  sendProxiedOwner)
| =  > Indicates that the certificate has been issued for allowing = the proxy
to
|  > perform proxying of NS, NA and RS = messages for any address in the
prefix of
|  > such = certificate. When a node's only certificate includes a prefix = and
only
|  > the id-kp-sendProxiedOwner authorization = KeyPurposeId value, the node
|  > cannot advertise that = prefix in an RA."
|  >
|  > The benefit of option = c) is that proxy security is tailored to the
proxy
| =  requirements, in the sense that different application scenarios = may
require one
|  type of authorization, the other, or both. = For example, MIPv6 would use a
|  certificate with just = id-kp-sendProxiedOwner, while PMIPv6 and RFC4389
would
|  use = a certificate with both id-kp-sendProxiedRouter and = sendProxiedOwner.
|  Compromising a MIPv6 HA would not allow an = attacker to issue RA and
Redirects.
|  My personal opinion is = that, to minimize security risks, authorization
capabilities
| =  should not exceed the ones strictly required by the application = scenario
to be
|  deployed, and two Key Purpose Ids for proxy = operation provide appropriate
|  granularity for this.
| =  >
|  > (sorry if I fail to expose fairly the = benefits of all options - feel
free to comment,
|  of = course)
|  >
|  > For me, b) would acceptable, but = I think c) should be better.
|  > What do you think?
| =  >
|  > Regards,
|  > Alberto
| =  >
|  > = _______________________________________________
|  > CGA-EXT = mailing list
|  > CGA-EXT@ietf.org
|  > https://www.ietf.or= g/mailman/listinfo/cga-ext



= --Apple-Mail-403--140169171-- --Apple-Mail-404--140169086 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkyMzE1 NTMxMlowIwYJKoZIhvcNAQkEMRYEFIhJC09M55ZRtQhnQBC+AojndOikMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAAzYEtq57ikRHhl2pJqGI5LER4uIwupAHxtzB0hHyBYQbwTqW5wC 7HLyvcajja793/vNs3l+qecR7JUb/ULWYlmAf4OEfKcT4+6jOaqGle+G10+h99yaQzVYDpoXsnrU psL1LZUNTiP10cy4amFKVJwRarpjvVDfcUokLUhWz+i+a3pIuYw7iqwJhwKyRRzkFwEHd11cI92a qYmM3sYYgIJh98KwEO+BoWAw1SJKbNgAdRwN2a65pBFBWpon5TThZzrIPXev/79DPhBbAyPyDkQk FhG6kTXYK6T0xG7wU5i89h7mDBnj7ix13w66FJ4dz9bD24w18uShRQ8dJHpLtu4AAAAAAAA= --Apple-Mail-404--140169086-- From alberto@it.uc3m.es Fri Sep 24 02:29:54 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A584A3A6B12 for ; Fri, 24 Sep 2010 02:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.755 X-Spam-Level: X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 rMbr4Nan7nxR for ; Fri, 24 Sep 2010 02:29:48 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4939F3A6A61 for ; Fri, 24 Sep 2010 02:29:44 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 3C07C710621; Fri, 24 Sep 2010 11:30:04 +0200 (CEST) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Roque Gagliano'" References: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> Date: Fri, 24 Sep 2010 11:30:03 +0200 Message-ID: <2009891B9B39467AB49AAC0C8D54827B@bombo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CB5BDB.D50DFBE0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: ActbN2loSg9a1HfkSyag2CzknrZK+gAknfdA In-Reply-To: X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17662.003 Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 09:29:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0039_01CB5BDB.D50DFBE0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Roque Thank you for your comments ! I have included them in the draft-ietf-csi-proxy-send text. =20 Regards, Alberto =20 _____ =20 De: Roque Gagliano [mailto:rogaglia@cisco.com]=20 Enviado el: jueves, 23 de septiembre de 2010 17:53 Para: Alberto Garc=EDa CC: cga-ext@ietf.org Asunto: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send =20 Alberto, =20 see inline comments. I will then modify the text in the document and submit the changes. I = will also write to PKIX asking for the new EKU. Regards, Roque -------------------------------------------------------------------------= --- ------------------------------------------------------------------ Roque Gagliano Cisco Systems International S=E0rl =20 Software Engineer Mailstop ROL01/2/ Corporate Development Technology Group Avenue des Uttins 5 =20 1180 Rolle rogaglia@cisco.com Switzerland Phone: +41 21 823 2805 For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html=20 =20 On Sep 17, 2010, at 2:56 PM, Alberto Garc=EDa wrote: Hi Roque, | -----Mensaje original----- | De: Roque Gagliano [mailto:rogaglia@cisco.com] | Enviado el: jueves, 16 de septiembre de 2010 11:16 | Para: Alberto Garc=EDa | CC: cga-ext@ietf.org | Asunto: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send | [...] | > c) could be to have 2 Key Purpose Ids for proxy operation instead = of one | (therefore replacing id-kp-sendProxy), in which case the following = text could be | included in draft-ietf-csi-send-cert, section 7: | =20 | I take option c). | =20 | When I first thought about this, I remembered the old times of modem access | and Proxy-ARP in routers. I see now a use-case for "id-kp-sendProxiedOwner" | even without considering MIP6. | =20 | I agree that we should go this path, it will make a better set of documents. | However, I believe that if we go this path, we need also to make sure that there | is a synchronization between this document and the proxy document to reflect | the correct sender/receiver behavior. Fine. Then, the main changes in draft-ietf-csi-proxy-send would be: CHANGE #1 -------------- "5.2.1. Processing rules for senders A Secure ND Proxy MUST NOT use a key to sign NDP message types which do not correspond to the authorization granted to the considered key. NA, NS and RS messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeID value [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source addresses of the messages MUST belong to the prefix associated to the certificate. RA and Redirect messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeID value of id-kp-sendProxiedRouter. The prefix included in the RA message for on-link determination and/or stateless address autoconfiguration, and the Target Address of the Redirect message, MUST be equal or be included into the prefix associated to that certificate. [...]" =20 (Roque) Why not use the terminology of draft-ietf-sidr-res-certs-18 = instead of "equal or included"? I believe the correct term is "encompass".=20 CHANGE #2 -------------- Rule #2 in "5.2.2. Processing rules for receivers" "2. The Key Hash field MUST indicate the use of a known public key. A valid certification path (see [RFC3971] Section 6.3) between the receiver's trust anchor and the sender's public key MUST be known. =20 =20 (Roque) I would mention rather than RFC3971, the = draft-ietf-csi-send-cert-06 section 9. I would also use the word "valid", which means that the validation process has been successful. =20 The Secure Proxy ND's X509v3 certificate MUST contain an extended key usage extension including the appropriate KeyPurposeId value and prefix for the message to validate: * For RA messages, a KeyPurposeId value of id-kp- sendProxiedRouter MUST exist for the certificate, and the prefix included in the RA message for on-link determination and/or stateless address autoconfiguration MUST be equal or be included into the prefix associated to that certificate. =20 (Roque) again the term should be "encompass". * For Redirect messages, a KeyPurposeId value of id-kp- sendProxiedRouter MUST exist for the certificate, and the prefix included in the Target Address of the Redirect message MUST belong to the prefix associated to that certificate. =20 (Roque) again the term should be "encompass". =20 * For NA, NS and RS messages, a KeyPurposeId value of id-kp- sendProxiedOwner MUST exist for the certificate, and the source addresses of the messages MUST belong to the prefix associated to the certificate. =20 (Roque) again the term should be "encompass". If any of these tests fails, the verification fails." CHANGE #3 -------------- Modification of the application scenarios to detail how the certificates = are configured. For example, for PMIPv6: " To provide SEND protection, each MAG is configured to act as a proxy by means of a certificate associated to the PMIPv6 domain, authorizing each MAG to proxy securely NA and RS messages by means of a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the certificate must also authorize the MAG to advertise prefixes, by associating to the same certificate a KeyPurposeId value of id-kp- sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId values is supported by [I-D.ietf-csi-send-cert]." CHANGE #4 -------------- And finally, in the following paragraph would be included in the = security considerations section: " A compromised Secure ND Proxy provisioned with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is able, like a compromised router to siphon off traffic from the host, or mount a man-in-the-middle attack, for hosts communicating to off- link hosts. However, a Secure ND Proxy with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedOwner can also siphon off traffic or mount a man-in-the-middle attack for communication between on-link hosts, even if the hosts use SEND. Note that different application scenarios may require one type of authorization, the other, or both. To minimize security risks, authorization capabilities SHOULD NOT exceed the ones strictly required by the application scenario to be deployed." Do you think the new text is reasonable? =20 Sounds good. =20 Roque | =20 | Finally, I would like to clarify the validation behavior when listen several EKUs in | a certificate. At this time, the document states that the existence = of a particular | EKU is a sufficient condition. This means that if a certificate has a id-kp- | sendProxiedRouter and a id-kp-sendRouter EKU and I am validating a RA with or | without the proxy option, it will validate in either cases using the = same key. I | believe this should be the correct behavior as it should be the = operator to decide | how it want to configure its network. I agree that a certificate could hold both id-kp-sendProxiedRouter and id-kp-sendRouter EKUs and validate RA or Redirect/RA proxying with the = same key.=20 I think the text provided above allows this behavior.=20 Thanks and regards, Alberto | =20 | =20 | =20 | Regards, | =20 | Roque | =20 | =20 | > | > "The inclusion of the proxied routing authorization value (id-kp- | sendProxiedRouter) | > indicates that the certificate has been issued for allowing the = proxy | > to perform proxying of RA and Redirect messages for the prefix(es) | > that are mentioned in the X.509 extensions for IP addresses. When a | > node's only certificate includes a prefix and only the | > id-kp-sendProxiedRouter authorization KeyPurposeId value, the node cannot | > perform proxying of NS, NA and RS messages. | > | > The inclusion of the proxied owner authorization value (id-kp- | sendProxiedOwner) | > Indicates that the certificate has been issued for allowing the = proxy to | > perform proxying of NS, NA and RS messages for any address in the prefix of | > such certificate. When a node's only certificate includes a prefix = and only | > the id-kp-sendProxiedOwner authorization KeyPurposeId value, the = node | > cannot advertise that prefix in an RA." | > | > The benefit of option c) is that proxy security is tailored to the proxy | requirements, in the sense that different application scenarios may require one | type of authorization, the other, or both. For example, MIPv6 would = use a | certificate with just id-kp-sendProxiedOwner, while PMIPv6 and = RFC4389 would | use a certificate with both id-kp-sendProxiedRouter and = sendProxiedOwner. | Compromising a MIPv6 HA would not allow an attacker to issue RA and Redirects. | My personal opinion is that, to minimize security risks, = authorization capabilities | should not exceed the ones strictly required by the application = scenario to be | deployed, and two Key Purpose Ids for proxy operation provide = appropriate | granularity for this. | > | > (sorry if I fail to expose fairly the benefits of all options - = feel free to comment, | of course) | > | > For me, b) would acceptable, but I think c) should be better. | > What do you think? | > | > Regards, | > Alberto | > | > _______________________________________________ | > CGA-EXT mailing list | > CGA-EXT@ietf.org | > https://www.ietf.org/mailman/listinfo/cga-ext =20 ------=_NextPart_000_0039_01CB5BDB.D50DFBE0 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Roque<= /span>

Thank you for = your comments ! I have included them in the draft-ietf-csi-proxy-send = text.

 =

Regards,

Alberto

 =


De: Roque = Gagliano [mailto:rogaglia@cisco.com]
Enviado el: jueves, 23 de septiembre de 2010 17:53
Para: Alberto = Garc=EDa
CC: cga-ext@ietf.org
Asunto: Re: [CGA-EXT] Key = Purpose Id specification and = draft-ietf-csi-proxy-send

 

Alberto,

 

see inline comments.



I will then modify the text in the document and submit the changes. I will = also write to PKIX asking for the new = EKU.



Regards,

Roque=


------------------------------------------------= -------------------------------------------------------------------------= ---------------------
Roque Gagliano=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0              =                 =   =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cisco Systems International S=E0rl=A0=A0
Software Engineer=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0 Mailstop ROL01/2/
Corporate Development  Technology = Group=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 = Avenue des Uttins 5
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1180 Rolle
rogaglia@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 = Switzerland
Phone: +41 21 823 2805=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0

For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html=

 

On Sep 17, 2010, at 2:56 PM, Alberto Garc=EDa = wrote:



Hi Roque,

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:rogaglia@cisco.com]
|  Enviado el: jueves, 16 de septiembre de 2010 11:16
|  Para: Alberto Garc=EDa
|  CC: cga-ext@ietf.org
|  Asunto: Re: [CGA-EXT] Key Purpose Id specification and
draft-ietf-csi-proxy-send
|

[...]

|  > c) could be to have 2 Key Purpose Ids for proxy operation = instead of
one
|  (therefore replacing id-kp-sendProxy), in which case the = following text
could be
|  included in draft-ietf-csi-send-cert, section 7:
|  
|  I take option c).
|  
|  When I first thought about this, I remembered the old times of = modem
access
|  and Proxy-ARP in routers. I see now a use-case for
"id-kp-sendProxiedOwner"
|  even without considering MIP6.
|  
|  I agree that we should go this path, it will make a better set = of
documents.
|  However, I believe that if we go this path, we need also to make = sure
that there
|  is a synchronization between this document and the proxy = document to
reflect
|  the correct sender/receiver behavior.

Fine. Then, the main changes in draft-ietf-csi-proxy-send would be:

CHANGE #1
--------------
"5.2.1.  Processing rules for senders

  A Secure ND Proxy MUST NOT use a key to sign NDP message = types which
  do not correspond to the authorization granted to the = considered key.
  NA, NS and RS messages MUST be signed with a key = corresponding to a
  Secure Proxy ND certificate with a KeyPurposeID value
  [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the = source
  addresses of the messages MUST belong to the prefix = associated to the
  certificate.  RA and Redirect messages MUST be signed = with a key
  corresponding to a Secure Proxy ND certificate with a = KeyPurposeID
  value of id-kp-sendProxiedRouter.  The prefix included = in the RA
  message for on-link determination and/or stateless = address
  autoconfiguration, and the Target Address of the Redirect = message,
  MUST be equal or be included into the prefix associated to = that
  certificate.
[...]"

 

(Roque) Why not use the terminology of draft-ietf-sidr-res-certs-18 instead of "equal or = included"? I believe the correct term is "encompass".



CHANGE #2
--------------
Rule #2 in "5.2.2.  Processing rules for receivers"
"2.  The Key Hash field MUST indicate the use of a known = public key.
      A valid certification path (see = [RFC3971] Section 6.3) between
      the receiver's trust anchor and the sender's public key MUST be
      known. =  

 

(Roque) I would mention rather than RFC3971, the draft-ietf-csi-send-cert-06 section 9. I would also use the = word "valid", which means that the validation process has been = successful.

 



The Secure Proxy ND's X509v3 certificate MUST contain an
      extended key usage extension = including the appropriate
      KeyPurposeId value and prefix for = the message to validate:

      *  For RA messages, a = KeyPurposeId value of id-kp-
         sendProxiedRouter = MUST exist for the certificate, and the
         prefix included in = the RA message for on-link determination
         and/or stateless = address autoconfiguration MUST be equal or be
         included into the = prefix associated to that certificate.

 

(Roque) again the term should be = "encompass".



      *  For Redirect = messages, a KeyPurposeId value of id-kp-
         sendProxiedRouter = MUST exist for the certificate, and the
         prefix included in = the Target Address of the Redirect message
         MUST belong to the = prefix associated to that certificate.

 

(Roque) again the term should be = "encompass".

 



      *  For NA, NS and RS = messages, a KeyPurposeId value of id-kp-
         sendProxiedOwner = MUST exist for the certificate, and the
         source addresses = of the messages MUST belong to the prefix
         associated to the certificate.

 

(Roque) again the term should be = "encompass".



      If any of these tests fails, = the verification fails."

CHANGE #3
--------------
Modification of the application scenarios to detail how the certificates = are
configured. For example, for PMIPv6:

"  To provide SEND protection, each MAG is configured to act = as a proxy
  by means of a certificate associated to the PMIPv6 = domain,
  authorizing each MAG to proxy securely NA and RS messages by = means of
  a KeyPurposeId value of id-kp-sendProxiedOwner.  In = addition, the
  certificate must also authorize the MAG to advertise = prefixes, by
  associating to the same certificate a KeyPurposeId value of = id-kp-
  sendProxiedRouter.  Note that the inclusion of multiple KeyPurposeId
  values is supported by [I-D.ietf-csi-send-cert]."

CHANGE #4
--------------
And finally, in the following paragraph would be included in the = security
considerations section:

"  A compromised Secure ND Proxy provisioned with an = authorization
  certificate with a KeyPurposeId value of = id-kp-sendProxiedRouter is
  able, like a compromised router to siphon off traffic from = the host,
  or mount a man-in-the-middle attack, for hosts communicating = to off-
  link hosts.  However, a Secure ND Proxy with an = authorization
  certificate with a KeyPurposeId value of = id-kp-sendProxiedOwner can
  also siphon off traffic or mount a man-in-the-middle attack = for
  communication between on-link hosts, even if the hosts use = SEND.
  Note that different application scenarios may require one = type of
  authorization, the other, or both.  To minimize = security risks,
  authorization capabilities SHOULD NOT exceed the ones = strictly
  required by the application scenario to be = deployed."


Do you think the new text is reasonable?

 

Sounds good.

 

Roque




|  
|  Finally, I would like to clarify the validation behavior when = listen
several EKUs in
|  a certificate. At this time, the document states that the = existence of a
particular
|  EKU is a sufficient condition. This means that if a certificate = has a
id-kp-
|  sendProxiedRouter and a id-kp-sendRouter EKU and I am validating = a RA
with or
|  without the proxy option, it will validate in either cases using = the same
key. I
|  believe this should be the correct behavior as it should be the operator
to decide
|  how it want to configure its network.

I agree that a certificate could hold both id-kp-sendProxiedRouter = and
id-kp-sendRouter EKUs and validate RA or Redirect/RA proxying with the = same
key.

I think the text provided above allows this behavior.

Thanks and regards,
Alberto

|  
|  
|  
|  Regards,
|  
|  Roque
|  
|  
|  >
|  > "The inclusion of the proxied routing authorization = value (id-kp-
|  sendProxiedRouter)
|  > indicates that the certificate has been issued for allowing = the proxy
|  > to perform proxying of RA and Redirect messages for the = prefix(es)
|  > that are mentioned in the X.509 extensions for IP = addresses. When a
|  > node's only certificate includes a prefix and only the
|  > id-kp-sendProxiedRouter authorization KeyPurposeId value, = the node
cannot
|  > perform proxying of NS, NA and RS messages.
|  >
|  > The inclusion of the proxied owner authorization value = (id-kp-
|  sendProxiedOwner)
|  > Indicates that the certificate has been issued for allowing = the proxy
to
|  > perform proxying of NS, NA and RS messages for any address = in the
prefix of
|  > such certificate. When a node's only certificate includes a = prefix and
only
|  > the id-kp-sendProxiedOwner authorization KeyPurposeId = value, the node
|  > cannot advertise that prefix in an RA."
|  >
|  > The benefit of option c) is that proxy security is tailored = to the
proxy
|  requirements, in the sense that different application scenarios = may
require one
|  type of authorization, the other, or both. For example, MIPv6 = would use a
|  certificate with just id-kp-sendProxiedOwner, while PMIPv6 and = RFC4389
would
|  use a certificate with both id-kp-sendProxiedRouter and sendProxiedOwner.
|  Compromising a MIPv6 HA would not allow an attacker to issue RA = and
Redirects.
|  My personal opinion is that, to minimize security risks, = authorization
capabilities
|  should not exceed the ones strictly required by the application scenario
to be
|  deployed, and two Key Purpose Ids for proxy operation provide appropriate
|  granularity for this.
|  >
|  > (sorry if I fail to expose fairly the benefits of all = options - feel
free to comment,
|  of course)
|  >
|  > For me, b) would acceptable, but I think c) should be = better.
|  > What do you think?
|  >
|  > Regards,
|  > Alberto
|  >
|  > _______________________________________________
|  > CGA-EXT mailing list
|  > CGA-EXT@ietf.org
|  > https://www.ietf.o= rg/mailman/listinfo/cga-ext

 

------=_NextPart_000_0039_01CB5BDB.D50DFBE0-- From rogaglia@cisco.com Fri Sep 24 03:56:35 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE383A6B14 for ; Fri, 24 Sep 2010 03:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=-3.504, 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 QM7LRMGnUIYf for ; Fri, 24 Sep 2010 03:56:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D95B13A69E6 for ; Fri, 24 Sep 2010 03:56:33 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAGMgnEyQ/khM/2dsb2JhbACUQ417cadinC2FQwSKOoJ+ X-IronPort-AV: E=Sophos;i="4.57,229,1283731200"; d="scan'208,217";a="10067321" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 24 Sep 2010 10:57:04 +0000 Received: from [144.254.21.40] ([144.254.21.40]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o8OAv4CC015515 for ; Fri, 24 Sep 2010 10:57:04 GMT From: Roque Gagliano Content-Type: multipart/alternative; boundary=Apple-Mail-429--71526328 Date: Fri, 24 Sep 2010 12:57:15 +0200 References: <20100924105545.B53443A6B42@core3.amsl.com> To: cga-ext@ietf.org Message-Id: <456B26CC-DA57-4C21-9B88-61B62829671E@cisco.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [CGA-EXT] Fwd: New Version Notification for draft-ietf-csi-send-cert-07 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 10:56:35 -0000 --Apple-Mail-429--71526328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I Just updated the new version with the changes discussed. Regards, Roque. Begin forwarded message: > From: IETF I-D Submission Tool > Date: September 24, 2010 12:55:45 PM GMT+02:00 > To: rogaglia@cisco.com > Cc: suresh.krishnan@ericsson.com, ana.kukec@fer.hr > Subject: New Version Notification for draft-ietf-csi-send-cert-07=20 >=20 >=20 > A new version of I-D, draft-ietf-csi-send-cert-07.txt has been = successfully submitted by Roque Gagliano and posted to the IETF = repository. >=20 > Filename: draft-ietf-csi-send-cert > Revision: 07 > Title: Certificate profile and certificate management = for SEND > Creation_date: 2010-09-24 > WG ID: csi > Number_of_pages: 21 >=20 > Abstract: > SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for > performing router authorization. This document specifies a > certificate profile for SEND based on Resource Certificates along > with extended key usage values required for SEND. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --Apple-Mail-429--71526328 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: September 24, 2010 12:55:45 PM = GMT+02:00
= Subject: New Version = Notification for draft-ietf-csi-send-cert-07 =


A new version of I-D, = draft-ietf-csi-send-cert-07.txt has been successfully submitted by Roque = Gagliano and posted to the IETF repository.

Filename: = draft-ietf-csi-send-cert
Revision: 07
Title: = Certificate profile and certificate management for = SEND
Creation_date: 2010-09-24
WG ID: = csi
Number_of_pages: 21

Abstract:
SEcure Neighbor Discovery = (SEND) Utilizes X.509v3 certificates for
performing router = authorization.  This document specifies a
certificate profile = for SEND based on Resource Certificates along
with extended key usage = values required for SEND.



The IETF = Secretariat.



= --Apple-Mail-429--71526328-- From alberto@it.uc3m.es Tue Sep 28 08:07:16 2010 Return-Path: X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20723A6B0B for ; Tue, 28 Sep 2010 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 q9vAQXeozd4h for ; Tue, 28 Sep 2010 08:07:14 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 22F503A6CF2 for ; Tue, 28 Sep 2010 08:07:13 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 8C03D844985 for ; Tue, 28 Sep 2010 17:07:54 +0200 (CEST) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: Date: Tue, 28 Sep 2010 17:07:53 +0200 Message-ID: <4D3CE09A57874865A93F099C84A87C0F@bombo> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: ActfHfie3bkpwirKTFuY0IVLQ99YqQAAI0Vg X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17672.000 Subject: [CGA-EXT] RV: New Version Notification for draft-ietf-csi-proxy-send-05 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 15:07:16 -0000 Hi, I have posted a new version of draft-ietf-csi-proxy-send, version -05 which addresses some comments made by the IESG (including the 2 KeyPurposeId's introduced in draft-ietf-csi-send-cert-07) Regards, Alberto -----Mensaje original----- De: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Enviado el: martes, 28 de septiembre de 2010 17:00 Para: alberto@it.uc3m.es CC: suresh.krishnan@ericsson.com; julienl@qualcomm.com; marco.bonola@gmail.com Asunto: New Version Notification for draft-ietf-csi-proxy-send-05 A new version of I-D, draft-ietf-csi-proxy-send-05.txt has been successfully submitted by Alberto Garcia-Martinez and posted to the IETF repository. Filename: draft-ietf-csi-proxy-send Revision: 05 Title: Secure Proxy ND Support for SEND Creation_date: 2010-09-28 WG ID: csi Number_of_pages: 29 Abstract: Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending a ND message is the owner of the address from which the message is sent and/or posses a key which authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. The IETF Secretariat.