[secdir] secdir review of draft-ietf-csi-proxy-send-04
Sandra Murphy <Sandra.Murphy@sparta.com> Fri, 02 July 2010 00:30 UTC
Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59523A659C; Thu, 1 Jul 2010 17:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.523
X-Spam-Level:
X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NieFJ1FUSJx; Thu, 1 Jul 2010 17:30:45 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DEE013A6837; Thu, 1 Jul 2010 17:30:44 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o620Um8Z031423; Thu, 1 Jul 2010 19:30:49 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o620Um1I008913; Thu, 1 Jul 2010 19:30:48 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 20:30:47 -0400
Date: Thu, 01 Jul 2010 20:30:45 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-csi-proxy-send.all@tools.ietf.org
Message-ID: <Pine.WNT.4.64.1007011933360.9620@SMURPHY-LT.columbia.ads.sparta.com>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1382430996-12988-1278029505=:9620"
X-OriginalArrivalTime: 02 Jul 2010 00:30:47.0855 (UTC) FILETIME=[D104CBF0:01CB197D]
Subject: [secdir] secdir review of draft-ietf-csi-proxy-send-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jul 2010 00:30:48 -0000
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.
- [secdir] secdir review of draft-ietf-csi-proxy-se… Sandra Murphy
- Re: [secdir] secdir review of draft-ietf-csi-prox… Alberto García
- Re: [secdir] (MAIN) secdir review of draft-ietf-c… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Sandra Murphy
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… Ralph Droms
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano
- Re: [secdir] secdir review of draft-ietf-csi-prox… marcelo bagnulo braun
- Re: [secdir] secdir review of draft-ietf-csi-prox… Sean Turner
- Re: [secdir] secdir review of draft-ietf-csi-prox… Murphy, Sandra
- Re: [secdir] secdir review of draft-ietf-csi-prox… Jeffrey Hutzelman
- Re: [secdir] (MAIN) secdir review of draft-ietf-c… Alberto García
- Re: [secdir] secdir review of draft-ietf-csi-prox… Roque Gagliano