| TOC |
|
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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.
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 10, 2005.
Copyright (C) The Internet Society (2004). All Rights Reserved.
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.
1.
Introduction
2.
Terminology
3.
Goals and Non-Goals
4.
SAML Introduction
4.1
Assertions
4.2
Artifact
4.3
Request/Response protocol
4.4
Bindings
4.5
Profiles
5.
Assertion Handling Models
6.
Scenarios
6.1
Network Asserted Identities
6.2
SIP Conferencing
6.3
PSTN-to-SIP phone call
7.
Header Syntax
8.
Example
9.
Requirement Comparison
10.
Security considerations
10.1
Stolen Assertion
10.2
MitM Attack
10.3
Forged Assertion
10.4
Replay Attack
11.
Contributors
12.
IANA Considerations
13.
Open issues
§.
Normative References
§.
Informative References
§
Authors' Addresses
A.
SAML Artifact format
§
Intellectual Property and Copyright Statements
| TOC |
This document proposes a method for using the Security Assertion Markup Language (SAML) in collaboration with SIP to acommodate 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]Peterson, J., Trait-based Authorization Requirements for the Session Initiation Protocol (SIP), February 2004..
Security Assertion Markup Language (SAML)[I-D.saml-tech-overview-1.1-03]Maler, E. and J. Hughes, Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1, March 2004. is an XML extension for security information exchange. It is being developed by OASIS. SAML enables users to gain access to multiple website resources without having to re-authenticate every time the domain changes. The first authentication would be transferred to subsequent domains using SAML.
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]Peterson, J., SIP Authenticated Identity Body (AIB) Format, May 2004.. 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.
| TOC |
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 [RFC2119]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..
The SIP entity 'Authentication Service' was introduced with [I-D.ietf-sip-identity]Peterson, J., Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), May 2004..
The Authentication Service is the entity that authenticates and authorizes a user and creates an Assertion. This entity is the equivalent of the asserting party in the SAML terminology.
For terminology related to SAML the reader is referred to [I-D.saml-tech-overview-1.1-03]Maler, E. and J. Hughes, Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1, March 2004..
| TOC |
This document tries to accomplish the following goals:
The following issues are outside the scope of this document:
| TOC |
In SAML there are three main entities: the user, the asserting party and the relying party. The asserting party is asserting 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:
We describe each in turn below
An Assertion is a package of information including authentication statements, attribute statements and authorization decision statements. All kinds of statements do not have to be present, but at least one. An Assertion contains several elements:
- Issuing information:
Who issued the assertion, when was it issued and the assertion identifier.
- 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.
- 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 jon@cs.example.com is associated with the attribute 'Department', which has the value 'Computer Science'.
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.
The artifact used in the Browser/Artifact profile, is a base-64 encoded string which is 40 bytes long. 20 bytes consists of the typecode, which is the source id. The remaining 20 bytes consists of a 20-byte random number that servers use to look up an assertion. The source server stores the assertion temporarily. The destination server receives the assertion and pulls the data from the artifact on the source site. The purpose of the artifact is to act as a token who references an assertion for the subject who holds the artifact.
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 is carrying back the requested Assertion. The XML format for protocol messages are defined within an XML schema in TBD.
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.
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 respresents 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 1SAML Pull model and in Figure 2SAML Push model.
| TOC |
As mentioned in Section 4.5Profiles, 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 referenced. 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. That is outside the scope of this document.
Note that this exchange also allows the Artifact to be bound to a particular signaling session by attaching the assertion to the service request. This requires the Asserting Party to participate in the signaling message exchange and provides stronger security properties but removes the property of "single sign-on".
+----------+ +--------------+ +--------------+
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| | |
| Artifact | |
|<---------------------| |
| | |
| Request + Artifact |
|----------------------+------------------------->|
| | |
| | |
| | SAML request |
| |<-------------------------|
| | |
| | |
| |SAML response + Assertion |
| |------------------------->|
| | |
| | |
| Accept/Reject |
|<---------------------+--------------------------|
| | |
| 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. Using programming languages, a call-by value is implemented.
+----------+ +--------------+ +--------------+
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| | |
| Assertion | |
|<---------------------| |
| | |
| Request + Assertion |
|----------------------+------------------------->|
| | |
| | |
| Accept/Reject |
|<---------------------+--------------------------|
| | |
| SAML Push model |
The usage of SAML in HTTP-based environments and in SIP is, however, affected by some architectural differences. The main goal of realizing single-sign-on (SSO) functionality in HTTP is not the goal of this extension to SIP.
The function of the entities in the Push and the Pull model are shown in Figure 1SAML Pull model and in Figure 2SAML Push model.
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 to obtain 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 that it does not act on behalf of the user to impersonate him or her to other parties with regard to access to this resource. 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]Peterson, J., Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), May 2004. aims to replace end-to-end authentication via 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 lifetime or indication of a particular resource) but they cannot fully prevent impersonation. If intermediate SIP proxies should also be able to process the Assertion then it cannot be bound to a particular receiver - the intermediate SIP proxies might not even be known to the SIP end host.
This problem appears if SAML Assertions are not bound to a particular protocol run. Binding the Assertion to a particular session is not useful in the context of SSO but in many SIP scenarios there seems to be a problem if such a binding is not provided. There is little usage in requesting Assertions from a separate Authentication Service for every SIP message exchange since the additional latency and performance impact could potentially be large.
| TOC |
This section shows message flows based on scenarios in [I-D.ietf-sipping-trait-authz]Peterson, J., Trait-based Authorization Requirements for the Session Initiation Protocol (SIP), February 2004. enriched with a SAML based solution. Section 6.1Network Asserted Identities provides an example of enhanced network asserted identities and Section 6.2SIP Conferencing shows a SIP conferencing scenario with role-based access control using SAML. A future version of this document will cover more scenarios from [I-D.ietf-sipping-trait-authz]Peterson, J., Trait-based Authorization Requirements for the Session Initiation Protocol (SIP), February 2004..
Figure 3Network Asserted Identities shows an enhanced network asserted identity scenario based on [I-D.ietf-sip-identity]Peterson, J., Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), May 2004. which again utilizes extensions proposed with [I-D.ietf-sip-authid-body]Peterson, J., SIP Authenticated Identity Body (AIB) Format, May 2004.. The enhancement is based on the attributes asserted by the Authentication Service.
Figure 3Network Asserted Identities shows three entities, Alice@example.com, AS@example.com and Bob@example2.com. 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 Header 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]Peterson, J., Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), May 2004. and particularly in [I-D.ietf-sip-authid-body]Peterson, J., SIP Authenticated Identity Body (AIB) Format, May 2004.. 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 identity which created the digital signature. Upon reception of the message, Bob learns the signature in the SAML header 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 3Network Asserted Identities.
Note that this scenario does not imply that the SAML assertions are solely used by SIP UAs. Assertions can also be helpful for SIP 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 omitted.
+--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2|
|.com | |@example.com | |com |
| | | | | |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:alice@foo.com | |
| | |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| Challenge | |
| | |
| | |
| Challenge response | |
|---------------------->| |
| | |
| | |
| | |
| INVITE | |
|---------------------->| |
| | INVITE |
| | + SAML assertion |
| |--------------------->|
| | |
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
| Network Asserted Identities |
A variation of the scenario presented in Figure 3Network Asserted Identities is given in Figure 4End host attaching SAML Assertion where an end host (Alice@example.com) obtains an Assertion from its SIP proxy server. This assertion is then attached by the end host to the outgoing INVITE message. Unlike in case of an Artifact, Bob@example.com 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).
+--------+ +--------------+ +--------+
| Alice@ | |Proxy Server | | Bob@ |
|example | | | |example |
|.com | |@example.com | |.com |
| | | | | |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:alice@example.com| |
| | |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| SAML Auth Header | |
| to use | |
| | |
| | |
| INVITE + SAML assertion |
|-----------------------+--------------------->|
| | |
| | |
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
| End host attaching SAML Assertion |
Note that Bob and Alice can 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 Alice@example.com needs to be associated with a particular SIP messaging session. How to achieve this binding is for further consideration.
This section is meant to raise some discussions about the usage of SAML in the domain of SIP conferencing.
Two possible usage cases are described. The first use case describes a user who routes its SIP message through the Authentication Service (Asserting Party) to allow SAML Assertions to be included. The following goals could be achieved by this procedure:
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...
| SIP Conferencing and SAML |
In the second use case, a SIP Proxy (which acts as an Asserting Party) stores authorization policies for usage with SIP conferencing. These authorization policies could be attached by the Asserting Party for this particular session. The Focus does not need to store this type of information.
These policies might not be configured by the user itself. One could think of a model similar to the Geopriv model where the rule maker does not need to be the same entity as the conferencing participant.
The authorization policies defined in [I-D.niemi-xcon-cpcp-rules]Niemi, A., Conference Policy Authorization Rules, May 2004. could be reused. If we think of virtual 3GPP/IEEE meeting scenario then certain members have more rights than others and it must be asserted that a particular person is the member of a company and possibly some other restrictions.
The SAML assertion could, for example, include (among other things):
<rule="a1234">
<conditions/>
<actions>
<join-handling>accept</join-handling>
</actions>
<transformations>
<is-key-participant>true</is-key-participant>
</transformations>
</rule>
| Carrying authz. policies for SIP Conferering in SAML |
The identity section of the conditions part is left empty since the Assertion is attached to a request which originates from a particular entity. The identity to whom the Assertion was granted is already included in other SAML specific attributes.
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 properly authenticated through PSTN signaling mechanisms, the gateway can create an assertion based on signaling information from Alice and digitally sign it with it's 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 assertion.
+-----------+
+----------------------+ | |
| | SS7 | SIP/PSTN |
| Public Switched |--------------------->| Gateway |
| | | |
| | | |
| Telephone Network | +--+-----------+----+
| ^ | | | |
+---------+------------+ | | SIP+SAML |
| SS7 | v |
| | +--------+ |
O | | | |
O /|\ <----+----| SIP | |
/|\ / \ SIP+ | Proxy | |
/ \ Bob SAML | | |
Alice | +--------+ |
| SIP based |
| Network |
+-------------------+
| PSTN to SIP call |
| TOC |
This document specifies a new SIP header: SAML-Payload
This header MUST NOT appear more than once in a SIP message.
SAML-Payload = "SAML-Payload" HCOLON saml-assertion
The saml-assertion field either contains a base64 encoded SAML Assertion which SHOULD be S/MIME protected or an Artifcat. An example of an Assertion is shown in Section 8Example and its protection is highly recommended but not mandated by the SAML specification.
If an SAML assertions is protected 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]Peterson, J., Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), May 2004., is included into the TBD element of the SAML Assertion.
| TOC |
This is an example of a SAML assertion and how it is structured in XML.
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1"
MinorVersion="1"
AssertionID="P1YaAz/tP6U/fsw/xA+jax5TPxQ="
Issuer="www.example.com"
IssueInstant="2004-06-28T17:15:32.753Z">
<saml:Conditions NotBefore="2004-06-28T17:10:32.753Z"
NotOnOrAfter="2004-06-28T17:20:32.753Z" />
<saml:AuthenticationStatement
AuthenticationMethod="urn:ietf:rfc:3075"
AuthenticationInstant="2004-06-28T17:15:12.706Z">
<saml:Subject>
<saml:NameIdentifier>
NameQualifier=alice@example.com
Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">uid=alice
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:
cm:SIP-artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
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 | +---------------------+-----+-------------------------------+ |IssuerInstant | X |Issuing time of the assertion | +---------------------+-----+-------------------------------+ | | |Conditions that MUST be taken | |Conditions | |into account when assessing | | | |the validity of the assertion | +---------------------+-----+-------------------------------+ | | |A URI reference that 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 | +---------------------+-----+-------------------------------+ | | |A URI reference who identifies | |ConfirmationMethod | |which method to be used for | | | |authenticating the subject | +---------------------+-----+-------------------------------+
| Tag descriptions |
| TOC |
A future version of this document will compare the requirements listed in [I-D.ietf-sipping-trait-authz]Peterson, J., Trait-based Authorization Requirements for the Session Initiation Protocol (SIP), February 2004. with the solution provided in this document.
| TOC |
This section discusses security considerations when using SAML with SIP.
Threat: If an eavesdropper can copy the real user's SAML response and included assertions and construct it's own SIP message, then the eavesdropper could be able to impersonate the user at other SIP entities.
Countermeasures: By providing adequate confidentiality, eavesdropping of a SAML assertion can be stopped.
Threat: 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.
Countermeasures: 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.
Threat: A malicious user could forge or alter a SAML assertion in order to communicate with the SIP entities.
Countermeasures: 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 signature.
Threat: 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 resources.
Countermeasures: Cases where multiple requests are made which references the same request must be tracked in order to avoid the threat.
| TOC |
The authors would like to thank Henning Schulzrinne for their input to this document.
| TOC |
This document contains a number of IANA considerations. A future version of this document will list them in this section.
| TOC |
During the work on this document a number of open issues have been discovered:
| TOC |
| TOC |
| [I-D.ietf-sipping-trait-authz] | Peterson, J., "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", draft-ietf-sipping-trait-authz-00 (work in progress), February 2004 (TXT). |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| TOC |
| TOC |
| Hannes Tschofenig | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bayern 81739 | |
| Germany | |
| EMail: | Hannes.Tschofenig@siemens.com |
| Jon Peterson | |
| NeuStar, Inc. | |
| 1800 Sutter St Suite 570 | |
| Concord, CA 94520 | |
| US | |
| EMail: | jon.peterson@neustar.biz |
| James Polk | |
| Cisco | |
| 2200 East President George Bush Turnpike | |
| Richardson, Texas 75082 | |
| US | |
| EMail: | jmpolk@cisco.com |
| Douglas C. Sicker | |
| University of Colorado at Boulder | |
| ECOT 531 | |
| Boulder, CO 80309 | |
| US | |
| EMail: | douglas.sicker@colorado.edu |
| Marcus Tegnander | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bayern 81739 | |
| Germany |
| TOC |
TypeCode := 0x0001
RemainingArtifact := SourceID AssertionHandle
SourceID := 20-byte_sequence
AssertionHandle := 20-byte_sequence
The sourceID is a 20-byte sequence which is used by the destination domain to determine the identity and location of the source domain. It is assumed that the destination domain will maintain a table of sourceID values as well as URLs for the domains it is having SAML sessions with and this information is communicated out-of-band. When the destination receives the SAML artifact, it determines if the source domain belongs to a known source domain and obtains the location before sending a SAML request.
If two source domains communicating with the same target domain MUST be distinguished by unique SourceIDs. The AssertionHandle is constructed on the basis that they SHOULD not have any predictable relationship to the contents of the assertion and that it MUST be not worth the effort to reconstruct or guess the value of the AssertionHandle.
In [I-D.saml-bindings-1.1]Maler, E., Philpott, R. and P. Mishra, Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1, September 2003. section 4.1.1.8, some RECOMMENDED practices for creation of SAML artifacts are listed.
| TOC |
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.
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 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.
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.