SIP                                                        H. Tschofenig
Internet-Draft                                                   Siemens
Expires: May 2, 2005                                         J. Peterson
                                                           NeuStar, Inc.
                                                                 J. Polk
                                                               D. Sicker
                                                              CU Boulder
                                                            M. Tegnander
                                                           November 2004

                           Using SAML for SIP

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).


Tschofenig, et al.        Expires May 2, 2005                   [Page 1]

Internet-Draft             Using SAML for SIP              November 2004

   This document describes how to use the Security Assertion Markup
   Language (SAML) to offer trait-based authorization.  As such, it
   provides an alternative to existing authorization mechanisms for SIP.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Goals and Non-Goals  . . . . . . . . . . . . . . . . . . . .   5
   4.   SAML Introduction  . . . . . . . . . . . . . . . . . . . . .   6
     4.1  Assertions . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2  Artifact . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3  Request/Response Protocol  . . . . . . . . . . . . . . . .   7
     4.4  Bindings . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.5  Profiles . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.   Assertion Handling Models  . . . . . . . . . . . . . . . . .   9
   6.   Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1  Network Asserted Identities  . . . . . . . . . . . . . . .  14
     6.2  SIP Conferencing . . . . . . . . . . . . . . . . . . . . .  16
     6.3  PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . .  17
     6.4  Compensation using SIP and SAML  . . . . . . . . . . . . .  18
   7.   SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . .  20
   8.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   9.   Requirement Comparison . . . . . . . . . . . . . . . . . . .  23
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  24
     10.1   Stolen Assertion . . . . . . . . . . . . . . . . . . . .  24
     10.2   MitM Attack  . . . . . . . . . . . . . . . . . . . . . .  24
     10.3   Forged Assertion . . . . . . . . . . . . . . . . . . . .  24
     10.4   Replay Attack  . . . . . . . . . . . . . . . . . . . . .  25
   11.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  26
   12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  27
   13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  28
   14.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  29
   15.  References . . . . . . . . . . . . . . . . . . . . . . . . .  32
   15.1   Normative References . . . . . . . . . . . . . . . . . . .  32
   15.2   Informative References . . . . . . . . . . . . . . . . . .  32
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  34
        Intellectual Property and Copyright Statements . . . . . . .  35

Tschofenig, et al.        Expires May 2, 2005                   [Page 2]

Internet-Draft             Using SAML for SIP              November 2004

1.  Introduction

   This document proposes a method for using the Security Assertion
   Markup Language (SAML) in collaboration with SIP to accommodate
   richer authorization mechanisms and enable trait- based authorization
   where you are authenticated using roles or traits instead of
   identity.  A motivation for trait based authorization and some
   scenarios are presented in [I-D.ietf-sipping-trait-authz].

   Security Assertion Markup Language (SAML)
   [I-D.saml-tech-overview-1.1-03] is an XML extension for security
   information exchange that is being developed by OASIS.  SAML is a
   XML-based framework for creating and exchanging security information.

   To provide trait-based authorization a few solutions are possible:
   authorization certificates, SPKI or extensions to the authenticated
   identity body [I-D.ietf-sip-authid-body].  The authors selected SAML
   due to the amount of work done in the area of SAML which provides
   some assurance that this technology is mature enough.

Tschofenig, et al.        Expires May 2, 2005                   [Page 3]

Internet-Draft             Using SAML for SIP              November 2004

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   The SIP entity 'Authentication Service' was introduced with
   [I-D.ietf-sip-identity].  We reuse this term to refer to an entity
   that authenticates and authorizes a user and creates an assertion.
   This entity is the equivalent of the asserting party in the SAML

   For terminology related to SAML the reader is referred to

Tschofenig, et al.        Expires May 2, 2005                   [Page 4]

Internet-Draft             Using SAML for SIP              November 2004

3.  Goals and Non-Goals

   This document tries to accomplish the following goals:

   o  This document defines how SAML assertions are carried in the SIP.
      As such, the usage of SAML assertions within SIP can be seen as a
      SAML profile.

   o  The requirements and scenarios defined in
      [I-D.ietf-sipping-trait-authz] are compared to the solution
      described in this document by utilizing SAML assertions.

   The following issues are outside the scope of this document:

   o  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

   o  The attributes stored in assertions are, for example, roles,
      membership to a certain organization, specific access rights or
      information about the authentication.  A definition of most of
      these attributes is application dependent and not defined in this
      document.  The SAML specification itself provides a number of
      common attributes and provides extension points for future
      enhancements.  A brief overview of the available attributes within
      an assertion is given in Section 4.1.

   o  SIP is not used as a request/response protocol between the Relying
      Party and the Asserting Party to fetch an assertion based on a
      received artifact.

Tschofenig, et al.        Expires May 2, 2005                   [Page 5]

Internet-Draft             Using SAML for SIP              November 2004

4.  SAML Introduction

   In SAML there are three main entities: the user, the asserting party
   and the relying party.  A user requests an assertions and receives
   them after a successful authentication and authorization protocol
   execution.  The asserting party provides assurance that a particular
   user has been given proper authorization.  The relying party has to
   trust the asserting party with regard to the provided information and
   then decides whether or not to accept the assertions provided, giving
   different levels of privileges.

   The components of SAML are:

   o  Assertions/Artifact

   o  Request/Response protocols

   o  Bindings

   o  Profiles

   We describe each in turn below

