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

[Sandra Murphy <[e-mail]>]

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 I’m 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 that’s 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.  I’m 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.  That’s 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 don’t 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 there’s 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 doesn’t 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 I’m 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.  I’m 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.