[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
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]