Network Working Group S. Greco Polito Internet-Draft University of Palermo Intended status: Informational H. Schulzrinne Expires: March 19, 2007 Columbia University September 15, 2006 SIP and SAML roaming profile draft-greco-sipping-roaming-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 March 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Greco Polito & Schulzrinne Expires March 19, 2007 [Page 1] Internet-Draft SIP and SAML roaming profile September 2006 Abstract Roaming services allow users that have a contract with a voice service provider to use access resources owned by other providers known as internet access providers. This draft proposes a token- based Authentication, Authorization, Accounting (AAA) and billing model for roaming users. It also introduces a protocol solution for the proposed model that is based on the Assertion Markup Language (SAML) protocol and the Session Initiation Protocol (SIP). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol description . . . . . . . . . . . . . . . . . . . . . 7 3.1. User behavior . . . . . . . . . . . . . . . . . . . . . . 9 3.2. VSP behavior . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Guarantor behavior . . . . . . . . . . . . . . . . . . . . 10 3.4. IAP behavior . . . . . . . . . . . . . . . . . . . . . . . 10 4. Roaming SAML profile . . . . . . . . . . . . . . . . . . . . . 11 4.1. Token building request and response . . . . . . . . . . . 11 4.2. SAML roaming assertion . . . . . . . . . . . . . . . . . . 13 4.3. Token request and response . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. XML schemas . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. XML schema of the Condition element . . . . . . . . . . . 18 6.2. XML schema of the token building request . . . . . . . . . 19 6.3. XML schema of the Statement element . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Greco Polito & Schulzrinne Expires March 19, 2007 [Page 2] Internet-Draft SIP and SAML roaming profile September 2006 1. Introduction The AAA and billing of roaming users requires interaction between the voice service providers (VSP) contracted by the users, and the internet access providers (IAP) that own access resources. In this draft we propose an AAA and billing model in which we want to leverage the business, billing and trust relationship that the user has with his or her VSP to give the VSP customer roaming access to various wireless and wired internet access providers, both traditional carriers, such as 3G providers, as well as local hotspot providers (e.g., in hotels and airports). We propose an AAA and billing solution in which VSPs provide their users with tokens containing all the information that IAPs need for verifying their authorization right and activating the accounting and billing procedures. These tokens are computed and signed by a third provider, called guarantor, which also provides accounting and billing mediation services. Using the model proposed in this draft, by adding a smaller set of guarantors, IAPs that do not know VSPs, and vice versa, can offer services to the VSPs' customers. Figure 1 shows the trust model of the AAA solution proposed in this draft. +------------+ +-----------+ +-----------+ | internet | trust | | trust | voice | | access |<------------->| guarantor |<------------->| service | | provider | relationship | | relationship | provider | +------------+ +-----------+ +-----------+ ^ | | +------------+ | | | trust | | user |<------------+ | | relationship +------------+ Figure 1: trust model The role of the guarantor is somewhat similar to that of a clearinghouse with regard to the functions of settlement and billing, but it is different with regard to the function of authorization. In fact the clearinghouses are used for authorizing users' calls, while the guarantor provides authorization for the use of access network resources. One of the main protocols that develop clearinghouse- based models is the Open Settlements Protocol (OSP) [OSP]. This Greco Polito & Schulzrinne Expires March 19, 2007 [Page 3] Internet-Draft SIP and SAML roaming profile September 2006 proposes a token-based authorization model for interdomain calls in which telephony operators can ask a clearinghouse entity, for tokens proving the right of their users to activate calls toward some destination. In this draft we extend the concept of token introduced by OSP focusing on the authorization and authentication of roaming users inside of the authorization of users' calls. We want to define a token with a long lifetime that can be held by the users and can allow them to be authenticated and authorized to use access network resources from unknown internet access providers. We propose an authentication and authorization model in which users can provide the IAPs with their tokens. The IAPs use these tokens to authenticate and authorize the visiting users locally, without need of interaction with the users' VSPs. Because of that, security associations between the IAPs and the VSPs are not required and the AA delay does not dependent on the distance between the access network and the servers where the credentials and profiles of visiting users are stored. We remind that many of the roaming solutions proposed until now, such us the Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) [RFC4187], require interactions between the IAPs and the VSPs of the visiting users. The token-based AAA accounting and billing model for roaming users that we will propose in this draft, is composed of two main phases, the token provisioning phase and the AAA and billing phase. The first starts with a token request from the user to its VSP and closes with the provisioning of the token to the user. The second starts with a token-based authentication request from the user to the IAP and includes all the procedures that allow the IAP, the VSP and the guarantor to perform the AAA and billing using the token. In this draft we focus on the token provisioning phase. It is composed of the procedure that allows the user to ask for and obtain the token from its VSP, and the token building procedure. Both the VSP and the guarantor are involved in the token building procedure. The former knows the user profile and sends this information to the guarantor inside a token building request. When the guarantor receives a token building request, it builds the token and sends it to the VSP. In this draft we use the SAML protocol for the description of the token provisioning procedure defining a new SAML profile called roaming profile. The SAML [saml-core-2.0-os] is an OASIS protocol for the description and exchange of security information between partners. In this draft SAML extensions are defined for the description of the AAA and billing token and the messages used for the communication between VSPs and guarantor in the token provisioning phase. Moreover, this draft introduces a set of specifications that allow to use the SIP [RFC3261] protocol as carrier of the user's token request and the token response. The draft is organized as follows. In Section 2 we provide the Greco Polito & Schulzrinne Expires March 19, 2007 [Page 4] Internet-Draft SIP and SAML roaming profile September 2006 terminology used in the subsequent sections. In Section 3 we introduce the token-based AAA and billing model along with the functions that the user, the voice service provider, the guarantor and the internet access provider perform for the token provisioning procedure. In Section 4 we introduce the SAML profile. More in detail, in Section 4.1 we define the rules for the SAML-based description of the messages used by the VSP and the guarantor in the token building phase. In Section 4.2, we introduce the SAML roaming assertion that is the SAML-based description of the token. In Section 4.3 we describe the rules for using the SIP messages as carriers of the user's token request and the token response compiled by the VSP. In Section 5 we provide our security considerations about the proposed protocol. Section 6 contains details about the extensions to the SAML elements that support the SAML roaming profile. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 5] Internet-Draft SIP and SAML roaming profile September 2006 2. Terminology Voice Service Provider (VSP): provider of multimedia voice services (VoIP services). Internet access provider (IAP): provider of access network resources. Guarantor: provider of mediation services for AAA and billing. User: customer contracting with a VSP for obtaining VoIP and roaming services. Security Assertion Markup Language (SAML): set of specifications describing security assertions that are encoded in Extensible Markup Language (XML) [XML], profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols [saml-glossary-2.0-os]. SAML assertion: piece of data produced by a SAML authority regarding either an act of authentication performed on a subject, attribute information about the subject, or authorization data applying to the subject with respect to a specified resource [saml-glossary-2.0-os] AAA and billing token or roaming token: element asserting the user's right to access the network. It contains user authorization information and information needed to the IAP for activating the accounting and billing procedures. Roaming assertion: SAML-based description of the token. SAML Simple Object Access Protocol (SOAP) binding: definition on how to use SOAP to send and receive SAML requests and responses. This binding has protocol-independent aspects, but also calls out the use of SOAP over HTTP [saml-binding-2.0-os]. Roaming SAML profile: set of constraints and rules for using the SAML protocol and the SAML assertion capability in the roaming AAA and billing context of use. For the SIP terminology, see [RFC3261]. For the overall SAML terminology see [saml-glossary-2.0-os]. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 6] Internet-Draft SIP and SAML roaming profile September 2006 3. Protocol description Figure 2 shows the messaging between user, VSP and guarantor for the token provisioning procedure, and the one between user, IAP, guarantor and VSP for the AAA procedures. The token provisioning procedure is performed in the following steps: 1. The user starts the procedure sending a token request to its VSP. It is carried in a SIP REGISTER message (details about this message are provided in Section 4.3). 2. The VSP activates the SIP authentication procedure when it receives the token request and challenges the user using a SIP 407 response. 3. The user sends the response to the challenge in another SIP REGISTER Request as required by the SIP specifications. This request also contains the token request as the previous one did. 4. The VSP verifies the user credentials and if the user authentication is successful, sends a token building request to the guarantor asking him for composing and signing an assertion for its user. This request contains information that the guarantor needs for building the token such as the user profile and the token length (see Section 4.1 for the description of this request). 5. The guarantor builds and signs the token and returns it to the VSP. The token is described using the SAML protocol (see Section 4.2) and inserted in a token building response(see Section 4.1 for the description of the token building response). 6. The VSP, mines the token from the received token building response, and sends it to the user inside a token response (the description of this message is provided in Section 4.3). Greco Polito & Schulzrinne Expires March 19, 2007 [Page 7] Internet-Draft SIP and SAML roaming profile September 2006 IAP user VSP guarantor | | | | | token provisioning procedure | |<==========================================================>| | | | | | |1)Token request | | | | (SIP REGISTER) | | | |------------------->| | | | | | | |2)407 Proxy | | | | Authent. Req | | | |<-------------------| | | | | | | |3)Token request | | | | (SIP REGISTER: | | | |Proxy-Authorization)| | | |------------------->| | | | |4)Token building | | | | request | | | | (HTTP: SAML-token | | | | building request) | | | |-------------------->| | | | | | | |5)Token building | | | | response | | | | (HTTP:SAML-token | | | | building response) | | | |<--------------------| | |6)Token Response | | | | (SIP 200 OK) | | | |<-------------------| | | | | | | token-based AAA procedure | |<==========================================================>| | | | | |1)Token-based | | | | Access Request | | | |<----------------| | | | | | | |2)Access Response| | | |---------------->| | | | | | | |------------------3) Accounting records-------------------->| | | | | | | |4)Accounting records | | | |<--------------------| Greco Polito & Schulzrinne Expires March 19, 2007 [Page 8] Internet-Draft SIP and SAML roaming profile September 2006 Figure 2: messaging for token provisioning and token-based AAA The user stores the received token and uses it in its subsequent access requests to visited access networks. The assertion-based AAA of roaming users requires the following interaction between the parties involved: 1. The user sends a token-based access request containing the token to the IAP asking for network access resources. The method for providing the IAP with the token and getting the authentication and authorization response from it, may depend on the access technology used. For example, if the access network develops the 802.1x [802.1x], a new Extensible Authentication Protocol (EAP) [RFC3748] authentication method can be defined in order to encapsulate in the EAP messages the token-based access request and response. Details about the interface between user and access network will be provided in feature versions of this draft. 2. The IAP verifies the token validity and returns a response containing the authorization verification result to the user. 3. The IAP sends the accounting records with information about the activity of the visited user along with the received token to the guarantor. 4. The guarantor forwards the accounting records to the VSP. 3.1. User behavior The user supports SIP and asks the VSP for the token using a REGISTER request (see Section 4.3). The token request causes the activation of the SIP authentication procedure between user and VSP. At the end of this procedure, the user receives the token in a SIP 200 OK message (see Section 4.3). The user will use this token to ask the IAPs for internet access service until its expiration time. 3.2. VSP behavior The VSP uses SIP to communicate with the user, and HTTP [RFC2616] with the guarantor. Each time the VSP receives a token request, it authenticates the user using the SIP authentication features, and sends a token building request to the guarantor. The VSP is the entity that maintains a contract with the user and knows his authorization profile. The VSP includes in the token building request the user identity, the user's authorization profile, and the token length. It structures this request in the format of SAML request using the set of extensions defined in the Section 4.1 of Greco Polito & Schulzrinne Expires March 19, 2007 [Page 9] Internet-Draft SIP and SAML roaming profile September 2006 this draft. When it receives the token from the guarantor, it sends it to the user in the body of the 200 OK response to the REGISTER request (see Section 4.3). The VSP charges the user on the basis of accounting records received through the guarantor. 3.3. Guarantor behavior The guarantor builds and signs tokens for VSPs that are its customers. When the guarantor receives the token building request, it builds the token in which inserts the information contained in the request along with its identifier, the Domain name of the VSP, its signature and its public key. It signs the token using its private key. The signature guarantees integrity, data origin and non repudiation of the token. The guarantor composes the token in the format of SAML assertion as described in Section 4.2 and returns it to the VSP. It uses the SAML assertion response specifications for describing the token building response (see Section 4.1 for details). The guarantor is responsible for paying the IAPs that authorize the user on the basis of its signature on the token. The guarantor receives accounting records from the IAPs that it uses to measure the amount of network resources used by the user. It asks the VSP for reimbursement and forwards the accounting records to it. 3.4. IAP behavior The verification of the token integrity is the first task performed by the IAP when it receives it from a visiting user. It uses the guarantor public key carried in the token for the verification. If the token is not corrupted, the access provider verifies its expiration time. If the token is not expired, the IAP allows the user to access the network. The digital signature guarantees non repudiation of the token and gives the right to ask the guarantor for the payment of the access resources used by visiting users to the IAP. The IAP provides the guarantor with accounting records monitoring the user behavior. It is not interested in knowing the entity that has authenticated the user because the guarantor guarantees the payment for the access resources inside of the VSP. The IAP inserts the VSP's domain name and the user identifier mined from the token in the accounting records. The former allows the guarantor to identify the VSP to which it has to refer for accounting and billing. The latter allows the VSP to identify the user to charge. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 10] Internet-Draft SIP and SAML roaming profile September 2006 4. Roaming SAML profile The SAML protocol defines a way for the exchange of security information about a subject between partners called requesting, asserting and relying parties. The asserting party is the entity that produces an authentication and authorization assertion about a subject when required by the requesting party. While the relying party uses the assertion for authorizing the subject. This draft defines a new SAML profile, called roaming SAML profile. It defines a set of specifications that allows to use SAML for the description of the token and the token building request and response. In the SAML roaming profile, the VSPs assumes the role of SAML requesting parties, the guarantor the one of asserting party, and IAPs the one of relying parties. In the following we will call the SAML assertion describing the token roaming assertion. 4.1. Token building request and response The token building request is the message used by the VSP for asking the guarantor for the token (see step 3 of the token provisioning procedure of Figure 2). It is structured as a SAML request and is described using the following elements: o The Issuer. This SAML element contains the identifier of the entity generating the request message. It contains the VSP's domain name in this context of use. o The Subject. It contains the identifier of the subject of the assertion and it is set to the SIP URI of the user in the token building request. o The Conditions. This element allows the SAML requesting party to propose restriction conditions limiting the validity and/or use of the assertion. In this context it is used by the VSP for providing the guarantor with information about the assertion length and the user profile. For the description of the token length we use the SAML Notbefore and NotOnOrAfter attributes of the assertion element. The first is set with the start time of the token, the second with the expiration time of the token. For the description of the user profile and its inclusion in the Conditions element, we propose an extension of the SAML ConditionAbstractType described in Section 6.1. Figure 3 shows an example of the token building request described using the elements introduced above. See Section 6.2 for the description of the XML schema of this request. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 11] Internet-Draft SIP and SAML roaming profile September 2006 serviceprovider.example.com bob@example.com Gold Figure 3: XML token building request example The token building response is the message used by the guarantor for providing the VSP with the token (see step 4 of the assertion provisioning procedure of Figure 2). The guarantor compiles it following the SAML processing rules [saml-core-2.0-os] for the response to a generic SAML query message, mapping this response in the SAML Response element. The SOAP SAML binding described in [saml-binding-2.0-os] is used for the transport of the token building Greco Polito & Schulzrinne Expires March 19, 2007 [Page 12] Internet-Draft SIP and SAML roaming profile September 2006 request and response. This binding defines how to use HTTP and SOAP to send and receive SAML requests and responses. 4.2. SAML roaming assertion We call roaming assertion the token described using the SAML assertion [saml-core-2.0-os] specifications and the set of extensions provided in this section. The token is mapped in the SAML Assertion element and its content is described using the following SAML elements: o The Issuer. In a generic SAML assertion, this element contains the identifier of the identity that is making the claim in the assertion and it is set with the guarantor identifier in a roaming-assertion. o The Signature. This element contains the signature provided by the guarantor. Following the OASIS specification [saml-core-2.0-os] [saml-sec-consider-2.0-os] for this element, the guarantor computes it using the XML signature specifications [xmldsig]. o The Subject. It contains the SIP URI of the user which is the subject of the statement in the roaming assertion. o The Conditions. In a generic SAML assertion, this element contains information that must be evaluated by the relying party for the verification and use of the assertion. In this context the NotBefore and NOtOnOrAfter attributes of this element are used for describing the start and expiration time of the token. o The Statement. It is an SAML extension point defined for allowing the use of SAML in new contexts. This draft defines an extension of the SAML type of the Statement element in order to include in this element the domain name of the VSP and information about the user profile. The XML schema of the extension to the type of the Statement element is provided in Section 6.3. Figure 4 shows an example of the roaming assertion. guarantor.example.com UmhxeI9DkkQU0iVs4FfiXYvTkMQ= jNFui......... MIIE........... bob@example.com Greco Polito & Schulzrinne Expires March 19, 2007 [Page 14] Internet-Draft SIP and SAML roaming profile September 2006 serviceprovider.example.com Gold Figure 4: XML roaming assertion example 4.3. Token request and response The token request and response are the messages used in the interface between user and VSP in the token provisioning procedure. As introduced above, this approach uses SIP protocol features for the description and the transport of these messages. It proposes to bind the assertion provisioning procedure to the SIP registration one (see Section 3.1) using the REGISTER message as carrier of the token request, and the 200 OK message as carrier of the token response and the roaming assertion. To achieve this scope, we propose to use the Supported header[draft-ietf-sip-serverfeatures-02], and we define the tag token_extension to describe the roaming extension defined in this draft. The user adds the Supported header with the tag token_extension to the REGISTER message in order to communicate to the SIP server that he supports that extension. The SIP server holds information about the tokens provided to their users, and when it receives a REGISTER message with the Supported header containing the token_extension tag, it checks if the last token provided to the user is expired or active. If the token is active, the SIP server registers the user and sends a 200 OK message to the user. If the token is expired, the SIP server has to register the user and provide him with a new token. It activates the token building procedure and sends the token to the user inside the body of the 200 OK response to the REGISTER. It inserts the tag token_extension in the Require[draft-ietf-sip-serverfeatures-02] header of the 200 OK message, and sets its Content Type Header with the application/ samlassertion+xml [application/samlassertion+xml] media type value. Other task that the SIP server performs when it receives the REGISTER message with the token_extension tag in the Supported header, is the verification of the registration length requested by the user that cannot go over the token expiration time. We remind that the SIP registration procedure creates a binding in a SIP location server that associates the SIP URI of the user with its contact of address, and that the user asks for the refresh of its registration with a new REGISTER request each time its previous registration expires. We Greco Polito & Schulzrinne Expires March 19, 2007 [Page 15] Internet-Draft SIP and SAML roaming profile September 2006 impose that the registration time does not have to go over the expiration time of the token in order to have a registration request from the user each time his token expires, and to avoid that a user with expired token can use SIP services. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 16] Internet-Draft SIP and SAML roaming profile September 2006 5. Security Considerations The security properties of the proposed protocol depend on the security features of SIP and SAML. VSP uses the SIP authentication features and authenticate the user before accepting his token requests for avoiding that malicious subjects impersonating him obtain assertions. For the same reason the guarantor authenticates the VSP before accepting its token building request. The VSP has to authenticate the guarantor before sending the token building request because this contains private information about the user. The VSP and the guarantor may use the SAML authentication features described in [saml-sec-consider-2.0-os]for their mutual authentication. Moreover they must guarantee confidential transport of the assertion encrypting the SOAP messages as specified for the SOAP SAML binding in [saml-sec-consider-2.0-os]. This avoids that users eavesdropping the conversation can make copies of the assertion. For the same reason VSPs encrypt the bodies of the 200 OK responses carrying assertions. Alternatively, the involved parties may use the Transport Layer Security (TLS) protocol [RFC2246] which allows building secure communication channel between them. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 17] Internet-Draft SIP and SAML roaming profile September 2006 6. XML schemas In this section we provide the XML schemas of the elements and types defined in this draft to support the SAML roaming profile. 6.1. XML schema of the Condition element As introduced in Section 4.1, the SAML Condition element is used for describing the token lifetime and the user profile. For the description of the token lifetime we use the Notbefore and NotOnOrAfter attributes of this element defined in [saml-core-2.0-os]. For the description of the user profile, we define the condition_profileType. It extends the ConditionAbstractType of the Condition element defined in [saml-core-2.0-os] and adds the UserProfile element to it. We use the quality of service class for describing the user profile. The quality of service class is described using the values Gold, Bronze, Silver. Figure 5 shows the xml schema of the condition_profileType. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 18] Internet-Draft SIP and SAML roaming profile September 2006 Figure 5: XML schema of the condition_profileType 6.2. XML schema of the token building request The token building request is described extending the SAML type RequestAstractType [saml-core-2.0-os] of a generic SAML request. As described in the XML schema of Figure 6, the extension that we propose adds the Subject and the Conditions element to the ones of the RequestAbstractType. The Subject element is used for including the SIP URI in the request. The Conditions element allows to introduce the token lifetime and the user profile in the token building request. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 19] Internet-Draft SIP and SAML roaming profile September 2006 Figure 6: XML schema of the token building request 6.3. XML schema of the Statement element Figure 7 shows the XML schema of the type of the Statement element of the roaming assertion. It is obtained as extension of the StatementAbstractType defined in [saml-core-2.0-os]. It allows to include in the Statement element of the roaming assertion the domain name of the VSP, and the policy_info element. This carries information about the user profile and has the type defined in Section 6.1. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 20] Internet-Draft SIP and SAML roaming profile September 2006 Figure 7: XML schema of the roaming Statement element type Greco Polito & Schulzrinne Expires March 19, 2007 [Page 21] Internet-Draft SIP and SAML roaming profile September 2006 7. Acknowledgements The authors thanks Andrea Forte for his contribute to the discussion on the security property of the model. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 22] Internet-Draft SIP and SAML roaming profile September 2006 8. References 8.1. Normative References [802.1x] IEEE, "Port-based network access control", 2001. [OSP] European Telecommunications Standards Institute, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization and usage exchange", 2003. [RFC2246] Dierks, T. and C. C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol HTTP 1/1", RFC 2616, June 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., and J. Peterson, "Session Initiation Protocol", RFC 3261, June 2002. [RFC3748] Fielding, R., Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", June 2004. [RFC4187] J. Arkko, J. and H. H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006. [XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998. [application/samlassertion+xml] OASIS Security Services Technical Committee, "application/ samlassertion+xml MIME Media Type Registration", IANA MIME Media Types application/samlassertion+xml, December 2004. [saml-binding-2.0-os] Cantor, S., Hirsch, F., Philpott, R., and E. Maler, "Binding for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-binding-2.0-os, March 2005. [saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, Greco Polito & Schulzrinne Expires March 19, 2007 [Page 23] Internet-Draft SIP and SAML roaming profile September 2006 "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [saml-glossary-2.0-os] Hodges, J., Philpott, R., and E. Maler, "Glossary for Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-glossary-2.0-os, March 2005. [saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-profiles-2.0-os, March 2005. [saml-sec-consider-2.0-os] Hirsch, F., Philpott, R., and E. Maler, "Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0", OASIS saml-sec-consider-2.0-os, March 2005. [xmldsig] World Wide Web Consortium, "XML-Signature Syntax and Processing", W3C Recommendation xmldsig, October 2000. 8.2. Informative References [draft-ietf-sip-serverfeatures-02] Rosenberg, J. and H. Schulzrinne, "The SIP Supported Header", draft draft-ietf-sip-serverfeatures-02, September 2000. Greco Polito & Schulzrinne Expires March 19, 2007 [Page 24] Internet-Draft SIP and SAML roaming profile September 2006 Authors' Addresses Silvana Greco Polito University of Palermo Viale delle Scienze Palermo, Sicily 90100 Italy Email: silvana.greco@tti.unipa.it, silvana@cs.columbia.edu Henning Schulzrinne Columbia University 450 Computer Science Building New York, NY 10027 US Email: hgs@cs.columbia.edu Greco Polito & Schulzrinne Expires March 19, 2007 [Page 25] Internet-Draft SIP and SAML roaming profile September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Greco Polito & Schulzrinne Expires March 19, 2007 [Page 26]