Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04

From: Roque Gagliano <[email-masked]>
Date: Thu, 7 Oct 2010 12:57:52 +0200

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:[email-masked]]
> Sent: Tue 9/14/2010 11:12 AM
> To: marcelo bagnulo braun
> Cc: Roque Gagliano; [email-masked]; [email-masked]; Murphy, Sandra; García; [email-masked]; "Alberto "@core3.amsl.com; Ralph Droms; [email-masked]; 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
> <[email-masked]> (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
> >> [email-masked]                                        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:[email-masked]]
> >>>>> |  Enviado el: viernes, 02 de julio de 2010 2:31
> >>>>> |  Para: [email-masked]; [email-masked];
> >>>>> [email-masked]
> >>>>> |  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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/secdir
> >
> 
>