[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 66: Security Policy Usecases
This email contains initial responses for Issue 66 as identified in
ws-sx minutes of August 2:
i066 - SecurityPolicy use cases
In progress
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:
Thanks,
Rich Levinson
Oracle
**************************************************
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.
[RAL5] ok
See earlier comment
[RAL6] ok
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
WSS 1.1.
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 Usecases
Comments on Policy usecase document from Gudge Gudge > -----Original Message----- > From: Hal Lockhart [mailto:hlockhar@bea.com] > Sent: 26 June 2006 22:00 > To: Ashok Malhotra > Cc: ws-sx@lists.oasis-open.org; Symon Chang > Subject: FW: [ws-sx] Issue 66: Security Policy Usecases > > Comments on the Policy usecase document from Symon Chang (now of BEA) > > Hal > > -----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:ashok.malhotra@oracle.com] > Sent: Thursday, June 15, 2006 11:13 AM > To: ws-sx@lists.oasis-open.org > 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 > usecases. > 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 > deliverables. > > All the best, Ashok > > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]