Network Working Group S. Schubert Internet-Draft NTT Expires: July 5, 2006 H. Tschofenig Siemens M. Dolly AT&T January 2006 Calling Party Category using SAML draft-schubert-sipping-saml-cpc-00.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 July 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Ability to convey a trait information of caller, such as calling party category which includes things like Law Enforcement, Technical Support, Anonymous Caller from Payphone etc. and type of location where the call initiated which includes things like Police Station, Hotel/Motel, Fire Station, Jail etc. might be useful for receiving Schubert, et al. Expires July 5, 2006 [Page 1] Internet-Draft Calling Party Category using SAML January 2006 entity of the call to make an authorization decision on its treatment of incoming call. This draft proposes an approach for conveying trait information for caller's category and call initiating point in SIP using the Security Assertion Markup Language(SAML). It relies on a third party to act as an asserting party to provide information described above. This draft is in a fairly early state and has many details that are missing. This version tries to describe and illustrate what the SAML based solution would look like to aid in evaluating SAML as solution to carry calling party's category and call initiating location information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. ACR Override . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Call back from Law Enforcement . . . . . . . . . . . . . . 7 3.3. PSTN Interaction . . . . . . . . . . . . . . . . . . . . . 7 3.4. Station Type and Privacy Setting . . . . . . . . . . . . . 7 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Server Behaviors . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Home Proxy with request . . . . . . . . . . . . . . . . . 12 6.2. Outbound Proxy with request . . . . . . . . . . . . . . . 13 6.3. Server Behavior receiving requests . . . . . . . . . . . . 14 7. Examples Call Flows . . . . . . . . . . . . . . . . . . . . . 16 7.1. Example Flow 1 . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Example Flow 2 . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Example Flow 3 . . . . . . . . . . . . . . . . . . . . . . 19 7.4. Example Flow 4 . . . . . . . . . . . . . . . . . . . . . . 21 8. Station Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Calling Party Category . . . . . . . . . . . . . . . . . . . . 24 10. XML Schema for Calling Party Category . . . . . . . . . . . . 25 11. XML Schema for Station Type . . . . . . . . . . . . . . . . . 26 12. XML Example for Calling Party Category . . . . . . . . . . . . 27 13. XML Example for Station Type . . . . . . . . . . . . . . . . . 28 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16.1. Normative Reference . . . . . . . . . . . . . . . . . . . 31 16.2. Informative Reference . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Schubert, et al. Expires July 5, 2006 [Page 2] Internet-Draft Calling Party Category using SAML January 2006 1. Introduction The Session Initiation Protocol(SIP), RFC 3261[2] is used to establish and maintain a dialog between a pair of User Agents(UA) in order to manage a communications session. Just as one might set up a white list and black list to prioritize a treatment of incoming calls, prioritizing calls and differentiating the treatments of incoming calls according to traits and meta data of caller might be desirable at time. It is at least proven useful to convey and consume some trait information to differentiate the treatments of incoming calls in PSTN/ISDN, and it might be equally useful in SIP. SS7 ISUP defines a Calling Party's Category(CPC) and OLI(Originating Line Information) parameters that characterizes the station used to originate the call and carries other important state that can describe the originating party. Looking at the semantics of the information carried in CPC and OLI, there are 3 distinctive types/categories of information. Trait information representing the caller or caller's organization which we call Calling Party's Category(CPC) in this draft, information representing the station where call is originating, which we call Station Type(ST) in this draft and information describing a type of call which is not considered in this draft as there are likely other ways to describe a call type using pre-existing SIP mechanisms and extensions. When CPC or OLI carried in ISUP messages are to be carried in SIP, the party responsible for each of this information may differ from when they are carried in ISUP messages. For example, trait information associated with the caller and caller's organization(CPC) are likely to be managed by the home service provider, on the other hand information characterizing station where call is originating are likely to be provided through the service provider serving the local network where user is connected. Putting it into SIP terms, from the caller's viewpoint, trait information characterizing the caller(CPC) is likely to be provided through the service provider serving the home network and is likely to be bound or linked with the AoR or the domain of the AoR. Trait information characterizing the station where call is initiated(ST) is likely to be provided through service provider serving the local network which can be a network which user had no previous relationship. It is also important to note that many of the values carried either Schubert, et al. Expires July 5, 2006 [Page 3] Internet-Draft Calling Party Category using SAML January 2006 in CPC or OLI are meaningless outside of PSTN or can be represented using another existing mechanism or/and extension. For example, the language of an operator can be expressed more richly using the Accept-Language head in SIP, emergency call can be expressed better using the SOS URI and Service URI defined in [5], and priority of the call can be represented using [6]. If these informations are primarily consumed by the gateway that interworks ISUP networks with SIP networks, and information are generally only carried in one way direction from ISUP networks to SIP networks, mechanism in consideration such as SAML might not be necessary. But as traits information described here alter the callee's treatments of incoming calls, sometime so much so that other calls in progress might be pre-empted to prioritize the calls with trait information with higher priority, it is important when deployed in SIP, that callee has a way to assure and ascertain that the trait information provided is valid and verifiable. This draft explores what it would be like to retrieve and carry trait information such as CPC and ST using SAML and SIP to see if it really satisfies the property desired for exchanging these trait information. Schubert, et al. Expires July 5, 2006 [Page 4] Internet-Draft Calling Party Category using SAML January 2006 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]. This work adopts the terminology from the framework in [4] Additionally, the following terms are used: Calling Party Category: Calling Party Category is an attribute of a caller that characterizes caller. It generally represents the kind of organization caller is associated with.(Police, Operator etc.) Station Type: Station type is an attribute which characterizes the location(facility) used to originate the call. 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 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 a 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. Artifact: An artifact is a base-64 encoded string that is 40 bytes long that serves as a pointer to a server that temporarily stores an assertion. The first 20 bytes provide an indication from which server the assertion needs to be retrieved. The remaining 20 bytes identify a unique assertion. Application Service Provider(ASP):The organization or entity that provides application-layer services, which may include voice (see "Voice Service Provider"). This entity can be a private individual, an enterprise, a government, or a service provider. An ASP is defined as something more general than a Voice Service Provider, since emergency calls are sometimes likely to use other media, including text and video. Note: For a particular user, the ASP may or may not be the same organization as the IAP and/or ISP. Schubert, et al. Expires July 5, 2006 [Page 5] Internet-Draft Calling Party Category using SAML January 2006 Voice Service Provider (VSP): A specific type of Application Service Provider which provides voice related services based on IP, such as call routing, a SIP URI, or PSTN termination. Internet Attachment Provider (IAP): An organization that provides physical network connectivity to its customers or users, e.g. through digital subscriber lines, cable TV plants, Ethernet, leased lines or radio frequencies. Examples of such organizations include telecommunication carriers, municipal utilities, larger enterprises with their own network infrastructure, and government organizations such as the military. Schubert, et al. Expires July 5, 2006 [Page 6] Internet-Draft Calling Party Category using SAML January 2006 3. Use Cases Many usecases are likely to be realized as category of information defined in this draft becomes readily available to be consumed by servers, but here are some possible usecases. 3.1. ACR Override Some User Agent Server(UAS), proxy and other servers might have Anonymous Call Rejection(ACR) service, which rejects call when the incoming call is an anonymous call. The same entity that has ACR service activated might have a local policy, where upon receiving a call with a "calling party category(CPC)" of "police", it would allow the call to go through even when the caller is anonymous by overriding the ACR service. 3.2. Call back from Law Enforcement VSP/ASP might have a local policy where upon receiving a request with a CPC of "police" asking to obtain an Address of Record(AOR) of caller recently making an anonymous call to the police station, it would override its general privacy policy about withholding the identity of the anonymous caller and return the AOR in question. 3.3. PSTN Interaction CPC and OLI can be mapped to the trait information described here in this draft for interaction between SIP networks and ISUP networks. 3.4. Station Type and Privacy Setting When roaming, user might use an outbound proxy that are provided through facility that they are visiting such as library, jail etc. If these facilities can be recognized through trait information as a call's originating point, receiving end might behave differently with its treatment of the call. For example, when receiving end recognizes that the call is coming through jail, callee might assume that call is monitored and warn the user about its possible privacy implication. When the call is coming through Library, UAS might automatically increases the volume on the microphone of the phone as it assumes that the caller would speak quietly. Schubert, et al. Expires July 5, 2006 [Page 7] Internet-Draft Calling Party Category using SAML January 2006 4. Overview of Operation Both CPC and ST would not work unless the asserting parties asserting the assertion and receiving entity verifying the assertion have a mutual trust relationships either directly or through federation. The discovery of this trust relationship and federation is out of scope. There are ideas trying to explore the associated federation using DNS as seen in [7] Note that asserting party of CPC and ST may differ according to an environment the caller is making a call. Where CPC is an attribute of a caller and generally associated with the caller through caller's organization(police, fire department etc.), Station Type(ST) is an attribute of a call's originating point. As one can roam easily in SIP using the same identity, ST may not always stay the same and rather changes frequently if the caller is using a mobile device such as WIFI cellular phone or laptop to make a call. Although this might be out of scope to discuss, an asserting party for CPC in most cases is likely to be the VSP which caller or caller's organization subscribes to. Caller or organization which would get assertion to claim some kind of CPC besides "ordinary" generally needs to go through some offline administrative arrangement to claim specific CPC. ST on the other hand represents an attribute of the call's originating point, which in many cases is a characteristic describing location and other trait information of an outbound proxy where caller is connected. And therefore asserting party of ST is usually a VSP of the local network. Process of obtaining the CPC and ST largely depends on who sets the assertion or artifact to the message. It seems desirable for proxies to query the assertion party and attach the CPC or ST in a form of artifact to a message rather than UAC querying the asserting party and attaching the assertion or artifact itself for several reasons. Reasons behind this are mentioned in the section 6.1 and 6.2. If it is the proxy that attaches the artifact then it will simply authenticate the user and attach the artifact according to its local policy. If the proxy is not an asserting party then, it can retrieve the assertion for its domain prior to handling the request or it can retrieve the assertion upon receiving the request on behalf of the user. If the proxy is an asserting party then it can simply use the local policy to decide whether to attach the artifact or not. The behavior of the receiving entity would be the same for proxy attaching the artifact and UAC attaching the assertion/artifact. Schubert, et al. Expires July 5, 2006 [Page 8] Internet-Draft Calling Party Category using SAML January 2006 If it is the UAC that attaches the artifact/assertion, process of obtaining the trait information preferably takes place before caller generates a request or even as part of the boot strap process, to minimize the call set-up delay. And this might be reasonable timing to obtain these trait information as both CPC and ST are rather static as long as user is not moving around and changing its outbound proxy. Location of asserting party for both ST and CPC are likely to be distributed through means such as manual configuration, SIP UA Profile framework[4] or some other proprietary means, if it's the UAC that queries the asserting parties to retrieve the If the caller is connected to the Internet from network that's not served by the home service provider, it is likely for caller to end up with two different location to inquire for assertions, one for CPC and one for ST.(For an example, user subscribed to AT&T but connected through an outbound proxy at your client's office or Jail served by another service provider..) UAC would query asserting party for CPC and ST independently, even if the assertion party for both CPC and ST are the same entity. Asserting party when receiving request would be required to do its best at authorizing and authenticating the SAML request. For CPC this would be accomplished through some form of a user authentication and authorization to see if the user is eligible to claim CPC. To minimize the configuration burden on UA, home proxy might query and obtain assertion on behalf of the caller and insert the assertion to the message on UAC's behalf. For ST, outbound proxy might need to query the asserting party at all time on behalf of the caller as there is generally no prior relationship between the caller and an asserting party of the local network if the caller is connected through network not served by its home service provider. After authenticating and authorizing the caller or the proxy, asserting party responsible for CPC would set an appropriate CPC for the caller and assertion party responsible for ST would do the same for ST and return the response in forms of either an artifact or an assertion as described in "Using SAML for SIP"[3]. After obtaining assertion containing CPC and/or ST or an artifact pointing to them, UAC would set them to its message following the convention described in [3] and send it to the callee. Proxy or UAS receiving either an artifact or assertion that Schubert, et al. Expires July 5, 2006 [Page 9] Internet-Draft Calling Party Category using SAML January 2006 understand this specification and interested in consuming the information would verify the validity of an assertion if desired following the convention described in [3]. If the asserting party of the information provided is not acknowledged by the receiving end, the information provided by the asserting party unknown to the receiving end SHOULD be considered invalid and no special treatment of incoming call SHOULD take place on that particular trait information. If the information is considered valid, and receiving end recognizes the asserting party, UAS or Proxy MAY reflect the given information to help make a better informative authorization decision for treatments of an incoming call.. Schubert, et al. Expires July 5, 2006 [Page 10] Internet-Draft Calling Party Category using SAML January 2006 5. UAC Behavior We assume that UAC is either configured manually or configured through means such as SIP UA Profile Framework[4] with an assertion parties to inquire for an assertion. And how UAC would be configured is out of scope of this document. If [4] is to be used, asserting party for CPC is likely to be realized through use of "user" profile type and that of ST is likely to be realized through "local-network" profile type. UAC supporting this specification SHOULD query using the SAML request, the asserting party responsible for CPC if it's configured with its location, following the convention described in [3]. UAC supporting this specification SHOULD query using the SAML request, the asserting party responsible for ST if it's configured with its location, following the convention described in [3]. If UAC receives an error in SAML response, UAC may receive a reason why it failed but it is NOT RECOMMENDED retry with the same request. If UAC receives an assertion in SAML response, it SHOULD set it to the outgoing message following the convention described in [3] for each assertion it receives. If UAC receives an artifact it SHOULD set it to its outgoing message following the convention described in [3] for each artifact it receives. If possible, UAC SHOULD cache the artifact/assertion it obtained for future communication and reuse them as long as the client is connected through the same outbound proxy or is communicating with the same AOR. UAC SHOULD indicate that it can accept the application/cpc and application/station MIME type in SIP requests it sends out. If UAC desires proxies on its request path to handle the CPC or ST, it is RECOMMENDED to either set the artifact in the SIP header or not to encrypt the message if the assertion is used. If it's the proxy that attaches the artifact, UAC does not need to be aware of this specification. Schubert, et al. Expires July 5, 2006 [Page 11] Internet-Draft Calling Party Category using SAML January 2006 6. Server Behaviors 6.1. Home Proxy with request Home proxy might query the asserting party on behalf of caller for the following reasons. CPC such as "police" is generally assigned to an organization, and not to an individual. Therefore it might be more sensible for home proxy representing the organization to query the asserting party on behalf of an individual belonging to that organization. It enables call initiated from device not supporting this specification to carry an artifact. It minimizes the configuration needed on UAC for obtaining the CPC or ST. When home proxy supporting this specification receives a request and it is set up to query an asserting party or it is an asserting party, it MAY check to see if the message already contains an assertion or an artifacts by searching within message's body for MIME type of application/cpc and application/station. NOTE: How do we distinguish the trait type if it's set as a header? Are we going to have a separate header for each artifact(SAML extension) defined? Also, do we want to define new MIME type for every SAML extensions? If not, we need to define a way to address the type of information contained in SAML, possibly using cid etc. If it finds neither or just one the following process should take place, otherwise it would behave as any other proxy normally would, and transfer the call. If the request only contains CPC, Proxy SHOULD verify that the request is going out through the processing proxy as an outbound proxy and it MAY query an asserting party responsible for ST to obtain an artifact if it's not an asserting party or it MAY attach the artifact if it is an asserting party responsible for ST following the convention described in [3]. Proxy would be assumed to be pre- configured with asserting parties to query. If the request only contains ST, it MAY query an asserting party responsible for CPC if it's not an asserting party or it MAY attach an artifact if it is an asserting party responsible for CPC following the convention described in [3]. If the request carries neither ST nor CPC, it MAY query two asserting Schubert, et al. Expires July 5, 2006 [Page 12] Internet-Draft Calling Party Category using SAML January 2006 parties, one responsible for CPC and one responsible for ST using SAML request if it's not an asserting party or it MAY attach an artifact for ST and CPC if it is an asserting party for CPC and ST following the convention described in [3]. In case of ST, proxy should verify that the request is going out through the processing proxy as an outbound proxy. If the response from the asserting party contains an error, it MAY log the error but it SHOULD NOT stop processing the requests it receives. And it SHOULD NOT retry to get an artifact with the same requests. It SHOULD process the request without the artifact. If proxy is not an asserting party and it receives an artifact, it SHOULD set it to the header of an outgoing message following the convention described in [3] for each artifact it receives. NOTE: As proxy is unable to modify the body, proxy MUST only accept an artifact, and base spec[3] is going to enable the inclusion of an artifact in the header for this to work. After attaching the artifact, proxy SHOULD forward the request. 6.2. Outbound Proxy with request Outbound proxy might query the asserting party on behalf of the caller for following reasons. Caller when roaming or using visiting network, generally has no prior relationship to an outbound proxy or with an asserting party which is responsible for a ST of the connecting outbound proxy. This can be problematic as an asserting party for ST has no way to authenticate and authorize the caller. Allowing issuing an assertion without any authentication or authorization is not desirable. It enables call initiated from device not supporting this specification to carry an artifact. It minimizes the configuration needed on UAC for obtaining the ST. When outbound proxy supporting this specification receives a request and it is set up to query an asserting party, it would check to see if the message already contains an assertion or artifacts by searching within message's body for MIME type of application/station. If it finds none it would do the followings, otherwise it would behave as it normally would as a proxy and forward the message Schubert, et al. Expires July 5, 2006 [Page 13] Internet-Draft Calling Party Category using SAML January 2006 If the request contains no ST, proxy should verify that the request is going out through the processing proxy as an outbound proxy, if so it MAY query an asserting party responsible for ST to obtain an artifact if it's not an asserting party or it MAY attach an artifact if it's an asserting party following the convention described in [3]. If the response from the asserting party is an error, it MAY log the error but it SHOULD NOT stop processing the requests. And it SHOULD NOT retry to get an artifact with the same requests. And it MUST forward the message without the artifact. If proxy receives an artifact it SHOULD set it to the header of an outgoing message following the convention described in [3]. After attaching the artifact, proxy SHOULD forward the request. 6.3. Server Behavior receiving requests UAS and/or Proxy servers supporting this specification, when receiving a request indicating the support for application/cpc and application/station MIME type SHOULD look into the message body for these MIME types. Upon finding the MIME body, UAS and/or Proxy server SHOULD check to see if the asserting party is one that it recognizes by checking the URI within the artifact if it's an artifact, and check the servingURL within the assertion if it's an assertion. If the asserting party is unknown, it SHOULD stop processing the assertion or artifact with an unknown asserting party and process the next assertion or artifact if there is more than one. If the asserting party is known but not trusted, it SHOULD stop processing the assertion or artifact and process the next assertion or artifact if there is more than one. If the asserting party is known to the processing party and it is an artifact, it SHOULD obtain the actual assertion following the convention described in [3]. NOTE: The matching process and list of assertion parties that are to be used for verifying the trusted assertion parties might be obtained through SIP UA Profile Framework[4] or some other mechanisms such as one described in [7]. As part of a verification process, UAS and/or Proxy SHOULD check the URI of the party which requested the assertion for ST, and compare it with an entity in a VIA header in case it is different from the value Schubert, et al. Expires July 5, 2006 [Page 14] Internet-Draft Calling Party Category using SAML January 2006 found in From header. If none of the entry in the VIA header matches the value represented in the assertion, it should be considered invalid.(If the outbound proxy in non-home network attaches the assertion on behalf of the UAC, it is ) UAS and/or Proxy server MAY use ST or CPC that are validated to alter its treatment of incoming call. Schubert, et al. Expires July 5, 2006 [Page 15] Internet-Draft Calling Party Category using SAML January 2006 7. Examples Call Flows 7.1. Example Flow 1 The following call flow shows a basic attachment of an assertion/ artifact by UAC's home proxy. This is likely the architecture for individual users subscribing to VSP such as Vonage etc.(VSP is part of the federation and proxy from this VSP is an asserting party.) As you can see Alice does not need to be aware of the asserting party. ----------- ------------- ------------- ----------- | Alice's | | provider | | proxy.bil | | Bob's | | phone | | .com | | oxi.com | | phone | ----------- ------------- ------------- ----------- | | | | | INVITE | | | |------------>| | | | 407 | | | |<------------| | | | INVITE + | | | | Digest | | | |------------>| | | | | INVITE + | | | | SAML artifact| | | |------------->| | | | SAML request | | | |<-------------| | | |SAML response | | | | + Assertion | | | |------------->| | | | | INVITE | | |------------>| | 180 Ringing | |------------------------------------------| | | | 200 OK | |<-----------------------------------------| | ACK | |----------------------------------------->| | Media Stream | |<========================================>| | | Schubert, et al. Expires July 5, 2006 [Page 16] Internet-Draft Calling Party Category using SAML January 2006 Figure 1: Individual Subscriber 7.2. Example Flow 2 The following call flow shows a basic attachment of an assertion/ artifact by UAC's company proxy. This is likely the architecture for corporate environment where organization/company subscribes to VSP such as Vonage etc.(VSP is part of the federation and proxy from this VSP is an asserting party.) and organization/company is assigned a single CPC value such as "police". As you can see Alice does not need to be aware of the asserting party. Schubert, et al. Expires July 5, 2006 [Page 17] Internet-Draft Calling Party Category using SAML January 2006 ----------- ------------- ------------- ------------- ----------- | Alice's | | proxy.atl | | Asserting | | proxy.bil | | Bob's | | phone | | anta.com | | Party | | oxi.com | | phone | ----------- ------------- ------------- ------------- ----------- | | | | | | | Request CPC | | | | |------------->| | | | | Auth | | | | |<-------------| | | | |------------->| | | | | SAML artifact| | | | |<-------------| | | | | Request ST | | | | |------------->| | | | | Auth | | | | |<-------------| | | | |------------->| | | | | SAML artifact| | | | |<-------------| | | | INVITE | | | | |------------>| | | | | | INVITE + SAML artifact | | | |---------------------------->| | | | | SAML request | | | | |<-------------| | | | | SAML response + Assertion | | | |------------->| | | | | | INVITE | | |------------>| | 180 Ringing | |---------------------------------------------------------| | | | 200 OK | |<--------------------------------------------------------| | ACK | |-------------------------------------------------------->| | Media Stream | |<=======================================================>| | | Figure 2: Corporate architecture Schubert, et al. Expires July 5, 2006 [Page 18] Internet-Draft Calling Party Category using SAML January 2006 7.3. Example Flow 3 The following call flow shows a basic retrieval of an assertion/ artifact from a single source of asserting party by UAC. It is assumed that UA is configured with information for assertion parties. As you can see Alice query the assertion twice, once for CPC and once for ST. Schubert, et al. Expires July 5, 2006 [Page 19] Internet-Draft Calling Party Category using SAML January 2006 ----------- ------------- ------------- ------------- ----------- | Alice's | | proxy.atl | | Asserting | | proxy.bil | | Bob's | | phone | | anta.com | | Party | | oxi.com | | phone | ----------- ------------- ------------- ------------- ----------- | | | | | | Request Assertion for CPC | | | |--------------------------->| | | | User Authentication | | | | and Authorizationn | | | |<---------------------------| | | |--------------------------->| | | | SAML artifact | | | |<---------------------------| | | | Request Assertion for | | | | Station Type | | | |--------------------------->| | | | User Authentication | | | | and Authorizationn | | | |<---------------------------| | | |--------------------------->| | | | SAML artifact | | | |<---------------------------| | | | INVITE + SAML artifact | | | |------------>| | | | | | INVITE + SAML artifact | | | |---------------------------->| | | | | SAML request | | | | |<-------------| | | | | SAML response + Assertion | | | |------------->| | | | | | INVITE | | |------------>| | 180 Ringing | |---------------------------------------------------------| | | | 200 OK | |<--------------------------------------------------------| | ACK | |-------------------------------------------------------->| | Media Stream | |<=======================================================>| | | Figure 3:UA querying the asserting parties Schubert, et al. Expires July 5, 2006 [Page 20] Internet-Draft Calling Party Category using SAML January 2006 7.4. Example Flow 4 Following is an example call flow for Alice initiating a call to Bob's phone from starbucks.com. Home proxy and outbound proxy are both querying an asserting party on behalf of the caller. It is assumed that Alice's UAC is pre-configured with the route set which makes the request route through outbound proxy and home proxy, which allows each proxy to query the assertion party and attach the artifact received in response to the outgoing message that it proxies. Note due to the space, proxy on Bob's side and bob is not shown. Schubert, et al. Expires July 5, 2006 [Page 21] Internet-Draft Calling Party Category using SAML January 2006 ----------- ------------- ------------- ------------- ----------- | Alice's | | proxy.star| | Asserting | | proxy.atl | |Asserting| | phone | | bucks.com | | Party | | anta.com | | party | ----------- ------------- ------------- ------------- ----------- | | | | | | INVITE | | | | |------------>| | | | | |Assertion | | | | | Request | | | | |------------->| | | | |Authentication| | | | |and authoriza | | | | |tion | | | | |<-------------| | | | |------------->| | | | |SAML artifact | | | | |<-------------| | | | | INVITE + SAML artifact | | | |---------------------------->| | | | | | Assertion | | | | | Request | | | | |------------>| | | | Authentication | | | | and authorization| | | | |<------------| | | | |------------>| | | | |SAML artifact| | | | |<------------| | | | |INVITE + SAML| | | | | artifacts(CPC+ST) | | | |------------------> Figure 4:Roaming scenario. Figure 4 Schubert, et al. Expires July 5, 2006 [Page 22] Internet-Draft Calling Party Category using SAML January 2006 8. Station Type Predefined Values for station type is taken from CPC/OLI defined in ISUP: 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. Schubert, et al. Expires July 5, 2006 [Page 23] Internet-Draft Calling Party Category using SAML January 2006 9. 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. Schubert, et al. Expires July 5, 2006 [Page 24] Internet-Draft Calling Party Category using SAML January 2006 10. XML Schema for Calling Party Category TBD Schubert, et al. Expires July 5, 2006 [Page 25] Internet-Draft Calling Party Category using SAML January 2006 11. XML Schema for Station Type TBD Schubert, et al. Expires July 5, 2006 [Page 26] Internet-Draft Calling Party Category using SAML January 2006 12. XML Example for Calling Party Category TBD Schubert, et al. Expires July 5, 2006 [Page 27] Internet-Draft Calling Party Category using SAML January 2006 13. XML Example for Station Type TBD Schubert, et al. Expires July 5, 2006 [Page 28] Internet-Draft Calling Party Category using SAML January 2006 14. Security Considerations As the information carried in both CPC and ST may alter the treatment of the call by the recipient, it is important that the information carried is securely transferred. Usage of TLS and preferably direction connection with the assertion party when fetching and requesting the SAML document is recommended. Schubert, et al. Expires July 5, 2006 [Page 29] Internet-Draft Calling Party Category using SAML January 2006 15. Acknowledgement I like to thank Erick Sasaki and Christian Schmidt for providing constructive feedbacks. Schubert, et al. Expires July 5, 2006 [Page 30] Internet-Draft Calling Party Category using SAML January 2006 16. References 16.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, ""Using SAML for SIP"", Draft draft-tschofenig-sip-saml-04.txt, July 2005. 16.2. Informative Reference [4] Petrie, "SIP UA Profile Framework", Draft draft-ietf-sipping-config-framework-07.txt, Jan 2006. [5] Schulzrinne, "A Uniform Resource Name (URN) for Services", Draft draft-ietf-ecrit-service-urn-00.txt, Feb 2006. [6] Schulzrinne and Polk, "Communications Resource Priority for the Session Initiation Protocol", Draft draft-ietf-sip-resource-priority-10, July 2005. [7] O, "Publishing SIP Peering Policy", Draft draft-lendl-sip-peering-policy-00, Dec 2005. Schubert, et al. Expires July 5, 2006 [Page 31] Internet-Draft Calling Party Category using SAML January 2006 Authors' Addresses Hannes Tshofenig NTT Corporation 1549 W15th Ave Vancouver, BC V6H 1R6 Canada Phone: +1 604 762 5606 URI: http://www.ntt.co.jp Hannes Tshofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: Email: Hannes.Tschofenig@siemens.com URI: http://www.siemens.com/ Martin Dolly AT&T San Francisco, CA 94110 US Phone: Email: dolly@att.com URI: http://www.att.com/ Schubert, et al. Expires July 5, 2006 [Page 32] Internet-Draft Calling Party Category using SAML January 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 July 5, 2006 [Page 33]