draft-ietf-ecrit-unauthenticated-access-02.txt   draft-ietf-ecrit-unauthenticated-access-03.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 30, 2011 Research in Motion UK Ltd Expires: January 12, 2012 Research in Motion UK Ltd
G. Bajko G. Bajko
Nokia Nokia
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
D. Kroeselberg D. Kroeselberg
Siemens Siemens
March 29, 2011 July 11, 2011
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-ietf-ecrit-unauthenticated-access-02.txt draft-ietf-ecrit-unauthenticated-access-03.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 2, line 7 skipping to change at page 2, line 7
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 September 30, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 10, line 7 skipping to change at page 10, line 7
`...../ `...../ `...../ `...../
Abbreviations: Abbreviations:
LLA: Link Layer Attachment LLA: Link Layer Attachment
ES: Emergency Services ES: Emergency Services
Figure 1: Flow Diagram Figure 1: Flow Diagram
4. ZBP Considerations 4. ZBP Considerations
Although subject to local regulatory mandates, it is expected that ZBP includes all cases where a subscriber is known to an ASP, but
for most ASPs even with a lack of authorization for regular service lacks the necessary authorization to access regular ASP services.
an otherwise authenticated and known subscriber must be granted Example ZBP cases include empty prepaid accounts, barred accounts,
access to emergency services. Naturally, without an obligation to roaming and mobility restrictions, or any other conditions set by ASP
support emergency services in ZBP cases an ASP can simply disallow policy.
access by such customers. As a result, all such subscribers may fall
back into a NASP situation as described above.
If ASPs desire or are required by regulation to provide emergency Local regulation might demand that emergency calls are always
services to subscribers with valid credentials that only fail authorized. An ASP can identify emergency sessions by identifying
authorization, the emergency services nature of a call can easily be the service URN [RFC5031] used in call setup. Emergency calls can
determined by inspecting the call setup procedure for the presence of then be authorized accordingly. The ZBP case therefore only affects
the emergency service URNs. This example shows that in the context the ASP.
of this document no specific considerations apply to the ZBP case due
to the fact that the ASP will be able to relate the service request
to an existing subscription or user and will be in control of
adjusting any authorization decision based on its deployemnt specific
policy. It is, however, noted that specific security considerations
apply due to the fact that emergency service access will likely be
granted with limited authorization only, see Section 7.
ZBP cases in the context of this document cover all cases where an Permitting a call with limited authorization could present an
otherwise valid subscription lacks authorization to access or regular opportunity for abuse. The ASP MAY choose to validate session
ASP services, i.e., a lack of authorization that would block the initiation messages for valid destinations, see Section 7.
subscriber from using the service for emergency purpose. Example ZBP
cases include empty prepaid accounts, barred accounts, or certain An ASP without a regulatory requirement to authorize emergency calls
roaming or mobility restrictions. The exact list of cases where can deny emergency call setup. Where an ASP does not authorize an
emergency services need to be supported by the ASP is local to the emergency call, the caller can fall back to NASP procedures.
ASP policy and deployment, and is therefore beyond the scope of this
document.
5. NASP Considerations 5. NASP Considerations
To start the description we consider the sequence of steps that are To start the description we consider the sequence of steps that are
executed in an emergency call based on Figure 2. executed in an emergency call based on Figure 2.
o As an initial step the devices attaches to the network as shown in o As an initial step the devices attaches to the network as shown in
step (1). This step is outside the scope of this section. step (1). This step is outside the scope of this section.
o When the link layer network attachment procedure is completed the o When the link layer network attachment procedure is completed the
skipping to change at page 14, line 36 skipping to change at page 14, line 36
The ISP is responsible for location determination and exposes this The ISP is responsible for location determination and exposes this
information to the end points via location configuration protocols. information to the end points via location configuration protocols.
The considerations described in [I-D.ietf-ecrit-location-hiding-req] The considerations described in [I-D.ietf-ecrit-location-hiding-req]
are applicable to this document. are applicable to this document.
The ISP MUST support one of the LCPs described in Section 6.5 of The ISP MUST support one of the LCPs described in Section 6.5 of
[I-D.ietf-ecrit-phonebcp]. The description in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp]. The description in Section 6.5 and 6.6 of
[I-D.ietf-ecrit-phonebcp] regarding the interaction between the end [I-D.ietf-ecrit-phonebcp] regarding the interaction between the end
device and the LIS applies to this document. device and the LIS applies to this document.
The interaction between the LIS at the ISP and the IAB is often The interaction between the LIS at the ISP and the IAP is often
priorietary but the description in priorietary but the description in
[I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader. [I-D.winterbottom-geopriv-lis2lis-req] may be relevant to the reader.
5.3. ESRP Profile 5.3. ESRP Profile
5.3.1. Emergency Call Routing 5.3.1. Emergency Call Routing
The ESRP continues to route the emergency call to the PSAP The ESRP continues to route the emergency call to the PSAP
responsible for the physical location of the end host. This may responsible for the physical location of the end host. This may
require further interactions with LoST servers but depends on the require further interactions with LoST servers but depends on the
skipping to change at page 22, line 5 skipping to change at page 21, line 15
8. Acknowledgments 8. Acknowledgments
Parts of this document are derived from [I-D.ietf-ecrit-phonebcp]. Parts of this document are derived from [I-D.ietf-ecrit-phonebcp].
Participants of the 2nd and 3rd SDO Emergency Services Workshop Participants of the 2nd and 3rd SDO Emergency Services Workshop
provided helpful input. provided helpful input.
We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc
Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT
meeting. meeting.
Furthermore, we would like to thank Martin Thomson and Bernard Aboba
for their detailed document review in preparation of the 81st IETF
meeting.
9. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
 End of changes. 9 change blocks. 
33 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/