One document matched: draft-ietf-sip-saml-05.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 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">
]>
<?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="full3978"
docName="draft-ietf-sip-saml-05.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>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="">Unaffiliated</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="2008"/>
<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-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 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-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". In particular, they leverage the
"mediated authentication architecture" utilizing the
Authentication Service (AS). The overall 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>
The approach used by this document is similar to the
one used for SIP Identity. I.e. the AS creates a SAML
assertion and makes it available to the verifier via a
reference, in the particular case of the AS-driven SIP SAML URI-based
Attribute Assertion Fetch Profile. <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.
In case of the Assertion-by Value 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>
<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/SAML-Info header |
| |--------------------->|
| | |
| | |
| | HTTP GET SAML assn |
| |<==================== |
| | |
| | |
| | HTTP 200 OK + assn |
| |=====================>|
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
]]>
</artwork>
</figure>
</t>
<t>
<xref target="fig-ovrall-msg-flow"/> shows an exchange
based on the AS-driven SIP SAML URI-based Attribute
Assertion Fetch Profile where the AS creates a SAML
assertion, creates a reference to it, and puts that
reference into the SAML-Info header before forwarding
the SIP message. Bob in our case acting as the
verifier uses the reference to retrieve the SAML
assertion and verifies it.
</t>
</section>
<section title="Header Syntax">
<t>
This document specifies the new SIP header "SAML-Info".
This header MAY appear in any SIP header and MAY also appear more
than once.
</t>
<t>
The grammar for this header is (following the ABNF
<xref target="RFC4234"/> in section 25 of RFC 3261 <xref
target="RFC3261"/>):
</t>
<t>
<figure anchor="fig-saml-info-grammar" title="SAML-Info ABNF grammar">
<artwork>
<![CDATA[
SAML-Info =
"SAML-Info" HCOLON ident-info *( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = generic-param
]]>
</artwork>
</figure>
</t>
<t>
The "absoluteURI" portion of the SAML-Info header 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 in the SAML-Info header. 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>
No parameters are defined for the SAML-Info header in this
document. Future Experimental RFCS may define additional
SAML-Info header parameters.
</t>
<t>
This document adds the following entries to Table 2 of
RFC 3261 <xref target="RFC3261"/>:</t>
<t>
<figure anchor="fig-saml-info-3261-table2-row"
title="New SAML-Info Row for RFC3261 Table 2">
<artwork>
<![CDATA[
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
SAML-Info R a o o - o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
]]>
</artwork>
</figure>
</t>
<t>
The SAML-Info header MUST NOT appear in
CANCEL.
</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
</t>
<t hangText="Contact Information:">
<vspace blankLines="1"/>
Hannes Tschofenig (Hannes.Tschofenig@nsn.com)
</t>
<t hangText=
"SAML Confirmation Method Identifiers:">
<vspace blankLines="1"/>
The SAML V2.0
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, 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 = | | SAML-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 as the value for
the SAML-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 SAML-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 + SAML-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 SAML-Info header 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
SAML-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 SAML-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>
When using an HTTPS URI then the SAML assertion does not necessarily
needs to be signed. If it 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"/>.
</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.
</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"/>
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.
</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> <!-- 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 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.
</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="option-tag" title="The 'saml-shusb' Option Tag">
<t>
This document creates and IANA registers one new option tag:
"saml-shusb". This option tag is to be used, as defined in RFC
3261, in the Require, Supported and Unsupported headers.
It is used to indicate support for this SIP extension, this
option tag is included in a Supported header of the SIP request.
</t>
</section>
-->
<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 because
the values in the
SAML assertion, which are tied to the SIP message,
will not verify.
</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>
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>
</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 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.
</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.
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">
<!--
<section title="IANA Registration for New SIP Option Tag">
<t>
The SIP option tag "saml-shusb" is created by this document, with
the definition and rule in Section 4.4 of this document, to be added
to sip-parameters within IANA.
</t>
</section>
-->
<section title="Header Field Names">
<t>
This document specifies the new SIP header 'SAML-Info'. Their syntax is given in Section 9. This header is defined
by the following information, which has been added to the header
sub-registry under http://www.iana.org/assignments/sip-parameters.
</t>
<t>
Header Name: SAML-Info
</t>
<t>Compact Form: y
</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="Open Issues">
<t>A list of open issues can be found at:
http://www.tschofenig.priv.at:8080/saml-sip/
</t>
</section>
-->
<section title="Change Log">
<t>
RFC Editor - Please remove this section before publication.
</t>
<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>
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; &RFC4234; &RFC2585;
</references> <!-- Normative -->
<references title="Informative References">
&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:10:12 |