One document matched: draft-ietf-sip-saml-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
<!ENTITY PUBLIC ""
""-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-sip-content-indirect-mech PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-content-indirect-mech.xml'>
<!ENTITY RFC4474 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY I-D.ietf-sipping-certs PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-certs.xml'>
<!ENTITY RFC4484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4484.xml'>
<!ENTITY I-D.jennings-sipping-pay PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-sipping-pay.xml'>
<!ENTITY I-D.peterson-message-identity PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.peterson-message-identity.xml'>
<!ENTITY IANA.application.samlassertion-xml PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.IANA.application.samlassertion-xml.xml">
<!ENTITY OASIS.saml-authn-context-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-authn-context-2.0-os.xml">
<!ENTITY OASIS.saml-bindings-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-bindings-2.0-os.xml">
<!ENTITY OASIS.saml-conformance-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-conformance-2.0-os.xml">
<!ENTITY OASIS.saml-core-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml">
<!ENTITY OASIS.sstc-saml-exec-overview-2.0-cd-01 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.sstc-saml-exec-overview-2.0-cd-01.xml">
<!ENTITY OASIS.saml-glossary-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-glossary-2.0-os.xml">
<!ENTITY OASIS.saml-metadata-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-metadata-2.0-os.xml">
<!ENTITY OASIS.saml-profiles-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-profiles-2.0-os.xml">
<!ENTITY OASIS.saml-sec-consider-2.0-os PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-consider-2.0-os.xml">
<!ENTITY OASIS.sstc-saml-tech-overview-2.0-draft-08 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.sstc-saml-tech-overview-2.0-draft-08.xml">
<!ENTITY RFC.2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC.2392 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2392.xml">
<!ENTITY RFC.2543 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2543.xml">
<!ENTITY RFC.2616 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC.2693 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">
<!ENTITY RFC.3261 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC.3280 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml">
<!ENTITY RFC.3281 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3281.xml">
<!ENTITY RFC.3323 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml">
<!ENTITY RFC.3515 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml">
<!ENTITY RFC.3553 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.xml">
<!ENTITY RFC.3893 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3893.xml">
<!ENTITY W3C.xmldsig-core PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml2/reference.W3C.xmldsig-core.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
ipr="full3978"
updates="4474"
docName="draft-ietf-sip-saml-03.txt">
<front>
<title abbrev="SIP SAML">SIP SAML Profile and Binding</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@siemens.com</email>
</address>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization abbrev="NeuStar, Inc.">NeuStar, Inc.</organization>
<address>
<postal>
<street>2000 Broadway Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>
<email>Jeff.Hodges@neustar.biz</email>
</address>
</author>
<author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="NeuStar, Inc.">NeuStar, Inc.</organization>
<address>
<postal>
<street>1800 Sutter St Suite 570</street>
<city>Concord</city>
<region>CA</region>
<code>94520</code>
<country>US</country>
</postal>
<email>jon.peterson@neustar.biz</email>
</address>
</author>
<author initials="J." surname="Polk" fullname="James Polk">
<organization abbrev="Cisco">Cisco</organization>
<address>
<postal>
<street>2200 East President George Bush Turnpike</street>
<city>Richardson</city>
<region>Texas</region>
<code>75082</code>
<country>US</country>
</postal>
<email>jmpolk@cisco.com</email>
</address>
</author>
<author initials="D." surname="Sicker" fullname="Douglas C. Sicker">
<organization abbrev="CU Boulder">University of Colorado at Boulder</organization>
<address>
<postal>
<street>ECOT 430</street>
<city>Boulder</city>
<region>CO</region>
<code>80309</code>
<country>US</country>
</postal>
<email>douglas.sicker@colorado.edu</email>
</address>
</author>
<date year="2007"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>SIP</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<keyword>SAML</keyword>
<keyword>SIP</keyword>
<abstract>
<t>
This document specifies a Session Initiation Protocol
(SIP) profile of Security Assertion Markup Language
(SAML) as well as a SAML SIP binding. The defined SIP
SAML Profile composes with the mechanisms defined in
the SIP Identity specification and satisfy
requirements presented in "Trait-based
Authorization Requirements for the Session Initiation
Protocol (SIP)".
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This document specifies composition of the Security
Assertion Markup Language (SAML) V2.0 with SIP <xref
target="RFC3261"/> in order to accommodate richer
authorization mechanisms and enable "trait-based
authorization." Trait-based authorization is
where one is authorized to make use of some resource
based on roles or traits rather than ones
identifier(s). Motivations for trait-based
authorization, along with use-case scenarios, are
presented in <xref
target="RFC4484"/>.
</t>
<t>
Security Assertion Markup Language (SAML) v2.0,
"SAMLv2",
is an XML-based framework for creating and exchanging
security information. <xref
target="OASIS.sstc-saml-exec-overview-2.0-cd-01"/> and
<xref
target="OASIS.sstc-saml-tech-overview-2.0-draft-08"/>
provide non-normative overviews of SAMLv2. The SAMLv2
specification set is normatively defined by
<xref target="OASIS.saml-conformance-2.0-os"/>.
</t>
<t>
Various means of providing trait-based authorization
exist: authorization certificates
<xref target="RFC3281"/>, SPKI <xref target="RFC2693"/>, or
extensions to the authenticated identity body <xref
target="RFC3893"/>. The authors
selected SAML due to its increasing use in
environments such as the Liberty Alliance,
and the
Internet2 project, areas where the applicability to
SIP is widely desired.
</t>
</section> <!-- intro -->
<section anchor="terminology" title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
The SIP network element "Authentication
Service" is introduced in <xref
target="RFC4474"/>. We reuse this term
to refer to a network element that authenticates and
authorizes a user and creates a "SIP identity
assertion". This
system entity is the logical equivalent of a "SAML
Authority" in the SAML terminology.
</t>
<t>
For overall SIP terminology, see <xref
target="RFC3261"/>.
</t>
<t>
In this specification, the term, or term component,
"SAML" refers to SAML V2.0 in all cases. For
example, the term "SAML assertion"
implicitly means "SAMLv2 assertion".
For overall SAML terminology, see <xref
target="OASIS.saml-glossary-2.0-os"/>.
</t>
<t>
The below list maps other various SIP terms to their SAML
(rough-)equivalents:
<list>
<t> <!-- hangIndent="40" -->
<list style="hanging">
<t hangText="Element, Network Element:">
<vspace blankLines="1"/>
System Entity, Entity<vspace blankLines="1"/>
</t>
<t hangText="Authentication Service:">
<vspace blankLines="1"/>
SAML Authority<vspace blankLines="1"/>
</t>
<t hangText="Invitee, Invited User,
Called Party, Callee:">
<vspace blankLines="1"/>
Relying Party<vspace blankLines="1"/>
</t>
<t hangText="Server, User Agent Server (UAS):">
<vspace blankLines="1"/>
SAML Responder<vspace blankLines="1"/>
</t>
<t hangText="User Agent Client (UAC), client:">
<vspace blankLines="1"/>
SAML Requester<vspace blankLines="1"/>
</t>
</list>
</t>
</list>
</t>
<t>
<vspace blankLines="1"/>
Additional terms defined in the context of this
specification:
<list>
<t>
<list style="hanging">
<t hangText="profile attribute(s):">
<vspace blankLines="1"/>
one or more attributes of a "user
profile".
</t>
<t hangText="user profile, subject profile:">
<vspace blankLines="1"/>
the set of various
attributes accompanying (i.e., mapped to)
a user account in many
environments.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="saml-introduction" title="SAML Introduction">
<t>
SAML
<xref target="OASIS.sstc-saml-exec-overview-2.0-cd-01"/>
<xref target="OASIS.sstc-saml-tech-overview-2.0-draft-08"/>
defines an XML-based framework for exchanging
"security assertions" between entities. In
the course of making, or relying upon such assertions,
SAML system entities may use SAML protocols, or other
protocols, to communicate an
assertion itself, or the subject of an assertion.
</t>
<t>
Thus one can employ SAML to make and encode statements
such as "Alice has these profile attributes and
her domain's certificate is available over there, and
I'm making this statement, and here's who I am."
Then one can cause such an assertion to be conveyed to
some party who can then rely on it in some fashion for
some purpose, for example input it into some local
policy evaluation for access to some resource. This is
done in a particular "context of use". Such
a context of use could be, for example, deciding
whether to accept and act upon a SIP-based invitation
to initiate a communication session.
</t>
<t>
The specification of how SAML is employed in a
particular context of use is known as a "SAML
profile". The specification of how SAML
assertions and/or protocol messages are conveyed in,
or over, another protocol is known as a "SAML
Binding". Typically, a SAML profile specifies the
SAML bindings that may be used in its context. Both
SAML profiles and SAML bindings reference other SAML
specifications, especially the SAML Assertions and
Protocols, aka "SAML Core", specification <xref
target="OASIS.saml-core-2.0-os"/>.
</t>
<t>
There is an additional subtle aspect of SAML profiles that
is worth highlighting -- the notion of a "SAML assertion
profile". A SAML assertion profile is the specification
of the assertion contents in the context of a particular
SAML profile. It is possibly further qualified by a particular
implementation and/or deployment context. Condensed
examples of SAML assertion profiles are:
</t>
<t>
<list style="symbols">
<t>
The SAML assertion must contain at least one
authentication statement and no other statements.
The relying party must be represented in the
<AudienceRestriction> element. The
SubjectConfirmation Method must be Foo. etc.
</t>
<t>
The SAML assertion must contain at least one
attribute statement and may contain more than one.
The values for the subject's
profile attributes named "Foo" and "Bar"
must be present. An authentication statement may
be present. etc.
</t>
</list>
</t>
<t>
The primary facets of SAML itself are:
</t>
<t>
<list style="symbols">
<t>Assertions</t>
<t>Abstract Request/Response protocol</t>
</list>
</t>
<t>
We describe each in turn below:
</t>
<section anchor="assertions" title="SAML Assertions">
<t>
A SAML assertion is a package of information
including issuer and subject, conditions and
advice, and/or attribute statements, and/or
authentication statements and/or other statements.
Statements may or may not be present. The SAML
assertion "container" itself contains
the following information:
</t>
<t>
<list style="hanging">
<t hangText="Issuing information:">
<vspace blankLines="1"/>
Who issued the
assertion, when was it issued and the
assertion identifier.<vspace
blankLines="1"/>
</t>
<t hangText="Subject information:">
<vspace blankLines="1"/>
The name of the
subject, the security domain and optional
subject information, like public
key.<vspace blankLines="1"/>
</t>
<t hangText="Conditions under which the
assertion is valid:">
<vspace blankLines="1"/>
Special kind of
conditions like assertion validity period,
audience restriction and target
restriction.<vspace blankLines="1"/>
</t>
<t hangText="Additional advice:">
<vspace blankLines="1"/>
Explaining how
the assertion was made, for example.</t>
</list>
</t>
<t>
In terms of SAML assertions containing SAML
attribute statements or SAML authentication
statements, here are explanatory examples:
<list>
<t>
With a SAML assertion containing a SAML
attribute statement, an issuing authority
is asserting that the subject is
associated with certain attributes with
certain subject profile attribute
values. For example, user
jon@cs.example.com is associated with the
attribute "Department", which
has the value "Computer
Science".
</t>
<t>
With a SAML assertion containing a SAML
authentication statement, an issuing
authority is asserting that the
subject was authenticated by certain means
at a certain time.
</t>
<t>
With a SAML assertion containing both a
SAML attribute statement and a SAML
authentication statement, an issuing authority
is asserting the union of the above.
</t>
</list>
</t>
</section>
<section anchor="request-response"
title="Abstract Request/Response Protocol">
<t>
SAML defines an abstract request/response protocol
for obtaining assertions.
See Section 3 "SAML Protocols" of
<xref target="OASIS.saml-core-2.0-os"/>.
A request asks for an
assertion. A response returns the requested
assertion or an error.
This abstract protocol may then be
cast into particular contexts of use by binding it
to specific underlying protocols, e.g., HTTP or
SIP, and "profiling" it for the specific
use case at hand. The SAML
HTTP-based web single sign-on profile
is
one such example
(see Section 4.1 Web Browser SSO Profile of
<xref target="OASIS.saml-profiles-2.0-os"/>).
Trait-based SIP communication session
establishment, the topic of this specification,
is another.
</t>
</section>
</section> <!-- saml-introduction -->
<!-- Goals/non-goals here -->
<section anchor="goals-nongoals" title="Specification Scope">
<t>
The scope of this specification is:
</t>
<t>
<list style="symbols">
<t>
Specify a SIP profile of SAML -- aka a "SIP
SAML profile" -- such that a subject's
profile attributes, and their domain's
certificate, can be conveyed to a relying
party using SAML. In doing so, satisfy the
requirements outlined in <xref
target="RFC4484"/>, and
compose with
<xref target="RFC4474"/>.
</t>
</list>
</t>
<t>
The following are outside the scope of this specification:
</t>
<t>
<list style="symbols">
<t>
Defining a means for configuring the runtime
behavior, or deployment characteristics, of
the Authentication Service.
<vspace blankLines="1"/>
Discussion:
<vspace blankLines="1"/>
For example, a SIP
Authentication Service could be implemented
such that its SAML-based features are employed,
or not,
on a subject-by-subject basis, and/or on a
domain-by-domain basis.
<!-- The configuration of the
Authentication Service in order to attach
certain assertions is outside the scope of
this specification and might depend on the
environment where SIP is used. To avoid
restricting the functionality of SIP either as
an in-band or an out-of-band mechanism, it can
be defined to trigger the inclusion of SAML
assertions. SAML itself provides mechanisms
for this purpose. --> <!--XCAP <xref
target="I-D.ietf-simple-xcap"/> is a possible
mechanism to configure the behavior of the
Authentication Service in an out-of-band
fashion.-->
</t>
<t>
The definition of specific conveyed subject profile
attributes (aka traits).
<vspace blankLines="1"/>
Discussion:
<vspace blankLines="1"/>
This specification defines a facility enabling
"trait-based authorization" as discussed
in <xref
target="RFC4484"/>.
<vspace blankLines="1"/>
The attributes of interest in trait-based
authorization will be ones akin to, for
example: roles, organizational membership,
access rights, or
authentication event context. Definition of
such attributes is
application- and/or deployment-context-dependent
and are not defined in this
specification. However, The SAMLv2 specification
defines several "SAML Attribute Profiles"
for encoding attributes from various application
domains, e.g., LDAP, UUID/GUID, DCE PAC, and XACML,
in SAML assertions
<xref target="OASIS.saml-profiles-2.0-os"/>.
<vspace blankLines="1"/>
In order for any trait-based system
to be practical, participating
entities must agree on
attributes and traits that will be
conveyed and subsequently relied upon.
Without such agreements,
a trait-based system cannot be usefully deployed. This
specification does not discuss the manner in which
participating entites might discover one
another or agree on the syntax and semantics
of attributes and traits.
<vspace blankLines="1"/>
Note that SAMLv2 specifies a "metadata"
facility that may be useful in addressing this
need.
</t>
</list>
</t>
</section> <!-- goals-nongoals -->
<section anchor="empl-saml-sip"
title="Employing SAML in SIP">
<t>
Employing SAML in SIP necessitates devising a new SAML
profile(s) and binding(s) because the those already
specified in the SAMLv2 specification set are specific
to other use contexts, e.g., HTTP-based web
browsing. Although SIP bears some similarity to HTTP,
it is a seperately distinct protocol, thus
requiring specification of SIP-specific SAML
profile(s) and binding(s). This is technically
straightforward as both SAML and SIP are
explicitly extensible.
</t>
<t>
The "Authenticated Identity Management in
SIP" specification <xref
target="RFC4474"/> (aka "SIP
Identity") facilitates the composition of SAML
and SIP in that it defines a "mediated authentication
architecture" where verifying endpoints verify SIP
identity assertions -- i.e., the "Identity"
header value -- signed by an Authentication Service
(AS). The semantic being that the AS is vouching that
it did indeed authenticate the calling party.
</t>
<t>
Such an Authentication Service, which likely has
access to various pieces of information concerning the
calling party, could also act as a SAML Authority, and
make such information available to the callee via
SAML.
</t>
<t>
Since <xref target="RFC4474"/>
stipulates that the AS must make its certificate
available for retrieval and convey the availability
and access mechanism via a URI, in the Identity-Info
header, we have an opportunity to compose SIP Identity
and SAML.
</t>
<t>
Such composition can be accomplished by having the
resource referred to by the URI in the Identity-Info
be a SAML assertion conveying both the AS's
certificate and user profile attributes. This is the
approach defined in this specification. <xref
target="fig-ovrall-msg-flow"/> illustrates this
approach in a high-level summary fashion. <xref
target="fig-ssp-as-driven-invite-expl"/>, further
below, illustrates additional details.
</t>
<t>
<figure title="SIP-SAML-based Network Asserted Identity"
anchor="fig-ovrall-msg-flow">
<artwork>
<![CDATA[
+--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2|
|.com | |@example.com | |.com |
| | | | | |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:alice@foo.com | |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| Challenge | |
| | |
| ACK | |
|---------------------->| |
| | |
| INVITE w/authn creds | |
|---------------------->| |
| | INVITE |
| | w/Identity header |
| |--------------------->|
| | and Identity-Info |
| | |
| | HTTP GET SAML assn |
| |<==================== |
| | and domain cert |
| | |
| | HTTP 200 OK + assn |
| |=====================>|
| | and domain cert |
| 200 OK | |
|<----------------------+----------------------|
| | |
]]>
</artwork>
</figure>
</t>
<t>
Since the AS already being trusted to create and add
the Identity header containing the
SIP Identity Assertion, and to supply a pointer to its
domain certificate, having it point instead to a SAML
assertion conveying the domain certificate and possibly
some user profile attributes, does not significantly
alter the first-order security considerations examined in
<xref target="RFC4474"/>. This specification
provides some additional security considerations analysis
below in <xref target="sec-cons"/>.
</t>
</section>
<section anchor="sip-saml-profiles" title="SIP SAML Profiles">
<t>
This section defines two "SIP SAML profiles":
<list style="symbols">
<t>
The "AS-driven SIP SAML URI-based Attribute
Assertion Fetch Profile"
</t>
<t>
The to-be-determined (TBD)
"call-by-value" profile
</t>
</list>
</t>
<section anchor="ssp-as-driven-attr-"
title="AS-driven SIP SAML URI-based Attribute
Assertion Fetch Profile">
<t>
</t>
<section anchor="ssp-asd-req-info"
title="Required Information">
<t>
The information given in this section is
similar to the info provided when registering
something, a MIME Media Type, say, with IANA.
In this case, it is for registering this
profile with the OASIS SSTC. See Section 2
"Specification of Additional
Profiles" in <xref
target="OASIS.saml-profiles-2.0-os"/>.
</t>
<t>
<list style="hanging">
<t hangText="Identification:">
<vspace blankLines="1"/>
urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0
<list style="hanging">
<t hangText="@@ NOTE:">
This URN must be agreed upon,
and then registered with IANA
per <xref target="RFC3553"/>.
</t>
</list>
</t>
<t hangText="Contact Information:">
<vspace blankLines="1"/>
@@ someone's or something's contact
info goes here
</t>
<t hangText=
"SAML Confirmation Method Identifiers:">
<vspace blankLines="1"/>
The SAML V2.0
"{bearer,hok,?}"
confirmation method identifier is used
in this profile.
</t>
<t hangText="Description:">
<vspace blankLines="1"/>
Given below.
</t>
<t hangText="Updates:">
<vspace blankLines="1"/>
None.
</t>
</list>
</t>
</section> <!-- Required information -->
<section anchor="ssp-asd-overview" title="Profile Overview">
<t>
<xref target="fig-ssp-as-driven-invite-expl"/>
illustrates this profile's overall protocol
flow. The following steps correspond to the
labeled interactions in the figure. Within an
individual step, there may be one or more
actual message exchanges depending upon the
protocol binding employed for that particular
step and other implementation-dependent
behavior.
</t>
<t>
Although this profile is overview is cast in
terms of a SIP INVITE transaction, the reader
should note that the mechanism specified
herein, and in <xref
target="RFC4474"/>, may be applied
to any SIP request message.
</t>
<t>
<xref target="fig-ssp-as-driven-invite-expl"/>
begins on the next page.
</t>
<t>
<vspace blankLines="100"/> <!-- page break -->
<figure anchor="fig-ssp-as-driven-invite-expl"
title="AS-driven SIP SAML Attribute Fetch
Profile: Example INVITE Transaction">
<artwork>
<![CDATA[
+------------------+ +------------------+ +-----------------+
| Caller | |Authn Service (AS)| | Callee |
|Alice@example.com | | @example.com | | Bob@example2.com|
+--------+---------+ +--------+---------+ +--------+--------+
- - | | | (steps)
^ ^ | INVITE | |
| | |---------------------->| | (1a)
| | From:alice@foo.com | |
| C | To:sip:bob@example.com| |
| S | | |
| e | 407 Proxy auth. req. | |
| q |<----------------------| | (1b)
| = | Challenge | |
| N | | |
| | ACK | |
| | |---------------------->| | (1c)
| V | | |
| - | | |
^ | INVITE + authorization| |
D | | header w/ creds | |
| |---------------------->| | (2)
I | | From:alice@foo.com | |
| | To:sip:bob@example.com| |
A | Proxy-Authorization:..| |
C | | INVITE |
L S | |--------------------->| (3)
e | | From:alice@foo.com |
O q | | To:sip:bob@example2.com
| | Identity: ..... |
G = | | Identity-Info: |
| | https://example.com|
| N | | /assns/?ID=abcde |
| | | |
| + | |URI resolution (eg. HTTP)
| | |<=====================| (4)
| 1 | | GET /assns/?ID=abcde |
| | | |
| | | | HTTP/1.1 200 OK |
| | | |=====================>| (5)
| | | | <saml:Assertion> |
| | | | <saml:Subject> |
| | | | <saml:NameID> |
| | | | Alice@example.com
| | | | <saml:SubjConf>
| | | | <saml:SubjConfData>
| | | | <ds:KeyInfo>...
| | | | <saml:AttrStatement>
| | | | foo=bar |
| | | 200 OK | |
| V |<----------------------+----------------------| (6)
. - | | |
V
]]>
</artwork>
</figure>
<list style="format Step %d.">
<t anchor="ssp-asd-steps-init">
Initial SIP Transaction between
Caller and AS
<vspace blankLines="1"/>
This optional initial step is
comprised of substeps 1a, 1b, and 1c
in <xref
target="fig-ssp-as-driven-invite-expl"/>.
In this step, the caller, Alice, sends
a SIP request message, illustrated as
an INVITE, indicating Bob as the
callee (1a), is subsequently
challenged by the AS (1b), and sends
an ACK in response to the challenge
(1c). The latter message signals the
completion of this SIP transaction
(which is an optional substep of this
profile).
</t>
<t> Caller sends SIP Request
Message with Authorization Credentials
to the AS
<vspace blankLines="1"/>
Alice then sends an INVITE message in
response to the challenge, or uses
cached credentials for the domain if
step 1 <!-- <xref format="counter"
target="ssp-asd-steps-init">Step</xref>
--> was skipped, as specified in <xref
target="RFC4474"/> and
<xref target="RFC3261"/>. Depending
on the chosen SIP security mechanism
for client authentication either digest authentication,
client side authentication of Transport Layer Security,
or a combination of both is used to
provide the AS with a strong assurance
about the identity of Alice.
</t>
<t> AS Authorizes the SIP Request and
Forwards it to Callee
<vspace blankLines="1"/>
First, the AS authorizes the
received INVITE message as specified in
<xref target="RFC4474"/>
and <xref target="RFC3261"/>.
If the authorization is successful,
the AS will form the "identity
signature" for the message and add
Identity and Identity-Info header fields to
the message. The AS also at this time
constructs and caches a SAML assertion
asserting Alice's profile attributes
required by Bob's domain
(example2.com), and also containing a
the domain's (example.com) public key
certificate, or a reference to it.
This certificate MUST contain the
public key corresponding to the
private key used to construct the
signature whose value was placed in
the Identity header. The AS
constructs a HTTP-based SAML URI
Reference incorporating the
assertion's Assertion ID (see section
2.3.3 of <xref
target="OASIS.saml-core-2.0-os"/>).
The AS uses this URI as the value for
the Identity-Info header it adds to
the INVITE message.
<vspace blankLines="1"/>
The AS determines which profile
attributes (if any) to assert in the
<AttributeStatement> via local
configuration and/or obtaining
example2.com's metadata <xref
target="OASIS.saml-metadata-2.0-os"/>.
The AS then sends the
updated INVITE message to Bob.
</t>
<t> Callee Dereferences HTTP-based SAML
URI Reference
<vspace blankLines="1"/>
Bob's UAC or SIP Proxy
receives the message and begins
verifying it per the "Verifier
Behavior" specified in <xref
target="RFC4474"/>. In
order to accomplish this task, it
needs to obtain Alice's domain
certificate. It obtains the
HTTP-based SAML URI Reference
from the message's Identity-Info header
and dereferences it per
<xref target="ssb-saml-http-uri-sip-binding"/>.
Note that this is not a SIP message, but
an HTTP message <xref target="RFC2616"/>.
</t>
<t> AS Returns SAML Assertion
<vspace blankLines="1"/>
Upon receipt of the above HTTP request,
which contains an embedded reference to
Alice's SAML Assertion,
Alice's AS returns her assertion in an
HTTP response message.
<vspace blankLines="1"/>
Upon receipt of Alice's SAML Assertion,
the AS continues its verification of the
INVITE message. If successful, it returns a
200 OK message directly to Alice. Otherwise it
returns an appropriate SIP error response.
</t>
<t> Callee Returns SIP 200 OK to Caller
<vspace blankLines="1"/>
If Bob determines, based upon Alice's identity
as asserted by the AS, and as further
substantiated by the information in the
SAML assertion, to accept the INVITE, he
returns a SIP 200 OK message directly to
Alice.
</t>
</list>
</t>
</section>
<section anchor="ssp-asd-prof-descp"
title="Profile Description">
<t>
The following sections provide detailed
definitions of the individual profile
steps. The relevant illustration is <xref
target="fig-ssp-as-driven-roles-only"/>,
below. Note that this profile is agnostic to
the specific SIP request, and also that the
Sender and Authentication Service (AS) may be
seperate or co-located in actuality.
<!-- <vspace blankLines="100"/> --> <!-- pagebreak -->
<figure anchor="fig-ssp-as-driven-roles-only"
title="AS-driven SIP SAML Attribute Fetch
Profile: Message Flow">
<artwork>
<![CDATA[
+------------------+ +------------------+ +------------------+
| Sender | |Authn Service (AS)| | Verifier |
| (UAC) | | (Sender's) | |(UAS or Proxy Svr)|
+--------+---------+ +--------+---------+ +--------+---------+
| | | (steps)
| SIP Request | |
|---------------------->| | (1a)
| | |
| 407 Proxy auth. req. | |
|<----------------------| | (1b)
| Challenge | |
| | |
| ACK | |
|---------------------->| | (1c)
| | |
| | |
|SIP Req + authorization| |
| header w/ creds | |
|---------------------->| | (2)
| | |
| | |
| | SIP Req + Ident & |
| | authz headers |
| |--------------------->| (3)
| | |
| | URI resolution |
| |<=====================| (4)
| | (via HTTP) |
| | |
| | HTTP/1.1 200 OK |
| |=====================>| (5)
| | |
| | |
| | ? | (6)
| | |
]]>
</artwork>
</figure>
</t>
<section anchor="ssp-asd-pd-init-trans"
title="Initial SIP Transaction between
Sender and AS">
<t>
This OPTIONAL step maps to Steps 1 and 2
of Section 5 "Authentication Service
Behavior" of <xref
target="RFC4474"/>. If the
SIP request sent by the caller in substep
1a is deemed insufficiently authenticated
by the AS per the rules stipulated by
<xref target="RFC4474"/>
Steps 1 and 2, then the AS MUST
authenticate the sender of the
message. The particulars of how this is
accomplished depend upon implementation
and/or deployment instantiation as
discussed in <xref
target="RFC4474"/>. Substeps
1b and 1c as shown in <xref
target="fig-ssp-as-driven-roles-only"/> are
non-normative and illustrative only.
</t>
</section>
<section anchor="ssp-asd-pd-req-w-cred"
title="Sender sends SIP Request Message with
Authorization Credentials to the AS">
<t>
This step maps to Steps 1 and 2
of Section 5 "Authentication Service
Behavior" of <xref
target="RFC4474"/>. This
request is presumed to be made in a context
such that the AS will not challenge it -- i.e.,
the AS will consider the sender of the
message to be authenticated. If this is not
true, then this procedure reverts back to
Step 1, above.
<vspace blankLines="1"/>
Otherwise, the AS carries out all other
processing
of the message as stipulated in
<xref target="RFC4474"/>
Steps 1 and 2, and if successful, this
procedure procedes to the next step below.
</t>
</section>
<section anchor="ssp-asd-pd-as-authz-fwd"
title="AS Authorizes the SIP Request and
Forwards it to Verifier">
<t>
This first portion of this
step maps to Steps 3 and 4
of Section 5 "Authentication Service
Behavior" of <xref
target="RFC4474"/>, which
the AS MUST perform, although with the following
additional substeps:
<list>
<t>
The AS MUST construct a SAML
assertion according to the "<xref
format="title"
target="ssp-asd-assn-prof-descp"/>"
specified in <xref
target="ssp-asd-assn-prof-descp"/>
of this specification.
</t>
<t>
The AS SHOULD construct an HTTPS,
and MAY construct an HTTP, URI per
Section "3.7.5.1 URI
Syntax" of <xref
target="OASIS.saml-bindings-2.0-os"/>.
</t>
<t>
The AS MUST use the URI
constructed in the immediately
preceding substep as the value of
the Identity-Info header that is
added to the SIP request message
per Step 4 of Section 5 of <xref
target="RFC4474"/>.
</t>
</list>
Upon successful completion of all of the above, the
AS forwards the request message.
</t>
<t>
At this point in this step, after perhaps
traversing some number of intermediaries,
the SIP request message arrives at a SIP
network entity performing the
"verifier" role. This role and
its behavior are specified in Section 6
"Verifier Behavior" of <xref
target="RFC4474"/>.
The verifier MUST perform the steps enumerated in
the aforementioned section, with the following
modifications:
<list>
<t>
Step 1 of <xref
target="RFC4474"/>
Section 6 maps to and is updated
by, the following two steps in
this procedure.
</t>
<t>
Steps 2, 3, and 4 of <xref
target="RFC4474"/>
Section 6 may be mapped across
this latter portion of this step,
and/or the following two steps, as
appropriate.
</t>
</list>
</t>
</section>
<section anchor="ssp-asd-pd-callee-deref-saml-ref"
title="Verifier Dereferences HTTP-based SAML
URI Reference">
<t>
The verifier SHOULD ascertain whether it
has a current cached copy of the SIP
message sender's SAML assertion and domain
certificate. If not, or if the verifier
chooses to (e.g., due to local policy), it
MUST dereference the the HTTP-based SAML
URI Reference found in the SIP message's
Identity-Info header. To do so, the
verifier MUST employ the "<xref
format="title"
target="ssb-saml-http-uri-sip-binding"/>"
specified in <xref
target="ssb-saml-http-uri-sip-binding"/>.
</t>
</section>
<section anchor="ssp-asd-pd-as-ret-assn"
title="AS Returns SAML Assertion">
<t>
This step also employs <xref
target="ssb-saml-http-uri-sip-binding"/>
"<xref format="title"
target="ssb-saml-http-uri-sip-binding"/>".
</t>
<t>
If the prior step returns an HTTP error
(e.g., 4xx series), then this procedure
terminates and the verifier returns
(upstream) a SIP 436
'Bad Identity-Info' Response code.
</t>
<t>
Otherwise, the HTTP response message will
contain a SAML assertion and be denoted as
such via the MIME media type of
"application/samlassertion+xml"
<xref
target="IANA.application.samlassertion-xml"/>.
The verifier
MUST perform the verification steps
specified in <xref
target="ssp-asd-assn-verif"/> "<xref
format="title"
target="ssp-asd-assn-verif"/>",
below. If successful, then this procedure
continues with the next step.
</t>
</section>
<section anchor="ssp-asd-pd-callee-send-200ok"
title="Verifier performs Next Step">
<t>
The SIP request was successfully processed.
The verifier now performs its next step, which
depends at least in part on the type of
SIP request it received.
</t>
</section>
</section> <!-- Profile Description -->
<section anchor="ssp-asd-assn-prof-descp"
title="Assertion Profile Description">
<t>
This section defines the particulars of how
the sender, i.e., the SAML Authority, MUST
construct certain portions of the SAML
assertions it issues. The schema for SAML
assertions themselves is defined in Section 2.3
of <xref target="OASIS.saml-core-2.0-os"/>.
</t>
<t>
An example SAML assertion, formulated according to
this profile is given in <xref target="example"/>.
</t>
<t>
Overall SAML assertion profile requirements:
<list>
<t>
The SAML assertion MUST be signed by the
same key as used to sign the contents of the
Identity header field. Signing of SAML
assertions is defined in Section 5.4 of
<xref target="OASIS.saml-core-2.0-os"/>.
</t>
</list>
</t>
<t>
In the following subsections, the SAML
assertion profile is specified
element-by-element, in a top-down, depth-first
manner, beginning with the outermost element,
"<Assertion>". Where
applicable, the requirements for an element's
XML attributes are also stated, as a part of
the element's description. Requirements for
any given element or XML attribute are only
stated when, in the context of use of this
profile, they are not already sufficiently
defined by <xref
target="OASIS.saml-core-2.0-os"/>.
</t>
<section anchor="ssp-asd-apd-assn"
title="Element: <Assertion>">
<t>
<list style="hanging">
<t hangText="Attribute: ID">
<vspace blankLines="1"/>
The value for the ID XML attribute
SHOULD be allocated randomly such
that the value meets the
randomness requirments specified
in Section 1.3.4 of <xref
target="OASIS.saml-core-2.0-os"/>.
</t>
<t hangText="Attribute: IssueInstant">
<vspace blankLines="1"/>
The value for the IssueInstant XML
attribute SHOULD be set at the
time the SAML assertion is created
(and cached for subsequent
retrieval). This time instant
value MAY be temporally the same
as that encoded in the SIP
message's Date header, and MUST be
at least temporally later, although it
is RECOMMENDED that it not be 10 minutes
or more later.
</t>
</list>
</t>
<section anchor="ssp-asd-apd-issuer"
title="Element: <Issuer>">
<t>
The value for the Issuer XML element
MUST be a value that matches either
the Issuer or the Issuer Alternative
Name fields <xref target="RFC3280"/>
in the certificate conveyed by the
SAML assertion in the
ds:X509Certificate element located on
this path within the SAML assertion:
<figure>
<artwork align="left">
<Assertion
<ds:Signature
<ds:KeyInfo
<ds:X509Data
<ds:X509Certificate
</artwork>
</figure>
</t>
</section>
<section anchor="ssp-asd-apd-subject"
title="Element: <Subject>">
<t>
The <Subject> element SHOULD contain
both a <NameID> element and a
<SubjectConfirmation> element.
</t>
<t>
The value of the <NameID>
element MUST be the same as the
Address of Record (AoR) value used in
computing the
"signed-identity-digest"
which forms the value of the Identity
header. See Section 9 of <xref
target="RFC4474"/>.
</t>
<t>
The <SubjectConfirmation> element
attribute Method SHOULD be set to the value:
<list>
<t>
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
</t>
</list>
Although it MAY be set to some other
implementation- and/or deployment-specific
value. The <SubjectConfirmation>
element itself SHOULD be empty.
</t>
</section>
<section anchor="ssp-asd-apd-conditions"
title="Element: <Conditions>">
<t>
The <Conditions> element SHOULD
contain an <AudienceRestriction>
element, which itself SHOULD contain
an <Audience> element. The value
of the <Audience> element SHOULD
be the same as the addr-spec of the
SIP request's To header field.
</t>
<t>
The following XML attributes of the
<Conditions> element MUST be set
as follows:
<list style="hanging">
<t hangText="Attribute: NotBefore">
<vspace blankLines="1"/>
The value of the NotBefore XML
attribute MUST be set to a
time instant the same as the
value for the IssueInstant XML
attribute discussed above, or
to a later time.
</t>
<t hangText="Attribute: NotOnOrAfter">
<vspace blankLines="1"/>
The value of the NotOnOrAfter XML
attribute MUST be set to a time
instant later than the value for
NotBefore.
</t>
</list>
</t>
</section>
<section anchor="ssp-asd-apd-attr"
title="Element: <AttributeStatement>">
<t>
The SAML assertion MAY contain an
<AttributeStatement> element. If
so, the <AttributeStatement>
element will contain attribute-value
pairs, e.g., of a user profile nature,
encoded according to either one
of the "SAML Attribute
Profiles" as specified in <xref
target="OASIS.saml-profiles-2.0-os"/>,
or encoded in some implementation-
and/or deployment-specific attribute
profile.
</t>
<t>
The attribute-value pairs SHOULD in fact
pertain to the entity identified in the
SIP From header field, since a SAML assertion
formulated per this overall section is
stating that they do.
</t>
</section>
</section>
</section> <!-- Assertion Profile Description -->
<section anchor="ssp-asd-assn-verif"
title="Assertion Verification">
<t>
This section specifies the steps that a
verifier participating in this profile MUST
perform in addition to the "Verifier
Behavior" specified in Section 6 of <xref
target="RFC4474"/>.
</t>
<t>
The steps are:
<list style="numbers">
<t>
Before Step 1 in Section 6 of <xref
target="RFC4474"/>,
the verifier MUST extract the AS's
domain certificate from the
<ds:X509Certificate>
XML element at the end of the
element path given in
<xref target="ssp-asd-apd-issuer"/>.
</t>
<t>
Perform Step 1 in Section 6 of <xref
target="RFC4474"/>.
</t>
<t>
After Step 1 in Section 6 of <xref
target="RFC4474"/>,
but before Step 2 of that section, the
verifier MUST verify the SAML
assertion's signature via the
procedures specified in Section 5.4 of
<xref
target="OASIS.saml-core-2.0-os"/> as
well as <xref
target="W3C.xmldsig-core"/>.
<vspace blankLines="1"/>
@@ TODO: do we need to define a new SIP
error response code for when a SAML assn
signature is bad?
e.g., '4xx Invalid SAML asssertion'.
</t>
<t>
Perform Step 2 in Section 6 of <xref
target="RFC4474"/>.
</t>
<t>
Verify that the signer of the SIP message's
Identity header field is the same as the
signer of the SAML assertion.
</t>
<t>
Perform Steps 3 and 4 in Section 6 of <xref
target="RFC4474"/>.
</t>
<t>
Verify that the SAML assertion's
<Issuer> element value matches
the Issuer or the Issuer Alternative
Name fields <xref target="RFC3280"/>
in the AS's domain certificate.
</t>
<t>
Verify that the SAML assertion's
<NameID> element value is the
same as the Address of Record (AoR)
value in the
"signed-identity-digest".
See Section 9 of <xref
target="RFC4474"/>.
</t>
<t>
Verify that the SAML assertion's
<SubjectConfirmation> element
value is set to whichever value
was configured at implementation- or
deployment-time. The default value is:
<list style="hanging">
<t>
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
</t>
</list>
</t>
<t>
Verify that the SAML assertion
contains an <Audience> element, and
that its value matches the value of the
addr-spec of the
SIP To header field.
</t>
<t>
Verify that the validity period
denoted by the NotBefore and
NotOnOrAfter attributes of the
<Conditions> element meets the
requirements given in <xref
target="ssp-asd-apd-conditions"/>.
</t>
</list>
</t>
</section> <!-- Assertion Verification -->
</section> <!-- ssp-as-driven-attr-
AS-driven sip saml profile -->
<section anchor="ssp-tbd"
title="The TBD "call-by-value" Profile">
<t>
To-Be-Determined (TBD)
</t>
</section> <!-- The TBD call-by-value Profile -->
</section> <!-- SIP SAML Profiles -->
<section anchor="saml-sip-bindings" title="SAML SIP Binding">
<t>
This section specifies one SAML SIP Binding at this time.
Additional bindings may be specified in future revisions of
this specification.
</t>
<section anchor="ssb-saml-http-uri-sip-binding"
title="SAML HTTP-URI-based SIP Binding">
<t>
This section specifies the "SAML
HTTP-URI-based SIP Binding", (SHUSB).
</t>
<t>
The SHUSB is a profile of the "SAML URI Binding"
specified in Section 3.7 of
<xref target="OASIS.saml-bindings-2.0-os"/>.
The SAML URI Binding specifies a means by which
SAML assertions can be referenced by URIs and thus be
obtained through resolution of such URIs.
</t>
<t>
This profile of the SAML URI Binding is congruent with
the SAML URI Binding -- including support for
HTTP-based URIs being mandatory to
implement --
except for the following further
restrictions which are specified in the
interest of interoperability (section
numbers refer to <xref
target="OASIS.saml-bindings-2.0-os"/>):
</t>
<t>
<list style="hanging">
<t
hangText="Section 3.7.5.3 Security Considerations:">
<vspace blankLines="1"/>
Support for TLS 1.0 or SSL 3.0 is mandatory to implement.
</t>
<t
hangText="Section 3.7.5.4 Error Reporting:">
<vspace blankLines="1"/>
All SHOULDs in this section are to be
interpreted as MUSTs.
</t>
</list>
</t>
</section>
</section> <!-- SAML SIP Bindings -->
<section anchor="example" title="Example SAML Assertions">
<t>
This section presents two examples of a SAML assertion,
one unsigned (for clarity), the other signed (for
accuracy).
</t>
<t>
In the first example, <xref target="fig-unsign-saml-assn"/>,
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.
</t>
<t>
The above items correspond to some aspects of this
specification's SAML assertion profile, as noted below
in Security Considerations dicussions, see:
<xref target="sec-cons-stolen-assn"/> and
<xref target="sec-cons-forged-assn"/>.
</t>
<t>
In lines 24-36, Alice's
telephone number is conveyed, in a "typed" fashion, using
LDAP/X.500 schema as the typing means.
<vspace blankLines="100"/><!-- pagebreak -->
</t>
<t>
<figure title="Unsigned SAML Assertion
Illustrating Conveyance of
Subject Attribute"
anchor="fig-unsign-saml-assn">
<artwork>
<![CDATA[
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 <AttributeStatement>
25 <saml:Attribute
26 xmlns:x500=
27 "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
28 NameFormat=
29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
30 Name="urn:oid:2.5.4.20"
31 FriendlyName="telephoneNumber">
32 <saml:AttributeValue xsi:type="xs:string">
33 +1-888-555-1212
34 </saml:AttributeValue>
35 </saml:Attribute>
36 </AttributeStatement>
37 </Assertion>
]]>
</artwork>
</figure>
</t>
<t>
In the second example, <xref target="fig-sign-saml-assn"/>,
the information described above is the same, the addition
is that this version of the assertion is signed. All the
signature information is conveyed in the
<ds:signature> element, lines 7-47. Thus this
assertion's origin and its integrity are assured.
Since this assertion is the same as the one in the
first example above, other than having a signature
added, the second
example below addresses the same Security Considerations
aspects, plus those requiring a Signature.
</t>
<t>
<vspace blankLines="100"/><!-- pagebreak -->
<figure title="Signed SAML Assertion
Illustrating Conveyance of
Subject Attribute"
anchor="fig-sign-saml-assn">
<artwork>
<![CDATA[
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 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
8 <ds:SignedInfo>
9 <ds:CanonicalizationMethod
10 Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
11 <ds:SignatureMethod
12 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
13 <ds:Reference
14 URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
15 <ds:Transforms>
16 <ds:Transform
17 Algorithm=
18 "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
19 <ds:Transform
20 Algorithm=
21 "http://www.w3.org/2001/10/xml-exc-c14n#">
22 <InclusiveNamespaces
23 PrefixList="#default saml ds xs xsi"
24 xmlns=
25 "http://www.w3.org/2001/10/xml-exc-c14n#"/>
26 </ds:Transform>
27 </ds:Transforms>
28 <ds:DigestMethod
29 Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
30 <ds:DigestValue>
31 Kclet6XcaOgOWXM4gty6/UNdviI=
32 </ds:DigestValue>
33 </ds:Reference>
34 </ds:SignedInfo>
35 <ds:SignatureValue>
36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4=
37 </ds:SignatureValue>
38 <ds:KeyInfo>
39 <ds:X509Data>
40 <ds:X509Certificate>
41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT
42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX
43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w==
44 </ds:X509Certificate>
45 </ds:X509Data>
46 </ds:KeyInfo>
47 </ds:Signature>
48 <Subject>
49 <NameID
50 Format=
51 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
52 Alice@example.com
53 </NameID>
54 <SubjectConfirmation
55 Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
56 </Subject>
57 <Conditions NotBefore="2003-04-17T00:46:02Z"
58 NotOnOrAfter="2003-04-17T00:51:02Z">
59 <AudienceRestriction>
60 <Audience>
61 example2.com
62 </Audience>
63 </AudienceRestriction>
64 </Conditions>
65 <AttributeStatement>
66 <saml:Attribute
67 xmlns:x500=
68 "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
69 NameFormat=
70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
71 Name="urn:oid:2.5.4.20"
72 FriendlyName="telephoneNumber">
73 <saml:AttributeValue xsi:type="xs:string">
74 +1-888-555-1212
75 </saml:AttributeValue>
76 </saml:Attribute>
77 </AttributeStatement>
78 </Assertion>
]]>
</artwork>
</figure>
</t>
</section> <!-- example saml assertion -->
<section anchor="sec-cons" title="Security Considerations">
<t>
This section discusses security considerations when
using SAML with SIP.
</t>
<section anchor="sec-cons-stolen-assn"
title="Man-in-the-middle Attacks and Stolen Assertions">
<t>
<list style="hanging">
<t hangText="Threat:">
<vspace blankLines="1"/>
By making SAML assertions available via
HTTP-based requests by a potentially
unbounded set of requesters, it is
conceivably possible that anyone would be
able to simply request one and obtain
it. By SIP intermediaries on the signaling
path for example. Or, an HTTP
intermediary/proxy could intercept the
assertion as it is being returned to a
requester.
<vspace blankLines="1"/>
The attacker could then conceivably
attempt to impersonate the subject (the
putative caller) to some SIP-based target
entity.
</t>
<t hangText="Countermeasures:">
<vspace blankLines="1"/>
Such an attack is implausible for several
reasons. The primary reason is that a message
constructed by an imposter using a stolen
assertion that conveys the public key certificate
of some domain will not verify per
<xref target="RFC4474"/> because
the imposter will not have the corresponding
private key with which to generate the signed
Identity header value.
</t>
<t>
Also, the SIP
SAML assertion profile specified herein
that the subject's SAML assertion must adhere
to causes it to be not useful to arbitrary
parties. The subject's assertion:
<list style="symbols">
<t>
should be signed, thus causing any
alterations to break its integrity and
make such alterations detectable.
</t>
<t>
does not contain an authentication
statement. Thus no parties implementing
this specification should be relying
on SAML assertions specified herein
as sufficient in and
of themselves to
allow access to resources.
</t>
<t>
relying party is represented in the
SAML assertion's
Audience Restriction.
</t>
<t>
Issuer is represented in the
SAML assertion.
</t>
<t>
validity period for assertion is
restricted.
</t>
<t>
etc.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="sec-cons-forged-assn" title="Forged Assertion">
<t>
<list style="hanging">
<t hangText="Threat:">
<vspace blankLines="1"/>
A malicious user
could forge or alter a SAML assertion in
order to communicate with the SIP
entities.
</t>
<t hangText="Countermeasures:">
<vspace blankLines="1"/>
To avoid this
kind of attack, the entities must assure
that proper mechanisms for protecting the
SAML assertion are employed, e.g., signing
the SAML assertion itself. Section 5.1 of
<xref target="OASIS.saml-core-2.0-os"/>
specifies the
signing of SAML assertions.
<vspace blankLines="1"/>
Additionally, the assertion content dictated
by the SAML assertion profile herein ensures
ample evidence for a relying party to verify
the assertion and its relationship with the
received SIP request.
</t>
</list>
</t>
</section>
<section anchor="sec-cons-replay-attack" title="Replay Attack">
<t>
<list style="hanging">
<t hangText="Threat:">
<vspace blankLines="1"/>
Theft of SIP message protected
by the mechanisms described herein
and replay of it at a
later time.
</t>
<t hangText="Countermeasures:">
<vspace blankLines="1"/>
There are various provisions within
<xref target="RFC4474"/>
that prevent a replay attack.
</t>
</list>
</t>
</section>
</section>
<section title="Contributors">
<t>
The authors would like to thank Marcus Tegnander and
Henning Schulzrinne for his contributions to earlier
versions of this document.
</t>
</section>
<section title="Acknowledgments">
<t>
We would like to thank RL 'Bob' Morgan, Stefan Goeman,
Shida Schubert, Jason Fischl and Vijay Gurbani for
their comments to this draft. The "AS-driven SIP SAML
URI-based Attribute Assertion Fetch Profile" is based
on an idea by Jon Peterson.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>[Editor's Note: A future version of this document will
provide IANA considerations.]
</t>
</section>
<section title="Open Issues">
<t>A list of open issues can be found at:
http://www.tschofenig.com:8080/saml-sip/
</t>
</section>
<section title="Change Log">
<t>
RFC Editor - Please remove this section before publication.
</t>
<section title="-02 to -03">
<t>
Denoted that this I-D is intended to update RFC4474
per SIP working group consensus at IETF-69. This is the
tact adopted in order to address the impedance mismatch
between the nature of the URIs specified as to be placed
in the Identity-Info header field, and what is
specified in RFC4474 as the allowable value of that
header field.
</t>
<t>
Added placeholder "TBD" section for
a to-be-determined "call-by-value" profile,
per SIP working group consensus at IETF-69.
</t>
<t>
Removed use-case appendicies (per recollection of
JHodges during IETF-69 discussion as being WG consensus,
but such is not noted in the minutes).
</t>
</section>
<section title="-00 to -02">
<t>
Will detail in -04 rev.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&RFC4474;
&RFC4484;
&OASIS.saml-bindings-2.0-os;
&OASIS.saml-core-2.0-os;
&OASIS.saml-metadata-2.0-os;
&OASIS.saml-profiles-2.0-os;
&RFC.2119;
&RFC.2392;
&RFC.2616;
&RFC.3261;
&RFC.3280;
&RFC.3515;
&RFC.3553;
&RFC.3893;
&W3C.xmldsig-core;
</references> <!-- Normative -->
<references title="Informative References">
&I-D.ietf-sip-content-indirect-mech;
&I-D.ietf-sipping-certs;
&I-D.jennings-sipping-pay;
&I-D.peterson-message-identity;
&IANA.application.samlassertion-xml;
&OASIS.saml-conformance-2.0-os;
&OASIS.saml-glossary-2.0-os;
&OASIS.saml-sec-consider-2.0-os;
&OASIS.sstc-saml-exec-overview-2.0-cd-01;
&OASIS.sstc-saml-tech-overview-2.0-draft-08;
<reference anchor="OASIS.sstc-saml-protocol-ext-thirdparty-cd-01">
<front>
<title>
SAML Protocol Extension for Third-Party Requests
</title>
<author fullname="Scott Cantor"
initials="S."
surname="Cantor">
<organization>Internet2</organization>
<address>
<email>cantor.2@osu.edu</email>
</address>
</author>
<date year="2006" month="March"/>
</front>
<seriesInfo name="OASIS SSTC Committee Draft"
value="sstc-saml-protocol-ext-thirdparty-cd-01"/>
<format type="PDF"
target="http://www.oasis-open.org/committees/download.php/18055/sstc-saml-protocol-ext-thirdparty-cd-01.pdf"/>
</reference>
&RFC.2543;
&RFC.2693;
&RFC.3281;
&RFC.3323;
</references> <!-- Informative -->
<!--
<section anchor="scenarios" title="Appendix: Use-case Scenarios">
<t>
This Appendix explores message flows based on
various use-case scenarios in
<xref target="RFC4484"/>,
and from various discussions,
to which SAML-based solutions are applied. <xref
target="scenario-conferencing"/> shows a SIP
conferencing scenario with role-based access control
using SAML.
</t>
<t>
Note that we present these scenarios as
illustrations of
possible SAML-based
use cases in SIP. This document does not
provide a detailed exposition of these scenarios -- that
is left for addtional documents.
</t>
<section anchor="sip-pstn-call" title="PSTN-to-SIP Phone Call">
<t>
Alice, using a phone connected to the PSTN, wants
to make a call to Bob, who resides in a SIP
network. Her call is switched through the PSTN by
means of PSTN signaling (outside the scope of this
document) to the PSTN/SIP gateway. At the gateway,
the call is converted from SS7 signaling to SIP
signaling. Since Alice's PSTN phone was previously
"authenticated" via PSTN signaling
mechanisms, the gateway is able to assert her
phone's identity (e.g., her telephone number) via
SIP Identity and SAML-based mechanisms (e.g., in
order to convey profile attributes) to Bob's SIP
proxy, which also dereferences the URI in the
Identity-Info header in order to obtain the SAML
assertion and the PSTN/SIP Gateway's domain
certificate. Alice's INVITE is then forwarded from the
SIP/PSTN gateway to Bob's phone, and is secured
via whatever means is locally established in Bob's
administrative domain.
</t>
<t>
<figure title="PSTN to SIP call" anchor="pstn-sip-call">
<artwork>
<![CDATA[
+-----------+
+----------------------+ | |
| | SS7 | PSTN/SIP |
| Public Switched |--------------------->| Gateway |
| | | |
| | | |
| Telephone Network | +--+-----------+------+
| ^ | | | ^ V |
+---------+------------+ | | ^ V SIP-Ident |
| SS7 | v ^ V +SAML |
| | +--------+ |
O | | Bob's | |
O /|\ <----+----| SIP | |
/|\ / \ SIP | | Proxy | |
/ \ Bob | | | |
Alice | +--------+ |
| SIP based |
| Network |
+---------------------+
]]>
</artwork>
</figure>
</t>
<t>
Note that the INVITE emitted by the PSTN/SIP gateway
could alternatively be simply forwarded by Bob's SIP
Proxy to Bob's phone, and Bob's phone could take on the
SIP Identity "verifier" role, which is being
played by Bob's SIP proxy in the figure.
</t>
<t>
Whichever approach is employed is a decision local to
Bob's administrative domain and can be made independently.
</t>
</section>
--> <!-- PSTN-to-SIP Phone Call -->
<!--
<section anchor="scenario-conferencing" title="SIP Conferencing">
<t>
This section is meant to foster discussion
about the usage of SAML in the domain of
conferencing. A user agent who routes its SIP message
through the Authentication Service (Asserting
Party) towards a conferencing server may want
or need various of her profile attributes included
and may also need to be authenticated by
the conference server. The following
properties could be provided by this procedure:
<list style="symbols">
<t>
The user identity can be replaced to allow
the user to be anonymous with regard to
the Focus. This can be accomplished via
<xref target="RFC3323"/> in combination
with <xref
target="RFC4474"/>, per the
latter, or,
</t>
<t>
The user identity could be asserted to the
Focus, via <xref
target="RFC4474"/> mechanisms,
and/or,
</t>
<t>
the SAML assertion could provide
additional user profile
information such as group
membership (belongs to the students,
staff, faculty group of university
X). This could, for non-identity-based
authorization systems, imply certain
rights.
</t>
</list>
</t>
<t>
The corresponding SIP message flow (in high level
detail) could have the following shape:
<figure title="SIP Conferencing and SAML"
anchor="msg-flow-conferencing">
<artwork>
<![CDATA[
+-----+ +-----------+ +-----------+
| | | SIP Proxy | | Focus |
|User | |(Asserting | | (Relying |
| | | party) | | party) |
+--+--+ +-----+-----+ +-----+-----+
| INVITE | |
|sip:conf-factory | INVITE |
|------------------>| w/Identity hdr |
| |------------------>|
| | |
| | HTTP GET SAML assn|
| |<==================|
| | and domain cert |
| | |
| | HTTP 200 OK + assn|
| |==================>|
| | and domain cert |
| | |
| | |
| | Ringing |
| Ringing |<------------------|
|<------------------| |
| | |
| | OK |
| OK |<------------------|
|<------------------| |
| | |
| ACK | |
|------------------>| ACK |
| |------------------>|
| | |
| | |
... many more msgs...
]]>
</artwork>
</figure>
</t>
<t>
However, there are obvious scaling issues with
the conference server having to do the outbound requests
in order to obtain SAML assertions and certificates for
conference participants.
</t>
<t>
This could be addressed by creating another SIP
SAML Profile where the caller obtains the
necessary information, e.g., SAML assertions, and
places them into its SIP request message prior to
sending it. This would obviate the need for the
callee relying party to make requests in order to
obtain said information. This is a topic for future
work, and possibly future revisions of this
specification.
</t>
</section>
--> <!-- SIP Conferencing -->
<!--
<section anchor="sip-saml-payment"
title="Compensation using SIP and SAML">
<t>
This section describes a scenario where
SAML is used in SIP to realize compensation
functionality as described in <xref
target="I-D.jennings-sipping-pay"/>.
</t>
<t>
Note that this
scenario is not directly addressed by the SIP SAML
Profile and SAML SIP Binding presently defined in
this specification. Rather, this use case calls for
additional such profiles and bindings to be developed.
</t>
<t>
<figure anchor="fig-compensation"
title="Message flow for SIP payment">
<artwork>
<![CDATA[
+--------+ +--------+ +--------+
|Payment | | User | |Merchant|
|Provider| | Alice | |Bob |
| | | | | |
| | | | | |
+---+----+ +---+----+ +---+----+
| | |
| | 1) Call |
| |------------------------>|
| | |
| | 2) 402 + Payment Offer |
| 3) Request for |<------------------------|
| a Payment | |
|<----------------------| |
| | |
| 4) SAML Assertion | |
| (=Receipt) | |
|---------------------->| |
| | 5) Call + Receipt |
| |------------------------>|
| | |
| | 6) 200 OK |
| |<------------------------|
| | |
]]>
</artwork>
</figure>
</t>
<t>
User Alice and the Merchant Bob interact with
each other using SIP and the Alice uses HTTP to
exchange messages with a Payment
Provider. Initially, Alice makes a call to Bob
(1). Bob determines that a payment is required and
includes information about the payment in an Offer
body of a 402 (Payment Required) response to Alice
(2). Alice looks at this Offer and decides to make
a payment. Alice therefore instructs her Payment
Provider to make a transfer from Alice"s
account to the Merchants"s account (3) using a
request for a SAML assertion with the extensions
defined in this document. The Payment Provider
returns a receipt for this transfer (4). This
receipt is a SAML Assertion. Alice resubmits the call
to Bob but this time provides the Receipt for the
transaction (5). Bob determines whether the
Receipt is valid (by checking the digital
signature and the content of the assertion) and
continues with the call processing, if the
authorization was succesful.
</t>
<t>
The Offer contains information about the
participating parties (i.e., the Payment Provider, the
Merchant Bob, and the user Alice), the transaction
amount, the account identifier for Bob at the Payment
Provider, and a replay protection indicator to make it
easier for the Merchant Bob to avoid replay
attacks. User Alice includes this information when
making the Request for Payment to the Payment
Provider; adds its own account information and
authorization password; and sends this to the Payment
Provider, which produces a Receipt for the transaction
if it is successful. This transfer from Alice to the
Payment Provider is made across an encrypted,
integrity protected channel. The Receipt includes a
timestamp when the Payment Provider made the
transaction and protects the Receipt with a digital
signature. Alice resubmits the call to the Merchant
Bob with the Receipt from the Payment
Provier. Merchant Bob can check for replay attacks
using the timestamp and a replay protection indiciator
initially provided with the Offer. Bob can then check
the signature is valid using the Payment
Provider"s public key.
</t>
</section>
--> <!-- Compensation using SIP and SAML -->
<!--
</section>
--> <!-- use case scenarios -->
</back>
</rfc>
<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
<!--
Local Variables:
mode: xml
indent-tabs-mode:nil
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:4
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->
| PAFTECH AB 2003-2026 | 2026-04-23 03:37:55 |