[CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send
Alberto García <alberto@it.uc3m.es> Wed, 08 September 2010 13:27 UTC
Return-Path: <alberto@it.uc3m.es>
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 <cga-ext@core3.amsl.com>; 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 <cga-ext@core3.amsl.com>; 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 <cga-ext@ietf.org>; 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 <cga-ext@ietf.org>; Wed, 8 Sep 2010 15:27:59 +0200 (CEST)
From: Alberto García <alberto@it.uc3m.es>
To: cga-ext@ietf.org
Date: Wed, 08 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 <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2010 13:27:41 -0000
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
- [CGA-EXT] Key Purpose Id specification and draft-… Alberto García
- Re: [CGA-EXT] Key Purpose Id specification and dr… Roque Gagliano
- Re: [CGA-EXT] Key Purpose Id specification and dr… Alberto García
- Re: [CGA-EXT] Key Purpose Id specification and dr… Roque Gagliano
- Re: [CGA-EXT] Key Purpose Id specification and dr… Alberto García