Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send
Alberto García <alberto@it.uc3m.es> Fri, 24 September 2010 09:29 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 A584A3A6B12 for <cga-ext@core3.amsl.com>; Fri, 24 Sep 2010 02:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.755
X-Spam-Level:
X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, 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 rMbr4Nan7nxR for <cga-ext@core3.amsl.com>; Fri, 24 Sep 2010 02:29:48 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4939F3A6A61 for <cga-ext@ietf.org>; Fri, 24 Sep 2010 02:29:44 -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 smtp02.uc3m.es (Postfix) with ESMTP id 3C07C710621; Fri, 24 Sep 2010 11:30:04 +0200 (CEST)
From: Alberto García <alberto@it.uc3m.es>
To: 'Roque Gagliano' <rogaglia@cisco.com>
References: <8BDAF9A478934FD5BC28B376D394FFB0@bombo> <3EDE6671-8809-47F3-A706-63E0A745BFD2@cisco.com> <E6451C31103E46809F5A4D1E4F956549@bombo> <A53CD62C-4BF3-4F1F-98BF-2F53634CE2B5@cisco.com>
Date: Fri, 24 Sep 2010 11:30:03 +0200
Message-ID: <2009891B9B39467AB49AAC0C8D54827B@bombo>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CB5BDB.D50DFBE0"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
Thread-Index: ActbN2loSg9a1HfkSyag2CzknrZK+gAknfdA
In-Reply-To: <A53CD62C-4BF3-4F1F-98BF-2F53634CE2B5@cisco.com>
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17662.003
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: Fri, 24 Sep 2010 09:29:55 -0000
Roque Thank you for your comments ! I have included them in the draft-ietf-csi-proxy-send text. Regards, Alberto _____ De: Roque Gagliano [mailto:rogaglia@cisco.com] Enviado el: jueves, 23 de septiembre de 2010 17:53 Para: Alberto García CC: cga-ext@ietf.org Asunto: Re: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send 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