[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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] 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] 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] 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:
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] 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] Issue PR013 From: Symon Chang
[mailto:sychang@bea.com]
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]