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

["Murphy, Sandra" <[e-mail]>]

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:[e-mail]]
Sent: Tue 9/14/2010 11:12 AM
To: marcelo bagnulo braun
Cc: Roque Gagliano; [e-mail]; [e-mail]; Murphy, Sandra; García; [e-mail]; "Alberto "@core3.amsl.com; Ralph Droms; [e-mail]; 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 
<[e-mail]> (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
>> [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
>>>>>
>>>>>
> 
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
>