[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: Identity security header components that are encrypted when using (A)Symmetric binding)
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]