Thanks for the replies. I tried to add some clarifying text below where
to me to still be a question. Also, I have been reviewing the saml use
cases here in light
of your suggestion to issue 101 about the hk and sv (and bearer) and I
the intro I suggested to address item 1 below, might be a place to put
forth an initial
cut at how this could work.
Martin Gudgin wrote:
I was assuming based on what I thought I read in:
Thanks for the response. Here are some
quicks comments on your answers/comments;
[RAL1] - OK.
[RAL2] - Great. Thanks.
[RAL3] - Great.
[RAL4] - Great.
[RAL5] - OK
[RAL6] - OK
[RAL7] - I believe the
sp:EncryptedSupportingTokens assertion actually appears as a peer of
the sp:AsymmetricBinding. But apart from that, I think we are in
I agree that the supporting tokens themselves are peers of
AsymmetricBinding, but the text for 7.4 and 7.5
in the message says the assertion indicating that those tokens need
to be encrypted is within the
In my comment, I was assuming that this was mutual auth ssl, in
which case I believe the only meaningful role for the
[RAL8] - OK. From the context, it seemed
that the statement about multiple policies was specific to the
particular auth mechanism. From your response I see that the statement
is just saying 'when we're using message level security, we specify the
protection requirements at one scope and the binding specifics at a
[RAL9] - That would be great!
[RAL10] - OK.
[RAL11] - I'm not sure what you mean by
'client key that is used for SSL'. Do you mean the master secret? Or
hk key would be as the protector of the message, which in this case
would be the client side key of the ssl. I agree
for server-side ssl only, there really isn't any key that appears
to be in use that the hk could be referencing. Maybe
this one needs some more discussion.
I agree. It can. However, this use case is an asymmetric binding,
and in that case there is no shared
[RAL12] - I thought holder-of-key could
also include shared secret key material.
secret key that is being considered from my interpretation -
referring to the request portion of
section 2.3.4. My additional comment there was to the viability of
ws10 supporting a shared
key in an hk assertion. In that case one would have an STR in the
message signature pointing
to the hk assertion. If this assertion were to then include as the
signing key to use for verification
of the signature, an EncryptedKey element as would probably be used
for the symmetric key,
then I think this would be too much for current ws10
implementations. I am assuming it is
implicitly supported in ws11, as the EncryptedKey is officially
referencible by an STR and
it would seem to me that saml implementations would take the hint
and support this construct
in the hk assertion as well. It is probably a topic for the WS11
SAML Token Profile to discuss,
although my opinion is that ws11 soap message security should imply
at least the acceptability
of using this technique.
OK. My only point was that I agreed that the
"SignedSupportingToken" would be replaced
[RAL13] - Great. Thanks.
[RAL14] - OK. I need to think more about 12
[RAL15] - Great. Sounds like we agree on
the number of sigs in the sender/holder-of-key case.
by SupportingToken in the sv case and EndorsingSupportingToken in
the hk case, since there
is no signing going on here with SAML over SSL, however, one can
interpret the hk token
as "endorsing" the client-side cert in the mutual auth case. My
comment on number of sigs
relevant to hk and sv were for the non-SSL case. For sv on SSL
there are zero "sigs". For
hk over SSL, the hk assertion itself is previously signed by the
issuer, but no signing takes
place explicitly on the SSL based request.
I'll *try* to post more about 12 and 14
before the call, but it's likely to be after, I'm afraid.
This email contains initial responses for Issue 66 as identified in
ws-sx minutes of August 2:
i066 - SecurityPolicy use cases
Should have responses, not necessarily a revised doc, ready by next weeks meeting.
These responses address the 15 issues raised by Martin plus
the one issue raised by Symon (which I labeled #16 for
convenience (even though it came earlier)). The typo issues
identified in the 2 emails will be taken and applied as submitted
(with review of course). Issues are listed below:
I think WSS defines the broad message format, with some detail being in WS-Trust and SecureConv and the strict layout details being the WS-SP. Net, I think the specs define the message formats. If they don't, we should fix the specs.
[RAL1]I agree we don’t need to define “message formats”, however, it might be useful, when a collection of “typical” ws-sp scenarios are agreed upon that we put together some sample messages that conform to the policies, similar to what is done in App C of the WS-SP spec, or in cases where existing scenarios, such as various interop specs have been used, that they be explicitly referenced. At this point the objective is to assemble (and in parallel, conceptualize) what would be a useful, typical set. What is here now, I think, has pretty decent coverage, but it needs to be more systematically structured, and probably have an introductory section giving an overview of the matrix of options that are being addressed (token types, ws versions, bindings, key usage techniques, etc.).
I'm not sure I'd agree that they are unwieldy, although I'll grant you long. They certainly look more unwieldy if they are not well-formed and/or not consistently indented. I've taken the liberty of cleaning this up. I also don't think they are that hard to understand once one has read the WS-SP spec assuming familiarity with WSS et.al.
[RAL2] Agree, once the character of the xml is familiar these use cases are pretty straight-forward to follow, so this comment will be removed.
Do you mean server-authentication only?
[RAL3] Yes, will change.
Do you mean mutual authentication?
[RAL4] Yes, will change.
See earlier comment.
See earlier comment
I believe the resolution for issue 74 addresses this.
[RAL7] OK, it sounds like from the refs in the ws-sx TC issue list to the resolution that there will be changes to sections 7.4,7,5 + 3 new sections in section 8, the net of which will allow us to specify an element: /sp:AsymmetricBinding/wsp:Policy/sp:EncryptSupportingTokens which will tell the initiator to encrypt the UsernameToken in this use case.
If the use case is X509 mutual auth with supporting username token than I don't believe this statement is accurate. Separate policies are not required to achieve this use case.
[RAL8] Assuming we are talking about the same thing, the Message Level input and output policies at the end of the xml in section 2.1.3 (which are being referred to as the “separate policies”), it seems, based on wssp sec C.2.1, C.3.1, that this is the recommended approach for specifying that the body must be encrypted for input and output. It also appears consistent with WS-Policy 1.5 - Attachment ex. 4.1.5. Possibly there is some default behavior or binding level option that would imply this that we are missing?
While I understand why one needs these message level assertions for real-world policy, I don't understand what they add to the use-case description, esp. given that they are all identical in the examples you give. Perhaps it would be better to state earlier in the document that all the policies assume an appropriate message level policy describing the protection requirements.
[RAL9] Agree in principle. How would it be if we described them in a preliminary section, as you suggest, and then reference them in each appropriate message with 2 <wsp:PolicyReference URI=”#…”> statements?
It what way is this anonymous? The initiator token identifies the client.
[RAL10] Agree. The intent here was to distinguish between this WS10
use case where the requestor wishes to remain anonymous, however
is unable to because of the key referencing limitations, and
the corresponding ws11 scenario, 2.2.3 where anonymity is achieved
by using an ephemeral or derived key encrypted to an EncryptedKey
using the server cert, where there is a ws11 STR available to
ref the EncryptedKey as the message signer. We suggest renaming
this scenario by removing the “anonymous”, and modifying the
text accordingly, as indicated above.
(Note: in another sense the intent here might be considered as doing the equivalent of 2.1.3 but without the username token and thus from that perspective be “anonymous”, since no “username” has been identified – the point is to consider what users might want to do and provide constructs for possible implementation)
In the HOK case I believe this would need to be some form of Endorsing supporting token.
[RAL11] Yes, and it can also be explained that in this case, the HK assertion must have its contained key be the client key that is used for SSL, otherwise the hk has no real meaning here. Possiby, sv and hk for SSL should be 2 separate use cases to emphasize this distinction.
Do you mean the key material from the SAML assertion?
[RAL12] In the general hk case, the saml hk assertion may contain the requestor’s public certificate, in which case the requestor’s private key must be used for the signing, which is probably only approach viable for ws10 since EncryptedKey not referencable by STR.
(Note: the term “key material” here that you use I am interpreting as possibly implying an ephemeral or derived key as opposed to a public x509 cert in the Saml Assertion. This may not be supportable in WS10. However, Scenario 2.3.8 (ws11) is an example of this type of structure.}
I hope you mean encrypted using a symmetric key, K, which is in turn encrypted using the server's certificate.
[RAL13] Yes, that is correct, the text will be expanded accordingly to avoid any confusion.
If the SAML assertion contains a symmetric key, why not just sign and encrypt with keys derived from that key?
[RAL14] For this use case the saml assertion contains a ref to an X509 public cert with a public key – see also response to comment 12.
For HOK case wouldn't this need to be an EndorsingSupportingToken?
[RAL15] Agree, this should probably be split in 2 use cases similar to issue 11 above. The nature of Sender-Vouches is that one signature is in play, whereas for Holder-of-Key 2 signatures are in play, in which case the signature on the assertion plays the role of (signed) endorsing token. For sender-vouches the message signature covers the (unsigned or unsigned) supporting token.
Symon's 2.3.5, 2.3.8 issue:
In addition, I have question on the section 2.3.5 and 2.3.8 on these
SAML1.1/2.0 Use cases. Why these two cases use SymmetricBinding (Line
940 and line 1073) instead of AsymmetricBinding? The example on WSS1.0
SAML10, on the section 2.3.2 and section 2.3.4 Use Cases, use
AsymmetricBinding (line 735 and line 861). I just don't understand the
reason of changing AsymmetricBinding to SymmetricBinding from WSS 1.0 to
Can you ask the authors of this document for the reason?
[RAL16] The intent here was to demonstrate the ability to use derived
or ephemeral keys in conjunction with SAML tokens, which I don't
believe was possible due to STR limitations in WS10. However, this is
not to imply that the asymmetric techniques cannot still be used. Possibly
some explanation in the use cases about this would be helpful.
Subject: RE: [ws-sx] Issue 66: Security Policy
Comments on Policy usecase document from Gudge
> -----Original Message-----
> From: Hal Lockhart [mailto:firstname.lastname@example.org]
> Sent: 26 June 2006 22:00
> To: Ashok Malhotra
> Cc: email@example.com; Symon Chang
> Subject: FW: [ws-sx] Issue 66: Security Policy Usecases
> Comments on the Policy usecase document from Symon Chang (now of BEA)
> -----Original Message-----
> From: Symon Chang
> Sent: Monday, June 26, 2006 3:30 PM
> To: Jong Lee; Hal Lockhart
> Subject: RE: [ws-sx] Issue 66: Security Policy Usecases
> Jong and Hal,
> The XML samples in the attached document have some syntax errors.
> Attached is my update of the document that has the fixes of syntax
> errors with track changes is turn-on. Can you please take it back to
> WS-SX-TC to have those typos be fixed?
> In addition, I have question on the section 2.3.5 and 2.3.8 on these
> SAML1.1/2.0 Use cases. Why these two cases use SymmetricBinding (Line
> 940 and line 1073) instead of AsymmetricBinding? The example on WSS1.0
> SAML10, on the section 2.3.2 and section 2.3.4 Use Cases, use
> AsymmetricBinding (line 735 and line 861). I just don't understand the
> reason of changing AsymmetricBinding to SymmetricBinding from
> WSS 1.0 to
> WSS 1.1.
> Can you ask the authors of this document for the reason?
> Thanks for your help in advance.
> Symon Chang
> -----Original Message-----
> From: Ashok Malhotra [mailto:firstname.lastname@example.org]
> Sent: Thursday, June 15, 2006 11:13 AM
> To: email@example.com
> Cc: Prateek Mishra; Mischkinsky,Jeff
> Subject: [ws-sx] Issue 66: Security Policy Usecases
> I'm attaching a document with a number of what we feel are typical
> Security Policy usecases along with sample Policies.
> The first thing to do is to discuss whether we need more or less
> My guess is we need more but we also don't need a 100 page document.
> Then we need to decide where this fits along with the other WS-SX
> All the best, Ashok