4.1  Assertions

   An assertion is a package of information including authentication
   statements, attribute statements and authorization decision
   statements.  All of statements do not have to be present, but at
   least one does.  An assertion contains several elements:

   Issuing information:

      Who issued the assertion, when was it issued and the assertion

   Subject information:

      The name of the subject, the security domain and optional subject
      information, like public key.

   Conditions under which the assertion is valid:

      Special kind of conditions like assertion validity period,
      audience restriction and target restriction.

Tschofenig, et al.        Expires May 2, 2005                   [Page 6]

Internet-Draft             Using SAML for SIP              November 2004

   Additional advice:

      Explaining how the assertion was made, for example.

   In an authentication statement, an issuing authority asserts that a
   certain subject was authenticated by certain means at a certain time.

   In an attribute statement, an issuing authority asserts that a
   certain subject is associated with certain attributes which has
   certain values.  For example, user is associated
   with the attribute 'Department', which has the value 'Computer

   In an authorization decision statement, a certain subject with a
   certain access type to a certain resource has given certain evidence
   that the identity is correct.  Based on this, the relying party then
   makes the decision on giving access or not.  The subject could be a
   human or a program, the resource could be a webpage or a web service,
   for example.

4.2  Artifact

   The artifact used in the Browser/Artifact profile, is a base-64
   encoded string that is 40 bytes long.  20 bytes consists of the
   typecode, which is the source id.  The remaining 20 bytes consists of
   a random number that servers use to look up an assertion.  The source
   server stores the assertion temporarily.  The destination server
   receives the artifact and pulls the assertion from the source site.
   The purpose of the artifact is to act as a token that references an
   assertion for the subject who holds the artifact.

4.3  Request/Response Protocol

   SAML defines a request/response protocol for obtaining assertions.
   The request asks for an assertion or makes queries for
   authentication, attribute and authorization decisions.  The response
   carries back the requested assertion.

4.4  Bindings

   The bindings in SAML maps between the SAML protocol and a transport
   and messaging protocol.  With SAML Version 1.1 there is only one
   binding specified, which is SAML embedded in SOAP-over-HTTP.  In a
   binding, a transport and messaging protocol is used only for
   transporting the request/response mechanism.

Tschofenig, et al.        Expires May 2, 2005                   [Page 7]

Internet-Draft             Using SAML for SIP              November 2004

4.5  Profiles

   When using a profile, SAML is used to provide assertions about a
   resource in the body of the message itself.  In Version 1.1 of SAML,
   there are two profiles specified, the Browser/Artifact profile and
   the Browser/POST profile.  The Browser/Artifact profile represents a
   "pull" model, where a special reference to the assertion called an
   artifact, is sent to the relying party from the asserting party.  The
   artifact is then used to "pull" the assertion from the asserting
   party.  The Browser/POST profile represents a "push" model, where an
   assertion is posted (using the HTTP POST command) directly to the
   relying party.  These two models are described in Figure 1 and Figure

Tschofenig, et al.        Expires May 2, 2005                   [Page 8]

Internet-Draft             Using SAML for SIP              November 2004

5.  Assertion Handling Models

   As mentioned in Section 4.5, two main models can be used in SAML and
   therefore also with the SIP-SAML extension defined in this document:
   The Push and the Pull model.

   In the Pull model the end host requests an assertion from the
   Asserting Party and receives, after successful authentication and
   authorization, an artifact.  The artifact is a special form of an
   assertion.  This artifact can be compared with the call-by reference
   approach where a reference to the assertion is stored at the
   Asserting Party and can later be dereferenced into the real assertion
   on a request by a replying party.  The Relying Party later fetches
   the SAML assertion after receiving a request by the user which
   includes the artifact.  For communicating the SAML request and
   response messages, a separate message exchange is needed with a
   protocol such as SOAP or HTTP.  This is outside the scope of this

Tschofenig, et al.        Expires May 2, 2005                   [Page 9]

Internet-Draft             Using SAML for SIP              November 2004

     +----------+         +--------------+           +--------------+
     |  User    |         | Asserting    |           |   Relying    |
     |          |         | Party        |           |   Party      |
     +----+-----+         +------+-------+           +------+-------+
          |                      |                          |
          |  Request Assertion   |                          |
          |--------------------->|                          |
          |                      |                          |
          | User Authentication  |                          |
          | and Authorization    |                          |
          |<---------------------|                          |
          |--------------------->|                          |
          |                      |                          |
          |    Artifact          |                          |
          |<---------------------|                          |
          |                      |                          |
          |               Request + Artifact                |
          |                      |                          |
          |                      |    SAML request          |
          |                      |<-------------------------|
          |                      |                          |
          |                      |SAML response + Assertion |
          |                      |------------------------->|
          |                      |                          |
          |              Accept/Reject                      |
          |                      |                          |

                       Figure 1: SAML Pull model

   With the Push model, the user requests an assertion from the
   Asserting Party.  The user can also trigger the Asserting Party to
   attach an assertion to the request.  The assertion, which is added to
   the service request, can be verified by the Relying Party without
   additional protocol interactions with the Asserting Party.  The
   assertion therefore contains enough information to authorize the
   service request.  This model realizes a call-by value style of

