< draft-wkumari-dhc-capport-13.txt   draft-wkumari-dhc-capport-14.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track O. Gudmundsson Intended status: Standards Track O. Gudmundsson
Expires: December 20, 2015 CloudFlare Expires: February 14, 2016 CloudFlare
P. Ebersman P. Ebersman
Comcast Comcast
S. Sheng S. Sheng
ICANN ICANN
June 18, 2015 August 13, 2015
Captive-Portal Identification in DHCP / RA Captive-Portal Identification in DHCP / RA
draft-wkumari-dhc-capport-13 draft-wkumari-dhc-capport-14
Abstract Abstract
In many environments offering short-term or temporary Internet access In many environments offering short-term or temporary Internet access
(such as coffee shops), it is common to start new connections in a (such as coffee shops), it is common to start new connections in a
captive portal mode. This highly restricts what the customer can do captive portal mode. This highly restricts what the customer can do
until the customer has authenticated. until the customer has authenticated.
This document describes a DHCP option (and a RA extension) to inform This document describes a DHCP option (and a RA extension) to inform
clients that they are behind some sort of captive portal device, and clients that they are behind some sort of captive portal device, and
that they will need to authenticate to get Internet Access. It is that they will need to authenticate to get Internet Access. It is
not a full solution to address all of the issues that clients may not a full solution to address all of the issues that clients may
have with captive portals; it is designed to be used in larger have with captive portals; it is designed to be used in larger
solutions. solutions. The method of authenticating to, and interacting with the
captive portal is out of scope of this document.
[ Ed note (remove): This document is being developed in github: [ Ed note (remove): This document is being developed in github:
https://github.com/wkumari/draft-wkumari-dhc-capport . ] https://github.com/wkumari/draft-wkumari-dhc-capport . ]
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 20, 2015. This Internet-Draft will expire on February 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 5, line 9 skipping to change at page 5, line 9
the Type and Length fields) in units of 8 bytes. the Type and Length fields) in units of 8 bytes.
URI The URI of the authentication page that the user should connect URI The URI of the authentication page that the user should connect
to. For the reasons described above, the implementer might want to. For the reasons described above, the implementer might want
to use an IP address literal instead of a DNS name. This should to use an IP address literal instead of a DNS name. This should
be padded with NULL (0x0) to make the total option length be padded with NULL (0x0) to make the total option length
(including the Type and Length fields) a multiple of 8 bytes. (including the Type and Length fields) a multiple of 8 bytes.
4. IANA Considerations 4. IANA Considerations
This document defines two DHCP Captive-Portal options, one for IPv6 This document defines two DHCP Captive-Portal options, one for IPv4
and one for IPv6. It requires assignment of an option code (TBA1) to and one for IPv6. It requires assignment of an option code (TBA1) to
be assigned from "Bootp and DHCP options" registry be assigned from "Bootp and DHCP options" registry
(http://www.iana.org/assignments/ bootp-dhcp-parameters/bootp-dhcp- (hhttp://www.iana.org/assignments/bootp-dhcp-parameters), as
parameters.xml), as specified in [RFC2939]. It also requires specified in [RFC2939]. It also requires assignment of an option
assignment of an option code (TBA2) from the "DHCPv6 and DHCPv6 code (TBA2) from the "DHCPv6 and DHCPv6 options" registry
options" registry (http://www.iana.org/assignments/dhcpv6-parameters/ (http://www.iana.org/assignments/dhcpv6-parameters).
dhcpv6-parameters.xml).
IANA is also requested to assign an IPv6 RA Option Type code (TBA3) IANA is also requested to assign an IPv6 RA Option Type code (TBA3)
from the "IPv6 Neighbor Discovery Option Formats" registry. Thanks from the "IPv6 Neighbor Discovery Option Formats" registry. Thanks
IANA! IANA!
5. Security Considerations 5. 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, but
DHCP servers / fake RAs are currently a security concern - this because this document removes the need for interception, the attacker
doesn't make them any better or worse. may have an easier time performing the attack. As the operating
systems and application that make use of this information know that
they are connecting to a captive portal device (as opposed to
intercepted connections) they can render the page in a sandboxed
environment and take other precautions, such as clearly labeling the
page as untrusted. The means of sandboxing and user interface
presenting this information is not covered in this document - by its
nature it is implementation specific and best left to the application
and user interface designers.
Devices and systems that automatically connect to an open network Devices and systems that automatically connect to an open network
could potentially be tracked using the techniques described in this could potentially be tracked using the techniques described in this
document (forcing the user to continually authenticate, or exposing document (forcing the user to continually authenticate, or exposing
their browser fingerprint). However, similar tracking can already be their browser fingerprint). However, similar tracking can already be
performed with the standard captive portal mechanisms, so this performed with the standard captive portal mechanisms, so this
technique does not give the attackers more capabilities. technique does not give the attackers more capabilities.
By simplifying the interaction with the captive portal systems, and By simplifying the interaction with the captive portal systems, and
doing away with the need for interception, we think that users will doing away with the need for interception, we think that users will
skipping to change at page 6, line 18 skipping to change at page 6, line 20
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 to Fred Baker, Paul Hoffman, Ted Lemon, Martin Nilsson, Ole Thanks to Fred Baker, Paul Hoffman, Ted Lemon, Martin Nilsson, Ole
Troan and Asbjorn Tonnesen for detailed review and comments. Also Troan and Asbjorn Tonnesen for detailed review and comments. Also
great thanks to Joel Jaeggli for providing feedback and text. great thanks to Joel Jaeggli for providing feedback and text.
7. Normative References 7. 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, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options", S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, May 2014. BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<http://www.rfc-editor.org/info/rfc7227>.
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 13 to 14:
o Added a bunch of disclaimers explaining that this is not a
complete solution. We expect that the actual interaction bit
should be done in CAPPORT.
From 13.2 to 13(posted): From 13.2 to 13(posted):
o Shortened the document by removing most of the [Editors notes], o Shortened the document by removing most of the [Editors notes],
Section 2, Section 5 and Appendix A. They were mainly background Section 2, Section 5 and Appendix A. They were mainly background
and have served their purpose. This change suggested by Paul and have served their purpose. This change suggested by Paul
Hoffman. Hoffman.
From 13.1 to 13.2: From 13.1 to 13.2:
o Moved all of the "what an OS could do with this info" to an o Moved all of the "what an OS could do with this info" to an
 End of changes. 14 change blocks. 
21 lines changed or deleted 41 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/