SIPPING S. Schubert
Internet-Draft NTT
Expires: January 6, 2007 H. Tschofenig
Siemens
M. Dolly
AT&T
T. Ohba
NTT
July 05, 2006
Conveying CPC using the SAML
draft-schubert-sipping-saml-cpc-02.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 January 6, 2007.
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 January 6, 2007 [Page 1]
Internet-Draft Conveying CPC using the SAML July 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 Calling Party Category . . . . . . . . . . . . 11
10. XML Schema for Originating Line Indication . . . . . . . . . . 12
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13.1. CPC and OLI Registry . . . . . . . . . . . . . . . . . . . 14
13.2. Calling Party Category Namespace Registration . . . . . . 14
13.3. Originating Line Indication Namespace Registration . . . . 15
14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
15. Internationalization Considerations . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16
16.2. Informative Reference . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Schubert, et al. Expires January 6, 2007 [Page 2]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 3]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 4]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 5]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 6]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 7]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 8]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 9]
Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 10]
Internet-Draft Conveying CPC using the SAML July 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.
busy-line-interrupt: The calling station is interrupting the call.
operator: The calling station is in a operation center.
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 Calling Party Category
See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].
END 13.3. Originating Line Indication Namespace Registration URI: urn:ietf:params:xml:ns:oli Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig (Hannes.Tschofenig@siemens.com). XML: BEGINSee RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].
Schubert, et al. Expires January 6, 2007 [Page 15] Internet-Draft Conveying CPC using the SAML July 2006 END 14. Acknowledgement The authors would like to thank Erick Sasaki, Jeff Hodges, Scott Cantor and Christian Schmidt for providing constructive feedbacks to this draft. 15. Internationalization Considerations The OLI and CPC values listed in this document MUST NOT be presented to the user. The values therefore have the characteristic of tokens or tags and no internationalization support is required. 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, 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. Schubert, et al. Expires January 6, 2007 [Page 16] Internet-Draft Conveying CPC using the SAML July 2006 16.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. [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 January 6, 2007 [Page 17] Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 18] Internet-Draft Conveying CPC using the SAML July 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 January 6, 2007 [Page 19]