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


Yes, this needs to be clarified more in the spec. I propose the following changes to the spec to make this more clear:

 

Change lines 1792-1794 as follows:

 

Security Bindings use tokens to secure the message exchange. The Security Binding will require one to create a signature using the token identified in the Security Binding policy. This signature will here-to-fore be referred to as the “message signature”. In case of Transport Binding the message is signed outside of the message XML by the underlying transport protocol and the signature itself is not part of the message.

 

Change lines 1834 – 1835 as follows:

 

If transport security is used, only the message timestamp (TS) is included in the Security header as illustrated below. The “message signature” is provided by the underlying transport protocol and is not part of the message XML.

 

Change lines 1838 – 1839 as follows:

 

Supporting tokens are included in the security header and may optionally include additional message parts to sign and/or encrypt. The supporting tokens can be added to any SOAP message and do not require any protection (signature or encryption) to be applied to the message before they are added. More specifically there is no requirement on “message signature” being present before the supporting tokens are added. However it is RECOMMENDED to employ underlying protection mechanism to ensure that the supporting tokens are cryptographically bound to the message during the transmission.

 

Does this help?

 

--Jan

 

From: Tony Gullotta [mailto:tony.gullotta@soa.com]
Sent: Wednesday, January 31, 2007 7:53 AM
To: Jan Alexander; Symon Chang; Hal Lockhart; Greg Carpenter; ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

Good. However, its still not clear to me then what the difference between a SupportingTokensAssertion and a SignedSupportingTokensAssertion is. I thought if you required signing the supporting token to "cryptographically bind" the token to the rest of the message, you'd use SignedSupportingTokensAssertion. The SupportingTokensAssertion did not require that.

 

Tony


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

The scenario below is possible as the transport binding supplies the message signature. However I agree that the spec is not clear in this regard and should be clarified to be more explicit. The intention here is ensure that the supporting tokens are cryptographically bound to the rest of the message.

 

From: Tony Gullotta [mailto:tony.gullotta@soa.com]
Sent: Tuesday, January 30, 2007 9:06 PM
To: Jan Alexander; Symon Chang; Hal Lockhart; Greg Carpenter; ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

My only issue with what your saying is "the current spec requires you to sign the message whenever you add a supporting token to it". We see a lot of customer use cases where they just want to include SAML assertions or Username tokens (maybe multiple tokens for application identity and end user identity) but they don't want to encrypt or sign anything at the message level. They may use SSL to protect the messages. I thought I could support those use cases with a TransportBinding and SupportingTokensAssertions. Now I'm not so sure.

 

Tony 

 


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

Symon,

 

Please see my comments inline.

 

Cheers,

--Jan

 

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

 

Jan,

 

The situation that you mentioned is called replay attack. I do agree with you that the EncryptedSupportingTokens without signature protection has risk on the replay attack.  However, any authentication related attacks may lead to other pretty nasty attacks, such as elevation of privilege attack, but this is not the point. The question is: does our TC provide simple policy assertions that meet our policy users’ requirements and needs? 

 

[Jan] It is not, because the attacker is attaching the encrypted username token to a different message – different payload. He can essentially send any message body on behalf of the original sender. This is called elevation of privilege.

 

If the user only has the authentication and confidentiality requirements, then are your suggest that the user have to also do integrity, authorization, and non-repudiation?  If the user has problem to sign, then are you suggest that the user has to choice for no security at all?   Can we have some thing in the middle?    

 

[Jan] The current WS-SecurityPolicy spec requires you to sign the message if you are adding the supporting tokens as per section 8, I’ve copied the text from the spec in another thread of this discussion. The timestamp protection rules are covered by [Timestamp] property that is orthogonal to supporting tokens. Essentially whenever a wsu:Timestamp element is required, it is also required that the element is covered by the message signature.

 

As regarding to the replay attack, it is possible to prevent the attack without the signature. The username can be embedded into the message body, and the body also be encrypted with recipient’s public cert. In this case, if the attacker just replaces the whole username token blob will not make the replay attack.  

 

[Jan] See my first comment. The attacker can substitute the body. You’re right that if you change the application logic to require the username toke appear twice, once in the header and once in the body and enforces that those two are the same than you can mitigate this issue, but I would argue that you don’t need to send the username token in the header in the first place if you already have it in the body, right?

 

In addition, the replay attack is not just for Username Token. The SAML Token with Bearer confirmation method will also have vulnerability on same kind of attacks, but the WS-SP standard has the assertion for it. The policy examples are shown on section 2.3.1.1 and 2.3.2.1 of the Example Document.  

 

[janalex] I’m not sure I’m following here. The SAML bearer token is added to the message as a supporting token and thus follows the same rules as all other supporting tokens. Your proposal for PR013 would allow this to happen, but currently this is not possible.

 

This Issue PR013 has not thing to do the strict layout format, nor the asymmetric binding rules. It also has not thing to do with how the timestamp should be protected. As you know, there is no 100% secure system in the world. Any vulnerability can lead to pretty nasty attacks eventually. Therefore, I don’t think the nasty elevation of privilege attack has any thing to do with this issue either.

 

Instead, the Issue PR013 is:  we need EncryptedSupportingTokens assertion to protect plain text password element in the Username Token. This is for current WSS 1.0 user which already has the encrypted username token protection, but no key for signature. This should be a valid use case scenario, isn’t it?

 

[janalex] My argument is that the current spec requires you to sign the message whenever you add a supporting token to it (see section 8). In other words you cannot use supporting tokens without having some key to sign the message with. And if you are able to sign the message you’re can very easily add username token to the signature so I don’t see a need for this assertion.

 

It is proposed that to add EncryptedSupportingTokens into the WS-SP spec and add the example onto Example Document for Username Token per Issue PR012. In addition, we can document the use case and add the security risk statement on the example. We can further suggesting to use more secure ways to protect the Username Token, such as SignedEncryptedSupportingTokens, where possible.

 

Best regards,

 

 

 

Symon Chang

 


From: Jan Alexander [mailto:janalex@microsoft.com]
Sent: Tuesday, January 30, 2007 10:48 AM
To: Hal Lockhart; Symon Chang; Greg Carpenter; ws-sx@lists.oasis-open.org
Cc: Marc Goodner
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]