[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: =?iso-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: <cga-ext@ietf.org>
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 <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