< draft-schulzrinne-ecrit-unauthenticated-access-07.txt		draft-schulzrinne-ecrit-unauthenticated-access-08.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track S. McCann		Intended status: Standards Track S. McCann
	Expires: September 8, 2010 Research in Motion UK Ltd		Expires: January 12, 2011 Research in Motion UK Ltd
	G. Bajko		G. Bajko
	Nokia		Nokia
	H. Tschofenig		H. Tschofenig
	D. Kroeselberg		D. Kroeselberg
	Nokia Siemens Networks		Nokia Siemens Networks
	March 7, 2010		July 11, 2010
	Extensions to the Emergency Services Architecture for dealing with		Extensions to the Emergency Services Architecture for dealing with
	Unauthenticated and Unauthorized Devices		Unauthenticated and Unauthorized Devices
	draft-schulzrinne-ecrit-unauthenticated-access-07.txt		draft-schulzrinne-ecrit-unauthenticated-access-08.txt
	Abstract		Abstract
	The IETF emergency services architecture assumes that the calling		The IETF emergency services architecture assumes that the calling
	device has acquired rights to use the access network or that no		device has acquired rights to use the access network or that no
	authentication is required for the access network, such as for public		authentication is required for the access network, such as for public
	wireless access points. Subsequent protocol interactions, such as		wireless access points. Subsequent protocol interactions, such as
	obtaining location information, learning the address of the Public		obtaining location information, learning the address of the Public
	Safety Answering Point (PSAP) and the emergency call itself are		Safety Answering Point (PSAP) and the emergency call itself are
	largely decoupled from the underlying network access procedures.		largely decoupled from the underlying network access procedures.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	access, does not have a VoIP provider or application service provider		access, does not have a VoIP provider or application service provider
	(ASP), or the credentials have become invalid, e.g., because the user		(ASP), or the credentials have become invalid, e.g., because the user
	has exhausted their prepaid balance or the account has expired.		has exhausted their prepaid balance or the account has expired.
	This document provides a problem statement, introduces terminology		This document provides a problem statement, introduces terminology
	and describes an extension for the base IETF emergency services		and describes an extension for the base IETF emergency services
	architecture to address these scenarios.		architecture to address these scenarios.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 12, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 4, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. No Access Authorization (NAA) . . . . . . . . . . . . . . 5		1.1. No Access Authorization (NAA) . . . . . . . . . . . . . . 5
	1.2. No ASP (NASP) . . . . . . . . . . . . . . . . . . . . . . 6		1.2. No ASP (NASP) . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Zero-Balance Application Service Provider (ZBP) . . . . . 6		1.3. Zero-Balance Application Service Provider (ZBP) . . . . . 6
	2. A Warning Note . . . . . . . . . . . . . . . . . . . . . . . . 6		2. A Warning Note . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Considerations for ISPs to support Unauthenticated		4. Considerations for ISPs to support Unauthenticated
	Emergency Services without Architecture Extensions . . . . . . 7		Emergency Services without Architecture Extensions . . . . . . 7
	5. Considerations for ISPs to support Unauthenticated		5. Considerations for ISPs to support Unauthenticated
	Emergency Services with Architecture Extensions . . . . . . . 8		Emergency Services with Architecture Extensions . . . . . . . 8
	6. NAA considerations for the network attachment procedure of		6. NAA considerations for the network attachment procedure of
	IAPs/ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12		IAPs/ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Link layer emergency indication . . . . . . . . . . . . . 12		6.1. Link layer emergency indication . . . . . . . . . . . . . 12
	6.2. Higher-layer emergency indication . . . . . . . . . . . . 13		6.2. Higher-layer emergency indication . . . . . . . . . . . . 13
	6.3. Securing network attachment in NAA cases . . . . . . . . . 13		6.3. Securing network attachment in NAA cases . . . . . . . . . 14
	7. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 14		7.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 15
	7.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 14		7.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 15
	7.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 14		7.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 15
	7.1.3. Location Determination and Location Configuration . . 15		7.1.3. Location Determination and Location Configuration . . 15
	7.1.4. Emergency Call Identification . . . . . . . . . . . . 15		7.1.4. Emergency Call Identification . . . . . . . . . . . . 15
	7.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 15		7.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 16
	7.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 16		7.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 16		7.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 16		7.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 16
	7.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 16		7.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 16
	7.2.2. Location Determination and Location Configuration . . 16		7.2.2. Location Determination and Location Configuration . . 16
	7.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 16		7.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 17
	7.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 16		7.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 17
	7.3.2. Emergency Call Identification . . . . . . . . . . . . 17		7.3.2. Emergency Call Identification . . . . . . . . . . . . 17
	7.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 17		7.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 17
	7.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 17		7.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . . 19		11.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Summoning police, the fire department or an ambulance in emergencies		Summoning police, the fire department or an ambulance in emergencies
	is one of the fundamental and most-valued functions of the telephone.		is one of the fundamental and most-valued functions of the telephone.
	As telephone functionality moves from circuit-switched telephony to		As telephone functionality moves from circuit-switched telephony to
	Internet telephony, its users rightfully expect that this core		Internet telephony, its users rightfully expect that this core
	functionality will continue to work at least as well as it has for		functionality will continue to work at least as well as it has for
	the older technology. New devices and services are being made		the older technology. New devices and services are being made
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	+----------+		+----------+
	Figure 1: Overview		Figure 1: Overview
	It is important to note that a single ESRP may also offer it's		It is important to note that a single ESRP may also offer it's
	service to several ISPs.		service to several ISPs.
	6. NAA considerations for the network attachment procedure of IAPs/ISPs		6. NAA considerations for the network attachment procedure of IAPs/ISPs
	This section discusses different methods to indicate an emergency		This section discusses different methods to indicate an emergency
	service request as part of network attachment. It provides some		service request as part of network attachment. It provides general
	general considerations and recommendations that are not specific to		considerations related to the access that provides the actual IP
	the access technology.		connectivity, without assuming a specific access technology. No
			specific recommendations are provided by this version of the
			document.
	To perform network attachment and get access to the resources		To perform network attachment and get access to the resources
	provided by an IAP/ISP, the end host uses access technology specific		provided by an IAP/ISP, the end host uses access technology specific
	network attachment procedures, including for example network		network attachment procedures, including for example network
	detection and selection, authentication, and authorization. For		detection and selection, authentication and authorization, or setup
			of service flows providing a specific quality-of-service level. For
	initial network attachment of an emergency service requester, the		initial network attachment of an emergency service requester, the
	method of how the emergency indication is given to the IAP/ISP is		method of how the emergency indication is given to the IAP/ISP is
	specific to the access technology. However, a number of general		specific to the access technology. However, a number of general
	approaches can be identified:		approaches can be identified:
	- Link layer emergency indication: The end host provides an		- Link layer emergency indication: The end host provides an
	indication, e.g. an emergency parameter or flag, as part of the link		indication, e.g. an emergency parameter or flag, as part of the link
	layer signaling for initial network attachment. Examples include an		layer signaling for initial network attachment. Examples include an
	emergency bit signalled in the IEEE 802.16-2009 wireless link.		explicit emergency bit signalled in the IEEE 802.16-2009 wireless
	signalling allows an IEEE 802.1X to occur without exchanging		link, or tokens in 802.11 access that allow an access network to
	cryptogrpahic keys		indicate emergency capability to devices and can be mirrored back in
			case a device actually requests emergency services during network
			entry as part of the lower-layer signaling.
	- Higher-layer emergency indication: Typically emergency indication		- Higher-layer emergency indication: Typically emergency indication
	in access authentication. The emergency caller's end host provides		in access authentication that is transparent to any access-specific
	an indication as part of the access authentication exchanges. EAP		lower-layer signaling. The emergency caller's end host provides an
	based authentication is of particular relevance here. [nwgstg3].		indication as part of the access authentication exchanges. EAP based
			authentication is of particular relevance here.
	6.1. Link layer emergency indication		6.1. Link layer emergency indication
	In general, link layer emergency indications provide good integration		In general, link layer emergency indications provide good integration
	into the actual network access procedure regarding the enabling of		into the actual network access procedures. This allows to recognize
	means to recognize and prioritize an emergency service request from		and prioritize an emergency service request from an end host at a
	an end host at a very early stage of the network attachment		very early stage of the network attachment procedure. However,
	procedure. However, support in end hosts for such methods cannot be		support in end hosts for such methods cannot be expected to be
	considered to be commonly available.		commonly available.
	No general recommendations are given in the scope of this memo due to		No general recommendations are given in the scope of this memo due to
	the following reasons:		the following reasons:
	- Dependency on the specific access technology.		- Dependency on the specific access technology.
	- Dependency on the specific access network architecture. Access		- Dependency on the specific access network architecture. Access
	authorization and policy decisions typically happen at a different		authorization and policy decisions typically happen at a different
	layers of the protocol stack and in different entities than those		layers of the protocol stack and in different entities than those
	terminating the link-layer signaling. As a result, link layer		terminating the link-layer signaling. As a result, link layer
	indications need to be distributed and translated between the		indications need to be distributed and translated between the
	different involved protocol layers and entities. Appropriate methods		different involved protocol layers and entities. Appropriate methods
	are specific to the actual architecture of the IAP/ISP network.		are specific to the actual architecture of the IAP/ISP network.
	6.2. Higher-layer emergency indication		6.2. Higher-layer emergency indication
	This section focuses on emergency indications based on authentication		This section discusses pros and cons of emergency indications based
	and authorization in EAP-based network access.		on authentication and authorization in EAP-based network access. No
			general recommendations like a preferred method to indicate emergency
			are given in this version of the document.
	An advantage of combining emergency indications with the actual		An advantage of combining emergency indications with the actual
	network attachment procedure performing authentication and		network attachment signaling performing authentication and
	authorization is the fact that the emergency indication can directly		authorization is the fact that the emergency indication can directly
	be taken into account in the authentication and authorization server		be taken into account in the authentication and authorization server.
	that owns the policy for granting access to the network resources.		Such server implements the policy for granting access to the network
	As a result, there is no direct dependency on the access network		resources. As a result, there is no direct dependency on the access
	architecture that otherwise would need to take care of merging link-		network architecture that would otherwise need to take care of
	layer indications into the AA and policy decision process.		merging link-layer indications into the AA and policy decision
			process.
	EAP signaling happens at a relatively early stage of network		EAP signaling happens at a relatively early stage of network
	attachment, so it is likely to match most requirements for		attachment, so it is likely to match most requirements for
	prioritization of emergency signaling. However, it does not cover		prioritization of emergency network entry. However, it does not
	early stages of link layer activity in the network attachment		cover early stages of link layer activity in the network attachment
	process. Possible conflicts may arise e.g. in case of MAC-based		process. Possible conflicts may arise e.g. in case of MAC-based
	filtering in entities terminating the link-layer signaling in the		filtering in entities terminating the link-layer signaling in the
	network (like a base station). In normal operation, EAP related		network (like a base station). In normal operation, EAP messages
	information will only be recognized in the NAS. Any entity residing		including information like the EAP identity will only be recognized
	between end host and NAS should not be expected to understand/parse		in the NAS. Note that otherwise, a NAS is agnostic to the actual EAP
	EAP messages.		method. Any entity residing between end host and NAS cannot be
			expected to understand or digest information that is exchanged as
			part of EAP messages, like EAP-related identities.
			In practice, due to lack of a common standard there is no single way
			to provide higher layer emergency indication during initial network
			entry as part of the NAI-formatted EAP identity, and different
			systems use different methods. Examples include directly selecting a
			special EAP identity (e.g. the NAI including the string 'emergency'),
			or NAI decoration.
	6.3. Securing network attachment in NAA cases		6.3. Securing network attachment in NAA cases
	For network attachment in NAA cases, it may make sense to secure the		For network attachment in NAA cases, it may make sense to secure the
	link-layer connection between the device and the IAP/ISP. This		link-layer connection between the device and the IAP/ISP. This
	especially holds for wireless access with examples being based		especially holds for wireless access with an example being IEEE
	access. The latter even mandates secured communication across the		802.16 based access that mandates secured communication across the
	wireless link for all IAP/ISP networks based on [nwgstg3].		wireless link for all IAP/ISP networks based on [nwgstg3].
	Therefore, for network attachment that is by default based on EAP		Therefore, for network attachment that is by default based on EAP
	authentication it is desirable also for NAA network attachment to use		authentication it is desirable also for NAA network attachment to use
	a key-generating EAP method (that provides an MSK key to the		a key-generating EAP method (that provides an MSK key to the
	authenticator to bootstrap further key derivation for protecting the		authenticator to bootstrap further key derivation for protecting the
	wireless link).		wireless link).
	The following approaches to match the above can be identified:		The following approaches to match the above can be identified. No
			preference is given for one of the following methods as requirements
			may vary depending on the specific environment:
	1) Server-only authentication: The device of the emergency service		1) Server-only authentication: The device of the emergency service
	requester performs an EAP method with the IAP/ISP EAP server that		requester performs an EAP method with the IAP/ISP EAP server that
	performs server authentication only. An example for this is EAP-TLS.		performs server authentication only. An example for this is EAP-TLS.
	This provides a certain level of assurance about the IAP/ISP to the		This provides a certain level of assurance about the IAP/ISP to the
	device user. It requires the device to be provisioned with		device user. It requires the device to be provisioned with
	appropriate trusted root certificates to be able to verify the server		appropriate trusted root certificates to be able to verify the server
	certificate of the EAP server (unless this step is explicitly skipped		certificate of the EAP server (unless this step is explicitly skipped
	in the device in case of an emergency service request).		in the device in case of an emergency service request).
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 39 ¶
	progress), August 2009.		progress), August 2009.
	[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for		[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
	Emergency Context Resolution with Internet Technologies",		Emergency Context Resolution with Internet Technologies",
	RFC 5012, January 2008.		RFC 5012, January 2008.
	[I-D.ietf-geopriv-held-identity-extensions]		[I-D.ietf-geopriv-held-identity-extensions]
	Winterbottom, J., Thomson, M., Tschofenig, H., and R.		Winterbottom, J., Thomson, M., Tschofenig, H., and R.
	Barnes, "Use of Device Identity in HTTP-Enabled Location		Barnes, "Use of Device Identity in HTTP-Enabled Location
	Delivery (HELD)",		Delivery (HELD)",
	draft-ietf-geopriv-held-identity-extensions-03 (work in		draft-ietf-geopriv-held-identity-extensions-04 (work in
	progress), February 2010.		progress), June 2010.
	[I-D.winterbottom-geopriv-lis2lis-req]		[I-D.winterbottom-geopriv-lis2lis-req]
	Winterbottom, J. and S. Norreys, "LIS to LIS Protocol		Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
	Requirements", draft-winterbottom-geopriv-lis2lis-req-01		Requirements", draft-winterbottom-geopriv-lis2lis-req-01
	(work in progress), November 2007.		(work in progress), November 2007.
	[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.		[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
	Shanmugam, "Security Threats and Requirements for		Shanmugam, "Security Threats and Requirements for
	Emergency Call Marking and Mapping", RFC 5069,		Emergency Call Marking and Mapping", RFC 5069,
	January 2008.		January 2008.
	[I-D.ietf-geopriv-arch]		[I-D.ietf-geopriv-arch]
	Barnes, R., Lepinski, M., Cooper, A., Morris, J.,		Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
	Tschofenig, H., and H. Schulzrinne, "An Architecture for		Tschofenig, H., and H. Schulzrinne, "An Architecture for
	Location and Location Privacy in Internet Applications",		Location and Location Privacy in Internet Applications",
	draft-ietf-geopriv-arch-01 (work in progress),		draft-ietf-geopriv-arch-02 (work in progress), May 2010.
	October 2009.
	[esw07] "3rd SDO Emergency Services Workshop,		[esw07] "3rd SDO Emergency Services Workshop,
	http://www.emergency-services-coordination.info/2007Nov/",		http://www.emergency-services-coordination.info/2007Nov/",
	October 30th - November 1st 2007.		October 30th - November 1st 2007.
	[nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network		[nwgstg3] "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network
	Architecture Stage-3		Architecture Stage-3
	http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech		http://www.wimaxforum.org/sites/wimaxforum.org/files/ tech
	nical_document/2009/09/		nical_document/2009/09/
	DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf",		DRAFT-T33-001-R015v01-O_Network-Stage3-Base.pdf",
End of changes. 26 change blocks.
	61 lines changed or deleted		74 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/