[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Proposal for resolving issue 33 ( was RE: [ws-sx] Issue 33: Identitysecurity header components that are encrypted when using (A)Symmetric binding)
I see your point re:user-name token but still have some concerns about calling out the encryption rules in such a specific way. One question I have is whether it would be appropriate to generalize this to a <EncryptSupportingToken> element in the symmetric and assymmetric bindings. Use of this token would be RECOMMENDED when username token was the supporting token. - prateek >The thinking around encryption of username token is that in cases where >it contains a plain-text or digest password it's insecure to send the >username token in the clear, so either message level or transport level >encryption needs to be used. This is called out (albeit as a >RECOMMENDED) in the WSS Username Token Profile[1] around line 165. > >I understand that the same requirement might apply to a SAML token. > >Gudge > > > >>-----Original Message----- >>From: Prateek Mishra [mailto:prateek.mishra@oracle.com] >>Sent: 17 May 2006 06:35 >>To: Martin Gudgin >>Cc: ws-sx@lists.oasis-open.org; Paul Cotton; Marc Goodner >>Subject: Re: Proposal for resolving issue 33 ( was RE: >>[ws-sx] Issue 33: Identity security header components that >>are encrypted when using (A)Symmetric binding) >> >>Martin, >> >>my apologies replying quite so late. But I have finally had a little >>time to look at your proposal. >> >>I think it addresses most of my issues but I do have one question. >> >>1. >> >>I am a little puzzled by the specific reference to UserNameToken in: >> >>[quote] >> >>X.4 Elements that are encrypted >> >>1. The ds:Signature element that forms the message signature when >>[Signature Protection] has a value of 'true' >>2. All wsse11:SignatureConfirmation elements when [Signature >>Protection] has a value of 'true' >>3. Any wsse:UsernameToken when a transport binding is NOT being >>used. >>[\quote] >> >>From this i understand that to require a supporting token be >>encrypted (e.g., SAML assertion) we would need >>to use a sp:EncryptedElement assertion. But the case of >>wsse:UsernameToken is somehow being treated >>differently? >> >> >>- prateek >> >> >> >>>Fulfilling my action item from last week; I think this information >>>belongs in an appendix, as it's really a collation of >>> >>> >>existing material. >> >> >>>I propose we add the following; >>> >>>Appendix x - Signed and Encrypted Elements in the Security Header >>> >>>This appendix lists the criteria for when various child >>> >>> >>elements of the >> >> >>>Security header are signed and/or encrypted at the message level >>>including whether they are signed by the message signature or a >>>supporting signature. It assumes that there are no >>> >>> >>sp:SignedElements and >> >> >>>no sp:EncryptedElements assertions in the policy. If such >>> >>> >>assertions are >> >> >>>present in the policy then additional child elements of the security >>>header might be signed and/or encrypted. >>> >>>X.1 Elements signed by the message signature >>> >>>1. The wsu:Timestamp element. >>>2. All wsse11:SignatureConfirmation elements. >>>3. Security Tokens corresponding to [Initiator Signature Token], >>>[Recipient Signature Token], [Initiator Encryption Token], [Recipient >>>Encryption Token], [Signature Token] or [Encryption Token] >>> >>> >>when [Token >> >> >>>Protection] has a value of 'true'. >>>4. Security Tokens corresponding to [Signed Supporting Tokens] or >>>[Signed Endorsing Supporting Tokens]. >>> >>>X.2 Elements signed by all endorsing signatures >>> >>>1. The ds:Signature element that forms the message signature >>>2. The wsu:Timestamp element in the case of a transport binding >>> >>>X.3 Elements signed by a specific endorsing signature >>> >>>1. Security Tokens corresponding to [Endorsing Supporting Tokens] >>>or [Signed Endorsing Supporting Tokens] when [Token Protection] has a >>>value of 'true' >>> >>>X.4 Elements that are encrypted >>> >>>1. The ds:Signature element that forms the message signature when >>>[Signature Protection] has a value of 'true' >>>2. All wsse11:SignatureConfirmation elements when [Signature >>>Protection] has a value of 'true' >>>3. Any wsse:UsernameToken when a transport binding is NOT being >>>used. >>> >>>Cheers >>> >>>Gudge >>> >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Martin Gudgin >>>>Sent: 30 April 2006 15:58 >>>>To: Prateek Mishra >>>>Cc: ws-sx@lists.oasis-open.org; Paul Cotton; Marc Goodner >>>>Subject: RE: [ws-sx] Issue 33: Identity security header >>>>components that are encrypted when using (A)Symmetric binding >>>> >>>>Prateek, TC, >>>> >>>>Here is data for Issue 33. >>>> >>>>The following statements apply if the element listed appears >>>>as a child of the wsse:Security header; >>>> >>>>Signing >>>> >>>>1. wsu:Timestamp is signed by the message signature. >>>>2. wsu:Timestamp is signed by any endorsing signature in >>>>the case of a transport binding. >>>>3. wsse11:SignatureConfirmation is signed by the message signature. >>>>4. ds:Signature of the message signature is signed by the >>>>signature of an endorsing token. >>>>5. ds:Signature of an endorsing token is never signed. >>>>6. xenc:EncryptedKey is never signed. >>>>7. xenc:EncryptedData is never signed. >>>>8. xenc:ReferenceList is never signed. >>>>9. Security Tokens ( e.g. wsse:UsernameToken, >>>>wsse:BinarySecurityToken, wsc:SecurityContextToken, >>>>wsc:DerivedKeyToken saml:Assertion ) are signed by the main >>>>signature if [Token Protection] is set to 'true' or the >>>>tokens are present in the header because they are Signed or >>>>SignedEndorsing support tokens. >>>>10. Security Tokens ( e.g. wsse:UsernameToken, >>>>wsse:BinarySecurityToken, wsc:SecurityContextToken, >>>>wsc:DerivedKeyToken saml:Assertion ) that are present in the >>>>header because they are Endorsing and SignedEndorsing >>>>supporting tokens are signed by the corresponding endorsing >>>>signature if [Token Protection] is set to 'true'. >>>> >>>>Encrypting >>>> >>>>11. ds:Signature of the message signature is encrypted if >>>>[SignatureProtection] is set to 'true'. >>>>12. wsse11:SignatureConfirmation is encrypted if >>>>[SignatureProtection] is set to 'true'. >>>>13. wsse:UsernameToken should be encrypted if transport >>>>security is NOT being used. >>>>14. ds:Signature of an endorsing token is never encrypted. >>>>15. xenc:EncryptedKey is never encrypted. >>>>16. xenc:EncryptedData is never encrypted. >>>>17. xenc:ReferenceList is never encrypted. >>>> >>>>The following assumptions are made; >>>> >>>>1. No sp:SignedElements assertions are present in the >>>>policy that would cause any of the above elements to be signed. >>>>2. No sp:EncryptedElements assertions are present in the >>>>policy that would cause any of the above elements to be encrypted. >>>> >>>>Let me know if the above makes sense. >>>> >>>>Gudge >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Martin Gudgin [mailto:mgudgin@microsoft.com] >>>>>Sent: 19 April 2006 06:33 >>>>>To: Prateek Mishra >>>>>Cc: ws-sx@lists.oasis-open.org; Paul Cotton; Marc Goodner >>>>>Subject: RE: [ws-sx] Issue 33: Identity security header >>>>>components that are encrypted when using (A)Symmetric binding >>>>> >>>>>Prateek, >>>>> >>>>>I'm sorry it has taken me so long to respond to this. >>>>> >>>>>I've reviewed the thread and I am now in the process of >>>>> >>>>> >>>>> >>>>> >>>>collating all >>>> >>>> >>>> >>>> >>>>>the information regarding signed and/or encrypted elements >>>>>appearing in >>>>>the security header. Realistically, I am unlikely to have a >>>>>comprehensive proposal until the end of next week. >>>>> >>>>>Regards >>>>> >>>>>Gudge >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Prateek Mishra [mailto:prateek.mishra@oracle.com] >>>>>>Sent: 22 March 2006 14:29 >>>>>>To: Martin Gudgin >>>>>>Cc: ws-sx@lists.oasis-open.org; Paul Cotton >>>>>>Subject: Re: [ws-sx] Issue 33: Identity security header >>>>>>components that are encrypted when using (A)Symmetric binding >>>>>> >>>>>><PM> Comments below </PM> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Paul kindly pointed me to the right thread, so I'm >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>replying here so >>>> >>>> >>>> >>>> >>>>>>>maybe we can keep the threads together. Apart from this >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>paragraph and >>>>> >>>>> >>>>> >>>>> >>>>>>>the text of your/Marc's mail below the content of this mail >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>is identical >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>to my previous one. >>>>>>> >>>>>>>I think we discussed on one of the calls, that more things >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>were signed >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>than encrypted in the security header. However, certain >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>things are >>>> >>>> >>>> >>>> >>>>>>>encrypted, so perhaps we should rename the issue; >>>>>>> >>>>>>>"Identify security header components that are signed and/or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>encrypted" >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>><PM> Agreed, this is a more comprehensive way to approach >>>>>>this question. >>>>>>Given a security policy based >>>>>>on asymmetric/symmetric binding >>>>>>it is hard to authoritatively figure out which headers are >>>>>>signed and/or >>>>>>encrypted. I am spending some time on this with >>>>>>our engineers and I believe it will lead to an >>>>>> >>>>>> >>>>>> >>>>>> >>>>>interoperability issue. >>>>> >>>>> >>>>> >>>>> >>>>>></PM> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Is that what you would like to clarify? Or was it just encrypted >>>>>>>elements? Or just signed elements? >>>>>>> >>>>>>> >>>>>>> >>>>>>>A quick look at Appendix C turns up, for the symmetric >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>binding at least; >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>SignedSupportingTokens >>>>>>>SignedEndorsingSupportingTokens >>>>>>>[Signature Token] in the case where [Token Protection] is >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>set to true. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>as being signed and; >>>>>>> >>>>>>>Message signature in the case where [Encrypt Signature] is true >>>>>>> >>>>>>>as being encrypted. >>>>>>> >>>>>>>I guess I'm wondering whether it is worth stating a list of >>>>>>>signed/encrypted elements at the binding level given that >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>the presence >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>of those elements depends on various property values and >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>in some case >>>>> >>>>> >>>>> >>>>> >>>>>>>the signing and/or encrypting depends on property values too. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>><PM> How about a table that captures your comments above? We >>>>>>would need >>>>>>to fill it out with some more details. >>>>>> >>>>>>For example, are [Signed] Supporting Tokens always encrypted? >>>>>> >>>>>>Do the rules apply to both requests and responses? >>>>>></PM> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >>> >>> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]