Last Call Review of draft-ietf-csi-proxy-send-
review-ietf-csi-proxy-send-secdir-lc-murphy-2010-07-11-00

Request Review of draft-ietf-csi-proxy-send
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-07-13
Requested 2010-06-09
Authors Marco Bonola, Suresh Krishnan, Alberto Garcia-Martinez, Julien Laganier
Draft last updated 2010-07-11
Completed reviews Secdir Last Call review of -?? by Sandra Murphy
Assignment Reviewer Sandra Murphy
State Completed
Review review-ietf-csi-proxy-send-secdir-lc-murphy-2010-07-11
Review completed: 2010-07-11

Review
review-ietf-csi-proxy-send-secdir-lc-murphy-2010-07-11

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.






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?






This draft validates the use of its new PS option against a proxy 


KeyPurposeId in the certificate.  However, I could not find that it 


validates the prefixes in the proxied messages against the prefixes 


mentioned in the certificate.  Surely it should.  RFC3971 requires that 


the prefixes in a PI option match the router cert prefixes, but Im not 


sure that carries through to the proxied messages or those (like NA) that 


refer to an address and have no PI option.






I was curious as to the topological scenarios possible with proxies. 


RFC4861 notes that multiple proxies might respond on a single link, 


draft-csi-sndp-prob-04.txt discusses proxies that are nested, RFC4389 says 


that a proxy never receives RAs from other proxies (which restricts 


topologies), and this draft mentions proxying messages that already 


contain a PS option.  In Sec 5.2.2 of this draft, steps 6 and 7 of the 


rules for receivers of the Proxy Signature option imply that there might 


be multiple proxies on a link as well as proxy responses colliding with 


direct responses.  While there is a discussion of scenarios for proxying 


ND messages, they are not discussions of topologies of the proxies 


themselves.  I believe that I would have benefited from an explanation of 


the topology envisioned here.






Each SPND proxy must be able to distinguish secure nodes (RFC3971 or SPND 


nodes) from insecure nodes (non-SEND) on the link for which it serves as 


proxy.  It decides whether to securely proxy ND messages received from 


those nodes based on that info.  Is there any thought as to how the SPND 


proxy would know this?  If this is manual configuration, that could be a 


lot of work or impossible depending on the scenario.  And if there are 


multiple proxies on the link in some topologies, they must be consistent.






I was curious as to whether unsigned ND messages could be proxied securely 


by a SPND node.  Section 5.2.1 p 10 says the PS option MUST be added, 


which satisfied me, but then Section 7.2 p 20 says there are cases where 


the PS option MUST NOT be added.  If thats a contradiction, it needs to 


be addressed.






The text seems to make a distinction between "locally generated"/"issued" 


messages for a proxied address and "forwarding" or "translating" a message 


from a proxied address.  I was never certain what cases might cause the 


local generation of an address.  RFC4389 seem to me to refer only to the 


forwarding of messages.  Perhaps the "local generate" term refers to the 


scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the term 


refers to some of the exchanges in RFC4389 proxying.  Im not sure.






After reading this, I was not sure that I had an adequate idea of the 


error processing when different information has the potential to conflict. 


I was particularly interested in the RA message. RFC4389 introduces a "P" 


bit for the RA messages to indicate a proxied message.  This draft 


introduces a PS option to secure proxied messages.  The new cert format 


has a "proxy" value for the KeyPurposeId.  I tried to work out the 


combinations:




P bit   PS opt   cert:"proxy" action
  0       no         no       no proxy needed (can use 3791)
  0       no         yes      no proxy needed (can use 3971)
  0       yes        no       silent discard of message
  0       yes        yes      weird but OK?
  1       no         no       "unsecured", even if 3971 signed?
                              cert says not a proxy, so drop?
  1       no         yes      "unsecured", even if 3971 signed?
                              If 3971 signed, check 3971 cert
                              prefixes or new cert prefixes?
  1       yes        no       silent discard of message
  1       yes        yes      secure proxy  all OK



As acknowledged in the Section 7.1, a RFC3971 message from a RFC3971 node 


to another RFC3971 node proxied through a SPND proxy appears unsecured to 


the receiver.  Thats no worse than proxying the message through a RFC3971 


proxy, so no harm done, for most messages.  For Router Solicitation 


messages, which according to RFC3489 dont get altered and can retain 


their signatures, the outcome is worse. I think.




Detailed comments:

Sec 4, p 6:

      Proxy ND's certificate.  When a ND message contains a PS option,
      it MUST NOT contain CGA and RSA Signature options.  This option
      can be appended to any ND message: NA, NS, RS, RA and Redirect.



Is that a "MAY" be appended?  Page 10 says "MUST" be added, but section 


