Subject: [Gen-art] Gen-ART and OPS-Dir review of draft-wkumari-dhc-capport-13

From: "Black, David" <[email-masked]>
Date: Sun, 5 Jul 2015 14:36:35 +0000

This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-wkumari-dhc-capport-13
Reviewer: David Black
Review Date: July 5, 2015
IETF LC End Date: July 7, 2015

Summary:  This draft is on the right track, but has open issues
 		described in the review.

This draft specifies DHCP (v4 and v6) and IPv6 RA options to provide the
contact URI of a captive portal (e.g., for a WiFi hotspot).  It's a
short draft that gets the job done - I found a few minor issues, and
have an additional security consideration to suggest.

Major issues: None

Minor issues:

[1] Section 2:

   captive portals will still need to implement the
   interception techniques to serve legacy clients, and clients will
   need to perform probing to detect captive portals.

Please explain what "the interception techniques" and "probing" are.
I think this material was in -12 and removed for -13 - it does not need
to be restored in its entirety, but those two terms deserve some
explanation.  This should also explain "DNS interception" in the last
paragraph in the section.

[2] Section 2.1 - DHCPv4 has the shortest URI length limit, 255 bytes.
That should be noted either here or in Section 2 in discussion of serving
multiple classes of clients.  This should not be a problem in practice.

[3] Sections 2.1, 2.2, 3: The term "URI of the authentication page" should
be changed to something like "contact URI for the captive portal" because
authentication is not always required by a captive portal.

[4] Section 4: The IANA Considerations section is incomplete - see IANA's
review.

[5] Section 5:

   Fake
   DHCP servers / fake RAs are currently a security concern - this
   doesn't make them any better or worse.

Please cite a reference for this, preferably with operational recommendations
on limiting these problems (e.g., ensure that DHCP and RA traffic cannot be
injected from outside/beyond the network that is relevant to the portal).

   Redirection to a portal where TLS can be used
   without hijacking can ameliorate some of the implications of
   connecting to a potentially malicious captive portal.

Please explain who or what does the redirection and what is redirected
(browser, VPN client?).  Is this a suggestion to use http:// URLs? (if
so, that should be said explicitly).

Nits/editorial comments:

p.3, first sentence:

   This document describe a DHCP ([RFC2131]) option (Captive Portal) and

s/describe/describes

I would add a sentence to section 2 to say that URI strings are not
null-terminated.

Section 3 - this should be renumbered to 2.3, as the overview text in
Section 2 applies to the RA option.

Possible additional security consideration:

Captive portals are increasingly hijacking TLS connections to force
browsers to talk to the portal.  Providing the portal's URI via a DHCP
or RA option is a cleaner technique, and reduces user expectations of
being hijacked - this may improve security by making users more reluctant
to accept TLS hijacking, which can be performed from beyond the network
associated with the captive portal.

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

Most of these questions reduce to the corresponding questions for DHCP
or IPv6 RAs.  Once the portal is contacted, there are significant
operational considerations that are well outside the scope of this
draft.

A.1.3  Has the migration path been discussed?

	Yes, briefly.  Minor issue [1] requests more information on
	existing techniques, with which coexistence is anticipated.

A.3.  Documentation

	An operational considerations or manageability section isn't
	called for.  I do not expect the options in this draft to
	have significant operational impact.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Jul 2015 08:50:08 -0700

Thank you David.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 11 Jul 2015 18:28:33 +0000

On Saturday, July 11, 2015 8:50 AM, joel jaeggli wrote

> ...
> Please cite a reference for this, preferably with operational 
> recommendations on limiting these problems (e.g., ensure that DHCP and 
> RA traffic cannot be injected from outside/beyond the network that is relevant to the portal).

There is definitely an attack vector there. Suppose an attacker can monitor the traffic, say on an unencrypted Wi-Fi hot spot. The attacker can see a DHCP request or INFORM, and race in a fake response with an URL of their own choosing. The mark's computer automatically connects there, and download some zero-day attack. Bingo!
 
 -- Christian Huitema

---

From: Warren Kumari <[email-masked]>
Date: Sat, 11 Jul 2015 16:13:28 -0400

On Saturday, July 11, 2015, Christian Huitema <[email-masked]> wrote:

> There is definitely an attack vector there. Suppose an attacker can
> monitor the traffic, say on an unencrypted Wi-Fi hot spot. The attacker can
> see a DHCP request or INFORM, and race in a fake response with an URL of
> their own choosing. The mark's computer automatically connects there, and
> download some zero-day attack. Bingo!
>
>
An attacker with this level of access can already do this. They fake a DHCP
response with themselves as the gateway and insert a 302 into any http
connection. Or, more likely they simply inject malicious code into some
connection.

Connecting to unknown/ unencrypted networks is inherently dangerous...

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Christian Huitema <[email-masked]>
Date: Sat, 11 Jul 2015 21:28:31 +0000

On Saturday, July 11, 2015 1:13 PM, Warren Kumari [mailto:[email-masked]] wrote
>> There is definitely an attack vector there. Suppose an attacker can monitor the traffic, say on an 
>> unencrypted Wi-Fi hot spot. The attacker can see a DHCP request or INFORM, and race in a fake 
>> response with an >> URL of their own choosing. The mark's computer automatically connects 
>> there, and download some zero-day attack. Bingo!
>
> An attacker with this level of access can already do this. They fake a DHCP response with themselves 
> as the gateway and insert a 302 into any http connection. Or, more likely they simply inject 
> malicious code into some connection. 
>

OK, you are probably correct that this is just one of the many attacks possible when connecting to insecure networks. Then, of course, there is the whole idea of letting an untrusted DHCP server direct one's browser to an arbitrary web page. Looks like an ideal setup for zero days and phishing tools. Ideally, we should only process the redirected page into a fairly tight sandbox...

-- Christian Huitema

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Jul 2015 11:44:42 -0400

>>>>> "Warren" == Warren Kumari <[email-masked]> writes:

    Warren>    On Saturday, July 11, 2015, Christian Huitema
    Warren> <[email-masked]>
    Warren>    wrote:

    Warren>      On Saturday, July 11, 2015 8:50 AM, joel jaeggli wrote
    >> ...  [5] Section 5:
    >> 
    >> Fake DHCP servers / fake RAs are currently a security concern -
    >> this doesn't make them any better or worse.
    >> 
    >> recommendations on limiting these problems (e.g., ensure that
    >> DHCP
    Warren>      and
    >> RA traffic cannot be injected from outside/beyond the network
    >> that
    Warren>      is relevant to the portal).  

>      There is definitely an
> attack vector there. Suppose an attacker can monitor the
> traffic, say on an unencrypted Wi-Fi hot spot. The attacker
> can see a DHCP request or INFORM, and race in a fake
> response with an URL of their own choosing. The mark's
> computer automatically connects there, and download some
> zero-day attack.  Bingo!

    Warren>    An attacker with this level of access can already do
    Warren> this. They fake a DHCP response with themselves as the
    Warren> gateway and insert a 302 into any http connection. Or, more
    Warren> likely they simply inject malicious code into some
    Warren> connection.

I'm with Christian.  The attack he describes--injecting a URI--is less
likely in my mind to be noticed than setting up a gateway.  So, I do
consider this a new vector.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Jul 2015 17:59:02 +0200

Okey dokey, I'm happy to add something.

Does anyone have any suggested text?

W

On Monday, July 13, 2015, Sam Hartman <[email-masked]> wrote:

> >>>>> "Warren" == Warren Kumari <[email-masked] <javascript:;>> writes:
>
>     Warren> <[email-masked] <javascript:;>>
>     Warren>    wrote:
>