RE: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokensassertion

This is not the intention of the signed/encrypted elements assertions and should probably be clarified in the spec more explicitly. The integrity/confidentiality requirements for supporting tokens are controlled by various supporting tokens assertions. The timestamp integrity requirements are controlled by security binding [Timestamp] property in section 6.2:

6.2 [Timestamp] Property

This boolean property specifies whether a wsu:Timestamp element is present in the wsse:Security header. If the value is 'true', the timestamp element MUST be present and MUST be integrity protected either by transport or message level security. If the value is 'false', the timestamp element MUST NOT be present. The default value for this property is 'false'.

The processing rules regarding protection requirements are controlled by multiple factors, [Timestamp] property being one of them, type of supporting tokens assertion another one, (signed/encrypted)(parts/elements) yet another one. Also adding a supporting token into the message requires message signature as described in the text below that was copied from section 8 of the spec.

Does this help?

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

Hmmm. I guess I would have thought the signed/encrypted elements assertions could be used for elements in the security header too so you would use them to indicate if you wanted the timestamp protected or not instead of assuming it would. I'm sorry to be a pest but I just want to make sure I'm not misunderstanding something. I get the importance of signing a timestamp but where exactly are the "processing rules" you are referring to that mandate that? 6.7 is only layout.

Tony

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

The strict layout rules are described in section 6.7. The example of application of those rules for AsymmetricBinding is shown in appendix C.3.

<sp:InitiatorEncryptionToken> and others were introduced to enable distinct keys to be used for encryption and signature on both sender and recipient sides. We also have <InitiatorToken> and <RecipientToken> parameters that set both InitiatorXXX and RecipientXXX properties if you want to use the same key for both encryption and signature.

The SupportingTokens assertion is meant to be used when an underlying protection mechanism takes care of confidentiality and integrity (for example IPSec) or when the token itself does not contain any confidential information and you trust your environment enough to not worry about the supporting token integrity. The security policy specification clarifies this even further on lines 1826 – 1835:

Even before any supporting tokens are added, each binding requires that the message is signed using a token satisfying the required usage for that binding, and that the signature (Sig1) covers important parts of the message including the message timestamp (TS) facilitate replay detection. The signature is then included as part of the Security header as illustrated below:

Note: if required, the initiator may also include in the Security header the token used as the basis for the message signature (Sig1), not shown in the diagram.

If transport security is used, only the message timestamp (TS) is included in the Security header as illustrated below:

To answer Tony’s question below, the (encrypted/signed)(parts/elements) control only the message data outside the security header that are required to be protected, they do not control how security tokens are protected inside the security header and they don’t prohibit the sender to protect message parts/elements that are not explicitly listed either. How the security tokens are protected and whether or not they are actually included in the message is controlled by security binding’s token assertion(s) and the various supporting tokens assertions. Of course you can send the message that does not have any message data signed or encrypted using the asymmetric binding if both encrypted and signed parts are empty and you are not sending any supporting tokens but there will still be wsu:Timestamp element inside the security header that needs to be signed according to the processing rules if the [timestamp] property is set to TRUE. And if wsu:Timestamp is not included then there is no point to use the security binding at all, because in this case the message will be very likely without any security header.

From: Symon Chang [mailto:sychang@bea.com]
Sent: Monday, January 29, 2007 4:41 PM
To: Tony Gullotta; 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,

I am also very interested to learn the rules and logic behind your e-mail message. If the asymmetric binding requires to sign and encrypt both sides, then why we have assertions like: <sp:InitiatorEncryptionToken> + <sp:RecipientSignatureToken> or <sp:InitiatorSignatureToken>+ <sp:RecipientEncryptionToken> in the asymmetric binding?

If creating EncryptedSupportingTokens assertion will open a whole class of attacks, then why we have SupportingTokens assertion? EncryptedSupportingToken assertion is more secure than SupportingTokens assertion, isn’t it? Also, are you saying that our TC only support signing, all the messages have to be signed in order to be security policy compliant?

Symon Chang

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

Jan, out of curiosity what asymmetric binding rules are you speaking of. I thought the asymmetric binding lays out how to use tokens for enc/sig but unless there is an encryptedElements, encryptedParts, signedElements, or signedParts, you're not "required" to sign and encrypt the request and reply.

From: Jan Alexander [mailto:janalex@microsoft.com]
Sent: Monday, January 29, 2007 2: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:

The existing service only support WSS 1.0, and cannot migrate to WSS 1.1 for all the clients at the same time easily.
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.

ws-sx message

6.2 [Timestamp] Property