http://docs.oasis-open.org/ws-sx/issues/
WS-SX TC Issues List
Date: 2006/02/27
Revision: 09
spec
schema
soap
wsdl
policy
all
New
Active
Pending
Review
Deferred
Closed
Dropped
Revocation versus cancelation of security tokens
The specification is not clear in the difference between revocation and canceling a security token.
Assume the following scenario:
A WS consumer requests a token from a STS and includes the token in a SOAP message sent to the WS provider.
Now the WS consumer may cancel the token at any point of time. The specification does not state the consequences
of canceling a token.
During our discussion, we came to following clarification:
The cancel operation is a purely local operation on the STS. After canceling a token, a STS MUST not validate
or renew the token. A STS MAY initiate the revocation of a token, however, revocation is out of scope of this
specification and a client MUST not rely on it.
ws-trust
ws-trust
spec
editorial
Martijn DeBoer
Editors
I'd suggest the following wording for clarification for "chapter 8: Cancel Binding":
Cancel - When a previously issued token is no longer needed, the Cancel binding can be used to cancel
the token.
After canceling a token at the issuer, a STS MUST not validate or renew the token. A STS MAY
initiate the revocation of a token, however, revocation is out of scope of this specification and a client
MUST NOT rely on it.
If a client needs to ensure the validity of a token, it must validate the token at the
issuer.
Proposal 1 accepted on Jan 11 TC call
Moved to review at Jan 18th TC call based on changes in ws-trust ed-01-r3
Moved to closed at Jan 25th TC call.
Signed parts clarifications
Section 5.1
Not clear with signed parts when you sign the body you can't sign the pieces
No way to sign a child element of body, need to use signed elements for that
ws-sp
spec
editorial
First F2F
Closed as duplicate of i011 on Jan 11 TC call
i011
Use of term "binding" in specs
Evaluate the use of the term binding in the specs.
ws-sc
ws-sp
ws-trust
spec
editorial
First F2F
Prateek Mishra
Line 228 - Add "Note that services might accept messages containing more
tokens than those specified in policy" as a second sentence.
Line 229 - Change to read "Any necessary key transport mechanisms"
Line 230 - Change to read "Any required message elements (e.g.
timestamps) in the wsse:Security header."
Line 233 - Remove this bullet.
Add a new bullet ( after line 232 ) that reads;
"Various parameters, including those describing the algorithms to be
used for canonicalization, signing and encryption."
Proposal 1 accepted on Feb 22nd TC call.
Transitive closure spec dependencies
Transitive closure spec dependencies
ws-sc
ws-sp
ws-trust
spec
editorial
First F2F
Paul Cotton
OASIS formatted specs
Editors to produce OASIS template formatted version and provide docs before Jan. 11th meeting.
ws-sc
ws-sp
ws-trust
spec
editorial
First F2F
Tony Nadalin
Editors completed and status changed to review per Jan 11 TC call
Moved to closed at Jan 25th TC call.
Adopt errata of SP into initial drafts
Editors to incorporate errata of WS-SP included in the contribution into initial draft before Jan. 11th meeting.
ws-sp
spec
editorial
First F2F
Tony Nadalin
Editors completed and status changed to review per Jan 11 TC call
Moved to closed at Jan 25th TC call.
i005
Put schema and wsdl in well identified place
Editors to put schema and wsdl in well identified place.
ws-sc
ws-sp
ws-trust
schema
wsdl
editorial
First F2F
Tony Nadalin
Editors completed and status changed to review per Jan 11 TC call
Moved to closed at Jan 25th TC call.
i005
Need well formed XML examples
OASIS requirement
Need to pull out all examples as separate files
ws-sc
ws-sp
ws-trust
spec
editorial
First F2F
Editors
Support for different key pairs for sign and encrypt in SP
Support for different key pairs for sign and encrypt in SP should be allowed in asymmetric binding.
See discussion thread.
ws-sp
spec
design
First F2F
Hal Lockhart
This proposal is intended to allow the Asymmetric Binding to permit the
use of distinct key pairs for encryption and signing.
Replace the text at the beginning of WS-SP section 8.5:
The AsymmetricBinding assertion is used in scenarios in which message
protection is provided by means defined in WSS: SOAP Message Security.
This binding has two binding specific token properties; [Initiator
Token] and [Recipient Token]. If the message pattern requires multiple
messages, this binding defines that the [Initiator Token] is used for
the message signature from initiator to the recipient, and for
encryption from recipient to initiator. The [Recipient Token] is used
for encryption from initiator to recipient, and for the message
signature from recipient to initiator.
With:
The AsymmetricBinding assertion is used in scenarios in which message
protection is provided by means defined in WSS: SOAP Message Security
using asymmetric key (Public Key) technology. Commonly used asymmetric
algorithms, such as RSA, allow the same key pair to be used for both
encryption and signature. However it is also common practice to use
distinct keys for encryption and signature, because of their different
lifecycles.
This binding enables either of these practices by means of four binding
specific token properties: [Initiator Token], [Recipient Token],
[Initiator Signature Token], [Initiator Encryption Token], [Recipient
Signature Token] and [Recipient Encryption Token].
If the same key pair is used for signature and encryption, the
[Initiator Token] and [Recipient Token] properties are used. If the
message pattern requires multiple messages, this binding defines that
the [Initiator Token] is used for the message signature from initiator
to the recipient, and for encryption from recipient to initiator. The
[Recipient Token] is used for encryption from initiator to recipient,
and for the message signature from recipient to initiator.
If distinct key pairs are used for signature and encryption, the
[Initiator Signature Token], [Initiator Encryption Token], [Recipient
Signature Token] and [Recipient Encryption Token] properties are used.
If the message pattern requires multiple messages, the [Initiator
Signature Token] is used for the message signature from initiator to the
recipient. The [Initiator Encryption Token is used for the response
message encryption from recipient to the initiator. The [Recipient
Signature Token] is used for the response message signature from
recipient to the initiator. The [Recipient Encryption Token is used for
the message encryption from initiator to the recipient. Note that in
each case, the token is associated with the party (initiator or
recipient) who knows the secret.
Immediately below the text:
/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy
The policy contained here MUST identify one or more token
assertions.
Insert:
/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorSignatureToken
This assertion indicates a requirement for an Initiator Signature
Token. The specified token populates the [Initiator Signature Token]
property and is used for the message signature from initiator to
recipient.
/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorSignatureToken/wsp:Policy
The policy contained here MUST identify one or more token assertions.
/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken
This assertion indicates a requirement for an Initiator Encryption
Token. The specified token populates the [Initiator Encryption Token]
property and is used for the message encryption from recipient to
initiator.
/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken/wsp:Policy
The policy contained here MUST identify one or more token assertions.
/sp:AsymmetricBinding/wsp:Policy/sp:RecipientSignatureToken
This assertion indicates a requirement for a Recipient Signature Token.
The specified token populates the [Recipient Signature Token] property
and is used for the message signature from recipient to initiator.
/sp:AsymmetricBinding/wsp:Policy/sp:RecipientSignatureToken/wsp:Policy
The policy contained here MUST identify one or more token assertions.
/sp:AsymmetricBinding/wsp:Policy/sp:RecipientEncryptionToken
This assertion indicates a requirement for a Recipient Encryption
Token. The specified token populates the [Recipient Encryption Token]
property and is used for encryption from initiator to recipient.
/sp:AsymmetricBinding/wsp:Policy/sp:RecipientEncryptionToken/wsp:Policy
The policy contained here MUST identify one or more token assertions.
Proof of possesion for security intermediaries
How does a security intermediary presents a sec token? How does it provide proof of possession
of that token in the current message structure?
ws-trust
spec
design
Prateek Mishra
Prateek Mishra
WS-SX Charter XPath reqts and WS-SecurityPolicy use of XPath (5.1, 5.2) appear in conflict
The WS-SX Charter states on lines 212-222 (red-lined version from WS-SX F2F):
"This work will specifically define the following:
1. Mechanism for specifying what parts of the message must
be secured, called protection assertions
a. Such protection assertions must be able to specify
integrity requirements at both the element and
header/body level in a security policy binding
(defined below) neutral manner.
b. Such protection assertions must be able to specify
confidentiality requirements at both the element and
header/body level in a security policy binding
(defined below) neutral manner.
c. Such mechanisms must not require the use of XPath [21]
but may provide it as an option."
I think this clearly states that a mechanism will be defined that is
able to specify integrity and confidentiality requirements at an
element level without using XPath.
However, section 5.1 of WS-SecurityPolicy states:
"5.1 Integrity Assertions
Two mechanisms are defined for specifying the set of
message parts to integrity protect.
One uses QNames to specify either message headers or
the message body while the other uses XPath expressions
to identify any part of the message."
A similar introduction exists in section 5.2 and in both sections the
followup text elaborates consistent with introductions.
My interpretation is that this is inconsistent with part c of the quoted
text from the charter above, because neither mechanism allows the
the addressing at the element level without XPath (the first does not
allow element addressing at all, the second uses XPath).
Finally, what raised my concern in the first place was that I was looking
for an element-specific non-XPath mechanism, which I thought would
be described in section 5.1.1. I read the text several times, but only
at the meeting when it was stated that SignedParts only applied to
the Body as a whole did I realize that the text then was consistent.
However, if only the Body can be addressed this does not meet the
requirement of part a. in the quote from the charter above.
Assuming my interpretation is correct, my suggestion is to either:
1. loosen the restriction in part c to say a mechanism such as
XPath may be required
or
2. add a 3rd mechanism to sections 5.1, 5.2
My concern also is that I am not aware of any 3rd mechanism.
Possibly wsu:Id or xml:id could be inserted to a target element,
but that might cause xml validation issues.
ws-sp
spec
editorial
Richard Levinson
Frederick Hirsch
Initial mail from Frederick,
prepared as charter clarification during Jan 18th TC call.
Closed with new ballot for charter clarification drafted per proposal 1 with typo corrections during
Jan 18th TC call.
Chairs have action (ai-08) to start a new ballot.
Examples should have <ds:SignatureValue> subelement, not <ds:Signature>
While going over some details I noticed that it appears that each <ds:Signature>
in the examples contains <ds:Signature>...</ds:Signature>. This should probably
be <ds:SignatureValue>...<ds:SignatureValue>.
See lines: 2376, 2604, 2626, 2751, 2973, 2990, 3124
ws-sp
ws-sp
spec
editorial
Richard Levinson
Editors
Assuming the issue is correct change the tag names to ds:SignatureValue
Assigned to editors to make proposed change on
Jan 11 TC call
Moved to review based at Jan 18th TC call on changes in ws-sp ed-01-r3
Moved to closed at Jan 25th TC call.
Add the OASIS boilerplate to the XSD and WSDL files
OASIS boilerplate (license, etc.) needs to be added to the XSD and WSDL files
ws-sc
ws-sp
ws-trust
schema
wsdl
editorial
Jan 11 TC call
Editors
Editors prepared new drafts as
oasis-wssx-ws-trust-1.0.xsd,
oasis-wssx-ws-trust-1.0.wsdl
oasis-wssx-ws-secureconversation.xsd
Proposal 1 accepted at Jan 18th TC call, status changed to review.
Moved to closed at Jan 25th TC call.
Is the key agreement algorithm proposed in WS-Trust sound?
Section 6.2.4 proposes the use of P_SHA-1 algorithm taken from rfc
2246 (TLS 1.0) for implementing a key agreement protocol.
However, key agreement in rfc 2246 involves a somewhat different
construction which uses P_SHA-1 only as a sub-component.
(1) Is there an analysis or other material available to support the use
of P_SHA-1 as proposed in WS-Trust?
(2) P_SHA-1 is an iterative method that could theoretically generate
keying material of unbounded size. It would seem that there would
need to be some constraints on the sizes of Ent(req), Ent(resp) and the
computed key. For example, would Ent(req) and Ent(resp) be
required to be at least 160 bits? And, if so, what then would be the
recommended size of the computed key?
ws-trust
spec
design
Prateek Mishra
Prateek Mishra
Close with no action. "Chris suggested the only change would be to add a new derived key
algorithm based on P-SHA256. Prateek agreed this was orthogonal."
Proposal 1 made and accepted on Feb. 8 TC call.
Support error handling in RequestSecurityToken extension
mechanism
The extension mechanism in the RequestSecurityToken and the RequestSecurityTokenResponse require the
recipient fault if an attribute or an element is found that is not understood. The recipient can
be required to return the attribute(s) or element(s) that it doesn't understand in defined format
in the fault message. The error information can help cross vendor interoperability and even among
different versions of the same vendor implementation. An implementation potentially can fall back
to a mode of operation that does not use new extensions.
Draft proposal: The recipient returns attribute name(s) and element name(s) that it doesn't understand in the fault message.
ws-trust
spec
design
C.Y. Chao
C.Y. Chao
From C.Y. Chao:
WS-Trust line 367-368 (also 369-371, 430-432, and 433-435)
Like ". . . If an element is found that is not understood, the recipient should fault. The recipient should list unrecognized elements and attributes in the detail element."
Line 2058-2067 Error Handling section, add
Error that occurred (faultstring) Unrecognized extensions found
Fault code (faultcode) wst:UnknownExtension
Fault detail (detail) . . .
<UnknownElement>element name</UnknownElement>
<UnknownAttribute>attribute name</UnknownAttribute>
Close with no action.
Agreed to proposal 2, close with no action, on feb 22nd Tc call.
sp:SignedParts mechanism
Should the sp:SignedParts mechanism (lines 592-605) allow specification
of header elements targeted to a specific s11:actor or s12:role?
ws-sp
spec
design
Michael McIntosh
Michael McIntosh
Section 4.1.1 SignedParts provides a mechanism to specify which "parts" of
a message are required to be integrity protected. The current text
indicates that, for the sp:SignedParts element, "If no child elements are
specified, all message headers targeted at the UltimateReceiver role
[SOAP12] or actor [SOAP11] and the body of the message MUST be integrity
protected." However, it isn't clear whether sp:Header elements, when
specified, impact all matching header elements or only those targeted at
the UltimateReceiver. Also, there is currently no way to specify that a
header not targeted to UltimateReceiver must be signed.
Proposal:
@ Line 575
Syntax
<sp:SignedParts ...="" >
<sp:Body />?
<sp:Header Name="xs:NCName"? Namespace="xs:anyURI" Target="xs:anyURI" ...="" />*
...
</sp:SignedParts>
@ Line 599
/sp:SignedParts/sp:Header/@Name
This optional attribute indicates the local name of the SOAP header to be
integrity protected. If this attribute is not specified, all SOAP headers
whose namespace and target match the Namespace and Target attributes are
to be protected.
/sp:SignedParts/sp:Header/@Namespace
This required attribute indicates the namespace of the SOAP header(s) to
be integrity protected.
/sp:SignedParts/sp:Header/@Target
This optional attribute indicates the role [SOAP12] or actor [SOAP11] of
the SOAP header(s) to be integrity protected. If this attribute is not
specified, all SOAP headers targeted at the UltimateReceiver role [SOAP12]
or actor [SOAP11] whose namespace matches the Namespace attribute are to
be protected.
sp:RequiredElements mechanism
Should the sp:RequiredElements mechanism (lines 735-740) allow
specification of otherwise optional elements that are not children of
soap:Header?
ws-sp
spec
design
Michael McIntosh
Michael McIntosh
Drop the issue.
Close with no action
Agreed to proposal 2, close with no action, on feb 22nd Tc call.
absolute XPath expressions
Should there a be way to specify that a signature reference for a given
SignedPart or SignedElement must use an absolute XPath expression?
ws-sp
spec
design
Michael McIntosh
Michael McIntosh
Rationale for proposal
Before Line 606 Add:
/sp:SignedParts/sp:Header/@UsePositionalReference
This optional attribute indicates that the specified SOAP header element
must be integrity protected in a way that prevents repositioning the
element in the message. If this attribute is "1" (true) and XML Signature
is used to protect the integrity of the element, the reference must use an
absolute path XPath expression. If this attribute is not specified the
default is "0" (false).
Before Line 626 Add:
/sp:SignedElements/@UsePositionalReference
This optional attribute indicates that the specified element(s) must be
integrity protected in a way that prevents repositioning the element(s) in
the message. If this attribute is "1" (true) and XML Signature is used to
protect the integrity of the element(s), the reference(s) must use an
absolute path XPath expression. If this attribute is not specified the
default is "0" (false).
supported XPath expressions
define a limited set of XPath expressions that MUST be supported
by an implementation (and list explicitly )
ws-sp
spec
design
Frederick Hirsch
Frederick Hirsch
At Feb. 8 TC call
Frederick reported that he was not able to get any concrete examples.
His developers did agree that doing less is always better.
Since there are no concrete examples the TC agreed to close this issue
with no action.
Describe minimum acceptable lengths for P_SHA1 inputs
Section 6.2.4 of WS-Trust describes the use of the P_SHA1 function to generate computed keys.
It does not provide guidance on minimum size of entropy required for this function. My crypto
101 guess is that a minimum of 20 bytes is required for each parameter but I would like more
informed guidance and have it included in the table. Is there any advantage to choosing longer
strings for Ent(req) or Ent(res)?
ws-trust
spec
design
Prateek Mishra
Correct section numbers in SP
OASIS template invalidated section numbers used to cross reference throughout SP. This needs to be corrected.
ws-sp
spec
editorial
Feb 8th TC call
Editors
XML tags of properties according to the properties
In chapter 6 the spec introduces several properties to control some behaviour.
The actual XML tags to set the properties is given in chapter 7. It is somehow difficult to
link the properties defined in chapter 6 to the actual XML tags defined in chapter 7. For example:
the [Protection Order] property can have several values. Chapter 7 then defines the real XML
tags as e.g. <sp:EncryptBeforeSigning /> to set this property. Because this property can have
several values there are several such XML tags to set this property. However, these XML names bear
no direct link to the property.
ws-sp
spec
design
Werner Dittmann
Use the following notation to set a multi value property:
<sp:ProtectionOrder value="EncryptBeforeSigning" />
Such a notation would also simplify parsing because a parser has to look for one tag name
only and can use the attribute to set the property's value.
Other properties are defined as boolean (true/false) properties. However, the actual XML
tag names to set the property differ from the specified property name - this is somehow confusing.
Take the Signature Protection property as an example: to set it you have to use the XML tag
<sp:EncryptSignature />. Why no use something like:
<sp:SignatureProtection value="on" /> or
<sp:SignatureProtection value="Encrypt" /> or just
<sp:SignatureProtection />
or something similar to make clear which property is set or defined.
Close with no action.
Proposal 2 accepted, to close with no action, at Feb 22nd TC call.
Properties for Algorithm Suite missing or wrong
The table at line 1280ff defines two properties [Sym KS] and [Asym KS].
Both propteries were not shown in the bullet list starting at line 1263. Should these two
properties read [Sym Sig] and [Asym Sig]?
The table starting at line 1282 defines a property [C14n]. This property name is the same
as the abbreviation for C14n in table starting at line 1277. This is not wrong, but
choosing different names would make it more clear.
ws-sp
spec
editorial
Werner Dittmann
The table at line 1280ff defines two properties [Sym KS] and [Asym KS], these should read [Sym Sig]
and [Asym Sig] which would match bullett list at line 1263.
The table starting at line 1282 defines a property [C14n], this should be spelled out as a
property name such as; [Canonicalization], [C14N algorithm] or [C14N Alg] or some such.
Editors to implement proposed changes (extracted and recorded in proposal 1), agreed on Feb 22nd TC call.
[Protection Order] Property using same source for keys
In "EncryptBeforeSigning" the spec states that both keys MUST derived from the same source.
What does this mean? Use the same certificate for both actions (for example if a X509 cert is used).
In that case this seems an unnecessary restriction. At least WS Security does not mandate this.
Also using the same cert to encrypt and sign is not a good security practice.
Proposed direction: Extend the ws-sp spec to support different key sources.
ws-sp
spec
editorial
Werner Dittmann
i009
Chap. 6.5 [Token protection] conflicts with chapter 8.3 and 8.4
If the policy uses EndorsingSupportingTokens _and_ sets [Token Protection] then I have the
same behaviour as defined for SignedEndorsingSupportingTokens. Is that true?
On the other hand if I use SignedEndorsingSupportingTokens and do _not_ set [Token Protection] -
what should be the result in that case?
Proposed direction: Clarify behaviour of these interdependencies.
ws-sp
spec
design
Werner Dittmann
At the beginning of chap 8 add something like:
How [Token Protection] interacts with supporting tokens
If [Token Protection] is true, then each signature covers the
token that generated it. So the main signature ( the one over the message headers
and body ) covers the main token (e.g. [Protection Token] in a symmetric
binding). Endorsing signatures cover the endorsing token.
For a signed SupportingToken the supporting token is covered by the
main message signature.
If you have a SignedEndorsingSupportingToken and [Token Protection] is
set to 'true' then the supporting token is signed twice, once by the
main signature and once by the endorsing signature.
Editors to implement proposed changes (extracted and recorded in proposal 1) in section 8, agreed on Feb 22nd TC call.
Chapter 6.7 [Security Header Layout]
Here the spec defines "LaxTimestampFirst" and "LaxTimestampLast", both define that a
Timestamp MUST be included. On the other hand in chapter
6.2 [Timestamp] the spec defines another way to switch Timestamps on/off. Which one rules?
Proposed direction: Clarify behaviour of these interdependencies.
ws-sp
spec
design
Werner Dittmann
In order for [Security Header Layout] property values of
LaxTimeStampFirst or LaxTimeStampLast to be valid [Timestamp] MUST be
set to true. This is called out in the assertions description in section
7.2 but should be called out in section 6 as well.
Editors to implement proposed changes (extracted and recorded in proposal 1) to add Section from 7.2 to section 6.
Agreed on Feb 22nd TC call.
When to include a token?
Using token inclusion values (chap 5.1.1) one can specify when to include a token. On the other hand in chap 5.3.3 X509Token Assertion there are ways defined how to reference a X509 token. For example if "RequireIssuerSerialReference" is set and the inclusion value is
"always": shall the token be included in the message? Which token shall the receipient take - the included one or the referenced?
With respect to the WS Security specification I interpret the inclusion value "always*" or "once" without any additional "Require*"
assertion as "include the token as a BinarySecurityToken and reference it using a Reference in the SecruityTokenReference". Is this a correct interpretation?
Also, with respect to WSS how to interpret or act on the RequireEmbeddedRefernce assertion? WSS does not specify an "embedded"
mechanism for X509 certificates.
Proposed direction: Clarify behaviour of the "token inclusion" and "token reference"
interworking to avoid misinterpretations and probable interop problems.
ws-sp
spec
design
Werner Dittmann
Multiple supporting tokens of the same type?
Can a Policy have more than one supporting token (of the same type), e.g. multiple SupportingTokens or multiple EndorsingSupportingTokens?
Proposed direction: IMHO we need an "overall" ws-sp outline to define which assertions are allowed at a specific level, for example similar to (a)symmetric binding outline but for to top level policy file.
ws-sp
spec
design
Werner Dittmann
Which token to use to encrypt/sign in case of multiple tokens defined in a supporting token assertion?
Every supporting token can have more than one token assertion, e.g.
X509 token assertions. If there are more than one such token assertion which on shall be used to sign/encrypt additional SignedParts or EncryptedParts if some are definied?
Proposed direction: Define and insert some clarification.
ws-sp
spec
design
Werner Dittmann
Need a mechanism to identify token assertions
An implementation that uses Security Policy Language has to know how to populate the required
tokens, e.g. UsernameToken or X509 tokens. Because a policy file usually contains several token
assertions there should be a mechanism avaliable to identify a token assertion.
For example if a policy requires two UsernameToken in a supporting token the application that
creates the message needs a way to link the different UsernameToken assertions to the user
data records that contains username, password, etc. To do so the application shall be able to
identify the UsernameToken and use this identifier as a link to the user data record.
Simliar mechanisms are required to locate the correct X509 certificate in a keystore, for example.
Proposed direction: Add an Id or name attribute or to token assertions. Any other ideas how to identify token in a Poliy file and associated them with real user/alias data?
ws-sp
spec
design
Werner Dittmann
Clarification for UsernameToken assertion
The UsernameToken defines additonal (optional) assertions that specify the WSS spec version.
IMHO this is not enough to fully specify a UsernameToken. For example a UsernameToken may have
a additonal elements such as a creation time. The WSS specs do not define in any way if such
elements shall be included or not (some are recommended but no mandated).
Proposed direction: The UsernameToken assertion should be extended to better reflect the WSS
username token elements and attributes.
ws-sp
spec
design
Werner Dittmann
WS-SP should permit Policy to specify the use of keys derived from passwords
At the end of section 5.3.1 it says:
Note: While Username tokens could be used cryptographically, such usage
is discouraged in general because of the relatively low entropy
typically associated with passwords. This specification does not define
a cryptographic binding for the Username token. A new token assertion
could be defined to allow for cryptographic binding.
I believe that WS-SP should enable all the functionality defined in the
referenced specs. Specifically, WSS 1.1 defines an algorithm for
deriving keys from passwords. I think WS-SP should support this and
allow organizations decide for themselves if they wish to use them or
not. There are already warnings about the issues in the security
considerations section of the WSS 1.1 Username Token Profile Security
Considerations section.
ws-sp
spec
editorial
Hal Lockhart
Hal Lockhart
Identify security header components that are encrypted
It appears that use of the SymmetricBinding and Asymmetric binding assertion implies encryption over several components of the security header, including the timestamp, Supporting tokens and SignedSupporting tokens.
This is not stated in the specification but can be gleaned from the construction given in Appendix C.
It would be helpful to implementors if this was made explicit in Sections 7.3 and 7.4
ws-sp
spec
editorial
Prateek Mishra
Prateek Mishra
Add the following sentence to Sections 7.4 (at end of first paragraph) and 7.5 (at end of first paragraph):
Use of this binding assertion implies that the following tokens, if
present in the security header of the request or response message, MUST
be encrypted: timestamp, Supporting tokens and SignedSupporting tokens.
Editorial comments on WS-Trust
See proposal for details
ws-trust
spec
editorial
Frederick Hirsch
Frederick Hirsch
1) Section 1.2, Remove line 54, modify line 55 to be
"Establishing, managing and assessing trust relationships."
("Managing trusts" is unclear).
2) Section 1.4
Neither schema (line 62) or wsdl (line 65) are located in the oasis docs directory. Should a draft be placed there?
3) Remove material in 1.5 from lines 109-115
Replicated in next section where it belongs.
4) Line 139 add [ for WS-PolicyAttachment
5) line 261 s/. As well,/ or/
6) Line 457, s/As well, /Additional
7) move lines 478-480 to 472, replace "As well, it is" with "It is also"
The mechanisms defined in this specification apply to both symmetric and asymmetric keys. As an example, a Kerberos KDC could provide the services defined in this specification to make tokens available; similarly, so can a public key infrastructure. In such cases, the issuing authority is the security token service.
It should be noted that in practice, asymmetric key usage often differs as it is common to reuse existing asymmetric keys rather than regenerate due to the time cost and desire to map to a common public key. In such cases a request might be made for an asymmetric token providing the public key and proving ownership of the private key. The public key is then used in the issued token.
A public key directory is not really a security token service per se; however, such a service MAY implement token retrieval as a form of issuance. It is also possible to bridge environments (security technologies) using PKI for authentication or bootstrapping to a symmetric key.
8) Line 490, replace "Subsequent" with "Additional". Line 492, remove " (e.g. multiple simultaneous exchanges) "
9) Line 560 s/post-dated/postdated/
10) Line 694, change last OK in table to "Issuer scope".
11) Line 743, s/and are/that is
12) Line 762, Is link really to Section 6.1 or to 4.1?
13) Line 878,
Replace "Two or more RSTR elements are returned in the collection." with "Each RequestSecurityTokenResponse element is an individual RSTR."
Add text "Two or more RSTR elements are returned in the collection." to end of line 876, for description of collection.
14) Line 927 add "This element schema is defined using the RequestSecurityTokenResponse schema type."
(this merely reiterates line 916 in the text describing the element).
15) Line 1128 indicate request and response separately.
16) Table entries at 1219 s/request/Trust service
17) Table 1225, is example missing token to be validated?
18) Any additional requirements/description on validation of envelope needed in section 7?
e.g. validate for specific role?
19) Is ws:LChallenge correct at line 1352?
20) Section 8.6, generally sign with private key associated with certificate, not certificate... (lines 1447, 1484)
21) 1699 s/binding/other bindings
Requester cannot fault upon response
Text seems to imply requestor can fault upon receiving a response.
See Line 386, also lines 432 and 435.
It isn't clear how the receiver of a response (the requestor) can fault if the message exchange pattern is complete.
ws-trust
spec
editorial
Frederick Hirsch
Proposal, remove lines 386-7.
Likewise lines 432, 435.
The TC discussed this issue and decided the document did not require any
change. Closed with no action on Feb 22nd TC call.
Clarify term pre-authentication
Is "pre-authentication" a well defined term? What does it mean to pre-authenticate using SSL/TLS?
ws-trust
spec
editorial
Frederick Hirsch
Frederick Hirsch
At Line 232, section 2.
Add sentence "Authenticating the server at the transport layer can mitigate the risk of spoofed
servers."
Add element extensibility to RequestSecurityTokenResponseCollection/IssuedTokens schema
Add element extensibility to RequestSecurityTokenResponseCollection schema. This would potentially allow bindings to define information associated with collection or to avoid repeating material in each SecurityTokenResponse, to give examples. Note that IssuedTokens shares the same schema as RequestSecurityTokenResponseCollection, so resolution applies to this element as well.
ws-trust
spec
schema
design
Frederick Hirsch
Frederick Hirsch
1) Insert before line 879:
/wst:RequestSecurityTokenResponseCollection/{any}
This is an extensibility mechanism to allow additional elements, based on schemas, to be added.
2) Insert before line 931
/wst:IssuedTokens/{any}
This is an extensibility mechanism to allow additional elements, based on schemas, to be added.
3) Update schema accordingly.
Clarify that ComputedKey optional
Can a computed key mechanism be implicit and not indicated with a ComputedKey element? (lines 744, 757)
ws-trust
spec
design
Frederick Hirsch
Frederick Hirsch
At Line 744 s/is/may be/
Add line to 757: "Use of the ComputedKey element is optional but SHOULD be used if a key needs to be computed."
Define URI for no-correlation anonymous context case
At Line 415, WS-Trust does not define a "anonymous" URI for the generic case of no correlation - but implies it is needed generically
ws-trust
spec
editorial
Frederick Hirsch
Frederick Hirsch
At Line 415, WS-Trust core define an "anonymous" URI for the generic case of no correlation -
http://docs.oasis-open.org/ws-sx/ws-trust/200512/anonymous-context
What values can be carried in a /wst:RequestSecurityToken/wst:Claims
element?
lines 530-535 of ws-trust-1[1].3-spec-ed-01-r03-diff state:
[quote]
/wst:RequestSecurityToken/wst:Claims
This optional element requests a specific set of claims. In most cases, this element contains
claims identified as required in a service's policy. Refer to [WS-Policy] for examples of how a
service uses policy to specify claim requirements. The @Dialect attribute specifies a URI to
indicate the syntax of the claims. No URIs are predefined; refer to profiles and other
specifications to define these URIs.
[\quote]
We are unable to follow what is meant here. What language is used to specify claims for
different token types?
There is a reference here to examples in WS-Policy (Sep 2004) but no other detail. WS-Policy
(Sep 2004) does not specifically discuss this issue nor does it offer an example of a service
using a policy to specify claim requirements.
I am also not sure what the role of "profiles" and the @Dialect attribute is. Is this a
reference to WSS 1.x profiles or to forthcoming profiles to developed as part of WS-SX?
Is the intent here to allow policies from WS-SecurityPolicy to be expressed?
ws-trust
spec
design
Prateek Mishra
Prateek Mishra
My guess is that this should reference is WS-SecurityPolicy with language like:
[quote]
This optional element requests a specific set of claims. In most cases, this element contains
claims identified as required in a service's policy.
Policy expressions taken from WS-SecurityPolicy may be used to describe the claims sought by the
requestor.
[\quote]
But this still leaves open the role of @Dialect. So I need the questions given above to be
answered first, before I can propose alternative text.
Clarification on token propagation of SCT required
Clarification on token propagation of SCT required when STS has no prior knowledge of which parties the requester needs a token for.
WS-SC defines SCT token propagation in order to distribute an SCT and its POP token to the requester (context initiator) and the other parties (endpoint for secured requests). Section 3 (lines 255 ff), Establishing Security Contexts, refers to the mechanisms in WS-Trust for token propagation. If the STS has no prior knowledge of which parties the requester needs a token for, WS-Trust provides two alternatives to define theses parties in the RST:
wsp:AppliesTo in RST and RSTR, Section 4.2.1 (lines 677 ff):
Both the requestor and the issuer can specify a scope for the issued token using the <wsp:AppliesTo> element.
wsp:AppliesTo can be used to carry wsa:EndpointReference elements which contain endpoint URLs.
Authorized Token Participants, Section 9.5 (lines 1969 ff):
This parameter is typically used when there are additional parties using the token or if the requestor needs to clarify the actual parties involved (for some profile-specific reason).
wst:ParticipantType can contain an arbitrary structure according to the ws-trust XSD.
From the quotes above, my guess is that WS-SC should refer to the Authorized Token Participants extension element for the RST and should give an example or enhance the existing SCT Request Example (section 3.2, lines 323 ff) in section 3.3 of the WS-SC spec.
ws-sc
spec
design
Martin Raepple
WS-SC HTTP Binding
WS-SC introduces the Security Context (SCT) Token which contains a unique identifier for a shared security context among the context initiator (requester) and (1 to n) service endpoints. There are certainly cases where the service endpoint is actually not one system but a collection of systems (server farm) used for cluster computing. Server farms are typically co-located with a load balancer which enables communication between the different servers of the cluster and the users of the cluster and may perform some type of load balancing
Based on the assumption that the servers in the cluster do not share a common address space or use any other means to synchronize stateful resources (such as the security context), the load balancer needs to send all subsequent requests for the same client to same server which has access to the previously created security context as part of the SCT establishment phase (see section 3.3).
The load balancer could certainly look at the wsse:security/wsc:SecurityContextToken/wsc:Identifier element to determine the context identifier and route the request to the server according to same sort of mapping. But this could have an impact of the overall performance since the load balance has to look inside the content of the HTTP request and parse the content of the SOAP message.
A much faster approach would be to carry the security context identifier in the HTTP header. Such an HTTP binding for WS-SC could specify the relationship between the WS-SC security context and the HTTP header and should define the name and semantics of new custom HTTP header(s).
ws-sc
spec
design
Martin Raepple
Chairs to investigate whether a second ballot is required to fix the XPath version number problem.
Done
Chairs to put link to issues list on TC home page.
Done
Frederick Hirsch to craft proposal for the Issue 11 - "WS-SX Charter XPath requirements ...".
Done
Chairs to create a Kavi location for WSDL files.
Done
Marc Goodner to create a new issue and assign to Editors to add the OASIS boilerplate to the XSD and WSDL files.
Done
Chairs to hold a F2F attendance ballot starting Mar 1 and closing at least two weeks before the F2F.
Due to start on March 1st.
Martin Gudgin to post interop document referenced from WS-SecurityPolicy F2F presentation.
Done
Chairs to arrange for a second charter clarification vote.
Done
Editors to check that XPath examples in WS-SecurityPolicy are fully namespace qualified.
Chris Kaler will reply by email to Issue 014's
questions.
Done
Marc Goodner to work on an initial interop
scenarios document. Prateek Mishra also offered to help.
Done
Heather Hinton and Tony Nadalin to work on an
initial use cases document. Prateek Mishara also offered to help.
Done
Tony Nadalin will look into the possibility of
hosting an interop event at the April F2F location
There will no interop at the April F2F. The F2F meeting will be Tue-Wed
Apr 4-5. Tony and Kelvin will provided F2F logistics information.
Chairs to ensure the list of voting members on the
roster is correct.
Chairs to re-run the charter clarification ballot
#2 a second time (after fixing the roster).
Marc Goodner to post WS-SX issue template to TC
site and Chairs to put it in a prominent location to make it easier to
find.
TC members to review the initial interop scenarios
by the Feb 15 TC meeting so that the TC can decide at that meeting
whether the TC has "critical mass" for an Apr F2F interop event.
Gudge to draft a revised proposal for Issue 9
Prateek to give a proposed use case for Issue 10 before
the next call.
Done
C.Y Chao to propose to the TC whether Issue 015 should
be closed or not due to revealing the information might be a security
risk.
Done
Prateek to propose resolution to Issue 20 by Feb 17.
It will take Prateek a couple of weeks to put together a
proposal for this technical issue.
Chairs to add information to the public page on how to
access previous versions of the Issues List.
They are available from
the URI http://docs.oasis-open.org/ws-sx/issues/
Prateek to provide additional broader scenarios for at
least WS-Trust.
TC members to come to the April F2F with data on when
they would be ready to carry out SC/Trust interop.
TC members to come to the April F2F with data on when
they would be ready to carry out SC/Trust interop.