OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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