[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)
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]