One document matched: draft-ietf-sip-saml-06.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">
<!ENTITY RFC3370 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3370.xml">
<!ENTITY RFC3548 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3548.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-06.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="2009"/>
<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. In doing so, satisfy the
requirements outlined in <xref
target="RFC4484"/>.
</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).
</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 and |
| | w/SAML-Signature |
| |--------------------->|
| | |
| | |
| | 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. To tie the SAML-Info field to the message
a digial signature is computed and placed in the
SAML-Signature header. Bob in our case acting as the
verifier uses the reference to retrieve the SAML
assertion, verifies it and the SAML-Signature.
</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 |
| | | | SAML-Signature |
| | | |
| + | |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 procedure is successful,
the AS creates 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 needs to obtain Alice's domain
certificate that is contained in the
SAML assertion. 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 binding between the
SAML assertion and the SIP message is verified.
A detailed description can be found in
<xref target="verifier-behavior"/>.
Various elements contained in the
SAML assertion are inspected and the processing of the
INVITE message is continued.
<!-- 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 |
| | + SIP-Signature |
| |--------------------->| (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 <xref target="as-behavior"/>, 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 MUST construct an HTTP URI per
Section "3.7.5.1 URI
Syntax" of <xref
target="OASIS.saml-bindings-2.0-os"/>.
To enable proper caching, the HTTP URI
pointing to the SAML assertion MUST be
unique, i.e., if the content of the SAML
assertion changes then the HTTP URI reference
MUST be different than any previously used HTTP
URI references used before.
</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 <xref target="verifier-behavior"/>.
<!-- Extended signature verification -->
</t>
<!--
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>
-->
</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>
<t>This field contains the domain certificate of the AS.</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, if present,
matches with the information carried in the SIP message.
This may include the following checks:
</t>
<t><list style="symbols">
<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>
</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="as-behavior" title="Authentication Service Behavior">
<t>
<xref target="RFC4474"/> defined a new role for SIP entities called an
authentication service. This document re-uses the concept and hence
the same constraints and properties apply to this document. The subsequent
text is copied from <xref target="RFC4474"/> and modified to fit
to the usage of SAML.</t>
<t>Any entity that
instantiates the authentication service role MUST possess the private
key of a domain certificate. Intermediaries that instantiate this
role MUST be capable of authenticating one or more SIP users that can
register in that domain. Commonly, this role will be instantiated by
a proxy server, since these entities are more likely to have a static
hostname, hold a corresponding certificate, and have access to SIP
registrar capabilities that allow them to authenticate users in their
domain. It is also possible that the authentication service role
might be instantiated by an entity that acts as a redirect server,
but that is left as a topic for future work.
</t>
<t>
SIP entities that act as an authentication service MUST add a Date
header field to SIP requests if one is not already present.
Similarly, authentication services MUST add a Content-
Length header field to SIP requests if one is not already present;
this can help verifiers to double-check that they are hashing exactly
as many bytes of message-body as the authentication service when they
verify the message.</t>
<t>
Entities instantiating the authentication service role perform the
following steps, in order, to generate an Identity header for a SIP
request:
</t>
<t><list style="hanging">
<t hangText="Step 1:">
<vspace blankLines="1"/>
The authentication service MUST extract the identity of the sender
from the request. The authentication service takes this value from
the From header field; this AoR will be referred to here as the
'identity field'. If the identity field contains a SIP or SIP Secure
(SIPS) URI, the authentication service MUST extract the hostname
portion of the identity field and compare it to the domain(s) for
which it is responsible (following the procedures in RFC 3261,
Section 16.4, used by a proxy server to determine the domain(s) for
which it is responsible). If the identity field uses the TEL URI
scheme, the policy of the authentication service determines whether
or not it is responsible for this identity. If the authentication service is not responsible for
the identity in question, it SHOULD process and forward the request
normally, but it MUST NOT add a SAML-Info and a SAML-Signature header.
<vspace blankLines="1"/>
</t>
<t hangText="Step 2:">
<vspace blankLines="1"/>
The authentication service MUST determine whether or not the sender
of the request is authorized to claim the identity given in the
identity field. In order to do so, the authentication service MUST
authenticate the sender of the message.
<vspace blankLines="1"/>
</t>
<t hangText="Step 3:">
<vspace blankLines="1"/>
The authentication service SHOULD ensure that any preexisting Date
header in the request is accurate. Local policy can dictate
precisely how accurate the Date must be; a RECOMMENDED maximum
discrepancy of ten minutes will ensure that the request is unlikely
to upset any verifiers. If the Date header contains a time different
by more than ten minutes from the current time noted by the
authentication service, the authentication service SHOULD reject the
request. This behavior is not mandatory because a user agent client
(UAC) could only exploit the Date header in order to cause a request
to fail verification; the SAML-Signature header is not intended to provide
a source of non-repudiation or a perfect record of when messages are
processed. Finally, the authentication service MUST verify that the
Date header falls within the validity period of its certificate.
<vspace blankLines="1"/>
</t>
<t hangText="Step 4:">
<vspace blankLines="1"/>
The authentication service MUST form the signature and add
the SAML-Signature header to the request containing this signature. After
the SAML-Signature header has been added to the request, the authentication
service MUST also add an SAML-Info header. The SAML-Info
header contains a URI from which the SAML assertion and a domain certificate can be acquired.
</t>
</list></t>
<t>
Finally, the authentication service MUST forward the message
normally.</t>
</section>
<section anchor="verifier-behavior" title="Verifier Behavior">
<t>
When a verifier receives a SIP message containing an
SAML-Signature and SAML-Info header, it may inspect these two header fields.
Typically, the results of a
verification are provided as input to an authorization process that
is outside the scope of this document. If an SAML-Info and SAML-Signature header is not
present in a request, and one is required by local policy (for
example, based on a per-sending-domain policy, or a per-sending-user
policy), then a 428 'Use SAML Header' response MUST be sent.
</t>
<t>In order to verify the identity of the sender of a message, an entity
acting as a verifier MUST perform the following steps, in the order
here specified.
</t>
<t><list style="hanging">
<t hangText="Step 1:">
<vspace blankLines="1"/>
The verifier has to acquire the certificate for the signing domain.
Implementations supporting this specification SHOULD have some means
of retaining domain certificates (in accordance with normal practices
for certificate lifetimes and revocation) in order to prevent
themselves from needlessly downloading the same certificate every
time a request from the same domain is received. Certificates cached
in this manner should be indexed by the URI given in the SAML-Info header field value.
<vspace blankLines="1"/>
Provided that the domain certificate used to sign this message is not
previously known to the verifier, SIP entities SHOULD discover this
certificate by dereferencing the SAML-Info header, unless they
have some more efficient implementation-specific way of acquiring
certificates for that domain. The domain certificate can be found in
the SAML assertion, either by reference or by value. The verifier processes this certificate
in the usual ways, including checking that it has not expired, that
the chain is valid back to a trusted certification authority (CA),
and that it does not appear on revocation lists. Once the
certificate is acquired, it MUST be validated following the
procedures in RFC 3280 <xref target="RFC3280"/>. If the certificate cannot be validated
(it is self-signed and untrusted, or signed by an untrusted or
unknown certificate authority, expired, or revoked), the verifier
MUST send a 437 'Unsupported Certificate' response.<vspace blankLines="1"/>
</t>
<t hangText="Step 2:">
<vspace blankLines="1"/>
The verifier MUST follow the process described in Section 13.4 of <xref target="RFC4474"/> to
determine if the signer is authoritative for the URI in the From
header field.<vspace blankLines="1"/></t>
<t hangText="Step 3:">
<vspace blankLines="1"/>
The verifier MUST verify the signature in the SAML-Signature header field,
following the procedures for generating the hashed digest-string
described in <xref target="extended-signature"/>. If a verifier determines that the signature
on the message does not correspond to the reconstructed digest-
string, then a 479 'Invalid SAML Assertion' response MUST be
returned.<vspace blankLines="1"/>
</t>
<t hangText="Step 4:">
<vspace blankLines="1"/>
The verifier MUST validate the Date, Contact, and Call-ID headers.
It must furthermore ensure that the value of the Date header
falls within the validity period of the certificate whose
corresponding private key was used to sign the Identity header.
</t>
</list>
</t>
</section>
<section anchor="header" title="SAML-Info Header Field">
<t>
This document introduces the SIP header field "SAML-Info" to carry a reference to a SAML assertion.
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="extended-signature" title="Extended RFC 4474 SIP Identity Signature Mechanism">
<t>
To allow the SIP Identity
mechanism <xref
target="RFC4474"/> to protect also the reference
to the SAML assertion additional SIP header fields
need to be protected by the signature calculation
mechanisms. The extended signature computation is included in the
SAML-Signature header field.
</t>
<t>
The grammar for this new header is (following the ABNF <xref target="RFC4234"/> in RFC
3261 <xref target="RFC3261"/>):
</t>
<t>
<figure>
<artwork>
<![CDATA[
SAML-Signature = "SAML-Signature" HCOLON ( signed-identity-digest
sig-info-fields sig-info-alg ) / sig-info-extension
signed-identity-digest = LDQUOT 32LHEX RDQUOT
sig-info-alg = "alg" EQUAL token
sig-info-fields = "fields" EQUAL token
sig-info-extension = generic-param
]]>
</artwork>
</figure>
</t>
<t>
The signed-identity-digest is a signed hash of a canonical string
generated from certain components of a SIP request. To create the
contents of the signed-identity-digest, the following elements of a
SIP message MUST be placed in a bit-exact string in the order
specified here, separated by a vertical line, "|" or %x7C, character:
</t>
<t>
<list style="symbols">
<t>The AoR of the UA sending the message, or addr-spec of the From
header field (referred to occasionally here as the 'identity
field').
</t>
<t>The addr-spec component of the To header field, which is the AoR
to which the request is being sent.
</t>
<t>The callid from Call-Id header field.
</t>
<t>The digit (1*DIGIT) and method (method) portions from CSeq header
field, separated by a single space (ABNF SP, or %x20). Note that
th CSeq header field allows linear whitespace (LWS) rather than
SP to separate the digit and method portions, and thus the CSeq
header field may need to be transformed in order to be
canonicalized. The authentication service MUST strip leading
zeros from the 'digit' portion of the Cseq before generating the
digest-string.
</t>
<t>The Date header field, with exactly one space each for each SP and
the weekday and month items case set as shown in BNF in RFC 3261.
RFC 3261 specifies that the BNF for weekday and month is a choice
amongst a set of tokens. The RFC 2234 rules for the BNF specify
that tokens are case sensitive. However, when used to construct
the canonical string defined here, the first letter of each week
and month MUST be capitalized, and the remaining two letters must
be lowercase. This matches the capitalization provided in the
definition of each token. All requests that use the Identity
mechanism MUST contain a Date header.
</t>
<t>The addr-spec component of the Contact header field value. If the
request does not contain a Contact header, this field MUST be
empty (i.e., there will be no whitespace between the fourth and
fifth "|" characters in the canonical string).
</t>
<t>The sig-info-params parameter contains a list of SIP header fields
whose values have to be included into the signature calculation. The individual
field names in small letters are encoded in the token parameter of the sig-info-fields, each
name separated by a "|" character.</t>
<t>The body content of the message with the bits exactly as they are
in the Message (in the ABNF for SIP, the message-body). This
includes all components of multipart message bodies. Note that
the message-body does NOT include the CRLF separating the SIP
headers from the message-body, but does include everything that
follows that CRLF. If the message has no body, then message-body
will be empty, and the final "|" will not be followed by any
additional characters.
</t>
</list>
</t>
<t>The precise formulation of this digest-string is, therefore
(following the ABNF <xref target="RFC4234"/> in RFC 3261 <xref target="RFC3261"/>):
<figure>
<artwork>
<![CDATA[
digest-string = addr-spec "|" addr-spec "|" callid "|"
1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|"
sigfields "|" message-body
]]>
</artwork>
</figure>
</t>
<t>The signfields parameter represent the concatination of the values of the SIP header fields that
are included in the signature calculation.</t>
<t>Note again that the first addr-spec MUST be taken from the From
header field value, the second addr-spec MUST be taken from the To
header field value, and the third addr-spec MUST be taken from the
Contact header field value, provided the Contact header is present in
the request.</t>
<t>After the digest-string is formed, it MUST be hashed and signed with
the certificate for the domain. The hashing and signing algorithm is
specified by the 'alg' parameter. This
document defines only one value for the 'alg' parameter: 'rsa-sha1'.
All implementations of this specification
MUST support 'rsa-sha1'. When the 'rsa-sha1' algorithm is specified
in the 'alg' parameter of Identity-Info, the hash and signature MUST
be generated as follows: compute the results of signing this string
with sha1WithRSAEncryption as described in RFC 3370 <xref target="RFC3370"/> and base64
encode the results as specified in RFC 3548 <xref target="RFC3548"/>. A 1024-bit or
longer RSA key MUST be used. The result is placed in the SAML-Signature
header field.</t>
<t>
This document adds the following entries to Table 2 of RFC 3261 <xref target="RFC3261"/>:
</t>
<t> <figure>
<artwork>
<![CDATA[
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
SAML-Signature R a o o - o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
]]>
</artwork>
</figure>
</t>
<t> Note, in the table above, that this mechanism does not protect the
CANCEL method. The CANCEL method cannot be challenged, because it is
hop-by-hop, and accordingly authentication service behavior for
CANCEL would be significantly limited. Note as well that the
REGISTER method uses Contact header fields in very unusual ways that
complicate its applicability to this mechanism, and the use of
Identity with REGISTER is consequently a subject for future study,
although it is left as optional here for forward-compatibility
reasons. The SAML-Signature header MUST NOT appear in
CANCEL.
</t>
</section>
<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. 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>
<t>We would also like to thank Eric Rescorla for his expert review.</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 two new SIP header fields:
'SAML-Info' (see <xref target="header"/> and 'SAML-Signature'
(see <xref target="extended-signature"/>). IANA is requested
to add these two headers 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>
<t>
Header Name: SAML-Signature
</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 title="480 'Use SAML Header' Response Code">
<t>
This document registers a new SIP response code.
It is used when a SAML-Info and SAML-Signature header is not
present in a request, and one is required by local policy (for
example, based on a per-sending-domain policy, or a per-sending-user
policy). 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: 480
</t>
<t>Default Reason Phrase: Use SAML Header</t>
</section>
</section>
<section title="Change Log">
<t>
RFC Editor - Please remove this section before publication.
</t>
<section title="-05 to -06">
<t>In response to the review comments by Eric Rescorla a new signature SIP header field was added.</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>
Will detail in -04 rev.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&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;
&RFC3370;
&RFC3548;
&W3C.xmldsig-core; &RFC4234; &RFC2585;
</references> <!-- Normative -->
<references title="Informative References">
&RFC4474;
&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:36 |