< draft-wkumari-dhc-capport-06.txt		draft-wkumari-dhc-capport-07.txt >
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Informational O. Gudmundsson		Intended status: Informational O. Gudmundsson
	Expires: June 5, 2015 Shinkuro Inc.		Expires: June 25, 2015 Shinkuro Inc.
	P. Ebersman		P. Ebersman
	Comcast		Comcast
	S. Sheng		S. Sheng
	ICANN		ICANN
	December 2, 2014		December 22, 2014
	Captive-Portal identification in DHCP / RA		Captive-Portal identification in DHCP / RA
	draft-wkumari-dhc-capport-06		draft-wkumari-dhc-capport-07
	Abstract		Abstract
	In many environments (such as hotels, coffee shops and other		In many environments (such as hotels, coffee shops and other
	establishments that offer Internet service to customers), it is		establishments that offer Internet service to customers), it is
	common to start new connections in a captive portal mode, i.e. highly		common to start new connections in a captive portal mode, i.e. highly
	restrict what the customer can do until the customer has accepted		restrict what the customer can do until the customer has accepted
	terms of service, provided payment information and / or		terms of service, provided payment information and / or
	authenticated.		authenticated.
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 5, 2015.		This Internet-Draft will expire on June 25, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 4		2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 4
	2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4		2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4
	2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 5		2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 5
	3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 5		3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 5
	4. The Captive-Portal RA Option . . . . . . . . . . . . . . . . 6		4. The Captive-Portal RA Option . . . . . . . . . . . . . . . . 6
	5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 6		5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	9. Normative References . . . . . . . . . . . . . . . . . . . . 9		9. Normative References . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	In many environments, users need to connect to a captive portal		In many environments, users need to connect to a captive portal
	device and agree to an acceptable use policy and / or provide billing		device and agree to an acceptable use policy and / or provide billing
	information before they can access the Internet.		information before they can access the Internet.
	In order to present the user with the captive portal web page, many		In order to present the user with the captive portal web page, many
	devices perform DNS and / or HTTP and / or IP hijacks. In addition		devices perform DNS and / or HTTP and / or IP hijacks. In addition
	to being kludgy hacks, these techniques resemble attacks that DNSSEC		to being kludgy hacks, these techniques resemble attacks that DNSSEC
	and TLS are intended to protect against. In an attempt to discourage		and TLS are intended to protect against. In an attempt to discourage
	the deliberate subversion of basic security tools, this document		the deliberate subversion of basic security tools, this document
	describes a DHCP option (Captive-Portal) and an IPv6 Router		describes a DHCP option (Captive-Portal) and an IPv6 Router
	Advertisement (RA) extension that informs clients that they are		Advertisement (RA) extension that informs clients that they are
	behind a captive portal device, and how to contact it.		behind a captive portal device, and how to contact it.
	document describes a DHCP option (Captive-Portal) and an IPv6 Router		This document neither condones nor condemns the use of captive
	Advertisement (RA) extension that informs clients that they are		portals; instead, it recognises that their apparent necessity, and
	behind a captive portal device, and how to contact it.		attempts to improve the user experience.
	This document neither condones nor condemns the use captive portals;
	instead, it recognises that their apparent necessity, and attempts to
	improve the user experience.
	The technique described in this document mainly improve the user		The technique described in this document mainly improve the user
	experience when first connecting to a network behind a captive		experience when first connecting to a network behind a captive
	portal. It may also help if the captive portal access times out		portal. It may also help if the captive portal access times out
	after connecting, but this is less reliable.		after connecting, but this is less reliable.
	1.1. Requirements notation		1.1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 32 ¶
	all DNS requests listing the address of its web portal. Once the		all DNS requests listing the address of its web portal. Once the
	user has authenticated the CP returns the "correct" addresses.		user has authenticated the CP returns the "correct" addresses.
	This technique has many shortcomings. It fails if the client is		This technique has many shortcomings. It fails if the client is
	performing DNSSEC validation, is running their own resolver, is using		performing DNSSEC validation, is running their own resolver, is using
	a VPN, or already has the DNS information cached.		a VPN, or already has the DNS information cached.
	2.2. HTTP Redirection		2.2. HTTP Redirection
	In this implementation, the CP acts like a transparent HTTP proxy;		In this implementation, the CP acts like a transparent HTTP proxy;
	but when it sees an HTTP request from an unauthenticated client, it		but when it sees an HTTP request from an unauthenticated client using
	intercepts the request and responds with an HTTP status code 302 to		HTTP/1.0, it intercepts the request and responds with an HTTP status
	redirect the client to the Captive Portal Login.		code 302 to redirect the client to the Captive Portal Login. If the
			client is using HTTP/1.1, we respond with a status code 303 See
			Other.
	This technique has a number of issues, including:		This technique has a number of issues, including:
	o It fails if the user is only using HTTPS.		o It fails if the user is only using HTTPS.
	o It exposes various private user information, such as HTTP Cookies,		o It exposes various private user information, such as HTTP Cookies,
	etc.		etc.
	o It doesn't work if the client has a VPN and / or proxies their web		o It doesn't work if the client has a VPN and / or proxies their web
	traffic to an external web proxy.		traffic to an external web proxy.
	skipping to change at page 5, line 47 ¶		skipping to change at page 5, line 47 ¶
	connect to.		connect to.
	The URI MUST NOT contain a DNS name, in order to not require the CP		The URI MUST NOT contain a DNS name, in order to not require the CP
	to access DNS queries from an unauthenticated user. Rather, if IPv4		to access DNS queries from an unauthenticated user. Rather, if IPv4
	is supported in the network, one option's URI MUST contain an IPv4		is supported in the network, one option's URI MUST contain an IPv4
	address literal, and if IPv6 is supported in the network, one		address literal, and if IPv6 is supported in the network, one
	option's URI MUST contain an IPv6 address literal. Note that this		option's URI MUST contain an IPv6 address literal. Note that this
	implies that a dual stack network would include two such options in		implies that a dual stack network would include two such options in
	its DHCP reply or RA.		its DHCP reply or RA.
			In many cases, a CP would like to collect billing infomation (for
			example, credit card information), and will want to do this over SSL/
			TLS. In order to make this work, the web server on the IP literal
			can redirect to a URI containing a DNS name. The CP implementor/
			operator will need to ensure that the client machine can access this
			URI and all service needed to make that work (for example, DNS,
			etc.). In this case, the operator/implementor will potentially need
			to deal with issues such as DNS tunnelling.
			Captive Portals are free to serve a HTTP redirect on this address to
			a DNS name (for example, so they can provide a TLS protected web page
			for credit card information). This will require that the client be
			able to perform DNS requests.
	[ED NOTE: Using an address literal is less than ideal, but better		[ED NOTE: Using an address literal is less than ideal, but better
	than the alternatives. Recommending a DNS name means that the CP		than the alternatives. Recommending a DNS name means that the CP
	would need to allow DNS from unauthenticated clients (as we don't		would need to allow DNS from unauthenticated clients (as we don't
	want to force users to use the CP's provided DNS) and some users		want to force users to use the CP's provided DNS) and some users
	would use this to DNS Tunnel out. This would make the CP admin block		would use this to DNS Tunnel out. This would make the CP admin block
	external recursives).]		external recursives).]
	4. The Captive-Portal RA Option		4. The Captive-Portal RA Option
	[Ed: I'm far from an RA expert. I think there are only 8 bits for		[Ed: I'm far from an RA expert. I think there are only 8 bits for
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 27 ¶
	vendors. This document provides a very high level example of what		vendors. This document provides a very high level example of what
	could be done with this information.		could be done with this information.
	Many operating systems / applications already include a "connectivity		Many operating systems / applications already include a "connectivity
	test" to determine if they are behind a captive portal (for example,		test" to determine if they are behind a captive portal (for example,
	attempting to fetch a specific URL and looking for a specific string		attempting to fetch a specific URL and looking for a specific string
	(such as "Success")). These tests sometimes fail or take a long time		(such as "Success")). These tests sometimes fail or take a long time
	to determine when they are behind a CP, but are usually effective for		to determine when they are behind a CP, but are usually effective for
	determining that the captive portal has been satisfied. These tests		determining that the captive portal has been satisfied. These tests
	will continue to be needed, because there is currently no definitive		will continue to be needed, because there is currently no definitive
	signal from the captive portal that it has been satisfied. The		signal from the captive portal that it has been satisfied. [ Editor
			note: It may be useful to write another document that specifies how a
			client can determine that it has passed the CP. This document could
			also contain advice to implmentors on only intercepting actually
			needed ports, how to advertise that the CP needs to be statisfied
			*again*, etc. This should not be done in this document though. ] The
	connectivity test may also need to be used if the captive portal		connectivity test may also need to be used if the captive portal
	times out the user session and needs the user to re-authenticate /		times out the user session and needs the user to re-authenticate /
	pay again. The operating system may still find the information about		pay again. The operating system may still find the information about
	the captive portal URI useful in this case.		the captive portal URI useful in this case.
	When the device is informed that it is behind a captive portal it		When the device is informed that it is behind a captive portal it
	SHOULD:		SHOULD:
	1. Not initiate new IP connections until the CP has been satisfied		1. Not initiate new IP connections until the CP has been satisfied
	(other than those to the captive portal page and connectivity		(other than those to the captive portal browser session and
	checks). Existing connections should be quiesced (this will		connectivity checks). Existing connections should be quiesced
	happen more often than some expect -- for example, the user		(this will happen more often than some expect -- for example, the
	purchases 1 hour of Internet at a cafe and stays there for 3		user purchases 1 hour of Internet at a cafe and stays there for 3
	hours -- this will "interrupt" the user a few times).		hours -- this will "interrupt" the user a few times).
	2. Present a dialog box to the user informing them that they are		2. Present a dialog box to the user informing them that they are
	behind a captive portal and ask if they wish to proceed.		behind a captive portal and ask if they wish to proceed.
	3. If the user elects to proceed, the device should initiate a		3. If the user elects to proceed, the device should initiate a
	connection to the captive portal login page using a web browser		connection to the captive portal login page using a web browser
	configured with a separate cookie store, and without a proxy		configured with a separate cookie store, and without a proxy
	server. If there is a VPN in place, this connection should be		server. If there is a VPN in place, this connection should be
	made outside of the VPN and the user should be informed that		made outside of the VPN and the user should be informed that
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 31 ¶
	continue until the network changes, or a new DHCP message without		continue until the network changes, or a new DHCP message without
	the CP is received.		the CP is received.
	6. IANA Considerations		6. IANA Considerations
	This document defines DHCPv4 Captive-Portal option which requires		This document defines DHCPv4 Captive-Portal option which requires
	assignment of DHCPv4 option code TBA1 assigned from "Bootp and DHCP		assignment of DHCPv4 option code TBA1 assigned from "Bootp and DHCP
	options" registry (http://www.iana.org/assignments/ bootp-dhcp-		options" registry (http://www.iana.org/assignments/ bootp-dhcp-
	parameters/bootp-dhcp-parameters.xml), as specified in [RFC2939].		parameters/bootp-dhcp-parameters.xml), as specified in [RFC2939].
	The IANA is also requested at assign an IPv6 RA Type code (TBA3) from		IANA is also requested to assign an IPv6 RA Option Type code (TBA3)
	the [TODO] registry. Thanks IANA!		from the "IPv6 Neighbor Discovery Option Formats" registry. Thanks
			IANA!
	7. Security Considerations		7. Security Considerations
	An attacker with the ability to inject DHCP messages could include		An attacker with the ability to inject DHCP messages could include
	this option and so force users to contact an address of his choosing.		this option and so force users to contact an address of his choosing.
	As an attacker with this capability could simply list himself as the		As an attacker with this capability could simply list himself as the
	default gateway (and so intercept all the victim's traffic), this		default gateway (and so intercept all the victim's traffic), this
	does not provide them with significantly more capabilities. Fake		does not provide them with significantly more capabilities. Fake
	DHCP servers / fake RAs are currently a security concern - this		DHCP servers / fake RAs are currently a security concern - this
	doesn't make them any better or worse.		doesn't make them any better or worse.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 25 ¶
	The primary author has discussed this idea with a number of folk, and		The primary author has discussed this idea with a number of folk, and
	asked them to assist by becoming co-authors. Unfortunately he has		asked them to assist by becoming co-authors. Unfortunately he has
	forgotten who many of them were; if you were one of them, I		forgotten who many of them were; if you were one of them, I
	apologize.		apologize.
	Thanks to Vint Cerf for the initial idea / asking me to write this.		Thanks to Vint Cerf for the initial idea / asking me to write this.
	Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo		Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo
	and Erik for the V6 RA kick in the pants.		and Erik for the V6 RA kick in the pants.
	Thanks for Fred Baker for detailed review and comments. Also great		Thanks to Fred Baker and Asbjorn Tonnesen for detailed review and
	thanks to Joel Jaeggli for providing feedback and text.		comments. Also great thanks to Joel Jaeggli for providing feedback
			and text.
	9. Normative References		9. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Appendix A. Changes / Author Notes.		Appendix A. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
			From 06 to 07:
			o Incoroprated a bunch of comments from Asbjorn Tonnesen
			o Clarified that this document is only for the DHCP bits, not
			everything.
			o CP's *can* do HTTP redirects to DNS banes, as long as they allow
			access to all needed services.
	From 05 to 06:		From 05 to 06:
	o Integrated comments from Joel, as below		o Integrated comments from Joel, as below
	o Better introduction text, around the "kludgy hacks" section.		o Better introduction text, around the "kludgy hacks" section.
	o Better "neither condones nor condems" text		o Better "neither condones nor condems" text
	o Fingerprint text.		o Fingerprint text.
End of changes. 15 change blocks.
	26 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/