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

Roque Gagliano <rogaglia@cisco.com> Thu, 23 September 2010 15:52 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 660493A698F for <cga-ext@core3.amsl.com>; 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 <cga-ext@core3.amsl.com>; 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 <cga-ext@ietf.org>; 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 <rogaglia@cisco.com>
In-Reply-To: <E6451C31103E46809F5A4D1E4F956549@bombo>
Date: Thu, 23 Sep 2010 17:53:12 +0200
Message-Id: <A53CD62C-4BF3-4F1F-98BF-2F53634CE2B5@cisco.com>
References: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> <E6451C31103E46809F5A4D1E4F956549@bombo>
To: =?iso-8859-1?Q?Alberto_Garc=EDa?= <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, 23 Sep 2010 15:52:37 -0000

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àrl	
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ía 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ía
> |  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.org/mailman/listinfo/cga-ext
> 
>