Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04
Roque Gagliano <rogaglia@cisco.com> Thu, 07 October 2010 10:56 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 BCECC3A7021; Thu, 7 Oct 2010 03:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.916
X-Spam-Level:
X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LStCYjdXrTdx; Thu, 7 Oct 2010 03:56:22 -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 9CA713A6A03; Thu, 7 Oct 2010 03:56:20 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnsIANNErUyQ/khLgWdsb2JhbACES4FIlBsBiBYVAQEWIiKnFJxGAoVFBIFdiGM
X-IronPort-AV: E=Sophos; i="4.57,297,1283731200"; d="scan'208,217"; a="66053839"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2010 10:57:21 +0000
Received: from dhcp-10-55-80-224.cisco.com (dhcp-10-55-80-224.cisco.com [10.55.80.224]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o97AvKAG020636; Thu, 7 Oct 2010 10:57:21 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-280-1051710693"
From: Roque Gagliano <rogaglia@cisco.com>
In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC3D015B@nemo.columbia.ads.sparta.com>
Date: Thu, 07 Oct 2010 12:57:52 +0200
Message-Id: <634F9C92-61D0-4D17-AA80-D02A02AFB676@cisco.com>
References: <E7FA9617215B4AE08B038FC422C42568@bombo> <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> <E78B1895-1C34-4C74-96E2-21A6D267FC6C@gmail.com> <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> <4C8E41F6.906@it.uc3m.es> <4C8F90D4.3040301@ieca.com> <5ABE30CE099A524CBF95C715D37BCACC3D015B@nemo.columbia.ads.sparta.com>
To: "Murphy, Sandra" <Sandra.Murphy@cobham.com>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Sun, 10 Oct 2010 08:25:44 -0700
Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, García <alberto@it.uc3m.es>, draft-ietf-csi-proxy-send.all@tools.ietf.org, Ralph Droms <rdroms.ietf@gmail.com>, marcelo bagnulo braun <marcelo@it.uc3m.es>, csi-chairs@tools.ietf.org, IESG IESG <iesg@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: Thu, 07 Oct 2010 10:56:24 -0000
Hi Sandra, Both document have now been updated to include the new EKU. I believe that you can now re-visit your review. Regards, Roque Ref: http://www.ietf.org/id/draft-ietf-csi-send-cert-08.txt http://tools.ietf.org/html/draft-ietf-csi-proxy-send-05 On Sep 14, 2010, at 7:33 PM, Murphy, Sandra wrote: > Hopefully readable. As it is sent from a smartphone. > > Roque and I have communicated about timing of my rereview. He says I might as well wait for the wg to decide. I am interested, iirc, in what actions or messages require what certs > > > Sandy > > -----Original Message---. Looking forward to (having time to) reviewing the new draft. > > -- > From: Sean Turner [mailto:turners@ieca.com] > Sent: Tue 9/14/2010 11:12 AM > To: marcelo bagnulo braun > Cc: Roque Gagliano; draft-ietf-csi-send-cert@tools.ietf.org; secdir@ietf.org; Murphy, Sandra; García; draft-ietf-csi-proxy-send.all@tools.ietf.org; "Alberto "@core3.amsl.com; Ralph Droms; csi-chairs@tools.ietf.org; IESG IESG; Russ Housley > Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 > > marcelo bagnulo braun wrote: > > > > > > El 13/09/10 16:29, Roque Gagliano escribió: > >> Hi Ralph, > >> > >> I can answer for the draft-ietf-csi-send-cert document. The new > >> revision addressed all the DISCUSS positions for that document. > >> > >> As I mentioned in a previous email, we came back to the WG to ask one > >> change that is been requested by one of the authors of the > >> draft-ietf-csi-proxy-send document. The change consist of adding a new > >> EKU. > >> > >> I think is best to wait for the WG opinion on this issue because if > >> this additional EKU is needed, it makes sense to have it in this same > >> document. > >> > > Right, the problem is that the WG is slient, so we probably need to > > solve this in some other way i.e. propose something to the WG and see if > > anybody objects. > > > > The new EKU is the proposed way to deal with one comment from Sandy's > > review of the proxy send document. It seems we could live without, but > > it would be a somehow inferior solution. I would suggest that unless > > getting a new EKU is a lot of work, we go ahead with that. > > Getting an EKU is pretty easy. Ask Russ Housley > <housley@vigilsec.com> (cced) for one. He controls assigning the OID > out of the PKIX arc. Obvioulsy, you'll need to add some text in the > document to explain its use. > > spt > > > would that make sense? > > > > Regards, marcelo > > > > > >> 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 13, 2010, at 4:21 PM, Ralph Droms wrote: > >> > >>> Can you clarify the status of draft-ietf-csi-send-cert and > >>> draft-ietf-csi-proxy-send? Does the new rev of > >>> draft-ietf-csi-send-cert address the DISCUSS positions on both docs? > >>> > >>> - Ralph > >>> > >>> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: > >>> > >>>> Hi Sandra, > >>>> > >>>> I issued a new version of the draft draft-ietf-csi-send-cert documents. > >>>> > >>>> I believe the new version addresses all the concerns expressed in > >>>> this mail exchange. > >>>> > >>>> Regards, > >>>> > >>>> Roque > >>>> > >>>> > >>>> > >>>> > >>>> On Jul 6, 2010, at 5:32 PM, Alberto García wrote: > >>>> > >>>>> Hi, > >>>>> The text of this email has been extracted from a thorough review of > >>>>> draft-ietf-csi-proxy-send being made by Sandra Murphy. > >>>>> The reason why the email has been separated is to include the > >>>>> authors of draft-ietf-csi-send-cert in the discussion of this part > >>>>> of the text, since I think some of the issues raised by Sandra > >>>>> affect this document. > >>>>> > >>>>> I include my comments inline. > >>>>> > >>>>> | -----Mensaje original----- > >>>>> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > >>>>> | Enviado el: viernes, 02 de julio de 2010 2:31 > >>>>> | Para: iesg@ietf.org; secdir@ietf.org; > >>>>> draft-ietf-csi-proxy-send.all@tools.ietf.org > >>>>> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 > >>>>> | > >>>>> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. > >>>>> | > >>>>> | I have reviewed this document as part of the security directorate's > >>>>> | ongoing effort to review all IETF documents being processed by > >>>>> the IESG. > >>>>> | These comments were written primarily for the benefit of the > >>>>> security area > >>>>> | directors. Document editors and WG chairs should treat these > >>>>> comments just > >>>>> | like any other last call comments. > >>>>> | > >>>>> | This document provides new Neighbor Discovery options that will > >>>>> secure > >>>>> | proxied Neighbor Discovery messages. It is an update to: > >>>>> | > >>>>> | RFC4861: Neighbor Discovery in IPv6 > >>>>> | RFC4389: Neighbor Discovery Proxies (ND Proxy) > >>>>> | RFC3971: Send Neighbor Discovery (SEND) > >>>>> | > >>>>> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. > >>>>> | > >>>>> | The need for new mechanisms for security for proxied messages is > >>>>> explained > >>>>> | in draft-ietf-csi-sndp-prob-04.txt. > >>>>> | > >>>>> | I've read all of these, but it is pretty new to me, so I could > >>>>> have missed > >>>>> | something. > >>>>> | > >>>>> | The Neighbor Discovery protocol communicates link-level > >>>>> addresses in the > >>>>> | protocol messages. The ND Proxy extension would make changes to > >>>>> those > >>>>> | fields. SEND, which secures the base ND protocol, relies on the > >>>>> sender of > >>>>> | a message computing a signature associated with the source IP > >>>>> address of > >>>>> | the message. Any ND Proxy changes to messages would invalidate the > >>>>> | signature and the ND Proxy itself could not generate a new > >>>>> signature > >>>>> | (since it would not have the private key associated with the > >>>>> source IP > >>>>> | address). This draft introduces a Proxy Signature (PS) option > >>>>> to secure > >>>>> | the proxied messages. > >>>>> | > >>>>> | RFC3971, the base SEND spec, defines a new Router Authorization > >>>>> | Certificate profile, dependent on RFC3779, which authorizes the > >>>>> router to > >>>>> | act as a router and act for certain prefixes. Message > >>>>> authorization in > >>>>> | SEND of some ND messages checks the prefixes listed in the > >>>>> certificate > >>>>> | against the prefixes mentioned in those messages. There is no > >>>>> explicit > >>>>> | representation in the certificate of the authority to act as a > >>>>> router. > >>>>> | Possession of the certificate in SEND serves as implicit > >>>>> authorization to > >>>>> | act as a router, as that was the only authorization defined. > >>>>> | > >>>>> | With the introduction of proxies, there was a need to > >>>>> distinguish the > >>>>> | various roles that a node might have in the network. No longer is > >>>>> | possession of a certificate adequate authorization. The draft > >>>>> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to > >>>>> distinguish > >>>>> | three different roles: router, proxy and owner. That draft > >>>>> notes that > >>>>> | multiple key purposes are possible. I believe that it is also > >>>>> possible to > >>>>> | have single roles - so a node could be a proxy but not a router. > >>>>> > >>>>> Yes, of course single roles are supported. > >>>>> > >>>>> | With the extensions of the csi-send-cert draft, possession of a > >>>>> | certificate is no longer proof of any particular authorization. > >>>>> It seem > >>>>> | clear to me that the authorization validation described in > >>>>> RFC3971 is no > >>>>> | longer sufficient. I believe that a discussion is needed of > >>>>> what messages > >>>>> | require or allow each particular key purpose authorization. > >>>>> Issuing an > >>>>> | RA, for example, seems likely to require the "router" value of > >>>>> the key > >>>>> | purpose field, if the new certificate format was used for > >>>>> authorization. > >>>>> | Issuing an NA may require the "owner" value of the key purpose > >>>>> field, if > >>>>> | the new certificate format was used for authorization rather > >>>>> than a CGA. > >>>>> | I do not know if that discussion would be more appropriate here > >>>>> or in the > >>>>> | csi-send-cert draft, or another draft entirely that updates RFC3971 > >>>>> | directly. > >>>>> | > >>>>> | If a SPND proxy was using SEND to communicate with other nodes that > >>>>> | understood SPND, would it be OK to use a new format cert (with the > >>>>> | "router" KeyPurposeId) as a router certificate for the SEND RSA > >>>>> Signature > >>>>> | Options? > >>>>> | > >>>>> I see. I agree that this needs more precision. > >>>>> > >>>>> 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)" > >>>>> (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) > >>>>> - "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) > >>>>> > >>>>> 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). > >>>>> 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 mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > > >
- [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