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

[marcelo bagnulo braun <[e-mail]>]

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.

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
> [e-mail]										Switzerland
> Phone: [phone]									
>
> 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:[e-mail]]
>>>> |  Enviado el: viernes, 02 de julio de 2010 2:31
>>>> |  Para: [e-mail]; [e-mail]; [e-mail]
>>>> |  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
>>>>
>>>>