One document matched: draft-ietf-sip-saml-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
<!ENTITY PUBLIC ""
""-->
<!-- saved until updated citation is in http://xml.resource.org/public/rfc/bibxml2 repository...
<bang ENTITY OASIS.sstc-saml-tech-overview-2.0-draft-16 PUBLIC ""
"file:///home/hodges/doc/IETF/bibxml/bibxml2/reference.OASIS.sstc-saml-tech-overview-2.0-draft-16.xml">
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3969 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3969.xml'>
<!ENTITY RFC4474 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY RFC2585 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2585.xml'>
<!ENTITY RFC4234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml'>
<!ENTITY RFC4484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4484.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 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">
<!ENTITY I-D.ietf-oauth-v2 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2.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="exp"
ipr="trust200902"
docName="draft-ietf-sip-saml-08.txt">
<front>
<title abbrev="SAML over SIP">SIP SAML Profile and Binding</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization abbrev=""></organization>
<address>
<!-- <postal>
<street>Woodside Road</street>
<city>Redwood City</city>
<region>CA</region>
<code>94061</code>
<country>US</country>
</postal> -->
<email>Jeff.Hodges@KingsMountain.com</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="2010"/>
<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>
<keyword>OAuth</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
identity. 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-16"/>
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 for encoding authorization information
exists, such as authorization certificates
<xref target="RFC3281"/>, SPKI <xref target="RFC2693"/>, or
extensions to the authenticated identity body <xref
target="RFC3893"/>. This document focuses on an encoding
of the authorization information using SAML assertions
but does not exclude other formats to be used utilized
in the future.
</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-16"/>
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="spec-scope" title="Specification Scope">
<t>
The scope of this specification is:
</t>
<t>
<list style="symbols">
<t>
Specify a SIP profile of SAML -- also known as 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> <!-- spec-scope -->
<!-- ****************************************************** -->
<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 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 SIP SAML Profiles defined in this document make
use of concepts defined by <xref target="RFC4474"/>
"Enhancements for Authenticated Identity
Management in the Session Initiation Protocol
(SIP)" -- also known as "SIP
Identity". SIP Identity allows the SIP UA client and an entity on behalf
of the UA client to attach a SAML assertion (or a reference to it).
Since intermediaries, like an outbound SIP proxy, are not allowed to modify the
body of a SIP message such an intermediary would attach a pointer to the
assertion instead.</t>
<t>The specific details on how the SAML assertion is requested are outside the scope
of this document. Possible mechanisms are to use a software library that can be
accessed via an API, a separate authorization server that can be queried via HTTP
(as envisioned by OAuth <xref target="I-D.ietf-oauth-v2"/>), or any other mechanism.
As such, this document does not further describe the functional split between the
party that attaches the SAML assertion to the SIP message and the party that
creates the SAML assertion.
</t>
<t>
The SIP Identity specification calls the party that makes identity assertions
about the caller "Authentication Service (AS)". 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. This document uses the term SAML Authority and
Authentication Service interchangable particularly because of the fact that the
entity that attaches the SAML assertion to the SIP message also uses the
SIP Identity mechanism to bind it to the message.
</t>
<t>Note that technically there is a difference between attaching a reference to a
SAML assertion and attaching a SAML assertion to the body of a message.
We define two different profiles to cover these two cases:
</t>
<t><list style="hanging">
<t hangText="AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile:">
<vspace blankLines="1"/>In case of this profile the AS attaches a reference
to a SAML assertion to the SIP message and makes it available to the verifier.
More details about this profile can be found in <xref
target="ssp-as-driven-attr-"/>. <vspace blankLines="1"/></t>
<t hangText="Assertion-by-Value Profile:">
<vspace blankLines="1"/> In case of this profile the SAML assertion is made
available to the verifying party directly without the additional step of
utilizing a reference. This approach is described in <xref
target="ssp-caller-driven-prof"/>.
</t>
</list>
</t>
</section>
<section title="URI Parameter Definition">
<t>
This document represents the URL pointing to the authorization information
using a URI parameter. The grammar for this parameter is (following the ABNF
<xref target="RFC4234"/> in Section 25 of RFC 3261 <xref
target="RFC3261"/>):
</t>
<t>
<figure anchor="fig-token-info-grammar" title="'token-info' ABNF Grammar">
<artwork>
<![CDATA[
token-info =
"token-info" HCOLON ident-info *( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = generic-param
]]>
</artwork>
</figure>
</t>
<t>
The "absoluteURI" MUST
contain a URI which dereferences to a resource
containing a SAML assertion. All implementations of
this specification MUST support the use of HTTP and
HTTPS URIs. Such HTTP and
HTTPS URIs MUST follow the conventions of RFC 2585
<xref target="RFC2585"/>, and for those URIs the
indicated resource MUST be of the form
'application/samlassertion+xml' described in that
specification.
</t>
<t>
An example of the syntax of the "token-info" parameter is given below:
<figure>
<artwork>
<![CDATA[
From: <tel:+17005554141;
token-info=https://example.com/assns/?ID=abcde>;
tag=1928301774
]]>
</artwork>
</figure>
</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
"Assertion-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
<vspace blankLines="1"/>
</t>
<t hangText="Contact Information:">
<vspace blankLines="1"/>
Hannes Tschofenig (Hannes.Tschofenig@nsn.com)
<vspace blankLines="1"/>
</t>
<t hangText=
"SAML Confirmation Method Identifiers:">
<vspace blankLines="1"/>
The SAML V2.0
confirmation method identifier is used
in this profile.<vspace blankLines="1"/>
</t>
<t hangText="Description:">
<vspace blankLines="1"/>
Given below.<vspace blankLines="1"/>
</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, 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
| | |
G = | | token-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 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.
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 and puts the value into
the token-info parameter.
<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 token-info parameter
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 + token-info |
| |--------------------->| (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 token-info parameter that is
added to the SIP request message.
</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
token-info parameter. 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 token-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> <!-- ssp-as-driven-attr-
AS-driven sip saml profile -->
<section anchor="ssp-caller-driven-prof"
title="Caller-driven SIP SAML Conveyed Assertion Profile">
<!-- The "Assertion-by-value" Profile -->
<t>
For the "Assertion-by-value" profile we
assume that a SAML assertion is obtained
out-of-band and attached to the body of the SIP
message. Note that any SIP message may be used to
convey the SAML assertion even though SIP INVITE
may be the most appropriate candiate. The
verification step described in <xref
target="ssp-asd-assn-verif"/> is applicable to
this profile as well as the description on the
content of the assertion illustrated in <xref
target="ssp-asd-assn-prof-descp"/>.
</t>
</section> <!-- ssp-caller-driven-prof -->
</section> <!-- SIP SAML Profiles -->
<!-- ****************************************************** -->
<section title="Assertion Profile">
<t>This section provides some guidance on what information
should be put into a SAML assertion by the SAML Authority and how
that information is then used by the Verifier.
</t>
<section anchor="ssp-asd-assn-prof-descp"
title="Assertion Profile Description">
<t>
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> If a SAML assertion is signed then it MUST be
signed by the same key that is used in the
Transport Layer Security mechanism utilized
with HTTPS. 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"/>.
<vspace blankLines="1"/>
</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
Address of Record (AoR).
</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. When included the value
of the <Audience> element MUST
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.<vspace blankLines="1"/>
</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 has to
perform to verify a SAML assertion created
according to the profile
from <xref target="ssp-asd-apd-assn"/>.
</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"/>.
The 479 'Invalid SAML Assertion' response code
is used when the
verifier is unable to process the SAML assertion.
</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, if SIP
Identity is used to bind the token-info parameter
to the SIP signaling message. Note that without
such protection certain attacks are feasible as described
in <xref target="sec-cons"/>.
</t>
<t>Verify that the content of the SAML assertion
matches with the information carried in the SIP message.
This may include the following checks:
</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.
</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>
<!-- ****************************************************** -->
<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. The description in
<xref target="ssp-asd-assn-prof-descp"/> is applicable
to this profile.
</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. <vspace blankLines="1"/>
</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
attempt to utilize the SAML assertion in another
exchange in order 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 because
the values in the
SAML assertion, which are tied to the SIP message,
will not verify.
</t>
<t>
Furthermore, the SIP
SAML assertion may contain restrictions regarding the
parties it can be used by.
Finally, the assertion should be signed and thus
causing any alterations to break its integrity and
make such alterations detectable.
</t>
</list>
</t>
</section>
<section anchor="sec-cons-privacy" title="Privacy">
<t>
<list style="hanging">
<t hangText="Threat:">
<vspace blankLines="1"/>
The ability for other entities to obtain
additional information about an individual,
such as role in an organization or other
authorization relevant information raises
privacy concerns.
<vspace blankLines="1"/>
Since the SAML assertion itself is not
confidentiality protected nor the exchange
of the reference to the SAML assertion an
intermediary or a third party adversary
would be allowed to gain additional
information about an individual
</t>
<t hangText="Countermeasures:">
<vspace blankLines="1"/>
To address the threats three cases need to be
differentiated.
<vspace blankLines="1"/>
First, a third party that did not participate in
any of the exchange is prevented from eavesdropping
on the content of the SAML assertion by employing
confidentiality protection of the SIP signaling exchange
as well as the HTTP exchange. This ensures that an
eavesdropper on the wire is unable to obtain information.
However, this does not prevent intermediaries, such as
SIP proxies from observing a URL to a SAML assertion
(in the token-info parameter). To deal with this second
type of attacker depending on the environment where such
a threat must be addressed it is necessary to
authenticate the entity that tries to resolve the
reference to a SAML assertion and to only provide a
positive response (with the SAML assertion) if the
requestor is authorized to obtain the desired information.
When a SAML assertion is carried inband then such a
protection is more difficult to accomplish as the SAML
assertion would have to be confidentiality protected with
the key of the intented recipient, for example using S/MIME.
Finally, the last type of threat concerns the intented
recipient of the SAML assertion itself. Proper permissions
for the distribution of information about the caller via the
content of the SAML assertion to certain recipients need to
be available. This permission must be provided by the caller
itself or, in certain circumstances, by someone on behalf of
the caller. From a technical point of view, some form of
authorization policies will be required.
</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 or protecting the
transport of the SAML assertion from the AS to the
verifying party using TLS. 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"/>
The SAML assertion may contain several elements to
prevent replay attacks. There is, however,
a clear tradeoff between the replaying an assertion
and re-using it over multiple SIP exchanges/sessions.
<vspace blankLines="1"/>
Additionally, the SAML assertion can be tied to the
SIP exchange with the help of the SIP Identity mechanism.
RFC 4474 <xref target="RFC4474"/> signs certain header
fields and the SIP message body and thereby helps to
protect message modifications. If a recipient knows that
all messages from a certain originator arrive with
SIP Identity protection applies then downgrading attacks
are not possible.
</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, Sebastian Felis, Nie Pin,
Marcos Dytz, Erkki Koivusalo, Richard Barnes,
Marc Willekens, Marc Willekens, Steffen Fries and
Vijay Gurbani for their comments to this draft.
</t>
<t>Eric Rescorla also provided a detailed review of the
document. We would like to thank him for his feedback.
</t>
<t>
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>When a SAML assertion is attached to the body of the message then
the "application/samlassertion+xml" MIME media type is used.
This MIME type is already registered with IANA and no further action
is required from IANA.
</t>
<section title="URI Parameter">
<t> This document extends the registry of URI parameters,
as defined RFC 3969 <xref target="RFC3969"/> with the
following value:
</t>
<t>
Parameter Name: token-info
</t>
<t>
Predefined Values: No
</t>
<t>
Reference: This document
</t>
</section>
<section title="477 'Binding to SIP Message failed' Response Code">
<t>
This document registers a new SIP response code.
It is sent when a verifier receives a SAML assertion but the
Subject and Condition elements cannot be matched to the content
in the SIP message, i.e., the binding between the SIP message and the
SAML assertion cannot be accomplished.
This response code is defined by
the following information, which has been added to the method and
response-code sub-registry under
http://www.iana.org/assignments/sip-parameters.
</t>
<t>
Response Code Number: 477
</t>
<t>Default Reason Phrase: Binding to SIP Message failed
</t>
</section>
<section title="478 'Unknown SAML Assertion Content' Response Code">
<t>
This document registers a new SIP response code.
It is used when the verifier is unable to parse the content of
the SAML assertion,
because, for example, the assertion contains only unknown elements in
in the SAML assertion, or the SAML assertion XML document is garbled.
This response code is defined by the following
information, which has been added to the method and response-code
sub-registry under http://www.iana.org/assignments/sip-parameters.
</t>
<t>
Response Code Number: 478
</t>
<t>Default Reason Phrase: Unknown SAML Assertion Content
</t>
</section>
<section title="479 'Invalid SAML Assertion' Response Code">
<t>
This document registers a new SIP response code.
It is used when the verifier is unable to process the SAML
assertion. A verifier may be unable to process the SAML assertion
in case the assertion is self-signed, or signed by a
root certificate authority for whom the verifier does not possess a
root certificate. This response code is defined by the following
information, which has been added to the method and response-code
sub-registry under http://www.iana.org/assignments/sip-parameters.
</t>
<t>
Response Code Number: 479
</t>
<t>Default Reason Phrase: Invalid SAML Assertion</t>
</section>
</section>
<section title="Change Log">
<t>
RFC Editor - Please remove this section before publication.
</t>
<section title="-06 to -07">
<t>Undo changes made in version 6.</t>
<t>Removed the header fields and switched to a URI parameter</t>
<t>Editorial changes</t>
</section>
<section title="-05 to -06">
<t>Defined a new SIP Identity signature mechanism.</t>
</section>
<section title="-04 to -05">
<t>Changed the document type to experimental</t>
<t>Removed option tag</t>
<t>Added the Caller-driven SIP SAML Conveyed Assertion Profile</t>
<t>Defined a new header (SAML-Info)</t>
<t>Changed the description for usage with this new header</t>
<t>Updated security considerations</t>
<t>Minor editorial cleanups</t>
</section>
<section title="-03 to -04">
<t>Updated IANA consideration section.
</t>
<t>Added option tag</t>
<t>Updated acknowledgments section</t>
<t>Minor editorial changes to the security considerations section</t>
</section>
<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>
Initial specifications to kickstart the work.
</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;
&RFC3969;
&RFC.2119;
&RFC.2392;
&RFC.2616;
&RFC.3261;
&RFC.3280;
&RFC.3515;
&RFC.3553;
&RFC.3893;
&W3C.xmldsig-core; &RFC4234; &RFC2585;
</references> <!-- Normative -->
<references title="Informative References">
&I-D.ietf-oauth-v2;
&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-16; -->
<reference anchor="OASIS.sstc-saml-tech-overview-2.0-draft-16">
<front>
<title>Security Assertion Markup Language
(SAML) V2.0 Technical Overview</title>
<author fullname="Nick Ragouzis" initials="N." surname="Ragouzis">
<organization>Enosis Group LLC</organization>
<address>
<email></email>
</address>
</author>
<author fullname="John Hughes" initials="J." surname="Hughes">
<organization>PA Consulting</organization>
<address>
<email></email>
</address>
</author>
<author fullname="Rob Philpott" initials="R." surname="Philpott">
<organization>RSA Security</organization>
<address>
<email></email>
</address>
</author>
<author fullname="Eve Maler" initials="E." surname="Maler">
<organization>Sun Microsystems</organization>
<address>
<email>eve.maler@sun.com</email>
</address>
</author>
<author fullname="Paul Madsen" initials="P." surname="Madsen">
<organization>NTT</organization>
<address>
<email>paulmadsen@rogers.com</email>
</address>
</author>
<author fullname="Tom Scavo" initials="T." surname="Scavo">
<organization>NCSA/University of Illinois</organization>
<address>
<email>trscavo@gmail.com</email>
</address>
</author>
<date year="2008" month="May"/>
</front>
<seriesInfo name="OASIS SSTC Working Draft" value="sstc-saml-tech-overview-2.0-draft-16"/>
<format type="PDF" target="http://www.oasis-open.org/committees/download.php/28345/sstc-saml-tech-overview-2.0-draft-16.pdf"/>
</reference>
<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 -->
</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 10:07:40 |