Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04

Roque Gagliano <rogaglia@cisco.com> Wed, 07 July 2010 09:11 UTC

Return-Path: <rogaglia@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5548C3A659C; Wed, 7 Jul 2010 02:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Oq004+xPoNvo; Wed, 7 Jul 2010 02:11:35 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8AA723A67D3; Wed, 7 Jul 2010 02:11:34 -0700 (PDT)
Authentication-Results: rtp-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: AvsEAArhM0xAZnwM/2dsb2JhbACgB3GlZZpihSQEiD0
X-IronPort-AV: E=Sophos; i="4.53,551,1272844800"; d="p7s'?scan'208"; a="129504915"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2010 09:11:37 +0000
Received: from Roque-Gaglianos-MacBook-Pro.local ([144.254.21.53]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o679BTh1004480; Wed, 7 Jul 2010 09:11:29 GMT
Received: from [127.0.0.1] by Roque-Gaglianos-MacBook-Pro.local (PGP Universal service); Wed, 07 Jul 2010 11:11:43 +0200
X-PGP-Universal: processed; by Roque-Gaglianos-MacBook-Pro.local on Wed, 07 Jul 2010 11:11:43 +0200
Mime-Version: 1.0 (Apple Message framework v1081)
From: Roque Gagliano <rogaglia@cisco.com>
In-Reply-To: <E7FA9617215B4AE08B038FC422C42568@bombo>
Date: Wed, 07 Jul 2010 11:11:31 +0200
Message-Id: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com>
References: <E7FA9617215B4AE08B038FC422C42568@bombo>
To: Alberto García <alberto@it.uc3m.es>
X-Mailer: Apple Mail (2.1081)
Content-Type: multipart/signed; boundary="Apple-Mail-62--461019046"; protocol="application/pkcs7-signature"; micalg="sha1"
X-Mailman-Approved-At: Wed, 07 Jul 2010 05:58:03 -0700
Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, 'Sandra Murphy' <Sandra.Murphy@sparta.com>, draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2010 09:11:38 -0000

Hi Alberto,

> In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in cert-04) it discusses the messages that are authorized by each KeyPurposeId
> 
> - "router authorization value indicates that the
> 
>    certificate has been issued for allowing the router to advertise
> 
>    prefix(es)"
> 
> 
What about the following text?

"router authorization value indicates that the

   certificate has been issued for allowing the router to generate RA messages for the

   prefix(es)  that are mentioned in the X.509 extensions for IP addresses""


> (I understand that implicitly states that it authorizes the generation of RA messages. It is not crystal clear for me if it authorizes NA for routers, although if I had to take this text literally, I would suppose routers would need an 'owner' authorization if this PKI model substitutes RFC3971 CGA authorization, considering that the prefix for NA would be narrowed in general to one address, while the RA authorization is prefix-wide)
> 
> - "proxy authorization value indicates that the
> 
>    certificate has been issued for allowing the proxy to perform
> 
>    proxying of neighbor discovery messages for the prefix(es) that are
> 
>    mentioned using the X.509 extensions for IP addresses"
> 
> (I understand it now implicitly states it authorizes for ANY neighbor discovery message. By the way, this is the assumption underlying in general draft-ietf-csi-proxy-send-04: in the application scenarios, some require RA proxying, which is assumed to be performed by means of the proxy cert)
> 
> 
What about the following text?

- "proxy authorization value indicates that the

   certificate has been issued for allowing the proxy to perform

   proxying of RA messages for the prefix(es) that are

   mentioned in the X.509 extensions for IP addresses"


> - "owner authorization [...]For an
> 
>    address in such certificate the host can assign the address, send/
> 
>    receive traffic from this address, and can respond to NSes about that
> 
>    address"
> 
> (this is the clearest of all statements - although I think issuing secured NS and RS should also be considered)
> 
What about the following text?

- "owner authorization [...]For an

   address in such certificate the host can assign the address, send/

   receive traffic from this address, and can respond to ND messages about that

   address"

> So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates provide authorization for securing *any* ND message. Considering the application scenarios, some require proxying RA (PMIPv6 and RFC4389), and the MIPv6 scenario just require NS/NA proxying.
> 
>  
> 
> In summary so far, there is some specification of the authorization in draft-csi-send-cert, which I think it would be nice that it could be refined, and if so, my opinion is that the refinement of which ND message is authorized by each KeyPurposeId should be in that document.
> 
> However, continuing with this issue, I must say that the way the 'proxy authorization' is defined, and the relationship with the other cases, is not satisfactory for me.
> 
> I think the use of 'owner' should be restricted for hosts that really own the address (therefore, a substitution of the CGA mechanism) - as opposed to proxies.
> 
> For the 'proxy authorization', I think it could be refined into something like “proxy host” authorization, and “proxy router” authorization.
> 
> ‘Proxy host’ would authorize for proxying NA, NS and RS, and “proxy router” authorization would authorize RA and Redirect. This would provide a finer grain which I think would be desirable (for example, MIPv6 does not need protecting neither RA nor redirect).
> 
> 

So, what you are proposing is to modify the name of the current EKU to "proxy router" and generate a new EKU named "proxy host"?

As a side note, I would like to proposse that you modify the first paragraph of Section 5.2.2 (Processing rules for receivers) by making a reference to the draft-csi-send-cert Section 9 as the certificate validation method. 

Additional, In the  draft-csi-send-cert document, we could add the following text at the end of Section 9 (validation):

"The host  MUST verify that the required Key PurposedId(s) value is present as described in Section 7."

In this sense we close the loop as:
	- you validate the certificate using SIDR defined validation method.
	- you then validate your particular KeyPurpisedId using the text in Section 9.

Roque.



 	

> I think this would work (if so, it should be changed in draft-csi-send-cert).
> 
>  
> 
> What do you think? (both authors of draft-csi-send-cert, Sandra, etc.).
> 
>  
> 
> Regards,
> 
> Alberto
> 
>  
> 
>  
>