WS-Trust 1.3
Committee Draft 01, 06 September 2006
Artifact Identifier:
ws-trust-1.3-spec-cd-01
Location:
Current: docs.oasis-open.org/ws-sx/ws-trust/200512
This Version: docs.oasis-open.org/ws-sx/ws-trust/200512
Previous Version: N/A
Artifact Type:
specification
Technical Committee:
OASIS Web Service Secure Exchange TC
Chair(s):
Kelvin Lawrence, IBM
Chris Kaler, Microsoft
Editor(s):
Anthony Nadalin, IBM
Marc Goodner, Microsoft
Martin Gudgin, Microsoft
Abbie Barbir, Nortel
Hans Granqvist, VeriSign
OASIS Conceptual Model topic area:
Related work:
N/A
Abstract:
This specification defines extensions that build on [WS-Security] to
provide a framework for requesting and issuing security tokens, and to broker
trust relationships.
Status:
This document was last revised or approved by the WS-SX TC on
the above date. The level of approval is also listed above. Check the current
location noted above for possible later revisions of this document. This
document is updated periodically on no particular schedule.
Technical Committee members should send comments on this
specification to the Technical Committee’s email list. Others should send
comments to the Technical Committee by using the “Send A Comment” button on the
Technical Committee’s web page at http://www.oasis-open.org/committees/ws-sx.
For information on whether any patents have been disclosed
that may be essential to implementing this specification, and any offers of
patent licensing terms, please refer to the Intellectual Property Rights
section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-sx/ipr.php).
The non-normative errata page for this specification is
located at http://www.oasis-open.org/committees/ws-sx.
Copyright © OASIS Open 2006. All Rights Reserved.
All capitalized terms in the following text have the
meanings assigned to them in the OASIS Intellectual Property Rights Policy (the
"OASIS IPR Policy"). The full Policy may be found at the OASIS
website.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published, and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this section are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, including by removing the copyright notice or references to OASIS,
except as needed for the purpose of developing any document or deliverable
produced by an OASIS Technical Committee (in which case the rules applicable to
copyrights, as set forth in the OASIS IPR Policy, must be followed) or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that
believes it has patent claims that would necessarily be infringed by
implementations of this OASIS Committee Specification or OASIS Standard, to
notify OASIS TC Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner consistent with the IPR
Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC
Administrator if it is aware of a claim of ownership of any patent claims that
would necessarily be infringed by implementations of this specification by a
patent holder that is not willing to provide a license to such patent claims in
a manner consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification. OASIS may include such claims on its website, but
disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of
any intellectual property 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;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS' procedures with respect to rights in any document
or deliverable produced by an OASIS Technical Committee can be found on the
OASIS website. Copies of claims of rights made available for publication 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 OASIS Committee Specification or OASIS
Standard, can be obtained from the OASIS TC Administrator. OASIS makes no
representation that any information or list of intellectual property rights
will at any time be complete, or that any claims in such list are, in fact,
Essential Claims.
1 Introduction. 5
1.1 Goals
and Non-Goals. 5
1.2
Requirements. 6
1.3
Namespace. 6
1.4 Schema
and WSDL Files. 7
1.5
Terminology. 7
1.5.1
Notational Conventions. 8
1.6
Normative References. 9
1.7
Non-Normative References. 10
2 Web
Services Trust Model 11
2.1 Models
for Trust Brokering and Assessment 12
2.2 Token
Acquisition. 12
2.3
Out-of-Band Token Acquisition. 13
2.4 Trust
Bootstrap. 13
3 Security
Token Service Framework. 14
3.1
Requesting a Security Token. 14
3.2
Returning a Security Token. 15
3.3 Binary
Secrets. 17
3.4
Composition. 17
4 Issuance
Binding. 19
4.1
Requesting a Security Token. 19
4.2 Request
Security Token Collection. 21
4.2.1 Processing
Rules. 23
4.3
Returning a Security Token. 23
4.3.1
wsp:AppliesTo in RST and RSTR. 25
4.3.2
Requested References. 26
4.3.3 Keys
and Entropy. 26
4.3.4
Returning Computed Keys. 27
4.3.5 Sample
Response with Encrypted Secret 27
4.3.6 Sample
Response with Unencrypted Secret 28
4.3.7 Sample
Response with Token Reference. 28
4.3.8 Sample
Response without Proof-of-Possession Token. 29
4.3.9 Zero
or One Proof-of-Possession Token Case. 29
4.3.10 More
Than One Proof-of-Possession Tokens Case. 29
4.4 Returning Security Tokens in Headers. 30
5 Renewal
Binding. 33
6 Cancel
Binding. 36
6.1
STS-initiated Cancel Binding. 37
7 Validation
Binding. 39
8 Negotiation
and Challenge Extensions. 42
8.1
Negotiation and Challenge Framework. 43
8.2
Signature Challenges. 43
8.3 Binary
Exchanges and Negotiations. 44
8.4 Key
Exchange Tokens. 45
8.5 Custom
Exchanges. 46
8.6
Signature Challenge Example. 46
8.7 Custom
Exchange Example. 48
8.8
Protecting Exchanges. 49
8.9
Authenticating Exchanges. 50
9 Key
and Token Parameter Extensions. 51
9.1
On-Behalf-Of Parameters. 51
9.2 Key and
Encryption Requirements. 51
9.3
Delegation and Forwarding Requirements. 56
9.4 Policies. 57
9.5
Authorized Token Participants. 57
10 Key
Exchange Token Binding. 59
11 Error
Handling. 61
12 Security
Considerations. 62
A. Key
Exchange. 64
A.1 Ephemeral
Encryption Keys. 64
A.2
Requestor-Provided Keys. 64
A.3
Issuer-Provided Keys. 65
A.4
Composite Keys. 65
A.5 Key
Transfer and Distribution. 66
A.5.1 Direct
Key Transfer 66
A.5.2
Brokered Key Distribution. 66
A.5.3
Delegated Key Transfer 67
A.5.4
Authenticated Request/Reply Key Transfer 68
A.6 Perfect
Forward Secrecy. 69
B. WSDL. 70
C. Acknowledgements. 72
[WS-Security] defines the basic mechanisms for providing
secure messaging. This specification uses these base mechanisms and defines
additional primitives and extensions for security token exchange to enable the
issuance and dissemination of credentials within different trust domains.
In order to secure
a communication between two parties, the two parties must exchange security
credentials (either directly or indirectly). However, each party needs to
determine if they can "trust" the asserted credentials of the other
party.
In this
specification we define extensions to [WS-Security]
that provide:
·
Methods for
issuing, renewing, and validating security tokens.
·
Ways to establish
assess the presence of, and broker trust relationships.
Using these
extensions, applications can engage in secure communication designed to work
with the general Web services framework, including WSDL service descriptions,
UDDI businessServices and bindingTemplates, and [SOAP]
[SOAP2] messages.
To achieve this,
this specification introduces a number of elements that are used to request
security tokens and broker trust relationships.
This specification
defines a number of extensions; compliant services are NOT REQUIRED to
implement everything defined in this specification. However, if a service
implements an aspect of the specification, it MUST comply with the requirements
specified (e.g. related "MUST" statements).
Section 12 is
non-normative.
The goal of WS-Trust
is to enable applications to construct trusted [SOAP]
message exchanges. This trust is represented through the exchange and brokering
of security tokens. This specification provides a protocol agnostic way to
issue, renew, and validate these security tokens.
This specification
is intended to provide a flexible set of mechanisms that can be used to support
a range of security protocols; this specification intentionally does not
describe explicit fixed security protocols.
As with every
security protocol, significant efforts must be applied to ensure that specific
profiles and message exchanges constructed using WS-Trust are not vulnerable to
attacks (or at least that the attacks are understood).
The following are
explicit non-goals for this document:
·
Password
authentication
·
Token revocation
·
Management of
trust policies
Additionally, the
following topics are outside the scope of this document:
·
Establishing a
security context token
·
Key derivation
The Web services trust
specification must support a wide variety of security models. The following
list identifies the key driving requirements for this specification:
·
Requesting and
obtaining security tokens
·
Establishing,
managing and assessing trust relationships
The [URI] that MUST be used by implementations of this
specification is:
http://docs.oasis-open.org/ws-sx/ws-trust/200512
Table 1 lists XML
namespaces that are used in this specification. The choice of any namespace
prefix is arbitrary and not semantically significant.
Table 1: Prefixes and XML
Namespaces used in this specification.
1.4 Schema
and WSDL Files
The schema [XML-Schema1], [XML-Schema2] for
this specification can be located at:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust.xsd
The WSDL for this
specification can be located in Appendix II of this document as well as at:
http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust.wsdl
In this document, reference is made to the wsu:Id attribute, wsu:Created
and wsu:Expires elements in the utility schema.
These were added to the utility schema with the intent that other
specifications requiring such an ID or timestamp could reference it (as is done
here).
Claim – A claim
is a statement made about a client, service or other resource (e.g. name,
identity, key, group, privilege, capability, etc.).
Security Token – A security token
represents a collection of claims.
Signed
Security Token – A
signed security token is a security token that is cryptographically
endorsed by a specific authority (e.g. an X.509 certificate or a Kerberos
ticket).
Proof-of-Possession
Token – A proof-of-possession (POP) token is a security token that
contains secret data that can be used to demonstrate authorized use of an
associated security token. Typically, although not exclusively, the
proof-of-possession information is encrypted with a key known only to the
recipient of the POP token.
Digest – A digest
is a cryptographic checksum of an octet stream.
Signature – A signature
is a value computed with a cryptographic algorithm and bound to data in such a
way that intended recipients of the data can use the signature to verify that
the data has not been altered and/or has originated from the signer of the
message, providing message integrity and authentication. The signature can be
computed and verified with symmetric key algorithms, where the same key is used
for signing and verifying, or with asymmetric key algorithms, where different
keys are used for signing and verifying (a private and public key pair are
used).
Security
Token Service – A security token service (STS) is a Web service that issues
security tokens (see [WS-Security]). That is, it
makes assertions based on evidence that it trusts, to whoever trusts it (or to
specific recipients). To communicate trust, a service requires proof, such as
a signature to prove knowledge of a security token or set of security tokens. A
service itself can generate tokens or it can rely on a separate STS to issue a
security token with its own trust statement (note that for some security token
formats this can just be a re-issuance or co-signature). This forms the basis
of trust brokering.
Trust – Trust is the
characteristic that one entity is willing to rely upon a second entity to
execute a set of actions and/or to make set of assertions about a set of
subjects and/or scopes.
Direct
Trust – Direct trust is when a relying party accepts as true all
(or some subset of) the claims in the token sent by the requestor.
Direct
Brokered Trust – Direct Brokered Trust is when one party trusts a second
party who, in turn, trusts or vouches for, a third party.
Indirect
Brokered Trust – Indirect Brokered Trust is a variation on direct brokered
trust where the second party negotiates with the third party, or additional
parties, to assess the trust of the third party.
Message
Freshness – Message
freshness is the process of verifying that the message has not been
replayed and is currently valid.
We provide basic
definitions for the security terminology used in this specification. Note that
readers should be familiar with the [WS-Security]
specification.
The keywords
"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].
Namespace URIs of
the general form "some-URI" represents some application-dependent or
context-dependent URI as defined in [URI ].
This specification
uses the following syntax to define outlines for messages:
·
The syntax appears
as an XML instance, but values in italics indicate data types instead of
literal values.
·
Characters are
appended to elements and attributes to indicate cardinality:
o
"?" (0
or 1)
o
"*" (0
or more)
o
"+" (1
or more)
·
The character
"|" is used to indicate a choice between alternatives.
·
The characters
"(" and ")" are used to indicate that contained items are
to be treated as a group with respect to cardinality or choice.
·
The characters
"[" and "]" are used to call out references and property
names.
·
Ellipses (i.e.,
"...") indicate points of extensibility. Additional children and/or
attributes MAY be added at the indicated extension points but MUST NOT
contradict the semantics of the parent and/or owner, respectively. By default,
if a receiver does not recognize an extension, the receiver SHOULD ignore the
extension; exceptions to this processing rule, if any, are clearly indicated
below.
·
XML namespace prefixes
(see Table 1) are used to indicate the namespace of the element
being defined.
Elements and Attributes defined by
this specification are referred to in the text of this document using XPath 1.0
expressions. Extensibility points are referred to using an extended version of
this syntax:
- An element extensibility point is
referred to using {any} in place of the element name. This indicates that
any element name can be used, from any namespace other than the namespace
of this specification.
- An attribute extensibility point is
referred to using @{any} in place of the attribute name. This indicates
that any attribute name can be used, from any namespace other than the namespace
of this specification.
In this document
reference is made to the wsu:Id
attribute and the wsu:Created and wsu:Expires elements in a utility schema (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd).
The wsu:Id attribute and the wsu:Created and
wsu:Expires elements were added to the utility schema with the
intent that other specifications requiring such an ID type attribute or
timestamp element could reference it (as is done here).
1.6 Normative References
[RFC2119] S.
Bradner, "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, Harvard University, March 1997.
http://www.ietf.org/rfc/rfc2119.txt.
[RFC2246] IETF Standard,
"The TLS Protocol", January 1999.
http://www.ietf.org/rfc/rfc2246.txt.
[SOAP] W3C Note, "SOAP:
Simple Object Access Protocol 1.1", 08 May 2000.
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
[SOAP12] W3C
Recommendation, "SOAP 1.2 Part 1: Messaging Framework", 24 June 2003.
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
[URI] T. Berners-Lee,
R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic
Syntax", RFC 3986, MIT/LCS, Day Software, Adobe Systems, January 2005.
http://www.ietf.org/rfc/rfc3986.txt
[WS-Addressing] W3C Recommendation, "Web Services
Addressing (WS-Addressing)", 9 May 2006.
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509.
[WS-Policy] W3C Member
Submission, "Web Services Policy 1.2 - Framework", 25 April 2006.
http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/
[WS-PolicyAttachment] W3C Member Submission, "Web Services
Policy 1.2 - Attachment", 25 April 2006.
http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment-20060425/
[WS-Security] OASIS Standard,
"OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security
2004)", March 2004.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
OASIS Standard, "OASIS Web Services
Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006.
http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf
[XML-C14N] W3C
Recommendation, "Canonical XML Version 1.0", 15 March 2001.
http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
[XML-Encrypt] W3C Recommendation,
"XML Encryption Syntax and Processing", 10 December 2002.
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
[XML-Schema1] W3C
Recommendation, "XML Schema Part 1: Structures Second Edition", 28
October 2004.
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.
[XML-Schema2] W3C Recommendation, "XML Schema Part
2: Datatypes Second Edition", 28 October 2004.
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
[XML-Signature] W3C Recommendation,
"XML-Signature Syntax and Processing", 12 February 2002.
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
[Kerberos]
J. Kohl and C. Neuman, "The Kerberos Network 149 Authentication Service
(V5)," RFC 1510, September 1993.
http://www.ietf.org/rfc/rfc1510.txt
[WS-Federation] "Web Services Federation
Language," BEA, IBM, Microsoft, RSA Security, VeriSign, July 2003.
[WS-SecurityPolicy]
OASIS Committee Draft, “WS-SecurityPolicy 1.2”, September 2006
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
[X509] S. Santesson, et al,"Internet
X.509 Public Key Infrastructure Qualified Certificates Profile."
http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.509-200003-I
2 Web
Services Trust Model
The Web service
security model defined in WS-Trust is based on a process in which a Web service
can require that an incoming message prove a set of claims (e.g., name, key,
permission, capability, etc.). If a message arrives without having the
required proof of claims, the service SHOULD ignore or reject the message. A
service can indicate its required claims and related information in its policy
as described by [WS-Policy] and [WS-PolicyAttachment] specifications.
Authentication of
requests is based on a combination of optional network and transport-provided
security and information (claims) proven in the message. Requestors can
authenticate recipients using network
