One document matched: draft-barnes-ecrit-auth-00.txt
Network Working Group R. Barnes
Internet-Draft BBN Technologies
Intended status: Informational June 2007
Expires: December 3, 2007
Proxy Authentication of the Emergency Status of SIP Calls
draft-barnes-ecrit-auth-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 December 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In order to prevent abuse of emergency calling resources for non-
emergency purposes, operators of SIP proxies require a capability to
distinguish emergency calls from non-emergency calls. This document
describes several mechanisms by which the entities participating in a
call can include in SIP headers a verifiable assertion that the
signaled call is an emergency call.
Barnes Expires December 3, 2007 [Page 1]
Internet-Draft Emergency Call Authentication June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authenticators . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Location and Service URN . . . . . . . . . . . . . . . . . 4
2.2. Asserter Identity . . . . . . . . . . . . . . . . . . . . . 4
2.3. Direct assertion . . . . . . . . . . . . . . . . . . . . . 5
3. Embedding Authenticators in SIP . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Barnes Expires December 3, 2007 [Page 2]
Internet-Draft Emergency Call Authentication June 2007
1. Introduction
In order to prevent abuse of emergency calling resources for non-
emergency purposes, operators of SIP [RFC3261] proxies require a
capability to distinguish emergency calls from non-emergency calls.
For example, in many jurisdictions, operators of circuit-switched
telephone networks are required to provide emergency calling free of
charge, and such requirements will likely be applied also to packet-
switched Voice Service Providers (VSPs). If VSPs cannot reliably
distinguish between emergency and non-emergency calls (and emergency
calls must be free), then there is a risk that legitimate emergency
calls will be charged, or that non-emergency calls will be able to
masquerade as emergency calls to escape charging.
In any emergency call, there are two entities that have authoritative
knowledge that a call is in fact an emergency call, namely the
calling party (who has an emergency) and the called party (the
emergency services provider). In some cases, certain SIP proxies may
also have such knowledge. Thus, what is required is a mechanism for
these entities to assert to other proxies in the signaling path that
the call is an emergency call, i.e., a mechanism for embedding
information that authenticates the call as an emergency call into SIP
header fields. This mechanism must specify how such assertions are
created by parties asserting an emergency call, and how they are
verified by parties relying on the fact that a call is an emergency
call.
This document describes options for such a mechanism, in two parts:
First, a set of data structures that allow verification (or
"authenticators"), and second, a set of requirements for how these
authenticators should be carried in SIP messages and header fields.
Each authenticator presented here relies on a different model for
verification, with a corresponding underlying trust model. Likewise,
each SIP embedding has different implications for which SIP messages
must be available to a verifying proxy.
The scope of this document is restricted to the authentication of
SIP-signalled emergency calls, in which the authenticator is asserted
(inserted into the SIP message flow) by the UAC, a UAS, or a proxy.
The primary focus of this document is citizen-to-authority emergency
calling; some solutions, however, apply to authority-to-authority or
authority-to-citizen calling as well.
2. Authenticators
This document describes three types of authenticators, with three
different underlying trust models. The first is based on trust in
Barnes Expires December 3, 2007 [Page 3]
Internet-Draft Emergency Call Authentication June 2007
the LoST infrastructure, the second on trust in an authentication
infrastructure for emergency services entities, and the third on
trust in an authentication infrastructure for a set of authorized
asserters. Each of these authenticators also has implications for
the choice of how it should be carried in SIP messages.
2.1. Location and Service URN
In this model, the authenticating information is a location object
and a service URN. The asserter inserts into a SIP message a
location object and the service URN corresponding to the emergency
service requested. To verify a call, the verifier performs a LoST
findService query to map the included location and service URN to a
set of one or more URIs. The call is authenticated if the URI in the
message's To header field is the same as one of the URIs included in
the LoST response. (Note that the inserted location may be that of
the caller/UAC or of the asserter, but need not be, so long as a LoST
query returns the URI in the To header field.)
This is the model assumed in current ECRIT documents: The emergency
caller inserts his own location (via a Geolocation header) into his
INVITE message, and the service URN is carried elsewhere in the
INVITE. Note, however, that it would also be possible for the UAS
(presumably an emergency service provider) could also insert a
location within its service boundary along with the same URN included
in the INVITE (or, likewise, a proxy could do the same).
This system assumes that the verifier trusts the LoST infrastructure:
A call is considered an emergency call whenever the To address is
listed as an emergency service provider in LoST [LoST].
An important restriction to the applicability of this solution is
that it requires the asserter possess a location value that can serve
as part of an authenticator. For instance, if the authenticator is
to be carried an INVITE message, the UAC must have access to its own
location (with some degree of precision). Since there are situations
where UACs may not have access to their own location (in access
networks prevent this), this solution must be embedded in SIP in such
a way that it can be inserted by a UAC, a UAS, or a proxy. In
addition, if the Geolocation header is used to convey the location
used here, then the SIP embedding must take into account the usage
restrictions in [location-conveyance].
2.2. Asserter Identity
In this model, the authenticating information is a verifiable
attestation of the asserter's identity. The asserter (a UAC or UAS)
inserts into a SIP message an Identity header that attests to its
Barnes Expires December 3, 2007 [Page 4]
Internet-Draft Emergency Call Authentication June 2007
identity (as defined in RFC 4474 [RFC4474]). To verify a call, the
verifier performs the verification operation described in RFC 4474.
The call is authenticated if the authenticated identity identifies
the asserter as an emergency services entity.
When applied to citizen-to-authority emergency calling, the asserter
will likely be the called party, namely an Emergency Services
Response Point (ESRP) or Public Safety Answering Point (PSAP). By
presenting a cryptographically-verified identity, the asserter
provides proof that it is an emergency services entity, and it is
assumed that calls received by such entities are emergency calls.
This system assumes that the verifier trusts the cryptographic
authentication system underlying the construction of the Identity
header. That is, the verifier must trust the certificate issuer at
the root of the certificate chain used to generate the Identity
header. Thus, in order for this solution to be globally deployed,
emergency services entities will need to be issued credentials.
While this can be done locally to a large extent (e.g. on a nation/
state level), verification of asserted identities will be optimized
if all credentials are ultimately within the trust domains of a few
root certificate issuers.
The use of the SIP Identity header for this purpose could pose a
series of problems. In particular, since the Identity header is
intended to authenticate the identity of the UAC, other mechanisms
would have to be defined to allow for a UAS or a proxy to act as an
asserter (e.g., [connected-identity]).
2.3. Direct assertion
In this model, the authenticating information is a signed object that
directly attest that the call is an emergency call. The asserter
constructs the content of the object based on information in the SIP
header fields, signs it, and inserts it into a SIP message. To
verify a call, the verifier validates the signature on the object,
verifies that the contents correspond to the SIP message that
contains it. The call is authenticated if the asserter is authorized
to attest to the emergency status of calls.
For instance, the asserter might construct a data structure that
contains the values of the From, To, Call-ID, and Date fields in a
SIP message. An asserter would construct such a data structure and
sign it; the verifier would validate the signature and compare the
header values in the data structure to those in the SIP message.
This system assumes that the verifier trusts a set of credentialed
entities to make assertions about the emergency status of calls (and
Barnes Expires December 3, 2007 [Page 5]
Internet-Draft Emergency Call Authentication June 2007
also that he trust the cryptographic authentication infrastructure
underlying the corresponding credentials). If each emergency
services entity is authorized to make such assertions (and these are
the only authorized entities), then this solution is equivalent in
complexity to the "asserter identity" solution above. However, if
there are centralized entities, such as SIP proxies that serve many
PSAPs, that are authorized to vouch for emergency calls, then the
burden of creating credentials for asserters (relative to the
"asserter identity" solution).
3. Embedding Authenticators in SIP
Authenticators are carried between asserters and verifiers by SIP
messages, so a mechanism for authenticating emergency calls will need
to define a way for authenticators to be embedded into SIP messages.
For example, in the "location + URN" system, the UAC could insert an
authenticator by including a Geolocation header in an INVITE message,
the UAS by including one its 200 (OK) message, and a proxy by
including one in either message. Or, following the model of
[connected-identity], either the UAC or the UAS could send an
authenticator in a separate UPDATE transaction after the intial
INVITE transaction has completed.
Rather than specifying a particular embedding, this document
describes a set of requirements or desiderata that should be
satisfied by such an embedding:
R1: The authentication solution must specify procedures that a SIP
element must follow in order to assert that a call is an emergency
call, including which SIP messages and header fields are used when
the authenticator is inserted by a UAC, a UAS, or a proxy (possibly
different for each of these three cases).
R2: The authentication solution must specify procedures that a SIP
proxy must follow in order to verify that a call is an emergency
call, including which SIP messages and header fields must be
inspected to extract an authenticator, and how the authenticator is
verified.
R3: The authentication solution should require as few additional SIP
messages as possible, beyond the INVITE transaction that initiates
the call. In addition to minimizing bandwidth requirements, reducing
additional messaging will simplify the message flows required to set
up an emergency call.
R4: Since the authentication of a call as an emergency call concerns
the call itself, and not a particular SIP message, the authentication
Barnes Expires December 3, 2007 [Page 6]
Internet-Draft Emergency Call Authentication June 2007
solution should allow for authenticators to be persisted from one SIP
message to another within the same dialog. This will allow stateless
elements, or elements that are only intermittently involved in
signaling, to nonetheless recognize the call as an emergency call.
R5: If an authenticator is inserted into a SIP message by a proxy, it
will only be visible to proxies "downstream" (in the sense of "nearer
the destination") from the asserting proxy in the path of the
message. The authentication solution should allow for authenticators
to be passed from an asserting proxy to a verifying proxy that is
either "upstream" or "downstream" from the asserting proxy (in the
sense of "nearer the UAC" or "nearer the UAS" for a given
transaction). The persistence mechanism suggested in R4 is a partial
solution to this problem: If an authenticator is embedded in a
request and persisted into a response, then it will be available to
all proxies along the signaling path between the UAC and the UAS
(twice to "downstream" proxies, once to "upstream" proxies).
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
This document outlines mechanisms for providing authentication of the
emergency status of SIP calls, according to a specified set of trust
models. Security concerns related to the mechanisms discussed are
presented in their respective sections.
6. Normative References
[LoST] Hardie, et al., T., "LoST: A Location-to-Service
Translation Protocol", Mar. 2007.
[draft-ietf-ecrit-lost-05]
[RFC3261] Rosenberg, et al., J., "SIP: Session Initiation Protocol",
Jun. 2002.
RFC 3261
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Barnes Expires December 3, 2007 [Page 7]
Internet-Draft Emergency Call Authentication June 2007
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", Aug. 2006.
RFC 4474
[connected-identity]
Ellwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", Feb. 2007.
[draft-ietf-sip-connected-identity-05]
[location-conveyance]
Polk, J. and B. Rosen, "Session Initiation Protocol
Location Conveyance", Feb. 2007.
[draft-ietf-sip-location-conveyance-07]
Author's Address
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
US
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
URI: http://www.bbn.com/
Barnes Expires December 3, 2007 [Page 8]
Internet-Draft Emergency Call Authentication June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes Expires December 3, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 08:36:35 |