Tschofenig, et al.        Expires May 2, 2005                  [Page 10]

Internet-Draft             Using SAML for SIP              November 2004

     +----------+         +--------------+           +--------------+
     |  User    |         | Asserting    |           |   Relying    |
     |          |         | Party        |           |   Party      |
     +----+-----+         +------+-------+           +------+-------+
          |                      |                          |
          |  Request Assertion   |                          |
          |--------------------->|                          |
          |                      |                          |
          |                      |                          |
          | User Authentication  |                          |
          | and Authorization    |                          |
          |<---------------------|                          |
          |--------------------->|                          |
          |                      |                          |
          |                      |                          |
          |    Assertion         |                          |
          |<---------------------|                          |
          |                      |                          |
          |               Request + Assertion               |
          |                      |                          |
          |                      |                          |
          |              Accept/Reject                      |
          |                      |                          |

                       Figure 2: SAML Push model

   The usage of SAML in HTTP-based environments and in SIP is, however,
   affected by some architectural differences.

   The function of the entities in the Push and the Pull model are shown
   in Figure 1 and in Figure 2.

   The user has to request an assertion at the Asserting Party and both
   entities mutually authenticate each other.  The requested assertion
   is sent to the user in a confidential manner to prevent eavesdroppers
   from obtaining this assertion.  The Relying Party trusts the
   Asserting Party.  It is assumed that the accessed resource is located
   at the Relying Party and that this entity does not become malicious
   or act on behalf of the user to impersonate him or her to other
   parties with regard to access to his resources.  To prevent some
   degree of misuse, attributes in the assertion limit its applicability
   for certain applications, servers or time frame.

   Signaling in SIP can, however, involve a number of entities in more
   complex scenarios.  As an example, the scenario addressed in
   [I-D.ietf-sip-identity] aims to replace end-to-end authentication via

Tschofenig, et al.        Expires May 2, 2005                  [Page 11]

Internet-Draft             Using SAML for SIP              November 2004

   S/MIME by a "mediated authentication architecture".  The end hosts
   only need to be able to verify assertions signed by an Authentication
   Service which guarantees that the sender was authenticated.

   Directly applying SAML to such a scenario, however, causes a problem:
   a SIP proxy, which securely receives a SAML assertion (such as
   confidentially protected to prevent eavesdroppers between the SIP UA
   and the SIP proxy to learn the assertion), can store this assertion
   to impersonate the user in future requests towards other SIP end
   users.  The fact that multiple parties see the assertion along the
   path (i.e., SIP proxies) make the situation worse.  The assertion
   might include some attributes which restrict its usage (such as
   recipient(s), unique identifier for the message or a time-based
   constraint) but they cannot fully prevent impersonation.

   This problem appears if SAML assertions are not bound to a particular
   protocol run.  Binding the assertion to a particular protocol session
   is not useful if the property of single-sign on is required.

   To provide referential integrity, a solution as mentioned in
   [I-D.ietf-sip-authid-body] can be used.  which allows a party in a
   SIP transaction to cryptographically sign the headers that assert the
   identity of the originator of a message, and provide some other
   headers necessary for reference integrity.  An authenticated identity
   body (AIB) is a MIME body of type 'message/sipfrag'.  This MIME body
   has a Content-Disposition type of 'aib'.  The MIME body is optional.
   The header fields From, Contact, Date and Call-ID must be used for
   providing identity.  Contact and Date header fields are required for
   providing reference integrity.  AIBs may contain other headers that
   help to uniquely identify the transaction or that provides related
   reference integrity.

   The requirements for a non-INVITE AIB is very much the same as for an
   INVITE: From, Call-ID, Date and Contact header fields are required.
   The same that goes for requests also goes for responses with some
   small differences.  The From header field of the AIB in the response
   to an INVITE must correspond to the address-of-record of the
   responder and not the From header field in the received request.  The
   To header field of the request must not be included.  A new Date
   header field has to be generated for the response while the Call-ID
   and CSeq are copied from the request.

   Following is an example of the format of an AIB for an INVITE:

Tschofenig, et al.        Expires May 2, 2005                  [Page 12]

Internet-Draft             Using SAML for SIP              November 2004

                Content-Type: message/sipfrag
                Content-Disposition: aib; handling=optional

                From: Alice <>
                To: Bob <>
                Contact: <>
                Date: Thu, 26 Aug 2004 13:51:34 GMT
                Call-ID: b76m5l94s90835
                CSeq: 435431 INVITE

                   Figure 3: AIB Format for an INVITE

   The same concept is applicable to this document as well with regard
   to reference integrity.  For a further discussion on this topic see
   Section 14 and [I-D.peterson-message-identity].

Tschofenig, et al.        Expires May 2, 2005                  [Page 13]

Internet-Draft             Using SAML for SIP              November 2004

6.  Scenarios

   This section shows message flows based on scenarios in
   [I-D.ietf-sipping-trait-authz] enriched with a SAML based solution.
   Section 6.1 provides an example of enhanced network asserted
   identities and Section 6.2 shows a SIP conferencing scenario with
   role-based access control using SAML.  A future version of this
   document will cover more scenarios from

