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: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion


I don’t disagree with that. However by not requiring the username supporting token to be signed the attacker can take out the whole username token blob from the original message and insert it into his own message and recipient of such crafted message will not be able to tell the difference. This can lead to pretty nasty elevation of privilege attack.

 

From: Hal Lockhart [mailto:hlockhar@bea.com]
Sent: Monday, January 29, 2007 8:11 PM
To: Jan Alexander; Symon Chang; Greg Carpenter; ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

If the only thing you need to encrypt is the password, it is not necessary to integrity protect it. If it is modified, the authentication will fail.

 

Hal

 


From: Jan Alexander [mailto:janalex@microsoft.com]
Sent: Monday, January 29, 2007 5:37 PM
To: Symon Chang; Greg Carpenter; ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Hal Lockhart
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

I see. The interesting thing to note is that the asymmetric binding does not support the scenario described below. According to the asymmetric binding rules you are required to sign and encrypt both the request and the reply.

 

If you want to go this path you’re opening yourself to a whole class of attacks based on the fact that the message you’re sending out is not signed. I wonder if the TC wants to promote this by explicitly creating a new supporting token type to allow such messages to be security policy compliant.

 

Thanks,

--Jan

 

From: Symon Chang [mailto:sychang@bea.com]
Sent: Monday, January 29, 2007 9:13 AM
To: Jan Alexander; Greg Carpenter; ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Hal Lockhart
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

Jan,

 

My scenario is a WSS 1.0 asymmetric binding scenario where there is only one recipient key from the services provider. The client does not have private key. On this scenario, the user does not want to change from asymmetric binding to symmetric binding. The reasons are:

 

  1. The existing service only support WSS 1.0, and cannot migrate to WSS 1.1 for all the clients at the same time easily.
  2. The existing service uses a simple asymmetric binding to encrypted plain text password, and does not want to change to symmetric binding because the use doesn’t want a complex, over-engineering, and poor-performance new solution that will cause interoperability problems.

 

My motivation is to provider a simple policy assertion for a simple cryptography problem – encrypt plain text password using server’s certificate, instead of ask users to change their existing WS security solution into a more complex and not interoperable security solution.  

 

Again, this is a simple support taken assertion for a very simple and common scenario that users want.  

 

Best regards,

 

 

Symon Chang


From: Jan Alexander [mailto:janalex@microsoft.com]
Sent: Friday, January 26, 2007 5:02 PM
To: Greg Carpenter; Symon Chang; ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Hal Lockhart
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

In your scenario the sender either have:

a)      a shared symmetric key - in this case you can use the same key to both encrypt and sign the supporting token or you can derive two keys (recommended) one used for encryption and second one used for signature.

b)      a recipient public key – in this case you will use the public key wrap a symmetric key that the sender generates which is then used to encrypt the supporting token. Again, you can either use the same key to sign the supporting token or you can derive two keys (recommended), one for encryption and one for signature.

 

In both cases you can easily create a signature over the supporting token, therefore I don’t understand why this support token type is needed. Can you please clarify your motivation?

 

Thanks,

--Jan

 

From: Greg Carpenter [mailto:gregcarp@microsoft.com]
Sent: Friday, January 26, 2007 8:48 AM
To: Symon Chang; ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Hal Lockhart
Subject: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

Issue PR013

 

From: Symon Chang [mailto:sychang@bea.com]
Sent: Wednesday, January 24, 2007 11:25 AM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Hal Lockhart
Subject: [ws-sx] NEW Issue: Need EncryptedSupportingTokens assertion

 

 
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.  
The issues coordinators will notify the list when that has occurred.
 
Protocol:  ws-sp 
 
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/21401/ws-securitypolicy-1.2-spec-cd-01.pdf 
 
Artifact:  policy
 
Type: design
 
Title: Need EncryptedSupportingTokens assertion  
 
Need EncryptedSupportingTokens assertion to encrypt plain text password in Username Token for authentication. 
 
Description:
 

The current WS-SP spec has SupportingTokens, SignedSupportingTokens, and SignedEncryptedSupportingTokens assertions, but does not have EncryptedSupportingTokens assertion.

 

Encrypted support token without signature is a common use case, when the plain text password is used on the Username Token for authentication, and the client does not have private key for signature. When the server can only accept plain text password, encrypt the password with server’s X509 certificate is a good security practice, but existing spec does not have a simply assertion in supporting token for this simple requirement. 

 
Related issues:
 
Need policy example for encrypted username token.
 
Proposed Resolution:
 

Added new EncryptedSupportingTokens assertion into WS-SP spec, after section 8.5. -- “SignedEncryptedSupportingTokens Assertion”. The text can be similar to the section 8.5.

 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]