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
> >
> 
>