6.1  Network Asserted Identities

   Figure 4 shows an enhanced network asserted identity scenario based
   on [I-D.ietf-sip-identity] which again utilizes extensions proposed
   with [I-D.ietf-sip-authid-body].  The enhancement is based on the
   attributes asserted by the Authentication Service.

   Figure 4 shows three entities,, and  If Alice wants to communicate with Bob, she sends
   a SIP INVITE to her preferred AS.  Depending on the chosen SIP
   security mechanism either digest authentication, S/MIME or Transport
   Layer Security is used to provide the AS with a strong assurance
   about the identity of Alice.  During this step authorization
   attributes for inclusion into the SAML assertion can be selected.

   After Alice is authenticated and authorized, a SAML assertion is
   attached to the SIP message.  The Authentication Service can be
   configured to attach a number of assertions, not limited to the
   authenticated identity.

   To bind the SAML assertion to a specific SIP session, it is necessary
   for the AS to compute a hash of some fields of the message.  A list
   of the fields to hash is described in [I-D.ietf-sip-identity] and
   particularly in [I-D.ietf-sip-authid-body].  The hash is digitally
   signed and inserted into the SAML assertion and placed into the SAML
   header.  The SAML header also contains information about the entity
   which created the digital signature.  Upon reception of the message,
   Bob verifies the signature of the SAML assertion and verifies the
   binding to the SIP message in order to prevent cut-and-paste attacks.
   The provided SAML assertion can then be used to assist during the
   authorization procedure.  If Bob does not understand the extension
   defined in this document, he silently ignores it.  When the 200 OK
   message arrives at Bob's AS, the same procedure as when Alice sent
   her INVITE to her AS can be performed, if desired.  This exchange is
   not shown in Figure 4.

   Note that this scenario does not imply that the SAML assertions are
   solely used by SIP UAs.  Assertions can also be helpful for SIP

Tschofenig, et al.        Expires May 2, 2005                  [Page 14]