7.2 p 20 talks of cases where it MUST NOT be added.




   o  A modification of the SEND processing rules for all ND messages:
      NA, NS, RS, RA, and Redirect.



This draft and RFC4389 do not mention  if the proxied message is a NA, 


and the proxy is a router, does the router bit get set?




Sec 5.2.1 p 10

5.2.1.  Processing rules for senders

   A ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST
   contain a PS option and MUST NOT contain either CGA or RSA Signature
   options.

Note contradiction in section 7.2 p 20.

Sec 5.2.1 p 11

       C.  If the Secure ND Proxy is forwarding a SEND message already
           containing a PS option, first the authenticity of the
           intercepted message is verified as specified in Section 5.2.2
           of this specification.  If the SEND message is valid, the
           original PS option MUST be removed from the message.  The
           intercepted message is finally modified as described in
           Section 4 of the ND Proxy specification [RFC4389].



Does this disagree with the RFC4389 statement that RA messages can not be 


received from other proxies?  That is, if an RA message P bit is set (and 


if it contains a PS option, one hopes the P bit is set), RFC4389 sec 


4.1.3.3 says the interface must not be used as a proxy interface.




   2.  Timestamp and Nonce options MUST be included according to the
       rules specified in SEND [RFC3971].  The value in the Timestamp
       option MUST be generated by the proxy.  If the proxy is
       forwarding a message, the Nonce value in the proxied message MUST
       be the same as in the forwarded message, otherwise it is
       generated by the proxy.



What is the "otherwise" here?  If the proxy is *not* forwarding, which 


might be if it is "locally generating" a message?  If the Nonce is not 


present in the forwarded messages?





Sec 6.2 p 16



This scenario seems to be using the SPND feature because the MAG is using 


a source address that does not really belong to it.  It is not forwarding 


any ND messages.  So perhaps this is the case where the "locally 


generated" terminology applies.




   To provide SEND protection, each MAG is configured to act as a proxy
   by means of a certificate associated to the PMIPv6 domain,
   authorizing each MAG to proxy securely ND messages.  In addition, the
   certificate must also authorize the MAG to advertise prefixes.  Note
   that the inclusion of multiple KeyPurposeId values is supported by
   [I-D.ietf-csi-send-cert].



I believe that means that the new cert format must show both the router 


and the proxy KeyPurposeID values because it is generating a RA.  But no 


such check is mentioned anywhere.




Sec 6.2 p 16

   A node receiving a message from the MAG containing the PS option MUST
   apply the rules defined in Section 5.2.2.  Note that unsolicited
   messages sent by MAG are validated by the host according to timestamp
   values specific to the MAG serving the link, not to any other MAG to
   which the host has been connected before in other links.



The host does not see any difference in the MAG, since the MAG is using 


the same source IP address as all other MAGs to which the host has been 


connected.  According to my reading of RFC3971, that means that theres a 


chance that unsolicited messages from the MAG would appear stale  as long 


as the unsolicited message was received before a solicited advertisement. 


Receipt of a solicited advertisement should update the timestamp at the 


host, based on the nonce matching, by RFC3971 rules




Sec 6.3 p 17/18

   A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy
   interface to check whether it contains one of the following secured
   ICMPv6 messages: NS, NA, RA, or Redirect.



This seems to disagree with Section 5.2.1, p 10, which says the PS option 


is added to *all* messages.  However, it does agree with the discussion in 


section 7.2 p 19/20, which says that the PS option is only generated on 


behalf of RFC3917 nodes and SPND nodes.




Section 7.1 p 19

   In the scenarios in which the proxy translates ND messages, the
   messages to translate can either be originated in a RFC3971 node or
   in an SPND node, without interoperability issues.



The discussion immediately above this text says that RFC3971 nodes drop a 


PS option in a proxied message and treat the message as unsecured, so I am 


not sure what this is talking about.  A secure proxied NA reply, for 


example, would appear unsecured to the RFC3971 host and secure to the SPND 


proxied host. Is "translates" an ND message different from 


"forwards"/"proxies" an ND message  i.e., the PS option is not applied?





sec 7.2 p 20

   Therefore, the Secure ND Proxy MUST generate messages containing the
   PS option for SPND and RFC3971 hosts, and MUST NOT generate messages
   containing the PS option for non-SEND nodes.



This (and other places in the subsequent paragraphs) seems to contradict 


sec 5.2.1 p 10 which says the PS option is a MUST, period.






What does the "for SPND and RFC3971 hosts" and the "for non-SEND hosts" 


mean?  I believe that it means that the proxy is forwarding messages on 


their behalf.  The use of the term "generate" here doesnt seem to mean 


the same as "locally generated" elsewhere.






I am not sure how the SPND would know which of the nodes on the proxy 


interface were non-SEND, RFC3917, or SPND nodes.  But if it can be 


configured with that information, could it also be configured to know the 


