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