Internet-Draft             Using SAML for SIP              November 2004

   proxies or B2B UAs.  Additionally, a push model is shown in this
   section but it is reasonable to use a pull as well.  For simplicity
   reasons a push model should be prefered since an additional message
   exchange between the Authentication Service and the UA can be

     +--------+           +--------------+          +--------+
     |Alice@  |           |Authentication|          | Bob@   |
     |example |           |Service       |          |example2|
     |.com    |           |  |          |com     |
     |        |           |              |          |        |
     +---+----+           +------+-------+          +---+----+
         |                       |                      |
         |      INVITE           |                      |
         |---------------------->|                      |
         |    |                      |
         |                       |                      |
         |  407 Proxy auth. req. |                      |
         |<----------------------|                      |
         |     Challenge         |                      |
         |                       |                      |
         |  Challenge response   |                      |
         |---------------------->|                      |
         |                       |                      |
         |       INVITE          |                      |
         |---------------------->|                      |
         |                       | INVITE               |
         |                       | + SAML assertion     |
         |                       |--------------------->|
         |                       |                      |
         |            200 OK     |                      |
         |                       |                      |

                 Figure 4: Network Asserted Identities

   A variation of the scenario presented in Figure 4 is given in Figure
   5 where an end host ( obtains an assertion from its
   SIP proxy server which acts as an Authentication Service.  This
   assertion is then attached by the end host to the outgoing INVITE
   message.  Unlike in case of an artifact, does not
   need to contact the Proxy Server.

   An example of this scenario could be to preempt a lower priority call
   if enough assurance for doing so is presented in the attached SAML
   assertion.  This would also mean that there is a priority value
   included in the INVITE (for example in the Resource-Priority Header).

Tschofenig, et al.        Expires May 2, 2005                  [Page 15]

Internet-Draft             Using SAML for SIP              November 2004

    +--------+           +--------------+          +--------+
    | Alice@ |           |Proxy Server  |          | Bob@   |
    |example |           |(AS           |          |example |
    |.com    |           |  |          |.com    |
    |        |           |              |          |        |
    +---+----+           +------+-------+          +---+----+
        |                       |                      |
        |      INVITE           |                      |
        |---------------------->|                      |
        ||                      |
        |                       |                      |
        |  407 Proxy auth. req. |                      |
        |<----------------------|                      |
        |   SAML Auth Header    |                      |
        |       to use          |                      |
        |                       |                      |
        |       INVITE + SAML assertion                |
        |                       |                      |
        |            200 OK     |                      |
        |                       |                      |

              Figure 5: End host attaching SAML Assertion

   Note that Bob and Alice do not need to be in the same administrative
   domain.  It is feasible that Bob is in a domain that is federated
   with Alice's domain.

   The assertion obtained by needs to be associated
   with a particular SIP messaging session.  How to achieve this binding
   is for further consideration.

6.2  SIP Conferencing

   This section is meant to raise some discussions about the usage of
   SAML in the domain of conferencing.  A user who routes its SIP
   message through the Authentication Service (Asserting Party) towards
   a conferencing server may want SAML assertions to be included.  The
   following properties could be provided by this procedure:

   o  The user identity can be replaced to allow the user to be
      anonymous with regard to the Focus

   o  The user identity could be asserted to the Focus

   o  The SAML assertion could provide additional information such as
      group membership (belongs to the students, staff, faculty group of

Tschofenig, et al.        Expires May 2, 2005                  [Page 16]

Internet-Draft             Using SAML for SIP              November 2004

      university X).  This could, for non-identity-based authorization
      systems, imply certain rights.

   The corresponding SIP message flow (in high level detail) could have
   the following shape:

       +-----+          +-----------+       +-----------+
       |     |          | SIP Proxy |       | Focus     |
       |User |          |(Asserting |       | (Relying  |
       |     |          | party)    |       | party)    |
       +--+--+          +-----+-----+       +-----+-----+
          |     INVITE        |                   |
          |sip:conf-factory   |                   |
          |------------------>|    INVITE+SAML    |
          |                   |------------------>|
          |                   |                   |
          |                   | Ringing           |
          | Ringing           |<------------------|
          |<------------------|                   |
          |                   |                   |
          |                   | OK                |
          | OK                |<------------------|
          |<------------------|                   |
          |                   |                   |
          |    ACK            |                   |
          |------------------>|    ACK            |
          |                   |------------------>|
          |                   |                   |
          |                   |                   |
                     ... many more msgs...

                  Figure 6: SIP Conferencing and SAML

6.3  PSTN-to-SIP Phone Call

   Alice, using a phone connected to the PSTN, wants to make a call to
   Bob, which resides in a SIP network.  Her call is switched through
   the PSTN by means of PSTN signaling (outside the scope of this
   document) to the PSTN/SIP gateway.  At the gateway, the call is
   converted from SS7 signaling to SIP signaling.  Since Alice was
   previously 'authenticated' through PSTN signaling mechanisms, the
   gateway can create an assertion based on signaling information from
   Alice and digitally sign it with his private key.  Alice's call is
   forwarded from the SIP/PSTN gateway to Bob's phone.  Bob can certify
   that the identity of Alice is correct by examining the SAML

Tschofenig, et al.        Expires May 2, 2005                  [Page 17]

Internet-Draft             Using SAML for SIP              November 2004

    +----------------------+                      |           |
    |                      |       SS7            |  SIP/PSTN |
    |  Public Switched     |--------------------->|  Gateway  |
    |                      |                      |           |
    |                      |                      |           |
    | Telephone Network    |                   +--+-----------+----+
    |         ^            |                   |        |          |
    +---------+------------+                   |        | SIP+SAML |
              | SS7                            |        v          |
              |                                |    +--------+     |
                                       O       |    |        |     |
              O                       /|\ <----+----| SIP    |     |
             /|\                      / \   SIP+    | Proxy  |     |
             / \                      Bob     SAML  |        |     |
            Alice                              |    +--------+     |
                                               |     SIP based     |
                                               |     Network       |

                       Figure 7: PSTN to SIP call

6.4  Compensation using SIP and SAML

   This section briefly elaborates a scenario where SAML is used in SIP
   to realize compensation functionality as described in

   Section 1 of [I-D.jennings-sipping-pay] shows a message exchange
   which is used by a number of payment protocols and hence can also be
   used by a SAML specified protocol.  To avoid repetition in this
   document a second alternative is provided in Figure 8.  Alice
   initiates a communication with an Authentication Service which acts
   as a financial institution.  Note that Alice does not necessarily
   need to use SIP for communication with the Authentication Service.
   Instead, it might be possible to use HTTP or other protocols which
   offer the necessary user credential or offer additional information
   (such as a web page).  After a successful authentication and
   authorization Alice obtains an assertion (or an artifact) which might
   contain payment relevant information.  For a later service access,
   Alice contacts the merchant Bob with the assertion.  Bob verifies the
   assertion and, it might want to contact the Authentication Service
   for a credit check.  A financial settlement between the merchant Bob
   and the Trusted Third Party is assumed.  Depending on the type of
   service, a one-time payment with immediate amount deduction may take
   place (e.g., in case of a prepaid account) or the amount is captured
   as a batch transaction.

Tschofenig, et al.        Expires May 2, 2005                  [Page 18]

Internet-Draft             Using SAML for SIP              November 2004

   The aspect of lightweight protocol execution is provided by

   o  The alternative usage of an artifact which leads to a lower
      bandwidth consumption.

   o  The ability to use a single assertion for multiple service access
      protocol executions, if desired.

   o  SAML, furthermore allows a cryptographic key to be bound to an
      assertion.  A high degree of flexibility is provided with regard
      to the possible credentials.  For example, it might not be
      necessary to use public key cryptography with every service
      access.  This might be useful if the cost of public key
      cryptographic is too expensive for a cheap service or when devices
      have performance limitations.  In this case, it might be useful to
      rely on symmetric cryptographic, such as hash chains.

    +--------+           +--------------+          +--------+
    |User    |           |Authentication|          |Merchant|
    |Alice   |           |Server        |          |Bob     |
    |        |           |(Trusted Third|          |        |
    |        |           | Party)       |          |        |
    +---+----+           +------+-------+          +---+----+
        |                       |                      |
        |  SIP, HTTP, etc.      |                      |
        |---------------------->|                      |
        |                       |                      |
        |  Assertion            |                      |
        |<----------------------|                      |
        |                       |                      |
        |                       |                      |
        |       INVITE + SAML assertion                |
        |                       |                      |
        |            200 OK     |                      |
        |                       |                      |

                 Figure 8: Message flow for SIP payment

   The main difference between the above-described mechanism and the one
   described in Section 1 of [I-D.jennings-sipping-pay] is the degree of
   user involvement and the type of protocol interaction.  In both cases
   it is possible to provide an indication to the user about the costs
   of a service access.  In fact, the assertion might specify these type
   of constraints directly or indirectly with the help of recurring
   service requests/responses.

Tschofenig, et al.        Expires May 2, 2005                  [Page 19]

Internet-Draft             Using SAML for SIP              November 2004

7.  SIP-SAML Extension

   To carry SAML assertions and artifacts two mechanisms are defined:

   o  The SIP header may either carry an Artifcat or a CID URI [RFC2392]
      pointing to an assertion in the SIP body.  The name of this new
      SIP header is SAML-Payload.  A SAML artifact consists of a
      TypeCode, SourceID and an AssertionHandle.  It is thereby assumed
      that the Relying Party will maintain a table of sourceID values as
      well as URLs for Asserting Parties to contact.  This information
      is communicated out-of-band.  This document also allows the
      Asserting Party to add a URL to point to the assertion to prevent
      this level of indirection.

   o  The SIP body may carry one or more SAML assertions.  The MIME type
      of this SAML assertion is defined in [I-D.hodges-saml-mediatype].

   A SIP user agent may add an assertion to the body of a SIP message or
   may add a reference to the assertion into the SIP header.  SIP
   proxies MUST NOT add the assertion to the body.  The SIP header MUST
   be used instead when an assertion has to be added.

   A SAML assertion SHOULD be protected and when added by a SIP entity
   then S/MIME MUST be used rather than XML digital signatures.

   To bind a SAML assertion to a SIP message a few selected SIP message
   fields are input to a hash function.  The digest-string, defined in
   Section 10 of [I-D.ietf-sip-identity], is included into the
   conditions extension point of the SAML assertion.  Details are for
   further study.

Tschofenig, et al.        Expires May 2, 2005                  [Page 20]

Internet-Draft             Using SAML for SIP              November 2004

8.  Example

   This is an example of a SAML assertion and how it is structured in

        <saml:Conditions NotBefore="2004-06-28T17:10:32.753Z"
             NotOnOrAfter="2004-06-28T17:20:32.753Z" />

   The elements in the assertion have the following meaning:

   |    Tag name         |Req- |        Description            |
   |                     |uired|                               |
   |MajorVersion         |  X  |Major version of the assertion |
   |MinorVersion         |  X  |Minor version of the assertion |
   |AssertionID          |  X  |ID of the assertion            |
   |Issuer               |  X  |The name of the SAML authority |
   |                     |     |that created the assertion     |

Tschofenig, et al.        Expires May 2, 2005                  [Page 21]

Internet-Draft             Using SAML for SIP              November 2004

   |IssuerInstant        |  X  |Issuing time of the assertion  |
   |                     |     |Conditions that MUST be taken  |
   |Conditions           |     |into account when assessing    |
   |                     |     |the validity of the assertion  |
   |                     |     |Specifies                      |
   |AuthenticationMethod |  X  |what kind of authentication    |
   |                     |     |took place                     |
   |AuthenticationInstant|  X  |Specifies the time when the    |
   |                     |     |authentication took place      |
   |Qualifier            |     |The name by which the subject  |
   |                     |     |is recognized                  |
   |                     |     |A URI reference representing   |
   |Format               |     |the format of NameIdentifier   |
   |                     |     |                               |
   |                     |     |Specifies a subject by supply- |
   |SubjectConfirmation  |     |ing data that allows the sub-  |
   |                     |     |ject to be authenticated       |
   |                     |     |Identifies                     |
   |ConfirmationMethod   |     |which method to be used for    |
   |                     |     |authenticating the subject     |

                      Figure 10: Tag descriptions

Tschofenig, et al.        Expires May 2, 2005                  [Page 22]

Internet-Draft             Using SAML for SIP              November 2004

9.  Requirement Comparison

   A future version of this document will compare the requirements
   listed in [I-D.ietf-sipping-trait-authz] with the solution provided
   in this document.

Tschofenig, et al.        Expires May 2, 2005                  [Page 23]

Internet-Draft             Using SAML for SIP              November 2004

10.  Security Considerations

   This section discusses security considerations when using SAML with

10.1  Stolen Assertion


      If an eavesdropper can copy the real user's SAML response and
      included assertions and construct a SIP message of his own, then
      the eavesdropper could be able to impersonate the user at other
      SIP entities.


      By providing adequate confidentiality, eavesdropping of a SAML
      assertion can be stopped.

10.2  MitM Attack


      Since the SAML assertion is carried within a SIP message, a
      malicious site could impersonate the user at some other SIP
      entities.  These SIP entities would believe the adversary to be
      the subject of the assertion.


      If the adversary is a not-participating in the SIP signaling
      itself (i.e., it is not a SIP proxy or a SIP UA), this threat can
      be eliminated by employing inherent SIP security mechanisms, such
      as TLS.  However, if this entity is part of the communication
      itself then reference integrity needs to be provided.  Assertions
      with tight restrictions (e.g., validity of the assertion) can also
      limit the possible damage.

10.3  Forged Assertion


      A malicious user could forge or alter a SAML assertion in order to
      communicate with the SIP entities.

Tschofenig, et al.        Expires May 2, 2005                  [Page 24]

Internet-Draft             Using SAML for SIP              November 2004


      To avoid this kind of attack, the entities must assure that proper
      mechanisms for protecting the SAML assertion needs to be in place.
      It is recommended to protect the assertion using a digital

10.4  Replay Attack


      In the case of using SIP with the SAML pull model, the threat of
      replay lies in the fact that the artifact is a one-time-use
      subject.  The same artifact can be used again to gain access to


      Cases where multiple requests are made which references the same
      request must be tracked in order to avoid the threat.

Tschofenig, et al.        Expires May 2, 2005                  [Page 25]

Internet-Draft             Using SAML for SIP              November 2004

11.  Contributors

   The authors would like to thank Henning Schulzrinne for his
   contributions to this document.

Tschofenig, et al.        Expires May 2, 2005                  [Page 26]

Internet-Draft             Using SAML for SIP              November 2004

12.  Acknowledgments

   We would like to thank RL 'Bob' Morgan and Stefan Goeman for their
   comments to this draft.

Tschofenig, et al.        Expires May 2, 2005                  [Page 27]

Internet-Draft             Using SAML for SIP              November 2004

13.  IANA Considerations

   This document contains a number of IANA considerations.  A future
   version of this document will list them in this section.

Tschofenig, et al.        Expires May 2, 2005                  [Page 28]

Internet-Draft             Using SAML for SIP              November 2004

14.  Open Issues

   This document raises a number of issues with regard to the SIP
   protocol interaction.  Some of them are raised in this document (such
   as reference integrity, who is allowed to add which information,
   etc.) but a more detailed treatment of this topic with a focus of
   identity management is described in [I-D.peterson-message-identity].
   In particular, the following sections are highly relevant for this

   Assertion Constraints and Scope:

      This aspect deals with the problem of binding a SIP assertion to a
      specific SIP message.  The goal is to provide a security property
      called reference integrity to prevent replay and impersonation
      attacks.  As described in Section 5 that a number of fields can be
      used for this purpose.  This document also considers scenarios
      where the SAML assertion was obtained outside a SIP protocol run.
      In these cases SIP fields are not available to provide reference
      integrity.  The concept of the holder-of-the-key assertion is
      described below and relevant for this discussion.

   Canonicalization versus Replication:

      To provide reference integrity a few selected fields need to be
      hashed, signed and placed into the assertion.  Two approaches are
      available for this purpose.  Hence it needs to be studied how the
      interworking between reference integrity and the usage of obtained
      SAML assertion can be properly accomplished.  For example, who
      indicates which fields are included?

   Placement of Assertions and Keys in Messages:

      This document assumes that the assertions are added to the SIP
      body and artifacts or references to assertions located in the SIP
      body are added to the SIP header.  A central question is therefore
      where these assertions should be attached? Should the SIP user
      agent or intermediate SIP proxies add assertions/artifacts? In the
      scenarios depicted in Section 6, we have both approaches depending
      on what kind of scenario it is.  In Figure 4, they are added at
      the UA and in contrast we have Figure 7, where the assertions are
      added at the PSTN/SIP gateway.

      MIME bodies can only be attached at the UA.  Proxies by definition
      do not attach MIME bodies; if an intermediary were to do so, it
      would not be playing the proxy server role in the SIP
      architecture.  The SIP content indirection mechanism
      [I-D.ietf-sip-content-indirect-mech] is also relevant in this

Tschofenig, et al.        Expires May 2, 2005                  [Page 29]

Internet-Draft             Using SAML for SIP              November 2004


   To provide reference integrity (by binding a SIP session and a SAML
   assertion together) two alternative approaches exist:

   Hashing of SIP message fields:

      If a hash is computed over a number of selected SIP fields and
      subsequently digitally signed then there is a some degree of
      protection that the assertion cannot be copied to other SIP
      messages and reused.  The drawback thereby is that the assertion
      has a very limited time period.  The hashed fields may vary from
      context to context.

   Holder-of-the-Key Assertion:

      SAML introduces the concept of a holder-of-the-key assertion to
      bind the assertions (authorization information) to a cryptographic
      key.  As a result, the end host which was quite passive when
      dealing with assertions can be turned into an active protocol
      participant.  The end host obtained the assertion and attached
      them to selected messages but did not provide any cryptographic
      computations with regard to the assertion itself.  With the end
      host being active in the protocol exchange security is improved a
      lot.  Furthermore, it is possible to combine the benefits of the
      work done with SIPPING-CERT [I-D.ietf-sipping-certs] and this
      document by binding a self-signed certificate created by the user
      and stored at the credential server to an assertion.  As noted in
      Section 9 of [I-D.ietf-sipping-certs] in the context of signing
      SIP messages the usage of a self-signed certificate is not very
      helpful except used with an Authentication Service.  Combined with
      a SAML assertion the signature would protect the SIP message and
      the SAML assertion would provide authorization information.

   A number of credentials can be used with the KeyInfo element of the
   Holder-of-the-Key assertion as described in Section 4.4 of

   Further open issues are:

   o  Some work on option-tags is required.  Are there cases when
      processing of the assertion would be required by the sender? Or
      when a proxy server wants to be able to say that a UA must supply
      this header in order to access a particular resource? If so, an
      option-tag should be defined for this extension that can be used
      in Require, Supported, 420, etc.

   o  Specific SAML confirmation method identifiers and identifiers for

Tschofenig, et al.        Expires May 2, 2005                  [Page 30]

Internet-Draft             Using SAML for SIP              November 2004

      the bindings or profiles must be defined and registered with
      OASIS.  A confirmation method identifier is a URI that specifies
      which method should be used by the target domain to assure that
      the identity of the subject is true.

      This mechanism seems to be provide the same reference integrity
      properties as the hash over the various headers/bodies proposed in
      the identity draft.

   o  Further use cases would be interesting.  For example, a mechanism
      to provide additional security for the SIP REFER method [RFC3515].

   o  A few new URIs need to be registered.  The proposed URIs for
      identification are:

      SIP Binding: urn:oasis:names:tc:SAML:1.0:bindings:SIP-binding

      Artifact profile:

      Assertion profile:

   o  The proposed URIs for Confirmation Method Identifiers are:

      Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01

      Assertion profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer

   o  These are based on the URIs already used in the existing SOAP-SAML
      binding, specified in Section 3 of [I-D.saml-bindings-1.1].

   o  An alignment with the work done by Liberty Alliance on Federated
      Identities as described in [I-D.liberty-idff-arch-overview] would
      be useful.

   o  The security consideration needs more details.

Tschofenig, et al.        Expires May 2, 2005                  [Page 31]

Internet-Draft             Using SAML for SIP              November 2004

15.  References

15.1  Normative References

              Hodges, J., "application/saml+xml Media Type
              Registration", draft-hodges-saml-mediatype-01 (work in
              progress), June 2004.

              Peterson, J., "Trait-based Authorization Requirements for
              the Session Initiation Protocol  (SIP)",
              draft-ietf-sipping-trait-authz-00 (work in progress),
              February 2004.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2392, August 1998.

15.2  Informative References

              Peterson, J., "SIP Authenticated Identity Body (AIB)
              Format", draft-ietf-sip-authid-body-03 (work in progress),
              May 2004.

              Burger, E., "A Mechanism for Content Indirection in
              Session Initiation Protocol (SIP)  Messages",
              draft-ietf-sip-content-indirect-mech-05 (work in
              progress), October 2004.

              Peterson, J., "Enhancements for Authenticated Identity
              Management in the Session Initiation  Protocol (SIP)",
              draft-ietf-sip-identity-03 (work in progress), September

              Jennings, C. and J. Peterson, "Certificate Management
              Service for SIP", draft-ietf-sipping-certs-00 (work in
              progress), October 2004.

              Jennings, C., "Payment for SIP Services",
              draft-jennings-sipping-pay-00 (work in progress), July

