Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04
Alberto García <alberto@it.uc3m.es> Wed, 07 July 2010 16:28 UTC
Return-Path: <alberto@it.uc3m.es>
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 594EA3A67B3; Wed, 7 Jul 2010 09:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level:
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 iuPIJvdkZ0Ma; Wed, 7 Jul 2010 09:28:13 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7C1A73A679F; Wed, 7 Jul 2010 09:28:12 -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 294086FC4D2; Wed, 7 Jul 2010 18:28:10 +0200 (CEST)
From: Alberto García <alberto@it.uc3m.es>
To: 'Roque Gagliano' <rogaglia@cisco.com>
References: <E7FA9617215B4AE08B038FC422C42568@bombo> <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com> <BF131EAB4CA44007987AC10FFB4F0158@bombo> <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com>
Date: Wed, 07 Jul 2010 18:28:07 +0200
Message-ID: <EC159F64304A4E95A9464BC6DD666B41@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acsd1/xnb/cMiJktQZa01B3qXSQOsQAGB08w
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
In-Reply-To: <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com>
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17492.000
X-Mailman-Approved-At: Wed, 07 Jul 2010 10:51:18 -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 16:28:14 -0000
Hi Roque | -----Mensaje original----- | De: Roque Gagliano [mailto:rogaglia@cisco.com] | Enviado el: miércoles, 07 de julio de 2010 15:26 | Para: Alberto García | CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy- | send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org; csi- | chairs@tools.ietf.org | Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04 | | Hi Alberto, | | Please see inline. | | Roque. | | On Jul 7, 2010, at 2:39 PM, Alberto García wrote: | | > Hi Roque, | > Thanks for your fast answer. | > | > | -----Mensaje original----- | > | De: Roque Gagliano [mailto:rogaglia@cisco.com] | > | Enviado el: miércoles, 07 de julio de 2010 11:12 | > | Para: Alberto García | > | CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; | > draft-ietf-csi-proxy- | > | send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org; csi- | > | chairs@tools.ietf.org | > | Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04 | > | | > | 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"" | > | > Yes, although I would also include Redirect messages, since the 'router | > function' pack is RA+Redirect | > | | ok. | | > | | > | | > | > (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" | > | > Yes, also including Redirect. | | ok. | | > | > | | > | | > | > - "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" | > | > Ummm. I think this is more than 'respond', since it also authorizes the node | > to sign RS and NS. I would detail the messages that are covered by this | > authorization: NS, NA, RS. | > What do you think? | > | > - "owner authorization [...]For an | > | address in such certificate the host can assign the address, send/ | > | receive traffic from this address, and can send NS, NA and RS messages | > about that address" | | | ok, but lets keep the respond in the sentence: | - "owner authorization [...]For an address in such certificate the host can assign | the address, send/receive traffic from this address, and can send or respond NS, | NA and RS messages about that address" I wonder if the 'respond' close to the 'RS' may induce the reader to think that the 'owner' could generate a RA, which in fact it can't. I would take out the respond, but if you think it is clear enough... | | > | | > | > 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"? | > | > Yes. | | Ok. | | > | > | | > | 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. | > | > Sure. I can include it in 5.2.2, processing step #2, in which certificates | > are considered | > | > | | > | 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. | > | > I agree that the validation section can be complemented a bit, for example, | > stating that at least one KeyPurposeId MUST be present. The part 'the | > required' in the text you propose is not clear to me: required... for what, | > in which sense? | > | | I was referring to verify that the KeyPurposeId matches the application. What | about replacing "required" by "correspondent" | | "The host MUST verify that the correspondent Key PurposedId(s) value is | present as described in Section 7." ok | | > | > Just one question (which could affect validation): I assume (maybe I'm | > wrong) that a certificate is bound to a Certified IPv6 address space, in the | > sense that the KeyPurposeId affects to ALL the addresses (or prefixes) of | > the certificate. Then, I don't understand how a given prefix can be at the | > same time 'router' or 'owner', or 'proxy router' or 'proxy host'. For me, | > all this functionalities should inherently incompatible for a given prefix | > (for example, a router maybe is authorized as a 'router' for a prefix, but | > should be authorized as 'owner' for just a single address of the prefix | > (don't think it is a good idea to allow to be 'owner' of the whole prefix, | > which in fact it is not). Also, either a node is 'router' for a prefix, or | > 'proxy router', but both do not make sense. The same for 'owner' and 'proxy | > owner/host' | > If some combinations are possible, but others are not, it should also be | > specified, I think. | | It is true that some combinations do not work. You will need more than one | certificate in those cases. In fact, I don't know if there is any combination that work (I think there is no one). If there is no one, then only one KeyPurposeId MUST be allowed per certificate (even if in the future there are cases in which many authorization roles are possible, then many certificates should be used). Or, if you think that many KeyPurposeIds must be supported, it should be clearly stated which combinations are not allowed (I think all of the combinations of KeyPurposeId currently being defined). Or I am missing anything? Regards, Alberto | | Roque. | | > | > Regards, | > Alberto | > | > | > | | > | 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 | > | > | > | > | > | > | > | > | > | > | > | >
- [secdir] secdir review of draft-ietf-csi-proxy-se… Sandra Murphy
- Re: [secdir] secdir review of draft-ietf-csi-prox… Alberto García
- Re: [secdir] (MAIN) secdir review of draft-ietf-c… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Sandra Murphy
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… Ralph Droms
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… marcelo bagnulo braun
- Re: [secdir] secdir review of draft-ietf-csi-prox… Sean Turner
- Re: [secdir] secdir review of draft-ietf-csi-prox… Murphy, Sandra
- Re: [secdir] secdir review of draft-ietf-csi-prox… Jeffrey Hutzelman
- Re: [secdir] (MAIN) secdir review of draft-ietf-c… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano