SIPPING S. Schubert Internet-Draft NTT Expires: December 14, 2006 H. Tschofenig Siemens M. Dolly AT&T T. Ohba NTT June 12, 2006 Conveying Calling Party Category (CPC) and Originating Line Information (OLI) using the Security Assertion Markup Language (SAML) draft-schubert-sipping-saml-cpc-01.txt 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 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document investigates and evaluates the usage of the Security Assertion Markup Language (SAML), "SAML HTTP-URI-Based SIP Binding" (SHUSB) for conveying Calling Party Category (CPC) and Originating Schubert, et al. Expires December 14, 2006 [Page 1] Internet-Draft Conveying CPC using the SAML June 2006 Line Information (OLI). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ACR Override . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Call-back from Law Enforcement . . . . . . . . . . . . . . 4 3.3. PSTN Interaction . . . . . . . . . . . . . . . . . . . . . 4 3.4. Call Prioritization . . . . . . . . . . . . . . . . . . . 4 4. SHUSB Solution Discussion . . . . . . . . . . . . . . . . . . 5 4.1. Assertion's Presence . . . . . . . . . . . . . . . . . . . 5 4.2. Assertion's Contents . . . . . . . . . . . . . . . . . . . 5 4.3. Extra Round Trips . . . . . . . . . . . . . . . . . . . . 5 5. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Content Indicator . . . . . . . . . . . . . . . . . . . . 6 5.2. New SIP SAML Profile . . . . . . . . . . . . . . . . . . . 6 5.2.1. By-Value in Body . . . . . . . . . . . . . . . . . . . 7 5.2.2. By-Value in Header . . . . . . . . . . . . . . . . . . 7 6. Call Flow Examples . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Using SHUSB . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. By-Value in Body . . . . . . . . . . . . . . . . . . . . . 9 6.3. By-Value in Header . . . . . . . . . . . . . . . . . . . . 10 7. Originating Line Indication . . . . . . . . . . . . . . . . . 10 8. Calling Party Category . . . . . . . . . . . . . . . . . . . . 11 9. XML Schema for Originating Line Indication . . . . . . . . . . 11 10. XML Schema for Originating Line Indication . . . . . . . . . . 11 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 15.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Schubert, et al. Expires December 14, 2006 [Page 2] Internet-Draft Conveying CPC using the SAML June 2006 1. Introduction SS7 ISUP [8] defines a Calling Party's Category (CPC) and Originating Line Information (OLI) parameters that characterizes the station used to originate the call and carries other important state that can describe the originating party. CPC and OLI are widely deployed in ISUP network and used to alter the handling of the messages, such as prioritizing etc. CPC and OLI characterize the originating party. The information carried in CPC or OLI may not be privacy sensitive, but needs to be trustworthy enough for the receiving party to make an appropriate policy decision on how to handle the call. This is especially important when CPC and OLI are to be carried using the Session Initiation Protocol (SIP) [2]. For example, the receiving party may preempt other calls to prioritize the target call or to allow access to resources depending on the information carried in CPC or OLI. The use case of asserting parameters, such as CPC and OLI, and to make them available to other parties to make decisions is termed as "trait-based authorization" (see [7]). The Security Assertion Markup Language (SAML) [5] seems to be promising solution to convey CPC and OLI in SIP. This draft explores the applicability of "SAML HTTP-URI-Based SIP Binding" (SHUSB) defined in the "SIP SAML Profile and Binding" document [3] for conveying CPC and OLI. 2. Terminology 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 [1]. Additionally, the following terms are used: Calling Party Category: Calling Party Category is an attribute of a caller that characterizes the caller. It generally represents an organization caller is associated with. (Police, Operator etc.) Asserting Party: An asserting Party is an entity, which by some means authorize and authenticate the target for an assertion and it is an entity that will verify the assertion when recipient of an assertion inquires about the assertion's validity. Assertion: An assertion is an XML document that contains authentication statements, attribute statements and authorization Schubert, et al. Expires December 14, 2006 [Page 3] Internet-Draft Conveying CPC using the SAML June 2006 decision statements. In an authentication statement, an issuing authority asserts that a certain subject was authenticated by certain means at a certain time. In an attribute statement, an issuing authority asserts that a certain subject is associated with certain attributes which has certain values. In an authorization decision statement, a certain subject with a certain access type to certain resource has given certain evidence that the identity is correct. The assertion is digitally signed to protect it against unwanted modifications by third parties. 3. Use Cases 3.1. ACR Override A User Agent Server (UAS), a proxy and other servers might have Anonymous Call Rejection (ACR) service enabled that rejects incoming calls when they are anonymous. The same entity that has ACR service enabled might have a local policy, by which upon receiving a call with a specific CPC value such as "police", it would allow the call to go through even when the caller is identified as anonymous, by overriding the ACR service. 3.2. Call-back from Law Enforcement A Voice Service Provider/Application Sercice Provider might have a local policy to return an AoR of their subscriber by overriding their general privacy policy when it is requested from an organization with an appropriate CPC value (e.g., Police, PSAP etc.). This might be useful for example when PSAP which had received an anonymous call that was disconnected and need to make a call-back to complete the dispatch. 3.3. PSTN Interaction CPC and OLI in ISUP message can be mapped to CPC and OLI attributes defined here in this draft for interconnecting SIP networks and ISUP networks. 3.4. Call Prioritization Intermediaries on the signaling path might prioritize the call according to the value carried in CPC. For example, if the call is from the police and the call is tagged with the CPC value set to "police", the intermediaries on the signaling path might alter the routing to prioritize the call or preempt other calls to ensure that the call reaches the target party. Schubert, et al. Expires December 14, 2006 [Page 4] Internet-Draft Conveying CPC using the SAML June 2006 4. SHUSB Solution Discussion SHUSB has drastically simplified the way SAML is used in SIP by defining a "mediated" authentication architecture where Authentication Service (AS) also acts as a SAML Authority (Asserting Party). The profile also eliminated various ways of obtaining and conveying SAML assertion by limiting the model used to "PULL Model" alone. This simplification although beneficial when used in context of end- to-end SAML usage raises some performance questions when CPC is to be conveyed using the SHUSB and consumed by intermediaries. 4.1. Assertion's Presence SHUSB reuses the SIP-Identity [4] and the Identity-Info header as a placeholder to hold the reference to the SAML assertion. Because the Identity-Info header permits reference to either a public certificate of the domain or to the SAML assertion, it is non-deterministic whether a SAML assertion is available at the URI referenced in the Identity-Info header. This indeterminacy of assertion's presence will cause verifier/consumer to attempt fetching the document even if there is no SAML assertion present at the URI. 4.2. Assertion's Contents Currently SHUSB does not define a way to represents what information SAML assertion will contain. One can only find out by fetching the document. As intermediaries along the signaling path are supposed to consume the SAML assertion if CPC is to be carried using SAML, increase in number of intermediaries along the signaling path can cause unnecessary processing on each of the intermediaries fetching the SAML assertion and results in additional call setup delay. 4.3. Extra Round Trips SHUSB requires consuming/verifying entity whether it's a proxy or an UAS to use HTTP or HTTPS to fetch the SAML assertion referenced in SIP-Identity header. With the increased number of intermediaries along the signaling path, which need to process the SAML assertion, the call setup delay increases due to the round trips required by each proxy to dereference the URI reference to a SAML assertion. Schubert, et al. Expires December 14, 2006 [Page 5] Internet-Draft Conveying CPC using the SAML June 2006 5. Possible Solutions Section 4 described a few challenges when using the currently specified SHUSB for CPC and OLI. conveyance There is, however, room for improvement. This section provides a number of alternatives and lists their advantages and disadvantages. 5.1. Content Indicator Two of the issues realized in the previous sections were related to uncertainty of the contents at the URI provided through Identity-Info header. This may be solved by defining a parameter that can be used along with the URI in the Identity-Info header to indicate the presence of SAML assertion Furthermore, an indicator to hint the type of information that is contained in the SAML assertion might be useful as well. As an example, the SAML Attribute Profiles listed in Section 8 of [6] provide an identification of the attributes. This allows to group several attributes to an application (e.g., urn:oasis:names:tc:SAML:2.0:profiles:attribute:DCE identifier for DCE PAC information). Pros: The SAML assertion will only be fetched when the content of the SAML assertion is believed to be useful by the entity handling the call. The SAML assertion will only be fetched when there is a SAML assertion at the URI presented in Identity-Info header. Requires no extensions on UAC. Cons: Call setup delay anticipated due to the nature of "Pull Model" is not resolved. 5.2. New SIP SAML Profile To solve the third issue presented in the previous section, defining an additional SIP SAML profile that would allow the SAML assertion to be carried by-value in the SIP header may be considered. Note: It is assumed that asserting party is played by the Authentication Service and SIP-Identity is still used to provide the integrity protection over request, and the same key is used for signing SAML assertion and Identity header. Schubert, et al. Expires December 14, 2006 [Page 6] Internet-Draft Conveying CPC using the SAML June 2006 5.2.1. By-Value in Body As the SAML assertion can become quite large, logical means to carry the SAML assertion would be to carry it in the message body. Pros: Once the public key of the asserting domain is obtained, no extra round trip will be necessary at the consuming/verifying party. Cons: S/MIME cannot be used when intermediaries need to consume/verify the SAML assertion and the SAML assertion is placed in the body. (Although end-2-middle security [8] may be used.) Requires extension on UAC to support the fetching and inclusion of SAML assertion. 5.2.2. By-Value in Header Another approach would be to include the SAML assertion in the header. By including the header field that carries SAML assertion to be part of the target header for calculating the hash for Identity header, integrity of the SAML assertion can be achieved and many of the security threats anticipated by the inclusion in the header is eliminated. Pros: S/MIME can be used for end-to-end encryption of body. Requires no extensions on the UAC. Once the public key of the asserting domain is obtained, no extra round trip will be necessary at the consuming/verifying entity. Cons: Increase in the header size. 6. Call Flow Examples 6.1. Using SHUSB The following call flow shows a basic retrieval of an assertion or URI reference by intermediaries on the signaling path when SHUSB is used. Schubert, et al. Expires December 14, 2006 [Page 7] Internet-Draft Conveying CPC using the SAML June 2006 ----------- ------------- ------------- ------------- ----------- | Alice's | | providerA | | proxy.B | | proxy.C | | Bob's | | phone | | .com | | .com | | .com | | phone | ----------- ------------- ------------- ------------- ----------- | | | | | | INVITE | | | | |------------>| | | | | 407 | | | | |<------------| | | | | INVITE + | | | | | Digest | | | | |------------>| | | | | | INVITE + | | | | | Identity-Info| | | | |------------->| | | | | SAML request | | | | |<-------------| | | | |SAML response | | | | | + Assertion | | | | |------------->| | | | | |INVITE + | | | | |Identity-Info| | | | |------------>| | | | SAML request | | | |<---------------------------| | | | SAML response + Assertion | | | |--------------------------->| | | | | | INVITE + | | | | | Identity-Info| | | | |------------->| | | SAML request | | |<------------------------------------------| | | SAML response + Assertion | | |------------------------------------------>| | 180 Ringing | |<--------------------------------------------------------| | 200 OK | |<--------------------------------------------------------| | ACK | |-------------------------------------------------------->| | Media Stream | |<=======================================================>| | | Figure 1: Using SHUSB Schubert, et al. Expires December 14, 2006 [Page 8] Internet-Draft Conveying CPC using the SAML June 2006 6.2. By-Value in Body The following call flow shows a basic retrieval of an assertion/ artifact by intermediaries on the signaling path with SAML assertion in the message body. As shown in the figure, UAC needs to retrieve the artifact before establishing the call. ----------- ------------- ------------- ------------- ----------- | Alice's | | proxy.atl | | Asserting | | proxy.bil | | Bob's | | phone | | anta.com | | Party | | oxi.com | | phone | ----------- ------------- ------------- ------------- ----------- | | | | | | Request Assertion for CPC | | | |--------------------------->| | | | User Authentication | | | | and Authorization | | | |<---------------------------| | | |--------------------------->| | | | SAML artifact | | | |<---------------------------| | | |<---------------------------| | | | INVITE + SAML artifact | | | |------------>| | | | | | INVITE + SAML assertion | | | |---------------------------->| | | | | | INVITE | | |------------>| | 180 Ringing | |---------------------------------------------------------| | | | 200 OK | |<--------------------------------------------------------| | ACK | |-------------------------------------------------------->| | Media Stream | |<=======================================================>| | | Figure 3:By-Value in Body Schubert, et al. Expires December 14, 2006 [Page 9] Internet-Draft Conveying CPC using the SAML June 2006 6.3. By-Value in Header The following call flow shows a basic retrieval of an assertion/ artifact by intermediaries on the signaling path with SAML assertion in the header. ----------- ------------- ------------- ------------- ----------- | Alice's | | providerA | | proxy.B | | proxy.C | | Bob's | | phone | | .com | | .com | | .com | | phone | ----------- ------------- ------------- ------------- ----------- | | | | | | INVITE | | | | |------------>| | | | | 407 | | | | |<------------| | | | | INVITE + | | | | | Digest | | | | |------------>| | | | | | INVITE + | | | | |SAML assertion| | | | |------------->| | | | | |INVITE + | | | | |SAML assertion| | | | |------------->| | | | | | INVITE | | | | |------------->| | 180 Ringing | |<---------------------------------------------------------| | 200 OK | |<---------------------------------------------------------| | ACK | |--------------------------------------------------------->| | Media Stream | |<========================================================>| | | Figure 1: By-Value in Header 7. Originating Line Indication Predefined Values for OLI is taken from CPC/OLI defined in ISUP: Schubert, et al. Expires December 14, 2006 [Page 10] Internet-Draft Conveying CPC using the SAML June 2006 payphone: The calling station is a payphone. prison: The calling station is in a prison. hotel: The calling station is in a hotel or motel. hospital: The calling station is in a medical facility. police: The calling station is associated with a branch of law enforcement. cellular: The calling station is a radio-telephone operating in its home network. cellular-roaming: The calling station is a radio-telephone roaming in another network. 8. Calling Party Category Predefined Values for calling party category is taken from CPC/OLI defined in ISUP: payphone: The caller has been identified as a payphone user. ordinary: The caller has been identified, and has no special features. operator: The call was generated by an operator position. 9. XML Schema for Originating Line Indication payphone 10. XML Schema for Originating Line Indication ordinary Schubert, et al. Expires December 14, 2006 [Page 11] Internet-Draft Conveying CPC using the SAML June 2006 11. Example This section presents an example SAML assertion. Figure X, the assertion is attesting with respect to the subject (lines 7-15) "Alice@example.com" (line 11). The validity conditions are expressed in lines 16-23, via both a validity period expressed as temporal endpoints, and an "audience restriction" stating that this assertion's semantics are valid for only the relying party named "example2.com". Also, the assertion's issuer is noted in lines 4-5. The authentication statement in lines 24-30 indicate that the issuer is attesting to having authenticated the subject using the mechanism denoted in the > AuthnContext < element. Lines 31-37 provide information about the Originating Line Indication (OLI) stating that the calling station is a pay phone. Schubert, et al. Expires December 14, 2006 [Page 12] Internet-Draft Conveying CPC using the SAML June 2006 1 4 5 example.com 6 7 8 11 Alice@example.com 12 13 15 16 18 19 20 example2.com 21 22 23 24 25 26 27 urn:oasis:names:tc:SAML:2.0:ac:classes:Password 28 29 30 31 32 35 payphone 36 37 38 Figure 4: Unsigned SAML Assertion Illustrating Conveyance of OLI Attribute 12. Security Considerations TBD Schubert, et al. Expires December 14, 2006 [Page 13] Internet-Draft Conveying CPC using the SAML June 2006 13. IANA Considerations TBD. 14. Acknowledgement I like to thank Erick Sasaki and Christian Schmidt for providing constructive feedbacks to this draft. 15. References 15.1. Normative Reference [1] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, ""SIP: Session Initiation Protocol"", RFC 3261, June 2002. [3] Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. Slicker, ""SIP SAML Binding for SIP"", Draft draft-ietf-sip-saml-00.txt, June 2006. [4] Peterson, J. and C. Jennings, ""Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"", Draft draft-ietf-sip-identity-06.txt, October 2005. [5] Cantor, S., Kemp, J., Philpott, R., and E. Maler, ""Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0"", OASIS Standard saml-core-2.0-os, March 2005. [6] 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- profile-2.0-os, March 2005. 15.2. Informative Reference [7] Peterson, J., ""Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)"", Draft draft-ietf-sipping-trait-authz-02, January 2006. [8] INTERNATIONAL Telecommunications Union, "Signaling System No. 7: ISDN user part formats and codes", Recommendation Q.763, September 1997. Schubert, et al. Expires December 14, 2006 [Page 14] Internet-Draft Conveying CPC using the SAML June 2006 [9] Ono, K. and S. Tachimoto, "End-to-middle Security in the Session Initiation Protocol (SIP)", draft draft-ietf-sip-e2m-sec-01, October 2005. Schubert, et al. Expires December 14, 2006 [Page 15] Internet-Draft Conveying CPC using the SAML June 2006 Authors' Addresses Shida Schubert NTT Corporation 1094 W 15th Ave Vancouver, BC V6H 1R6 Canada Phone: +1 604 762 5606 Email: shida at ntt-at.com URI: http://www.ntt.co.jp/ Hannes Tshofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: Email: Hannes.Tschofenig at siemens.com URI: http://www.siemens.com/ Martin Dolly AT&T San Francisco, CA 94110 US Phone: Email: mdolly at att.com URI: http://www.att.com/ Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7748 Email: ohba.takumi at lab.ntt.co.jp URI: http://www.ntt.co.jp Schubert, et al. Expires December 14, 2006 [Page 16] Internet-Draft Conveying CPC using the SAML June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schubert, et al. Expires December 14, 2006 [Page 17]