Tschofenig, et al.        Expires May 2, 2005                  [Page 32]

Internet-Draft             Using SAML for SIP              November 2004


              Wason, T., "Liberty ID-FF Architecture Overview", 2004.

              Peterson, J., "Security Considerations for Impersonation
              and Identity in Messaging  Systems",
              draft-peterson-message-identity-00 (work in progress),
              October 2004.

              Maler, E., Philpott, R. and P. Mishra, "Bindings and
              Profiles for the OASIS Security Assertion Markup Language
              (SAML) V1.1", September 2003.

              Maler, E., Philpott, R. and P. Mishra, "Assertions and
              Protocol for the OASIS Security Assertion Markup Language
              (SAML) V1.1", September 2003.

              Maler, E. and R. Philpott, "Security and Privacy
              Considerations for the OASIS Security Markup Language
              (SAML) V1.1", September 2003.

              Maler, E. and J. Hughes, "Technical Overview of the OASIS
              Security Assertion Markup Language (SAML) V1.1", March

   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E. and J.
              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
              March 1999.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

              Eastlake, D., Reagle, J. and D. Solo, "XML-Signature
              Syntax and Processing, W3C Recommendation (available at
    ", February 2002.

Tschofenig, et al.        Expires May 2, 2005                  [Page 33]

Internet-Draft             Using SAML for SIP              November 2004

Authors' Addresses

   Hannes Tschofenig
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520


   James Polk
   2200 East President George Bush Turnpike
   Richardson, Texas  75082


   Douglas C. Sicker
   University of Colorado at Boulder
   ECOT 430
   Boulder, CO  80309


   Marcus Tegnander
   Letterkenny Institute of Technology
   Port Road
   Letterkenny, Donegal

Tschofenig, et al.        Expires May 2, 2005                  [Page 34]

Internet-Draft             Using SAML for SIP              November 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Tschofenig, et al.        Expires May 2, 2005                  [Page 35]