status of nodes on the outgoing interface?  It might then detect that 


doing the computation to add the PS option was a waste of effort because 


there were no SPND nodes on that side.






If the RFC3971 node produces a solicitation that needs to be forwarded 


through the SPND proxy, and the SPND proxy forwards the advertisement it 


received in reply along with the PS option, the RFC3971 will drop the PS 


option.  True?  Should the SPND still produce the (wasted) signature?




Sec 7.2 page 20

  o  For translating ND messages for nodes that can arrive to the link
      in which the proxy operates,

   o  For synthesizing ND messages on behalf of remote nodes,



I think "translating" here means forwarding through the proxy and doing 


the RFC4389 changes, while "synthesizing ND messages" means the mobile 


node scenarios where no message is received for forwarding but one is 


created (PMIPv6 and MIPv6?).






An explanation of this difference and a consistent set of terms would have 


helped a lot.




   o  For translating ND messages for nodes that can arrive to the link
      in which the proxy operates, the rule can be easily applied: only
      messages validated in the Secure ND Proxy according to the SEND
      specification [RFC3971] MUST be proxied securely by the inclusion
      of a PS option.  Unsecured ND messages could be proxied if
      unsecured operation is enabled in the proxy, but the message
      generated by the Secure ND Proxy for the received message MUST NOT
      include a PS option.



Is it possible for a proxy to receive a message with a PS option? 


Previous text (sec 5.2.1 part C) seems to indicate so.  If the "MUST be 


proxied securely" applies to SPND protected messages as well as RFC3971 


protected messages, then this case is the same as the previous paragraph 


"MUST generate messages containing the PS option for SPND and RFC3971 


hosts . . .".  Unless this is a difference between translating messages 


and generating messages, of course.




Sec 8 p 22

            However, when two on-link hosts communicate using
   their respective link-local addresses, the threats involved with a
   compromised router and a compromised proxy ND differs because the
   router is not able to siphon off traffic exchanged between the hosts
   or mount a man-in-the-middle attack, while the proxy ND can, even if
   the hosts use SEND.



This should be explained in more detail.  I believe that the reason is 


that a SEND router would not be able to produce a NA reply to an NS that 


would be believed, but the SPND could pretend to be proxying a NA reply 


believably  as long as the recipient used SPND and could accept the PS 


option.




   Proper configuration of when the PS option must or must not be
   included, depending on the proxied nodes being SEND or non-SEND may
   result in security considerations which are discussed in Section 7.



This is pretty contorted.  I believe that this is trying to say that 


Section 7 discusses some of the security considerations resulting from the 


decision to append or omit PS protections depending on the SEND awareness 


of the proxied nodes.  But Im not sure.




   Attacks to the timestamp of the secured ND message can be performed
   as described in section 7.3 of [I-D.ietf-csi-sndp-prob].



I found that section of that draft to be particularly unclear.  And it is 


not normatively cited here.  Im not saying that it should be, but if that 


draft does not progress (giving opportunity to improve the discussion), 


the reader of this draft would be lost.  Is there any way to summarize the 


vulnerabilities so that the reader of this draft have some hint of what 


can go wrong and why?







NITS

Sec 5.2.2 p 12

       the IP of node for which the message is proxied.  In this way, a
       ^^^^^^^^^^^^^^
        the IP address of a node

       cached link-layer address created securily by means of RSA
                                         ^^^^^^^^
                                         securely

Sec 6.1 p 13-14

Sometimes the Home Address is abbreviated HoA and sometimes as HA

Sec 6.2 p 16

   link to which the MN is attached to, to be generated by the LMA when
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        to which the MN is attached,
   the MN first attach to a PMIPv6 domain,
                ^^^^^^
                attaches

sec 7.2 p 20

   options on behalf of nodes with SEND capabilities (i.e. that they
   could use SEND to defend their messages if being in the same link
                                              ^^^^^^^^
                                              present on
   than the proxy, either RFC3971 nodes or SPND nodes).
   ^^^^
   with <or "as">


sec 7.2 p 20

                                      Not using the PS option for a
         RFC3971 or SPND MN would make more vulnerable the address in
         the home link when the MN is away than when it is in the home
         link



This is a bit awkward.  I suggest moving the "more vulnerable" part" so 


that it reads:






Not using the PS option for a RFC3971 or SPND MN would make the address in 


the home link more vulnerable when the MN is away than when it is in the 


home link




Sec 8 p 22

   The security of proxied ND messages not including a PS option is the
   same of an unsecured ND message.  The security of a proxied ND
        ^^
        as
   message received by a non-SEND host or RFC3971 host is the same of an
                                                                   ^^
                                                                   as
   unsecured ND message.

Sec 8 p 22

   Attacks to the timestamp of the secured ND message can be performed
           ^^
           on.