Re: [secdir] Secdir review of draft-ietf-pcp-upnp-igd-interworking-07

[<[e-mail]>]

Dear Vincent,

Thank you for the review.

Please see inline.
Cheers,
Med

De : Vincent Roca [mailto:[e-mail]]
Envoyé : jeudi 25 avril 2013 11:01
À : IESG; [e-mail]; [e-mail]
Cc : Vincent Roca
Objet : Secdir review of draft-ietf-pcp-upnp-igd-interworking-07

Hello,

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.

--

1- Authors refer to [IGD2] (which is produced by UPnP), saying that the authorization framework
defined there SHOULD be used. However I haven't found the description of such a framework
in [IGD2] (I've looked at the Content Table and searched "Authorization" keyword). Can you be
more explicit in your reference?


[Med] This basically refers to access and authorization levels discussed in [IGD2]. Perhaps, "Framework" is confusing here. What about tis change:



OLD:

 "The IGD:2 authorization framework SHOULD be used [IGD2<http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-08#ref-IGD2>]."



NEW:

"The IGD:2 access and authorization considerations discussed in [IGD2<http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-08#ref-IGD2>] SHOULD be taken into account."

Additionally  [IGD2] says (p.10):
        "IGD 2 introduces access control features. [IGD2] RECOMMENDS access control requirements
        and authorization levels to be applied by default. However, devices MAY choose a different
        security policy,"
I do not understand the consequences of devices choosing a different security policy, and how it
relates to your I-D.

then, same page:
        "In the 2-box model, where the control point is in the same device that desires to receive
        communication through the NAT, [IGD2] RECOMMENDS that access control is not needed. But in
        the 3-box model, where the control point is configuring NAT port mappings for a third device,
        [IGD2] RECOMMENDS that authentication and authorization is used."
It's not clear to me in which case of [IGD2] your I-D corresponds to.
[Med] Both cases are covered for IGD:2. For the IGD:1 case, only the 3-box model is recommended:


"When only

   IGD:1 is available, operation on the behalf of a third party SHOULD

   NOT be allowed.
"

2- It is said:
"Means to prevent a malicious user from creating mappings on behalf of a third party must be enabled
as discussed in Section 13.1 of [I-D.ietf-pcp-base]."
What are the means mentioned? If I look at 13.1 of this reference, I see that the THIRD_PARTY option
"MUST NOT be implemented or used" unless the network is trusted, and the example of trusted network
is the case where there's an ACL on PCP client/PCP server/network.
Can you be more explicit in your recommendations?
[Med] I made the following change :

OLD:

   This document defines a procedure to create PCP mappings for third

   party devices belonging to the same subscriber.  Means to prevent a

   malicious user from creating mappings on behalf of a third party must

   be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base<http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-08#ref-I-D.ietf-pcp-base>].

NEW:

   This document defines a procedure to create PCP mappings for third
   party devices belonging to the same subscriber.  Means to prevent a
   malicious user from creating mappings on behalf of a third party must
   be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base].  In
   particular, THIRD_PARTY option MUST NOT be enabled unless the network
   on which the PCP messages are to be sent is fully trusted.  For
   example if access control lists are installed on the PCP client, PCP
   server, and the network between them, so those ACLs allow only
   communications from a trusted PCP client to the PCP server.

Better?


3- You reference [Sec-DCP] but do not provide the URL, nor version number. Since this is an external
document, it would be great.
Also, the one I found (http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf
accessible from page http://upnp.org/specs/gw/deviceprotection1/) is from Feb. 2011, not 2009.

[Med] Fixed. Thanks.

4- I don't see any threat model in this Security Discussions section.
There's good one in [I-D.ietf-pcp-base], but this is a different protocol, deployed differently.
What can we say for the IWF itself?
[Med] This document does not define a new protocol. [I-D.ietf-pcp-base] discusses security considerations without any assumption on how PCP messages are triggered: user interface, application, etc. This document focuses on the particular case where PCP messages are triggered by IGD ones. As such this document does not change the threat model discussed in the base PCP specification. For the UPnP IGD leg, we provided some security recommendations defined by the UPnP Forum.

There are some elements in this section, some pointers, but I don't get any clear idea of the
situation.

--

Otherwise, regardless of any security consideration:

5- Fig. 1 mentions UPnP control point. Other figures of Section 3 mention IGD control point.
Is it the same? If yes, can you harmonize?
[Med] Fixed. Only 'IGD Control Point' is used now.

This figure also remains somewhat mysterious to me. Can you add some more text at the end of
the first paragraph of Introduction. And why does this figure appear after the "two configurations"
discussion?
[Med] The figure is now positioned just after the first paragraph.

6- Introduction: you mention that two configurations are possible. Do you consider both of them?
What are the consequences of these two configurations on IWF?
[Med] Both configurations are in scope. I made the following change to make this explicit:

OLD:



   Two configurations are considered:



   o  No NAT function is embedded in the IGD.  This is required for

      instance in DS-Lite or NAT64 deployments;

   o  The IGD embeds a NAT function.

NEW:

   Two configurations are considered within this document:

   o  No NAT function is embedded in the IGD (Section 5.4).  This is
      required for instance in DS-Lite or NAT64 deployments;
   o  The IGD embeds a NAT function (Section 5.5).

As such, reading this introduction did not help me so much understanding the proposal. Section 3
is much better from that point of view.

Cheers,

  Vincent