Session Initiation Protocol A. Pashalidis
SIP Working Group J. Girao
Internet-Draft NEC Europe Ltd.
Intended status: Experimental July 7, 2008
Expires: January 8, 2009
SIP SAML Profile and Binding
draft-pashalidis-sip-saml-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Pashalidis & Girao Expires January 8, 2009 [Page 1]
Internet-Draft SIP SAML SSO July 2008
Abstract
This document specifies the SIP/SAML profile and binding, i.e. a
protocol for the use of Security Assertion Markup Language (SAML)
assertions for the purposes of authentication and the exchange of
attributes in a Session Initiation Protocol (SIP) environment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SIP/SAML Direct Variant . . . . . . . . . . . . . . . . . . . 6
4. SIP-Artifact Variant . . . . . . . . . . . . . . . . . . . . . 9
5. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 12
6. The SIP/SAML bindings . . . . . . . . . . . . . . . . . . . . 13
6.1. SIP/SAML message encoding . . . . . . . . . . . . . . . . 13
6.2. SIP/SAML artifact encoding . . . . . . . . . . . . . . . . 13
6.2.1. SIP/SAML URI artifact encoding . . . . . . . . . . . . 13
6.2.2. SIP/SAML Content artifact encoding . . . . . . . . . . 14
6.2.3. SIP/SAML artifact header . . . . . . . . . . . . . . . 14
6.3. The SAML-Endpoint Header . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Pashalidis & Girao Expires January 8, 2009 [Page 2]
Internet-Draft SIP SAML SSO July 2008
1. Introduction
This document specifies the SIP/SAML profile and binding, i.e. a
protocol for the authentication of Session Initiation Protocol (SIP)
users by means of Security Assertions Markup Language (SAML)
assertions, and for the exchange of user attributes over the SIP
protocol.
SAML is a set of protocol specifications that provide, among other
things, seamless Single Sign-On (SSO) in a distributed environment
where a user wishes to log into multiple Service Providers (SPs). In
particular, once a user has authenticated himself towards a trusted
entity called the "Identity Provider" (IDP), the SAML protocols
enable the IDP and the SPs to exchange information about the user's
authentication status at the IDP in a secure manner and in a way that
takes into account the user's privacy. Moreover, the SAML protocols
enable the SPs and the IDP to exchange information about the user in
the form of attributes. This feature is useful in the context of
identity management systems that perform such attribute exchanges in
an automated way, while enabling the user to exercise control over
the dissemination of his personal information.
However, the SAML protocols are not self-contained in the sense that
they require a transport mechanism. In particular, SAML messages
need to be conveyed from one party to the other by some underlying
transport protocol. The encoding of SAML messages in such transport
protocols is called a SAML binding; multiple such bindings have been
specified in the past. Examples are the HTTP REDIRECT binding, the
HTTP POST binding, and the SOAP binding [SAMLBINDINGS].
With each newly specified SAML profile and binding, the number and
the diversity of applications and services that can interoperate with
any given SAML-based IDP increases. This adds value to the overall
system, because it enables the user to log into a larger and more
diverse set of services in a seamless manner. Moreover, the number
of services that can query the user's attributes from the IDP
increases, resulting in a potentially more personalised experience
for the user.
This document specifies the SIP/SAML profile. This profile is used
in the case where the service provider is a SIP proxy. The main use
case for this profile is a user who would like to register at this a
SIP proxy by means of the SIP REGISTER method, and who would like to
be authenticated at the SIP proxy by means of a SAML Assertion that
is issued by his IDP.
The remainder of this document is structured as follows.
Pashalidis & Girao Expires January 8, 2009 [Page 3]
Internet-Draft SIP SAML SSO July 2008
o Section 2 provides an overview of the terminology and the
abbreviations used in this document.
o Section 3 specifies the `Direct' variant of the SIP/SAML profile.
o Section 4 specifies the `Artifact' variant of the SIP/SAML
profile.
o Section 5 specifies how certain errors are handled in the SIP/SAML
profile.
o Section 6 specifies the SIP/SAML binding.
o Section 7 discusses important security aspects of the protocols.
Pashalidis & Girao Expires January 8, 2009 [Page 4]
Internet-Draft SIP SAML SSO July 2008
2. Terminology
This document makes use of terms defined in [RFC3261] and [SAML]. In
addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in [RFC2119].
Pashalidis & Girao Expires January 8, 2009 [Page 5]
Internet-Draft SIP SAML SSO July 2008
3. SIP/SAML Direct Variant
In this section, the Direct Variant of the SIP/SAML profile is
specified. In the following, UA denotes the user agent (client), SP
denotes a SIP Proxy, and IDP denotes a SAML-based Identity Provider.
This specification relies on a new SIP header, called the `SAML-
Endpoint (SAML-EP)' header. This header contains a URI endpoint
pointing to the user's SAML-based IDP. The format of the SAML-EP
header is specified in section Section 6.3 in detail.
1. UA -> SP : SIP REGISTER + SAML-EP header(s)
2. SP -> UA : SIP 302 REDIRECT [SIDP URI] + SAML request
3. UA -> IDP : SIP REGISTER + SAML request
4. UA <-> IDP: AUTHENTICATION
5. UA <- IDP : SIP 302 REDIRECT [SP URI] + SAML response
6. UA -> SP : SIP REGISTER + SAML response
Figure 1: The Direct Variant of the SIP/SAML Profile
Figure 1 shows the direct variant of the SAML/SIP profile in full
i.e. where the user authenticates himself at the IDP for the first
time. The figure shows individual steps that occur during the
protocol execution. With the exception of step 4, all the steps
uniquely correspond to a particular message that is exchanged in the
corresponding step. In the following, we say `message X' in order to
refer to the message that is exchanged in step X of the protocol.
First, the UA constructs a SIP REGISTER message and sends it to the
SP (message 1). This message MUST contain one or more SAML-EP
headers, where the value of each SAML-EP header MUST be one or more
URIs. All the indicated URIs MUST belong to some SAML-based IDP that
is able to consume SIP REGISTER messages conforming to the format of
message 3. The population of the SAML-EP header values is the
responsibility of the UA. If multiple SAML-EP header values are
present in message 1 (either in the same or in multiple SAML-EP
headers), then each URI within a SAML-EP header value MUST refer to a
different IDP. Also, each URI within a SAML-EP header value MUST
refer to an IDP where the user maintains an active account. However,
there is no requirement to include more than IDP URI, even if the
user maintains accounts at multiple IDPs. Moreover, the order of the
URIs within SAML-EP header values SHOULD reflect the user's
preferences, most preferred first. That is, if the user prefers to
Pashalidis & Girao Expires January 8, 2009 [Page 6]
Internet-Draft SIP SAML SSO July 2008
be authenticated by IDP A in preference to IDP B, then the URI
referring to IDP A SHOULD be included in a SAML-EP header before the
URI referring to IDP B.
The following two possibilities exist when message 1 is received by
the SP. Case 1: the SP does not support the SIP/SAML profile
specified in this document. In this case, the SAML-EP header(s) are
ignored, and the SP responds 'normally', i.e. as in standard SIP.
The UA MUST be able to correctly handle a message conforming to
standard SIP (instead of message 2 in Figure 1) as a response to
message 1. Case 2: the SP supports the SIP/SAML profile. In this
case, it MUST examine the SAML-EP headers and check whether or not an
agreement exists with at least one of the indicated IDPs. If an
agreement exists with at least one of them, then it MUST pick one of
those with whom an agreement exists; the one it selects is denoted by
SIDP. The SP SHOULD select the IDP that corresponds to the first URI
within any SAML-EP header with whom an agreement exists. If no
agreement consists with any of the IDPs then the SP MUST act as if it
does not support the SIP/SAML profile specified in this document,
i.e. respond with a message conforming to 'standard' SIP.
After the SIDP has been selected, the SP MUST decide with which SAML/
SIP profile it would like to proceed. This decision MAY be based on
a policy or similar criteria. If the 'SIP Artifact' profile profile
is selected, then the remainder of the processing and the protocol is
as described in section Section 4. Otherwise, i.e. if the 'direct'
profile is selected, then processing continues as follows.
Message 2 is constructed as follows. The SP constructs a SIP 302
REDIRECT message where the value of the 'Contact' header is equal to
the value of the SAML-EP header (from message 1) that corresponds to
the SIDP. This value is denoted by SIDP URI in Figure 1. Moreover,
message 2 MUST contain a SAML Request, which MUST be constructed
according to [SAML]. This SAML Request MUST be included into message
2 according to the SIP/SAML binding specified in Section 6.1.
Upon reception of message 2, the UA SHOULD check that the SIDP URI
indicated in the 'Connect' header is one of those proposed in message
1. If this is not the case, then the UA MAY abort the protocol
execution at this point. It also MAY inform the user about the
inconsistency, and it MAY ask for the user's permission on whether to
proceed with the given SIDP URI. It is RECOMMENDED that the UA does
not proceed with the protocol execution if the indicated SIDP URI is
not one of the ones proposed in message 1, unless the user explicitly
allows the protocol execution to continue.
After reception of message 2, the UA MUST decide how to proceed in
trying to obtain a SAML Response that matches the SP's SAML Request
Pashalidis & Girao Expires January 8, 2009 [Page 7]
Internet-Draft SIP SAML SSO July 2008
in message 2. Multiple possibilities MAY exist for this, and this
specification does not impose the UA to use any particular method.
However, if the UA decides to continue with the `Direct Variant' of
the SIP/SAML profile, then it MUST proceed as follows.
It constructs message 3 as a new SIP REGISTER message, which is sent
to the SIDP URI. The message contains the SAML Request from message
2, which is included according to the SIP/SAML binding specified in
Section 6.1. Note that, since message 3 is sent to an IDP (which is
NOT a SIP Proxy), its purpose it not to register at a SIP Proxy; its
purpose is to trigger authentication at the IDP.
In step 4 of the protocol, IDP authenticates the user. This may
involve multiple messages between the UA and the IDP. This
specification does not impose any particular authentication
mechanism. However, in order to guarantee minimal interoperability,
the standard SIP user authentication mechanism (Digest
Authentication, see section 22 of [RFC3261]) MUST be implemented at
both the IDP and the UA. However, whether or not the IDP will choose
this method or some other method, is dependent on policy.
After the authentication of the user towards the IDP, the IDP
constructs message 5. This is a SIP 302 REDIRECT message where the
'Contact' header MUST contain a value that is extracted from the SAML
request in 3, according to [SAML]. According to [SAML], the SAML
Response contains the description of an authentication context if the
user's authentication in step 4 has been successful. If this is the
case, the authentication context in the SAML Response MUST describe
the user's authentication context that resulted from the
authentication in step 4. The SAML Response is included in message 5
according to the SIP/SAML binding, as specified in Section 6.1.
Finally, the UA constructs a new SIP REGISTER message and sends this
to the SP in step 6. This SIP REGISTER message MUST contain the SAML
Response from message 5, according to the SIP/SAML binding specified
in Section 6.1. Upon reception of that message, the SP MUST examine
the SAML Response according to [SAML]. If the SP is satisfied, the
user is recorded as 'registered' in the SIP Proxy, and the remaining
processing continues according to standard SIP [RFC3261].
Pashalidis & Girao Expires January 8, 2009 [Page 8]
Internet-Draft SIP SAML SSO July 2008
4. SIP-Artifact Variant
This section specifies the SIP-Artifact Variant of the SIP/SAML
Profile. The main difference between the SIP-Artifact Variant and
the Direct Variant is that, in the SIP-Artifact Profile, the UA
cannot see the SAML messages that are exchanged between the SP and
the IDP. Instead, the SP and the IDP exchange SAML messages
directly. Special identifiers that identify individual SAML
messages, called `SAML Artifacts' are tunneled through the UA.
1. UA -> SP : SIP REGISTER + a SAML-EP header(s)
2. SP -> UA : SIP 302 REDIRECT [SIDP URI + Artifact] + SAML-EP header
3. UA -> IDP : SIP REGISTER + Artifact + SAML-EP header
4. IDP <-> SP: Artifact Resolution
5. UA <-> IDP: AUTHENTICATION
6. UA <- IDP : SIP 302 REDIRECT [SP URI + Artifact] + SAML-EP header
7. UA -> SP : SIP REGISTER + Artifact + SAML-EP header
8. SP <-> IDP: Artifact Resolution
Figure 2: The SIP-Artifact Variant of the SIP/SAML Profile
Figure 2 shows the SIP-Artifact variant of the SAML/SIP profile in
full i.e. where the user authenticates himself at the IDP for the
first time. The figure shows individual steps that occur during the
protocol execution. With the exception of steps 4, 5, and 8 all the
steps uniquely correspond to a particular message that is exchanged
in the corresponding step. In the following, we say `message X' in
order to refer to the message that is exchanged in step X of the
protocol.
First, the UA constructs a SIP REGISTER message and sends it to the
SP (message 1). This message is constructed in a manner identical to
the construction of the first message in the `direct' variant, as
specified in the section above. The behaviour of the SP after having
received message 1 is identical to the behaviour specified for the
`direct' variant in the section above, up to the point where the SP
decides which variant to use. If the SP decides to use the
`Artifact' variant, the processing is as follows.
Pashalidis & Girao Expires January 8, 2009 [Page 9]
Internet-Draft SIP SAML SSO July 2008
The SP MUST construct a SAML Artifact pointing to a SAML Request
message for consumption by the SIDP, according to [SAML]. Message 2
is then constructed as a SIP 302 REDIRECT message, where the
`Contact' header MUST take as value the URI indicated by the SAML-
Endpoint header (from message 1) that corresponds to the SIDP,
modified as follows. The SAML Artifact MUST be encoded into the URI,
according to the binding specified in Section 6.2.
Moreover, message 2 MUST contain exactly one SAML-EP header, where
the value is the URI at which the SP will accept a SAML Artifact
Resolution request from the SIDP.
Upon reception of message 2, the UA SHOULD check that the SIDP URI
indicated in the 'Connect' header is one of those proposed in message
1. If this is not the case, then the UA MAY abort the protocol
execution at this point. It also MAY inform the user about the
inconsistency, and it MAY ask for the user's permission on whether to
proceed with the given SIDP URI. It is RECOMMENDED that the UA does
not proceed with the protocol execution if the indicated SIDP URI is
does not correspond to any of those that were proposed in message 1,
unless the user explicitly allows the protocol execution to continue.
The UA constructs message 3 as a new SIP REGISTER message, which is
sent to the SIDP URI. Message 3 MUST contain a single SAML-EP
header, with a value identical to the value of the SAML-EP header
from message 2. Since message 3 is sent to an IDP (which is NOT a
SIP Proxy), its purpose it not to register at a SIP Proxy; its
purpose is to trigger authentication at the IDP.
In step 4 of the protocol, the IDP resolves the SAML Artifact found
in the query string of the URI from message 3, into a SAML Request
message. This is done by means of the Artifact Resolution protocol
specified in [SAMLART]. The SAML binding the is used for this
exchange MUST be the the SIP/SAML binding specified in section
Section 6. Moreover, the SAML Endpoint that the IDP uses for
initiating the exchange is the one indicated in the SAML-EP header in
message 3.
If the SAML Artifact has sucessfully been resolved into a SAML
Request message, in step 5 of the protocol the IDP authenticates the
user. This corresponds to step 4 in the 'direct' variant specified
in the previous section, and the requirements concerning this steps
are identical to the requirements in the 'direct' variant.
After the authentication of the user towards the IDP, the IDP MUST
construct a SAML Artifact pointing to a SAML Response message for
consumption by the SP, according to [SAML]. Message 6 is then
constructed as a SIP 302 REDIRECT message, where the `Contact' header
Pashalidis & Girao Expires January 8, 2009 [Page 10]
Internet-Draft SIP SAML SSO July 2008
MUST take the value of an specific URI that is extracted from the
SAML request in 3, according to [SAML], modified as follows. The
SAML Artifact MUST be encoded into the URI, according to the binding
specified in Section 6.2.
The SAML Response to which the SAML Artifact points, MUST contain the
description of an authentication context if the user's authentication
in step 5 has been successful. If this is the case, the
authentication context in the SAML Response MUST describe the user's
authentication context that resulted from the authentication in step
5.
Moreover, message 6 MUST contain exactly one SAML-Endpoint header,
where the value is the URI at which the IDP will accept a SAML
Artifact Resolution request from the SP.
Upon reception of message 6, the UA constructs message 7 as a new SIP
REGISTER message. Message 7 MUST contain exactly one SAML-Endpoint
header, where the value is identical to the value of the SAML-
Endpoint header from message 6. Message 7 is then sent to the URI
indicated in the 'Contact' header of message 6.
In step 8 of the protocol, the IDP resolves the SAML Artifact found
in the query string of the URI from message 7, into a SAML Response
message. This is done by means of the Artifact Resolution protocol
specified in [SAMLART]. The SAML binding the is used for this
exchange MUST be the the SIP/SAML binding specified in section
Section 6. Moreover, the SAML Endpoint that the SP uses for
initiating the exchange is the one indicated in the SAML-Endpoint
header of message 7.
Pashalidis & Girao Expires January 8, 2009 [Page 11]
Internet-Draft SIP SAML SSO July 2008
5. Error handling
This section specifies how certain errors are handled within SIP/SAML
Profile.
TBD.
Pashalidis & Girao Expires January 8, 2009 [Page 12]
Internet-Draft SIP SAML SSO July 2008
6. The SIP/SAML bindings
This section specifies the SIP transport for SAML messages and SAML
Artifacts.
6.1. SIP/SAML message encoding
A SIP message that carries a SAML message MUST include the SAML
message as the SIP message body. A 'Content-Type' header MUST be
included in the SIP message, with a value of 'text/xml'. The message
body MUST consist solely of the SAML message which MUST be
constructed according to [SAML]. The SIP message MUST otherwise
conform to the format of a standard SIP message. This includes
respecting the rules regarding the character encoding and the
presence of a 'Content-Length' header - see [RFC3261]
6.2. SIP/SAML artifact encoding
There are three mechanisms to embed the SAML artifact into the
message: in the SIP URI, a SIP header or in the body of the SIP
message. While the advantage of the first lies in freeing the body
of the SIP message to carry other information, the other two conform
better to existing SIP specifications. This specification mandates
that, should the SIP/SAML artifact binding be supported, then
Section 6.2.3 MUST be supported, while Section 6.2.1 and
Section 6.2.2 are optional.
6.2.1. SIP/SAML URI artifact encoding
A SAML Artifact is encoded into a URI that occurs in a SIP message.
A URI into which a SAML Artifact is encoded is said to 'carry' the
SAML Artifact. Multiple URIs in the same SIP message MAY carry a
SAML Artifact. However, each URI MUST carry at most one SAML
Artifact. Whether or not a SAML Artifact is carried by a URI
occurring in a SIP message, is specified in the SIP/SAML profiles.
A SAML Artifact is encoded into a URI as follows. If the URI does
not have a query string component, then the URI MUST be appended with
a query component containing the parameter 'SAMLart' with the value
being the SAML Artifact in question. If the URI already contains a
query string component with other parameters, then the other
parameters MUST remain intact. If the URI already contains a query
string parameter with the name "SAMLart", where the matching
algorithm MUST be case-insensitive, then this parameter MUST be
replaced.
Pashalidis & Girao Expires January 8, 2009 [Page 13]
Internet-Draft SIP SAML SSO July 2008
6.2.2. SIP/SAML Content artifact encoding
A SAML Artifact is encoded into the body of a SIP message as follows.
A 'Content-Type' header MUST be included in the SIP message with the
value 'text/xml'. The message body MUST contain only the artifact in
XML format, which is detailed below. Otherwise, the message should
abide to the format of a standard SIP message.
The XML message will belong to the namespace described in [SAML] and
MUST contain only one element of type
'urn:oasis:names:tc:SAML:2.0:protocol:Artifact' with the name
'SAMLart'. This element MUST contain the artifact value.
6.2.3. SIP/SAML artifact header
This section specifies the format of the SAML Artifact Header. The
SAML Artifact header follows the header and grammar rules as
specified in section 7.1 of [RFC3261].
header = "SAMLart" HCOLON SAMLart-value
Figure 3: The SAML-Endpoint Header Format
The SAMLart-value MUST be a valid base-64 encoded string.
6.3. The SAML-Endpoint Header
This section specifies the format of the SAML-Endpoint Header. The
SAML-Endpoint header follows the header and grammar rules as they are
specified in section 7.1 of [RFC3261].
header = "SAML-Endpoint" HCOLON header-value *(COMMA URI-value)
Figure 4: The SAML-Endpoint Header Format
The URI-value MUST be a valid URI as specified in [RFC2396].
Pashalidis & Girao Expires January 8, 2009 [Page 14]
Internet-Draft SIP SAML SSO July 2008
7. Security Considerations
This specification introduces SAML-based user authentication in the
context of the SIP REGISTER method. As such, the privacy and
security considerations described in [SAMLSEC] apply to this
specification. The remainder of this section discusses requirements
that are specific to this document.
It is important to keep in mind that a SAML Assertion (which is part
of the SAML Response from the IDP) is sensitive information that must
be kept secret. Similarly, the SAML Artifact, which is part of the
IDP's response in the Artifact variant, is also sensitive
information. This is because knowledge of the assertion, in
particular the IDP's signature which is part of it, or knowledge of
the artifact, enables one to login (i.e. register) in the name of the
subject for which the assertion or artifact was generated.
The SAML assertion / artifact MUST therefore be conveyed from the IDP
to the SP in a way that preserves its confidentiality and its
integrity. The only exception to this rule is the case where the
authentication mechanism with which the user is authenticated at the
IDP involves the user's password being transmitted over the network
in the clear. In this case, the confidentiality and the integrity of
the SAML assertion / artifact SHOULD be protected along its way from
the IDP to the SP. The use of a user authentication mechanism which
involves the transmission of the user's password in the clear is NOT
RECOMMENDED.
In the "Direct" variant, protecting the SAML Assertion's
confidentiality and integrity requires protection both during the
transmission of the assertion from the IDP to the UA, and its
transmission from the UA of the SP. The protection mechanism that is
used MUST provide confidentiality and integrity protection against
active attackers. It is RECOMMENDED that a TLS channel with server-
side certificates is used both for the transmission of the assertion
from the IDP to the UA, and from the UA to the SP.
If a TLS channel is used for the transmission on the path IDP->UA,
then the IDP MUST NOT propose or select a TLS ciphersuite with an
effective key strength which is lower than the effective key strength
of its signature over the SAML Assertion. The IDP MUST use
independently generated keys for TLS and for signing SAML Assertions.
If a TLS channel is used for the transmission on the path US->SP,
then the UA MUST NOT propose or select a TLS ciphersuite with an
effective key strength which is lower than the effective key strength
of the signature over the SAML Assertion.
Pashalidis & Girao Expires January 8, 2009 [Page 15]
Internet-Draft SIP SAML SSO July 2008
In the "Artifact" variant, too, the use of TLS with server-side
certificates is RECOMMENDED. The same considerations and
requirements as above apply. Moreover, the communication between the
IDP and the SP for the purposes of SAML Artifact Resolution MUST be
authenticated, and the integrity and the confidentiality of this
communication MUST be protected. The following alternatives for the
protection of the direct communication between IDP and the SP are
RECOMMENDED. Note that all these alternatives result in a 'secure
channel' between the IDP and the SP.
o A long-lived TLS connection that is authenticated based on server-
side and client-side certificates.
o A long-lived IPsec connection where both parties are authenticated
based on a certificate.
The session key of secure channel MUST be at least as strong as the
key used by the IDP to sign SAML Assertions. It is the
responsibility of the IDP to reject incomong connection attempts from
SPs that do not provide for the minimum required protection level.
[RFC3766] SHOULD be used in order to compare the effective key
strengths.
Pashalidis & Girao Expires January 8, 2009 [Page 16]
Internet-Draft SIP SAML SSO July 2008
8. IANA Considerations
TBD. (None?)
Pashalidis & Girao Expires January 8, 2009 [Page 17]
Internet-Draft SIP SAML SSO July 2008
9. Acknowledgements
TBD.
Pashalidis & Girao Expires January 8, 2009 [Page 18]
Internet-Draft SIP SAML SSO July 2008
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "RFC 2396:
Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", RFC 3766,
April 2004.
[SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocols for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[SAMLBINDINGS]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", March 2005.
[SAMLSEC] Hirsch, F., Philpott, R., and E. Maler, "Security and
Privacy Considerations for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[utf8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629.
Pashalidis & Girao Expires January 8, 2009 [Page 19]
Internet-Draft SIP SAML SSO July 2008
Authors' Addresses
Andreas Pashalidis
NEC Europe Ltd.
Kurfuersten Anlage 36
Heidelberg D-69115
Germany
Phone: +49 (0)6221 4342 205
Fax: +49 (0)6221 4342 155
Email: andreas.pashaldis@nw.neclab.eu
Joao Girao
NEC Europe Ltd.
Kurfuersten Anlage 36
Heidelberg D-69115
Germany
Phone: +49 (0)6221 4342 117
Fax: +49 (0)6221 4342 155
Email: joao.girao@nw.neclab.eu
Pashalidis & Girao Expires January 8, 2009 [Page 20]
Internet-Draft SIP SAML SSO July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Pashalidis & Girao Expires January 8, 2009 [Page 21]