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]