Internet DRAFT - draft-schubert-sipping-saml-cpc
draft-schubert-sipping-saml-cpc
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
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:ietf:params:xml:ns:oli">
<saml:AttributeValue xsi:type="xs:string">payphone</saml:Attrib
uteValue>
</saml:Attribute>
Schubert, et al. Expires January 6, 2007 [Page 11]
Internet-Draft Conveying CPC using the SAML July 2006
10. XML Schema for Originating Line Indication
<saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:ietf:params:xml:ns:cpc">
<saml:AttributeValue xsi:type="xs:string">ordinary</saml:Attrib
uteValue>
</saml:Attribute>
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 January 6, 2007 [Page 12]
Internet-Draft Conveying CPC using the SAML July 2006
1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
4 <Issuer>
5 example.com
6 </Issuer>
7 <Subject>
8 <NameID
9 Format=
10 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
11 Alice@example.com
12 </NameID>
13 <SubjectConfirmation
14 Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
15 </Subject>
16 <Conditions NotBefore="2003-04-17T00:46:02Z"
17 NotOnOrAfter="2003-04-17T00:51:02Z">
18 <AudienceRestriction>
19 <Audience>
20 example2.com
21 </Audience>
22 </AudienceRestriction>
23 </Conditions>
24 <AuthnStatement AuthnInstant="2003-04-17T00:46:00Z">
25 <AuthnContext>
26 <AuthnContextClassRef>
27 urn:oasis:names:tc:SAML:2.0:ac:classes:Password
28 </AuthnContextClassRef>
29 </AuthnContext>
30 </AuthnStatement>
31 <AttributeStatement>
32 <Attribute
33 NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
34 Name="urn:ietf:params:xml:ns:oli">
35 <AttributeValue xsi:type="xs:string">payphone
</AttributeValue>
36 </Attribute>
37 </AttributeStatement>
38 </Assertion>
Figure 4: Unsigned SAML Assertion Illustrating Conveyance of OLI
Attribute
12. Security Considerations
The security considerations of SIP-SAML are fully applicable t this
Schubert, et al. Expires January 6, 2007 [Page 13]
Internet-Draft Conveying CPC using the SAML July 2006
document. Additionally, the requirements outlined in [7] are
relevant.
13. IANA Considerations
IANA is requested to register two URNs, to create two registries for
the CPC and OLI and to register a number of tokens.
13.1. CPC and OLI Registry
This document instructs IANA to register a registry for CPC and for
OLI tokens.The OLI tokens are listed in Section 7 starting with
'payphone' and finishing with 'cellular-roaming'. The CPC tokens are
listed in Section 8 starting with 'payphone' and finishing with
'operator'. Following the policies outline in RFC 2434 [2], new
tokens are assigned after Expert Review by the Expert Reviewer
appointed by the IESG. The same procedure applies to updates of
tokens within the registry and to deleting tokens from the registry.
The expert review should be guided by a few common-sense
considerations. The Expert's support of IANA will include providing
IANA with the new token(s) when the update is provided only in the
form of a schema, and providing IANA with the new schema element(s)
when the update is provided only in the form of a token. Each
registration must include the name of the token and a brief
description similar to the ones offered in for the initial
registrations contained this document: Token Identifier: Identifier
of the token. Description: Brief description indicating the meaning
of the token, including one or more examples where the term
encompasses several more precise terms.
13.2. Calling Party Category Namespace Registration
URI: urn:ietf:params:xml:ns:cpc Registrant Contact: IETF SIPPING
Working Group, Hannes Tschofenig (Hannes.Tschofenig@siemens.com).
XML:
Schubert, et al. Expires January 6, 2007 [Page 14]
Internet-Draft Conveying CPC using the SAML July 2006
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"_http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Calling Party Category Namespace</title>
</head>
<body>
<h1>Namespace for Calling Party Category</h1>
<h2>urn:ietf:params:xml:ns:cpc</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
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:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"_http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Originating Line Indication Namespace</title>
</head>
<body>
<h1>Namespace for Originating Line Indication</h1>
<h2>urn:ietf:params:xml:ns:oli</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
Schubert, et al. Expires January 6, 2007 [Page 15]
Internet-Draft Conveying CPC using the SAML July 2006
</html>
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]
