Internet Engineering Task Force H. Behrens Internet Draft snom technology AG K. Knuettel Fraunhofer FOKUS draft-behrens-sipping-roaming-architecture-00.txt February 9, 2003 Expires: August, 2004 Interdomain Trust-Relationships for SIP-based Roaming STATUS OF THIS MEMO This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This draft describes an authentication mechanism which can be used to enable users of VoIP to globally roam between any number of ITSPs (Internet Telephony Service Providers) without needing to have a prior customer or billing relationship with all of them. This enables profiles and one- line-billing. Providers using this authentication mechanism do neither need full-mesh trust relationships or roaming agreements with every other possible provider nor do they need to rely on a centralized brokerage entity to process calls. The Home Network (HN), which handles all AAA for a user attempting to use an ITSP's service is determined through a unique identifier submitted by the user. This Network Access Identifier [RFC2486] contains information about the trust domain or trust realm the user belongs to. Based on a simple discovery mechanism a provider can establish a trust path to this home network. Once this is established, the provider can authenticate the user and check his credit with the home network. Accounting and rate information will be sent to the home network for mediation and processing. Internet Draft SIP February 8, 2003 1. Introduction..............................................2 2. Requirements..............................................2 3. Architecture..............................................3 4. Terminology...............................................3 5. Conventions used in this document.........................4 6. Security Architecture.....................................4 6.1 Trust Relationships......................................4 6.2 Trust Relationships between Providers and Settlement.....5 7. Actors and Mechanisms.....................................5 7.1 Actors...................................................5 7.2 Mechanisms...............................................5 8. Call Flow.................................................6 10. Bibliography............................................10 1. Introduction More and more ISPs are beginning to add VoIP to their service portfolio. The last years have seen the merging of IP-based telephony and switched line telephony (both mobile and fixed-line) in the sense that users of VoIP want to be able to call a PSTN or PLMN number as well as being reachable under a home PSTN or PLMN number. Roaming between ISPs has not developed to a large degree. With the advent of voice communication becoming an important service, this will become more relevant. Users will want to use VoIP for their telephony and they will want to do this wherever they are located. The authors believe that one way to address this is to leverage a user’s existing customer and billing relationship with his home telephony provider.Users make use of this when signing up for ad-hoc service with a visited ITSP. The ITSP verifies the existing billing relationship and receives authorization of a certain amount of credit the home network is willing to underwrite. Based on the security architecture described here, mutual trust can be established and the user can both place VoIP calls through his visited network as well as being reachable under home number and URI. 2. Requirements The term ‘Roaming Capability’ has been defined in [RFC2486]. One aim of this document is to provide an architecture by which Roaming Capability can be assured by a federation of independent VoIP providers. In the world of IP-related protocols little attention has been given to this issue. Requirements for global roaming for WLAN users have been described by J. Caron in [CARON.1]. He also outlined a simple DNS-based method in [CARON.2]. The Roaming Scenario addressed here is as follows: - The principal with the NAI of alice@biloxi.com sends a REGISTER request to the SIP registrar of atlanta.com. atlanta.com in this case is Alice’s ‘Visited Network’ (VN). biloxi.com is her home network. - Alice wants to use her VN to place authenticated and secure VoIP calls. - Alice wants to be reachable both under her home URI as well as under a URI assigned by the VN. - Alice provides her NAI to her VN’s SIP registrar. - The VN o asserts that Alice’s Home Network signs Alice’s identity and authorizes a credit amount greater 0 o asserts that Alice’s HN is a trusted entity - atlanta.com assigns Alice a temporary Address of Record (AOR) URI as well as a valid contact address from within its own name space. H. Behrens, K. Knuettel [Page 2] Internet Draft SIP February 8, 2003 - Alice registers with her HN using the newly assigned Contact address as the Contact. - Alice’s SUA can place outgoing call either under the temporary URI assigned by the VN or her home URI at biloxi.com. - Alice is reachable both under her home-AOR as well as the visiting- AOR. Assuming Alice’s HN provides PSTN break-in, Alice is also reachable under her telephone number known to her buddies. - All calls placed by Alice for the duration of this registration are accounted to Alice’s HN. 3. Architecture The architecture is based on a model that is user-centric in that it assumes for each principal or user to have one Home Network with which he has a valid billing relationship. This entity can authenticate the user based on his NAI and is willing to underwrite credit as well as receive CDRs for further settlement. This HN corresponds to the ‘Authentication Service’ described in [PETERSON.1]. Basing the architecture on a user-centric model based on a NAI, greatly reduces the number of billing relationships in a roaming environment as well allowing incumbent HNs, such PSTN or PLMN providers [RFC2486], to leverage their existing customer relationships. New emerging operators can benefit from this, because they can deliver their services to any user with a valid NAI, knowing that they can bill the user’s HN up to the credit amount underwritten. HNs can benefit by charging for this service. This potentially creates a win-win situation between incumbent operators, who hold the trust and billing relationships, and emerging ITSPs who wish to be able to attract as many users as possible, without the financial and bureaucratic overhead involved in setting up a documented and secure billing relation with each of their users. The architecture consists of 1. Peers: entities participating in a roamable VoIP infrastructure 2. Security Architecture: the Security architecture, which describes the trust relationships as well as security mechanisms used. 3. Signaling Protocol: Signaling is based on the Session Initiation Protocol (SIP) [RFC3261]. 4. Accounting infrastructure: Both Authentication andAuthorization are covered by the Security Architecture and/or the Signaling Protocol. Accounting is based on - the Authentication and Authorization signed by the HN and accepted by the VN. - hub-and-spoke trust relationships from the participating operators to a Settlement Entity (SE). This document proposes an architecture, which fulfils these requirements by making use of pre-existing trust relationships. The architecture is strongly influenced by work done by J. Peterson [PETERSON.1] and [RFC3325] on one hand and the work of Aboba et. al [RFC2486],[RFC2194] on the other hand. 4. Terminology AAA Authentication, Authorization, Accounting AOR Address of Record CDR Call Detail Record CRM Customer Relationship Management DoT Domain of Trust ETSI European Telecommunication Standard Institute HN Home Network ITSP Internet Telephony Service Provider NAI Network Access Identifier H. Behrens, K. Knuettel [Page 3] Internet Draft SIP February 8, 2003 OSP Open Settlement Protocol PKI Public Key Infrastructure PLMN Public Line Mobile Network PSTN Public Switched Telephone Network URI Uniform Resource Identifier VN Visited Network VoIP Voice over IP 5. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 6. Security Architecture The proposed architecture is based on the assumption that all entities, participating in the execution of a call, establish a mutual Trust Domain (TD) for at least the duration of that call. The term ‘Trust Domain’ is used in the sense described in [RFC3324]. Such a TD can be of permanent nature or established within the context of one or more transactions. Based on this definition of Trust Domain the architecture described here, can be separated into two distinct layers: 1. Verification or Establishment of a common Trust Domain based on existing and derived direct Trust Relationships. 2. Use the mechanisms provided by this TD – Spec(T) – to assert the validity of VoIP calls and their related document trail. Section 6.1 and 6.2 will outline the direct Trust Relationships assumed in the scope of this document. Section 7 outlines how a common Trust Domain is established. Section 8 provides example call flows that combine the mechanisms to demonstrate how the requirements are fulfilled. 6.1 Trust Relationships For SIP-based VoIP to become commercially accepted, providers need to be able to - account and bill for their services - be able to cooperate with other VoIP providers in routing and signaling calls. Both of these requirements assume trust relationships between the user(s) being served as well as between the operators cooperating during the call. In order to achieve critical mass, it needs to be easy for providers to cooperate in a flexible ad-hoc fashion in placing and routing their calls. Authentication should be based on a globally unique identifier, so one principal has one AAA and billing relationship. This unique identifier needs to specify his home domain of trust to other entities. Within his DoT, the identifier needs to identify his specific principal identity. Authentication and authorization of a user can be transparent because the user uses only one set of credentials wherever he may be. Within this document we assume credentials based on exchange of PKI certificates. The model operates on direct trust relationships. A user has an a-priori trust relationship with his home network. Visited network and home network establish trust based on exchange and verification of certificates. The user and the visited network establish trust through H. Behrens, K. Knuettel [Page 4] Internet Draft SIP February 8, 2003 the mechanisms described in this document. Once the user and the VN have established a trust relationship, which is based on the VN knowing that the HN can be charged for the credit amount authorized, the user is fully authenticated and authorized and can use the VN’s services. This is even though a-priori trust or billing relationship exists between the authenticated user and the serving provider. 6.2 Trust Relationships between Providers and Settlement Entity Inter-operator accounting is still within the scope of the architecture described here. We assume that billing is based on a settlement and clearing entity. This entity provides CDR-aggregation, settlement, clearing and billing functionalities to the participating providers. Where there is more than one such entity, we assume an existing trust relationship between them. This architecture assumes the existence of such an entity, e.g. based on the Open Settlement Protocol (OSP) defined by the ETSI [TS102.321]. It is also assumed that each provider has its own trust relationship with the Settlement Agency. It should be noted that the model explicitly does not use any of the authentication or routing functionalities proposed in that specification. In the architecture presented here, OSP is strictly used for aggregation of CDRs and settlement among operators. The authors think that the fully integrated position taken by the ETSI does not fulfil the more organic and fluid environment of the upcoming VoIP industry. 7. Actors and Mechanisms 7.1 Actors The actors (players) are as follows: - The Service User (User): A user wanting to use VoIP telephony both for inbound as well as outbound calls. A user is uniquely identified based on his NAI, which identifies him as a user of his home domain. A mechanism of the location of the AAA server serving that home domain is assumed. - The Visited Network (VN): the VN is the network a user uses when roaming. He wants to use that networks services while being billed by his HN. Roaming should be transparent. This means that the user should not need an a-priori trust relationship with the VN. It also means that he should be reachable under his home AOR and home telephone number no matter who is roaming provider is. - The Home Network (HN): The Home Network has two functions: . act as a home AAA server for the User. . act as the home VoIP network for the User. 7.2 Mechanisms The mechanism is as follows: - A user registers with the VN (atlanta.com in the call flow given). The user submits his NAI in new header field ‘P-NAI’. The user submits a bogus URI in both the From and the To header. - The VN recognizes the registration as a P-NAI registration and sends back a “401 Unauthorized” response, with both the From and H. Behrens, K. Knuettel [Page 5] Internet Draft SIP February 8, 2003 the To URI set to the temporary URI that will be assigned to the user upon successful authentication and authorization. - The User submits the credentials belonging to the NAI specified, e.g. his signed public key in the next register message. - The VN requests authentication and authorization of the user from the home network. This can either be done through the AAA architecture or future extensions to the SIP protocol. - The HN authenticates the user and authorizes a certain amount of credit. The HN includes a one-time token, which he encrypts using the user’s public key in the return message. The HN signs the user’s credentials and the encrypted token together with the amount authorized. At this point authentication is established. Authorization is still pending. - The VN sends the user the encrypted token in a new header field ‘P-NAI-Token’ in the response to the user’s registration request. - The user decrypts the ‘P-NAI-Token’ with his private key. He then encrypts it with his VN’s public key. - The user requests a call using an INVITE message with the ‘P- NAI-Token’ (encrypted with the VN’s certificate) inserted in the header. - The VN decrypts the token and encrypts it using the HN’s public key. He uses this token in an authorization request sent to the HN. - The HN decrypts the received token and compares it with the locally generated token. If they match, all necessary trust relationships have been established. . The HN has authenticated the user to the VN. . The VN now trusts the user based on the VN’s trusting the HN. . The user trusts the VN. This is established by the VN possessing the clear text P-NAI-Token. . The HN receives proof of this trust and can therefore authorize the VN to bill up to the credit amount given 8. Call Flow Client is located in the foreign ITSP-Network and wants to be authenticated by his home network. Within that flow a trust relationship between the ITSPs is established. atlanta.com . . . . biloxi.com . ITSP/GME ITSP/GME . Alice's . . . . . . . . . . . . . . . . . . . . . softphone | | | | REGISTER F1 | | |--------------------> | | | 401 Unauthorized F2 | | |<-------------------- | | | REGISTER F3 | | |--------------------> | | | 100 Trying F4 | Authenticate F5 | |<-------------------- |----------------> | | | Authenticated F6 | | | contains encrypted | | | token | | 200 OK F7 |<--------------------- | | contains encrypted | | | token | | H. Behrens, K. Knuettel [Page 6] Internet Draft SIP February 8, 2003 |<-------------------- | | | REGISTER F8 | | | contains token | | | encrypted for VN | | |--------------------> | | | | REGISTER F9 | | | contains token | | | encrypted for HN | | |---------------------> | | | 200 OK F10 | | |<------------------- | | 200 OK F11 | | |<-------------------- | | F1 REGISTER sip:registrar.atlanta.com SIP/2.0 Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 P-NAI: Alice Content-Length: 0 F2 401 Unauthorized SIP/2.0 Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 P-NAI: Alice CSeq: 1826 REGISTER Expires: 7200 P-NAI: Alice Content-Length: 0 F3 REGISTER sip:registrar.atlanta.com SIP/2.0 Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1837 REGISTER Contact: Expires: 7200 P-NAI: Alice Content-Length: 0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42; Content-Length: 568 ******** ******* H. Behrens, K. Knuettel [Page 7] Internet Draft SIP February 8, 2003 F4 SIP/2.0 100 Trying Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1837 REGISTER Content-Length: 0 F5 /F6 TO BE DONE ! F7 SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1837 REGISTER Contact: Expires: 7200 P-NAI-Token: Content-Length: 0 F8 REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1847 REGISTER Contact: Expires: 7200 P-NAI: Alice Content-Length: 0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42; Content-Length: 568 ******** ******* F9 REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP xyv.atlanta.com:5060;branch=z9hG4bKnasdhf9 Max-Forwards: 70 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1847 REGISTER Contact: Expires: 7200 P-NAI: Alice Content-Length: 0 Content-Type: multipart/signed; H. Behrens, K. Knuettel [Page 8] Internet Draft SIP February 8, 2003 protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42; Content-Length: 568 ******** ******* F10 SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 Via: SIP/2.0/UDP xyv.atlanta.com:5060;branch=z9hG4bKnasdhf9 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1847 REGISTER Contact: Expires: 7200 P-NAI-Token: Content-Length: 0 F11 SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Alice From: Alice ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1847 REGISTER Contact: Expires: 7200 P-NAI-Token: Content-Length: 0 IANA Considerations SIP headers defined: P-NAI, P-NAI-Token Normative description: This document 9. Authors' Addresses Dr. Harry Behrens snom technology AG Pascalstr. 10B 10587 Berlin Germany Email: hb@snom.com Karsten Knuettel Fraunhofer FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin H. Behrens, K. Knuettel [Page 9] Internet Draft SIP February 8, 2003 Email: knuettel@fokus.fraunhofer.de 10. Bibliography [CARON.1]Caron, J., “Public Wireless LAN roaming issues”, , WIP, February 2002. [CARON.2]Caron, J., “DNS-based Roaming”, , WIP, April 2002. [PETERSON.1] Peterson, J. “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)”, , WIP, February 2003. [RFC2194] Aboba, B. et al., "Review of Roaming Implementations", RFC2194, September 1997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997 [RFC2486]Aboba, B. et al., "The Network Access Identifier", January 1999 [RFC3261]Rosenberg, J., Schulzrinne H., Camarillo G., Johnston, A.R., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, Internet Engineering Task Force, June 2002. [RFC3325] Jennings, C. et al. "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", November 2002 [TS102.321] ETSI TS, “Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open Settlement Protocol (OSP) for Interdomain Pricing, authorization and usage exchange”, Technical Specification 101 321. [RFC3261] . Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, Internet Engineering Task Force, June 2002. The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. H. Behrens, K. Knuettel [Page 10] Internet Draft SIP February 8, 2003 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (c) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. H. Behrens, K. Knuettel [Page 11]