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

[Sandra Murphy <[e-mail]>]

Thank you.  I was debating whether a message about message authorization 
vs cert authorization values was more appropriately directed to the csi 
group or the send-cert authors.  This spares me the trouble of trying to 
make up my mind.  :-)

I think this should prove to be an interesting discussion.

--Sandy


On Tue, 6 Jul 2010, 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
>
>
>
>
>
>