Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send

Roque Gagliano <rogaglia@cisco.com> Thu, 16 September 2010 09:15 UTC

Return-Path: <rogaglia@cisco.com>
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 <cga-ext@core3.amsl.com>; 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 <cga-ext@core3.amsl.com>; 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 <cga-ext@ietf.org>; 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 <rogaglia@cisco.com>
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: Alberto García <alberto@it.uc3m.es>
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 <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: Thu, 16 Sep 2010 09:15:34 -0000

Hi Alberto,

Please see inline.
 
> 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: 

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

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


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