Basic Security Profile Version 1.1

Abstract

This document defines the WS-I Basic Security Profile 1.1, based on a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.

Status of this Document

This document is a Working Group Draft; it has been accepted by the Working Group as reflecting the current state of discussions. It is a work in progress, and should not be considered authoritative or final; other documents may supersede this document.

Notice

The material contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by any of the authors or developers of this material or WS-I. The material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and WS-I hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.

IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Feedback

The Web Services-Interoperability Organization (WS-I) would like to receive input, suggestions and other feedback ("Feedback") on this work from a wide variety of industry participants to improve its quality over time.

By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an individual, and your company if you are providing Feedback on behalf of the company) will be deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner whatsoever the Feedback you provide regarding the work. You acknowledge that you have no expectation of confidentiality with respect to any Feedback you provide. You represent and warrant that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a company, you represent and warrant that you have the rights to provide Feedback on behalf of your company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all of your Feedback in a future version of the work, it may, but is not obligated to include your name (or, if you are identified as acting on behalf of your company, the name of your company) on a list of contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf you are acting, please do not provide any Feedback.

Feedback on this document should be directed to wsi_secprofile_comment@lists.ws-i.org.

Table of Contents

1. Introduction
1.1. Guiding Principles
2. Document Conventions
2.1. Security Considerations
2.2. Notational Conventions
2.3. Profile Identification and Versioning
3. Profile Conformance
3.1. Conformance Requirements
3.2. Conformance Targets
3.3. Conformance Scope
3.4. Claiming Conformance
3. Transport Layer Mechanisms
3.1. TLS and SSL Versions
3.1.1. SSL 2.0 Prohibited
3.2. TLS and SSL Ciphersuites
3.2.1. Mandatory Ciphersuites
3.2.2. Recommended Ciphersuites
3.2.3. Discouraged Ciphersuites
3.2.4. Prohibited Ciphersuites
4. SOAP Nodes and Messages
4.1. Security Policy
4.1.1. Out of Band Agreement
4.2. SOAP Envelope
4.2.1. Secure Envelope Validity
4.2.2. wsu:Id Attribute Value Uniqueness
4.3. Intermediary Processing
4.3.1. Removal of Headers
4.4. Basic Profile Clarification
4.4.1. BP Requirement R1029
4.4.2. BP Requirement R2301
4.4.3. BP Requirement R2710
4.4.4. BP Requirement R2712
4.4.5. BP Requirement R2724
4.4.6. BP Requirement R2725
4.4.7. BP Requirement R2729
4.4.8. BP Requirement R2738
5. SecurityHeaders
5.1. Processing Order
5.1.1. In Order of Appearance
5.2. SOAP Actor Attribute
5.2.1. Avoid Target Ambiguity
6. Timestamps
6.1. Placement
6.1.1. Not More Than One per Security Header
6.2. Content
6.2.1. Exactly One Created per Timestamp
6.2.2. Not More Than One Expires per Timestamp
6.2.3. Created Precedes Expires in Timestamp
6.2.4. Timestamp Contains Nothing Other Than Create and Expires
6.3. Constraints on Created and Expires
6.3.1. Value Precision to Milliseconds
6.3.2. Leap Second Values Prohibited
6.3.3. ValueType Attribute Prohibited
6.3.4. UTC Format Mandatory
7. Security Token References
7.1. Content
7.1.1. Exactly One SecurityTokenReference Child Element
7.2. TokenType Attribute
7.2.1. Value of TokenType Attribute
7.3. Direct References
7.3.1. Direct Reference to Security Token Reference Prohibited
7.3.2. Reference/@ValueType Attribute Mandatory
7.3.3. Reference/@URI Attribute Mandatory
7.4. Key Name References
7.4.1. Key Name References Prohibited
7.5. Key Identifier References
7.5.1. KeyIdentifier/@ValueType Attribute Mandatory
7.5.2. KeyIdentifier/@EncodingType Attribute Mandatory
7.6. Embedded References
7.6.1. Embedded Content
7.6.2. Embedded Token Format
7.6.3. Security Token Reference in Embedded Prohibited
7.7. Internal References
7.7.1. Direct or Embedded References Where Possible
7.7.2. Direct Preferred to Embedded References
7.7.3. Shorthand XPointers Mandatory for Direct References
7.7.4. Security Tokens Precede Their References
7.7.5. References Between Security Headers Prohibited
7.8. External References
7.8.1. Direct References Where Possible
7.9. SecurityTokenReference With EncryptedData
7.9.1. Reference to KeyInfo Prohibited
8. XML-Signature
8.1. Types of Signature
8.1.1. Enveloping Signatures Prohibited
8.1.2. Enveloped Signatures Discouraged
8.1.3. Detached Signatures Preferred
8.2. Signed Element References
8.2.1. Shorthand XPointer Where Referent has wsu:Id Attribute
8.2.2. Shorthand XPointer Where Referent is defined by XML Signature
8.2.3. Shorthand XPointer Where Referent is defined by XML Encryption
8.2.4. Shorthand XPointer to wsu:Id Attribute Where Possible
8.2.5. XPath References Where Necessary
8.3. Signature Transforms
8.3.1. Transforms Element Mandatory
8.3.2. Transform Element Mandatory
8.3.3. Transform Algorithms
8.3.4. Last Transform Algorithm
8.3.5. Inclusive Namespaces with Exclusive-C14N Transform
8.3.6. Inclusive Namespaces with STR Transform
8.3.7. TransformationParameters and CanonicalizationMethod with STR Transform
8.4. Canonicalization Methods
8.4.1. Exclusive C14N Mandatory
8.4.2. Inclusive Namespaces with Exclusive-C14N
8.5. Inclusive Namespaces
8.5.1. Order of PrefixList
8.5.2. Whitespace in PrefixList
8.5.3. PrefixList Contents
8.6. Digest Methods
8.6.1. SHA-1 Preferred
8.7. Signature Methods
8.7.1. Algorithms
8.7.2. HMACOutputLength Prohibited
8.8. KeyInfo
8.8.1. Exactly One KeyInfo Child Element
8.8.2. SecurityTokenReference Mandatory
8.9. Manifest
8.9.1. Manifest Prohibited
8.10. Signature Encryption
8.10.1. Encrypt Only Entire Signature
8.11. Signature Confirmation
8.11.1. Signature Confirmation Format
9. XML Encryption
9.1. EncryptedHeader
9.1.1. EncryptedHeader Format
9.2. Encryption ReferenceList
9.2.1. Single Key
9.2.2. Encryption DataReference for EncryptedData
9.3. EncryptedKey ReferenceList
9.3.1. EncryptedKey DataReference for EncryptedData
9.4. EncryptedKey
9.4.1. EncryptedKey Precedes EncryptedData
9.4.2. EncryptedKey ReferenceList Preferred
9.4.3. EncryptedKey/@Type Attribute Prohibited
9.4.4. EncryptedKey/@MimeType Attribute Prohibited
9.4.5. EncryptedKey/@Encoding Attribute Prohibited
9.4.6. EncryptedKey/@Recipient Attribute Prohibited
9.4.7. EncryptionMethod Mandatory
9.5. EncryptedData
9.5.1. EncryptedData and KeyInfo
9.5.2. EncryptedData/@Id Attribute Mandatory
9.5.3. EncryptedData EncryptionMethod Mandatory
9.6. Encryption KeyInfo
9.6.1. Exactly One Encryption KeyInfo Child Element
9.6.2. KeyInfo SecurityTokenReference Mandatory
9.7. Encryption DataReference
9.7.1. DataReference/@URI with Shorthand XPointer to EncryptedData
9.8. EncryptedKey DataReference
9.8.1. EncryptedKey DataReference/@URI with Shorthand XPointer to EncryptedData
9.9. Encryption KeyReference
9.9.1. KeyReference/@URI with Shorthand XPointer to EncryptedKey
9.10. EncryptedKey KeyReference
9.10.1. EncryptedKey KeyReference/@URI with Shorthand XPointer to EncryptedKey
9.11. EncryptedData EncryptionMethod
9.11.1. Data Encryption Algorithms
9.12. EncryptedKey EncryptionMethod
9.12.1. Key Transport Algorithms
9.12.2. Key Wrap Algorithms
9.12.3. Key Encryption Algorithms
9.13. Encrypted Headers
9.13.1. Encrypted Headers
10. Binary Security Tokens
10.1. Binary Security Tokens
10.1.1. BinarySecurityToken/@EncodingType Attribute Mandatory
10.1.2. BinarySecurityToken/@ValueType Attribute Mandatory
11. Username Token
11.1. Password
11.1.1. Not More Than One Password
11.1.2. Password/@Type Attribute Mandatory
11.1.3. Digest Value
11.1.4. Key Derivation
11.2. Created
11.2.1. Not More Than One Created
11.3. Nonce
11.3.1. Not More Than One Nonce
11.3.2. Nonce/@EncodingType Attribute Mandatory
11.4. SecurityTokenReference
11.4.1. UsernameToken wsse111:TokenType Value
11.4.2. UsernameToken Reference/@ValueType Attribute Value
11.4.3. UsernameToken KeyIdentifier Prohibited
12. X.509 Certificate Token
12.1. X.509 Token Types
12.1.1. X.509 Token Format
12.1.2. Certificate Path Token Types
12.1.3. PKCS7 Token Format
12.2. SecurityTokenReference
12.2.1. SecurityTokenReference to X.509 Token
12.2.2. SecurityTokenReference to PKCS7 Token
12.2.3. PkiPath Token Format
12.2.4. SecurityTokenReference to PkiPath Token
12.2.5. KeyIdentifier or X509IssuerSerial for External References
12.2.6. KeyIdentifier/@ValueType Attribute Value
12.2.7. KeyIdentifier Value
12.2.8. X509IssuerSerial Value
13. REL Token
13.1. SecurityTokenReferences
13.1.1. SecurityTokenReference to REL Token
13.1.2. Reference by licenseId Prohibited When wsu:Id Present
13.1.3. Issuer Signature on REL Token Precedes First Reference
14. Kerberos Token
14.1. Content
14.1.1. Kerberos Token Format
14.1.2. Internal Token in First Message
14.1.3. External Token in Subsequent Messages
14.2. SecurityTokenReference
14.2.1. SecurityTokenReference to Kerberos Token
14.2.2. KeyIdentifier ValueType for Kerberos
14.2.3. KeyIdentifier for External Token
15. SAML Token
15.1. KeyInfo
15.1.1. References to SAML Tokens Prohibited
15.2. SecurityTokenReference
15.2.1. SecurityTokenReference to SAML V1.1 Token
15.2.2. SecurityTokenReference to SAML V2.0 Token
15.2.3. KeyIdentifier/@ValueType Attribute
15.2.4. KeyIdentifier/@EncodingType Attribute
15.2.5. References to Internal SAML Assertions
15.2.6. References to External SAML Assertions
16. EncryptedKey Token
16.1. SecurityTokenReference
16.1.1. SecurityTokenReference to EncryptedKey Token
17. Attachment Security
17.1. SOAP with Attachments
17.1.1. Conformance
17.1.2. Relationship between Parts
17.1.3. Encryption and Root Part
17.2. Signed Attachments
17.2.1. Reference to Signed Attachments
17.2.2. Attachment Transforms
17.2.3. Canonicalization
17.2.4. Digest Values
17.2.5. Content-Type
17.3. Encrypted Attachments
17.3.1. References to Encrypted Attachments
17.3.2. Type attribute
17.3.3. Reference URIs
17.3.4. Content
18. Security Considerations
18.1. SOAPAction Header
18.1.1. SOAPAction header
18.2. Clock Synchronization
18.3. Security Token Substitution
18.3.1. Security Token Substitution
18.3.2. Security Token Reference in Subsequent Messages
18.4. Protecting against removal and modification of XML Elements
18.5. Only What is Signed is Protected
18.6. Use of SHA1
18.7. Uniqueness of ID attributes
18.8. Signing Security Tokens
18.9. Signing Username Tokens
18.10. Signing Binary Tokens
18.11. Signing XML Tokens
18.12. Replay of Username Token
18.12.1. Replay of Username Token
18.13. Use of Digest vs. Cleartext Password
18.14. Encryption with Signatures
18.14.1. Encrypt DigestValue
18.15. Possible Operational Errors
Appendix A: Referenced Specifications
Appendix B: Extensibility Points
Appendix C: Acknowledgements

1. Introduction

This document defines the WS-I Basic Security Profile 1.1 (hereafter, "Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications to and amplifications of those specifications which promote interoperability.

Section 1, "Introduction," introduces the Basic Security Profile 1.1 and relates the philosophy that it takes with regard to interoperability.

Section 2, "Document Conventions," describes notational conventions utilized by the Basic Security Profile 1.1.

Section 3, "Profile Conformance," explains what it means to be conformant to the Basic Security Profile 1.1.

Each subsequent section addresses a component of the Basic Security Profile 1.1, and consists of two parts: an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. Note that there is no relationship between the section numbers in this document and those in the referenced specifications.

1.1 Guiding Principles

The Profile was developed according to a set of principles that, together, form the philosophy of the Basic Security Profile 1.1, as it relates to bringing about interoperability. This section documents these guidelines.

No guarantee of interoperability

Although it is impossible to completely guarantee the interoperability of a particular service, the Basic Security Profile 1.1 attempts to increase interoperability by addressing the most common problems that implementation experience has revealed to date.

Focus profiling effort

The focus of the Basic Security Profile 1.1 is the specifications that are explicitly defined as in-scope for the Basic Security Profile 1.1. Other specifications are profiled to the minimal extent necessary to allow meaningful profiling of the scoped specifications. This allows an in-depth profile of the scoped specifications with reduced constraining of other specifications.

Application semantics

Although communication of application semantics can be facilitated by the technologies that comprise the Basic Security Profile 1.1, assuring the common understanding of those semantics is not addressed by it.

Testability

When possible, the Basic Security Profile 1.1 makes statements that are testable. However, such testability is not required. Preferably, testing is achieved in a non-intrusive manner (e.g., examining artifacts "on the wire"). Note: Due to the nature of cryptographic security, non-intrusive testing may not be possible.

Strength of requirements

The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate cases where such a requirement cannot be met, conditional requirements (e.g., MAY, SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce ambiguity and mismatches between implementations.

Restriction vs. relaxation

When amplifying the requirements of referenced specifications (including the Basic Profile 1.0), the Basic Security Profile 1.1 may restrict them, but does not relax them (e.g., change a MUST to a MAY).

Multiple mechanisms

If a referenced specification allows multiple mechanisms to be used interchangeably to achieve the same goal, the Basic Security Profile 1.1 selects those that are well-understood, widely implemented and useful. Extraneous or underspecified mechanisms and extensions introduce complexity and therefore reduce interoperability.

Future compatibility

When possible, the Basic Security Profile 1.1 aligns its requirements with in-progress revisions to the specifications it references. This aids implementers by enabling a graceful transition, and assures that WS-I does not 'fork' from these efforts. When the Basic Security Profile 1.1 cannot address an issue in a specification it references, this information is communicated to the appropriate body to assure its consideration.

Compatibility with deployed services

Backwards compatibility with deployed Web services is not a goal for the Basic Security Profile 1.1, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced specification unless doing so addresses specific interoperability issues.

Focus on interoperability

Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Basic Security Profile 1.1 only addresses those that affect interoperability.

Conformance targets

Where possible, the Basic Security Profile 1.1 places requirements on artifacts (e.g., WSDL descriptions, SOAP messages) rather than the producing or consuming software's behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone.

Lower-layer interoperability

The Profile speaks to interoperability at the web-services layer only; it assumes that interoperability of lower-layer protocols (e.g. TCP, HTTP) and technologies (e.g. encryption and signature algorithms) is adequate and well-understood. WS-I does not attempt to assure the interoperability of these protocols and technologies as a whole. This assures that WS-I's expertise in and focus on Web Services standards is used effectively.

Do no harm

Interoperability of security technologies does not in and of itself ensure security, and the act of combining new technologies and protocols is especially susceptible to security threats. The profile takes steps to avoid introducing new security threats.

Best Practices

It is not the intent of the Basic Security Profile 1.1 to define security best practices. However, when multiple options exist, we may use known security weaknesses as a means of reducing choice and thus enhancing interoperability. The Basic Security Profile 1.1 will offer non-normative security considerations where the authors deem appropriate; however, these are by no means exhaustive and should not be perceived as a sanctioning of a security best practice.

Selected Errata Inclusion

The Basic Security Profile 1.1 restates selected requirements from the WS-Security Errata rather than including the entire Errata by reference, preferring interoperability over strict conformance.

2. Document Conventions

This document follows conventions common to all WS-I profiles. These are described in the following sections.

2.1 Security Considerations

In addition to interoperability recommendations (which are made in Rnnnn statements and intended to improve interoperability), the Basic Security Profile 1.1 makes a number of security recommendations intended to improve security. These Security Considerations are presented as follows:

Cnnnn Statement text here.

where "nnnn" is replaced by a number that is unique among the security recommendations in the Basic Security Profile 1.1, thereby forming a unique security recommendation identifier. Each security recommendation contains a SHOULD or a MAY to highlight exactly what is being recommended; however, these recommendations are informational only and are non-normative. Though security recommendations are expected to be tested by the test tools to highlight possible security problems, security recommendations have no impact on conformance.

It should be understood that, while a number of recommendations are made about security, adherence to these security recommendations does not guarantee security.

2.2 Notational Conventions

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.

Normative statements of requirements in the Basic Security Profile 1.1 (i.e., those impacting conformance, as outlined in "Conformance Requirements") are presented in the following manner:

RnnnnStatement text here.

where "nnnn" is replaced by a number that is unique among the requirements in the Basic Security Profile 1.1, thereby forming a unique requirement identifier.

Requirement identifiers can be considered to be namespace qualified, in such a way as to be compatible with QNames from Namespaces in XML. If there is no explicit namespace prefix on a requirement's identifier (e.g., "R9999" as opposed to "bp10:R9999"), it should be interpreted as being in the namespace identified by the conformance URI of the document section it occurs in. If it is qualified, the prefix should be interpreted according to the namespace mappings in effect, as documented below.

Some requirements clarify the referenced specification(s), but do not place additional constraints upon implementations. For convenience, clarifications are annotated in the following manner: C

Some requirements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where "xxxx" is an identifier for the specification (e.g., "WSDL20" for WSDL Version 2.0). Note that because such work was not complete when this document was published, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

As noted above, some requirements may present compatibility issues (whether forwards or backwards) with previously published versions of the profile. For convenience, such requirements are annotated in the following manner: Compat

Extensibility points in underlying specifications (see "Conformance Scope") are presented in a similar manner:

EnnnnExtensibility Point Name - Description

where "nnnn" is replaced by a number that is unique among the extensibility points in the Basic Security Profile 1.1. As with requirement statements, extensibility statements can be considered namespace-qualified.

This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

• soap - "http://schemas.xmlsoap.org/soap/envelope/"
• xsd - "http://www.w3.org/2001/XMLSchema"
• wsi - "http://www.ws-i.org/schemas/conformanceClaim"
• ds - "http://www.w3.org/2000/09/xmldsig#""
• xenc - "http://www.w3.org/2001/04/xmlenc#"
• c14n - "http://www.w3.org/2001/10/xml-exc-c14n#"
• wsse - "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
• wsse11 - "http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
• wsu - "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
• b10 - "http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.htm"
• bp11 - "http://www.ws-i.org/Profiles/BasicProfile-1.1.html"
• saml - "urn:oasis:names:tc:SAML:1.0:assertion"
• samlp - "urn:oasis:names:tc:SAML:1.0:protocol"
• saml2 - "urn:oasis:names:tc:SAML:2.0:assertion"
• rel - "urn:mpeg:mpeg21:2003:01-REL-R-NS"

2.3 Profile Identification and Versioning

This document is identified by a name (in this case, Basic Security Profile) and a version number (here, 1.1). Together, they identify a particular profile instance.

Version numbers are composed of a major and minor portion, in the form "major.minor". They can be used to determine the precedence of a profile instance; a higher version number (considering both the major and minor components) indicates that an instance is more recent, and therefore supersedes earlier instances.

Instances of profiles with the same name (e.g., "Example Profile 1.1" and "Example Profile 5.0") address interoperability problems in the same general scope (although some developments may require the exact scope of a profile to change between instances).

One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one. Profile instances with the same name and major version number (e.g., "Example Profile 1.0" and "Example Profile 1.1") MAY be considered compatible. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.

3 Profile Conformance

Conformance to the Basic Security Profile 1.1 is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile. This section explains these terms and describes how conformance is defined and used.

3.1 Conformance Requirements

Requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability. All requirements in the Basic Security Profile 1.1 are considered normative, and those in the specifications it references that are in-scope (see "Conformance Scope") should likewise be considered normative. When requirements in the Basic Security Profile 1.1 and its referenced specifications contradict each other, the Basic Security Profile 1.1's requirements take precedence for purposes of Profile conformance.

Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of the requirement and its impact on conformance. Each requirement is individually identified (e.g., R9999) for convenience.

For example;

R9999 Any WIDGET SHOULD be round in shape.

This requirement is identified by "R9999", applies to the target WIDGET (see below), and places a conditional requirement upon widgets; i.e., although this requirement must be met to maintain conformance in most cases, there are some situations where there may be valid reasons for it not being met (which are explained in the requirement itself, or in its accompanying text).

Each requirement statement contains exactly one requirement level keyword (e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The conformance target keyword appears in bold text (e.g. "MESSAGE"). Other conformance targets appearing in non-bold text are being used strictly for their definition and NOT as a conformance target. Additional text may be included to illuminate a requirement or group of requirements (e.g., rationale and examples); however, prose surrounding requirement statements must not be considered in determining conformance.

Definitions of terms in the Basic Security Profile 1.1 are considered authoritative for the purposes of determining conformance.

None of the requirements in the Basic Security Profile 1.1, regardless of their conformance level, should be interpreted as limiting the ability of an otherwise conforming implementation to apply security countermeasures in response to a real or perceived threat (e.g., a denial of service attack).

3.2 Conformance Targets

Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry data) or parties (e.g., SOAP processor, end user) requirements apply to.

This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service (e.g., clients and service instances).

Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and avoid ambiguity.

The following conformance targets are used in the Basic Security Profile 1.1:

• BINARY_SECURITY_TOKEN - a SECURITY_TOKEN named wsse:BinarySecurityToken.
• CANONICALIZATION_METHOD - an element named ds:CanonicalizationMethod, included as a child of a SIGNED_INFO or a wsse:TransformationParameters child of a SIG_TRANSFORM.
• CREATED - an element named wsu:Created, included as a child of a TIMESTAMP or USERNAME_TOKEN.
• DESCRIPTION - descriptions of types, messages, interfaces and their concrete protocol and data format bindings, and the network access points associated with Web services (e.g., WSDL descriptions). (from Basic Profile 1.0)
• DIGEST_METHOD - an element named ds:DigestMethod, included as a child of a SIG_REFERENCE.
• ED_ENCRYPTION_METHOD - an element named xenc:EncryptionMethod, included as a child of an ENCRYPTED_DATA.
• EK_DATA_REFERENCE - an element named xenc:DataReference, included as a child of an EK_REFERENCE_LIST.
• EK_ENCRYPTION_METHOD - an element named xenc:EncryptionMethod, included as a child of an ENCRYPTED_KEY.
• EK_KEY_REFERENCE - an element named xenc:KeyReference, included as a child of an EK_REFERENCE_LIST.
• EK_REFERENCE_LIST - an element named xenc:ReferenceList, included as a child of an ENCRYPTED_KEY.
• ENC_DATA_REFERENCE - an element named xenc:DataReference, included as a child of an ENC_REFERENCE_LIST.
• ENC_KEY_INFO - an element named ds:KeyInfo, included as a child of an ENCRYPTED_KEY or ENCRYPTED_DATA.
• ENC_KEY_REFERENCE - an element named xenc:KeyReference, included as a child of an ENC_REFERENCE_LIST.
• ENC_REFERENCE_LIST - an element named xenc:ReferenceList, included as a child of a SECURITY_HEADER.
• ENCRYPTED_DATA - an element named xenc:EncryptedData, referenced by an EK_REFERENCE_LIST or an ENC_REFERENCE_LIST.
• ENCRYPTED_KEY - an element named xenc:EncryptedKey, included as a child of a SECURITY_HEADER.
• ENCRYPTED_KEY_TOKEN - a SECURITY_TOKEN that is an ENCRYPTED_KEY.
• EXPIRES - an element named wsu:Expires, included as a child of a TIMESTAMP.
• EXTERNAL_SAML_TOKEN - an EXTERNAL_SECURITY_TOKEN that is a SAML_TOKEN.
• EXTERNAL_SECURITY_TOKEN - a security token defined in a security token profile, not included as a descendant of a SOAP_ENVELOPE.
• EXTERNAL_TOKEN_REFERENCE - a SECURITY_TOKEN_REFERENCE that refers to an EXTERNAL_SECURITY_TOKEN.
• HEADER_ELEMENT - an element included as a child of the SOAP_HEADER.
• INCLUSIVE_NAMESPACES - an element named xc14n:InclusiveNamespaces, include as a child of a SIG_TRANSFORM or a CANONICALIZATION_METHOD.
• INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate. (from Basic Profile 1.0)
• INTERNAL_SAML_TOKEN - an INTERNAL_SECURITY_TOKEN that is a SAML_TOKEN.
• INTERNAL_SAML_V2_SECURITY_TOKEN - An INTERNAL_SECURITY_TOKEN that is a SAML_V2_0_TOKEN.
• INTERNAL_SECURITY_TOKEN - a security token defined in a security token profile, included as a child of a SECURITY_HEADER or STR_EMBEDDED.
• KERBEROS_TOKEN - a BINARY_SECURITY_TOKEN containing a GSS wrapped Kerberos v5 AP-REQ.
• MIME_BODY - the body of a multipart entity, as defined by MIME.
• MIME_HEADER - a header field of a multipart entity, as defined by MIME.
• MIME_PART - the MIME_BODY and all MIME_HEADERs associated with a single multipart entity, as defined by MIME.
• NONCE - an element named wsse:Nonce, included as a child of a USERNAME_TOKEN.
• PASSWORD - an element named wsse:Password, included as a child of a USERNAME_TOKEN.
• PKCS7_TOKEN - a BINARY_SECURITY_TOKEN containing a PKCS#7 certificate chain.
• PKIPATH_TOKEN - a BINARY_SECURITY_TOKEN containing a PkiPath certificate chain.
• RECEIVER - software that consumes a message according to the protocol(s) associated with it. A receiver is considered conformant when it is capable of consuming conformant messages containing the artifacts that it supports and its behavior is conformant with all statements related to RECEIVER in the Basic Security Profile 1.1. A conformant receiver need not accept all possible conformant messages. A conformant receiver may choose not to support artifacts that provide unneeded or undesired functionality. When a receiver supports a specific artifact, and the Basic Security Profile 1.1 contains statements related to that artifact, a conformant receiver must accept all required conformant forms of that artifact. (from Basic Profile 1.0)
• REL_TOKEN - a SECURITY_TOKEN named rel:license.
• SAML_AUTHORITY_BINDING - an element named saml:AuthorityBinding, included as a child of an SECURITY_TOKEN_REFERENCE.
• SAML_SC_KEY_INFO - an element named ds:KeyInfo, included as a child of a SAML_SUBJECT_CONFIRMATION.
• SAML_SUBJECT_CONFIRMATION - an element named saml:SubjectConfirmation, included in a SAML_TOKEN.
• SAML_TOKEN - a SECURITY_TOKEN which is a SAML_V1_1_TOKEN or a SAML_V2_0_TOKEN.
• SAML_V1_1_TOKEN - a SECURITY_TOKEN named saml:Assertion which conforms to SAML 1.1 (via the OASIS Web Services Security SAML Token Profile 1.0).
• SAML_V2_0_TOKEN - a SECURITY_TOKEN named saml2:Assertion which conforms to SAML 2.0 (via the OASIS Web Services Security SAML Token Profile 1.1).
• SECURE_ENVELOPE - a SOAP envelope that contains sub-elements that have been subject to integrity and/or confidentiality protection. A message is considered conformant when all of its contained artifacts are conformant with all statements targeted to those artifacts as appropriate in the Basic Security Profile. Use of artifacts for which there are no statements in the Basic Security Profile does not affect conformance.
• SECURE_MESSAGE - protocol elements that have Web Services Security applied to them. Protocol elements include a primary SOAP envelope and optionally associated SwA attachments.
• SECURITY_HEADER - a HEADER_ELEMENT named wsse:Security.
• SECURITY_TOKEN - an INTERNAL_SECURITY_TOKEN or EXTERNAL_SECURITY_TOKEN (e.g. USERNAME_TOKEN, X509_TOKEN, REL_TOKEN, SAML_TOKEN, SAML_V2_0_TOKEN, KERBEROS_TOKEN, etc.).
• SECURITY_TOKEN_REFERENCE - an element named wsse:SecurityTokenReference, included as a descendant of a SECURITY_HEADER or ENCRYPTED_DATA.
• SENDER - software that generates a message according to the protocol(s) associated with it. A sender is considered conformant when all of the messages it produces are conformant and its behavior is conformant with all statements related to SENDER in the Basic Security Profile 1.1. (from Basic Profile 1.0)
• SIG_KEY_INFO - an element named ds:KeyInfo, included as a child of a SIGNATURE.
• SIG_REFERENCE - an element named ds:Reference, included as a child of a SIGNED_INFO.
• SIG_TRANSFORMS - an element named ds:Transforms, included as a child of a SIG_REFERENCE.
• SIG_TRANSFORM - an element named ds:Transform, included as a child of a SIG_TRANSFORMS.
• SIGNATURE - an element named ds:Signature, included as a child of a SECURITY_HEADER.
• SIGNATURE_METHOD - an element named ds:SignatureMethod, included as a child of a SIGNED_INFO.
• SIGNED_INFO - an element named ds:SignedInfo, included as a child of a SIGNATURE.
• SOAP_ENVELOPE - an element named soap:Envelope, which has no parent element.
• SOAP_HEADER - an element named soap:Header, included as a child of the SOAP_ENVELOPE.
• STR_EMBEDDED - an element named wsse:Embedded, included as a child of a SECURITY_TOKEN_REFERENCE.
• STR_ISSUER_SERIAL - an element named ds:X509IssuerSerial, included as a child of a child element named ds:X509Data of a SECURITY_TOKEN_REFERENCE.
• STR_KEY_NAME - an element named ds:KeyName, included as a child of a SECURITY_TOKEN_REFERENCE.
• STR_KEY_IDENTIFIER - an element named wsse:KeyIdentifier, included as a child of a SECURITY_TOKEN_REFERENCE.
• STR_REFERENCE - an element named wsse:Reference, included as a child of a SECURITY_TOKEN_REFERENCE.
• TIMESTAMP - an element named wsu:Timestamp, included as a child of a SECURITY_HEADER.
• USERNAME_TOKEN - a SECURITY_TOKEN named wsse:UsernameToken.
• X509_TOKEN - a BINARY_SECURITY_TOKEN containing an X.509 certificate.

3.3 Conformance Scope

The scope of the Basic Security Profile 1.1 delineates the technologies that it addresses; in other words, the Basic Security Profile 1.1 only attempts to improve interoperability within its own scope. Generally, the Basic Security Profile 1.1's scope is bounded by the specifications referenced by it.

The Profile's scope is further refined by extensibility points. Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters; when identified in the Basic Security Profile 1.1 as an extensibility point, such a mechanism or parameter is outside the scope of the Basic Security Profile 1.1, and its use or non-use is not relevant to conformance.

Note that the Basic Security Profile 1.1 may still place requirements on the use of an extensibility point. Also, specific uses of extensibility points may be further restricted by other profiles, to improve interoperability when used in conjunction with the Basic Security Profile 1.1.

Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement.

The Profile's scope is defined by the referenced specifications in Appendix A, as refined by the extensibility points in Appendix B.

3.4 Claiming Conformance

Claims of conformance to the Basic Security Profile 1.1 can be made using the following mechanisms, as described in Conformance Claim Attachment Mechanisms, when the applicable Profile requirements associated with the listed targets have been met:

The conformance claim URI for the Basic Security Profile 1.1 is " http://ws-i.org/profiles/basic-security/1.1/core " , with the following exceptions, which are associated with specific sections:

• Transport Layer Mechanisms - "http://ws-i.org/profiles/basic-security/1.1/transport"
• Username Token - "http://ws-i.org/profiles/basic-security/1.1/username-token"
• X.509 Certificate Token - "http://ws-i.org/profiles/basic-security/1.1/x.509-certificate-token"
• REL Token - "http://ws-i.org/profiles/basic-security/1.1/rel-token"
• Kerberos Token - "http://ws-i.org/profiles/basic-security/1.1/kerberos-token"
• SAML Token - "http://ws-i.org/profiles/basic-security/1.1/saml-token"
• Attachment Security - "http://ws-i.org/profiles/basic-security/1.1/swa"

If a claim of conformance is made as described in CCAM to Basic Security Profile 1.1 (" http://ws-i.org/profiles/basic-security/1.1/core "), then the claim MUST also specify which tokens, be they BSP profile tokens or other mutually agreed upon tokens, are supported.

The conformance URI for transport level security ("http://ws-i.org/profiles/basic-security/1.1/transport") can be used in isolation or in combination with other conformance URIs.

3. Transport Layer Mechanisms

This section of the Basic Security Profile 1.1 incorporates the following specifications by reference, and defines extensibility points within them:

• RFC 2818: HTTP over TLS
• RFC 2246: The TLS Protocol Version 1.0
  Extensibility points:
  • E0009 - TLS Ciphersuites - TLS allows for the use of arbitrary encryption algorithms. Note that while section 4.2 of the Basic Security Profile 1.1 mandates, recommends, and discourages support for certain ciphersuites, the Basic Security Profile 1.1 does not prohibit use of any specific ciphersuite.
  • E0010 - TLS Extensions - TLS allows for extensions during the handshake phase.
• The SSL Protocol Version 3.0
  Extensibility points:
  • E0011 - SSL Ciphersuites - SSL allows for the use of arbitrary encryption algorithms. Note that while section 4.2 of the Basic Security Profile 1.1 mandates, recommends, and discourages support for certain ciphersuites, the Basic Security Profile 1.1 does not prohibit use of any specific ciphersuite.

3.1 TLS and SSL Versions

SSL and TLS are both used as underlying protocols for HTTP/S. The Profile places the following constraints on those protocols:

3.2 TLS and SSL Ciphersuites

In SSL and TLS, choices of algorithms are expressed as ciphersuites. The following subsections specify ciphersuites that are required, recommended, discouraged and prohibited, respectively. The use of any other ciphersuite not discussed below is optional.

4. SOAP Nodes and Messages

This section of the Basic Security Profile 1.1 incorporates the following specifications by reference, and defines extensibility points within them:

• Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) OASIS Standard Specification, 1 February 2006
  Extensibility points:
  • E0002 - Security Tokens - Security tokens may be specified in additional security token profiles.
• Basic Profile Version 1.0 (BP1.0)
• Basic Profile Version 1.0 Errata
• Basic Profile Version 1.1 (BP1.1)
• Simple SOAP Binding Profile Version 1.0 (SSBP1.0)

4.1 Security Policy

4.2 SOAP Envelope

4.3 Intermediary Processing

4.4 Basic Profile Clarification

The Basic Security Profile is an extension profile to the Basic Profile. This means it is consistent with the Basic Profile but profiles additional functionality - how to add conformant security features to the Basic Profile when needed.

As an extension of the Basic Profile, the Basic Security Profile is designed to support the addition of security functionality to SOAP messaging, in an interoperable manner. One example of such functionality is the confidentiality of selected SOAP header blocks and SOAP body elements and content through the use of OASIS Web Services Security encryption. The intent of such techniques is to change the nature of the SOAP message so that unintended parties cannot read such content. This means that the secured SOAP message is no longer obviously related to the original WSDL description, and is not intelligible without decryption. Other security mechanisms such as signatures may also modify the content of SOAP envelopes.

The Basic Profile includes requirements on the content of SOAP envelopes (or in Basic Profile 1.0 the format of SOAP messages). Testing conformance to these statements by using a "man-in-the-middle" interceptor as outlined in the WS-I Monitor Tool Functional Specification will not be possible if encryption has been applied to portions of the SOAP envelope and have not yet been decrypted. Even if interception is possible, some messages may have a different structure due to security.

Such SOAP messages still conform to the Basic Profile, since conformance to the Basic Profile means conformance once a receiver has reversed security changes introduced by a message sender. This is not obvious in some Basic Profile requirements, so this document further clarifies these requirements in the normative "Basic Profile Clarifications" section below.

It is helpful to visualize a SOAP message in light of a protocol layering model, such as the ISO seven layer protocol model [ Tanenbaum ]. This model shows how a protocol is in fact composed of different layers, and how to a given layer underlying layers are transparent. The implementation of a given protocol layer at an endpoint may be modeled as that implementation consuming a service of the underlying protocol layer, and providing a service to the layer above it. In this model no protocol layer need be aware of layers above or below it, making the layer implementations independent. This is illustrated in Figure 1.

Figure 1: Protocol Stack with SOAP Message Security

Traditionally, protocol layers have been distinguished by the use of protocol enveloping, where the message at one layer is conveyed as the body in the next lower layer. The sender passes a message to the lower level protocol implementation that packages it in a protocol envelope and sends it to the corresponding layer in the receiver. The sender and receiver at this lower layer perform whatever processing is necessary for delivery according to the specification of that layer, and finally the receiver passes the message up to the peer of the sender.

SOAP Security may be viewed as a lower layer with respect to the more general SOAP web services application layer. Thus a SOAP sender may pass a SOAP message to a lower layer SOAP security implementation that applies encryption (for example), and sends the message to the destination SOAP Security layer, which removes the encryption before passing the message up to the peer SOAP web services application layer.

Thus a Basic Profile interceptor and compliance monitoring activity should logically occur at a receiver at the interface between the SOAP security implementation and SOAP web services application layer.

This section clarifies the BP1.0 (including Errata), BP1.1, SSBP1.0, and AP1.0 statements that might be unclear when SOAP Message Security is applied in compliance with the Basic Security Profile.

This section lists each possibly confusing BP1.0, BP1.1, SSBP1.0, and AP1.0 requirement and an associated statement to clarify that requirement in the context of the basic security profile.

When these clarifying statements include the phrase "reverse SOAP Message Security" it means to remove various impacts of applying SOAP Message Security that may have been applied since the MESSAGE (BP1.0) or ENVELOPE (BP 1.1) was originally created for that recipient according to the BP. This may mean decrypting relevant portions of the XML or removing XML Signature elements or making other reverse transformations as appropriate to the aspects of SOAP Message Security that were applied in the specific circumstance.

Not all security must be reversed, only that for the intended recipient, as applied to the BP compliant envelope before sent to that recipient.

5. SecurityHeaders

5.1 Processing Order

Web Services Security: SOAP Message Security defines the order for processing elements within wsse:Security headers. The Profile provides the following guidance:

5.2 SOAP Actor Attribute

SOAP defines an actor attribute for use in SOAP headers. The Profile places the following constraints on its use with Security headers:

6. Timestamps

Web Services Security: SOAP Message Security defines a Timestamp element for use in SOAP messages. The Profile places the following constraints on its use:

6.1 Placement

6.2 Content

<!-- This example is incorrect because the wsu:Timestamp element is missing a wsu:Created child element -->
<wsu:Timestamp wsu:Id="timestamp">
   <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
</wsu:Timestamp>

<wsu:Timestamp wsu:Id="timestamp">
   <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
   <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
</wsu:Timestamp>

6.3 Constraints on Created and Expires

7. Security Token References

7.1 Content

7.2 TokenType Attribute

7.3 Direct References

<!-- This example is incorrect because the second wsse:SecurityTokenReference element refers to the 
     wsse:SecurityTokenReference with an wsu:Id of TheFirstSTR  -->
<wsse:BinarySecurityToken wsu:Id='SomeCert'
                          ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                          EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
</wsse:BinarySecurityToken>
<wsse:SecurityTokenReference wsu:Id="TheFirstSTR">
   <wsse:Reference URI='#SomeCert'
                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>
<wsse:SecurityTokenReference>
   <wsse:Reference URI='#TheFirstSTR'
                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>

<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCert">
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
   </wsse:Embedded>
</wsse:SecurityTokenReference>
<wsse:SecurityTokenReference>
   <wsse:Reference URI='#SomeCert'
                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>

7.4 Key Name References

<!-- This example is incorrect because it uses a ds:KeyName element to refer to an X.509 certificate  -->
<wsse:SecurityTokenReference>
   <ds:KeyName>CN=Security WG, OU=BSP, O=WS-I, C=US</ds:KeyName>
</wsse:SecurityTokenReference>

7.5 Key Identifier References

<!-- This example is incorrect because the wsse:KeyIdentifier element is missing a ValueType attribute -->
<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
      MIGfMa0GCSq
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                       ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" >
      MIGfMa0GCSq
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

<!-- This example is incorrect because the wsse:KeyIdentifier element is missing an EncodingType attribute -->
<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier ValueType="http