Issue PR012
From: Symon Chang
[mailto:sychang@bea.com]
Sent: Wednesday, January 24, 2007 11:17 AM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Hal Lockhart
Subject: [ws-sx] NEW Issue: Need policy example for encrypted username
token
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/21836/UseCases-Examples-6-06-draft-10-02-distr-tc.doc
Artifact: examples
Type: design
Title: Need policy example for encrypted username token
One the examples document, we have insecure example of Username Token policy, but no simple encrypt password policy on Username token. This is a must-to-have scenario to be shown in the example document.
Description:
On the Security Policy Examples document, there is
an example of unencrypted plain text Username Token policy on 2.1.1.1, but
there is no example for encrypted plain text Username Token policy.
Sending unencrypted password text, as showed on
2.1.1.1, is not a secure way to handle the Username Token. The example should
not be advertised as the only way to handle plain text password.
We do have an encrypted plain text password policy
on section 2.1.3 -- “(WSS 1.0) UsernameToken with Mutual X.509v3
Authentication, Sign, Encrypt”. However, this example requires signature.
It is more complicated.
Encrypted support token without signature is a very
common use case. It is documented on the first WS-Security Interop Scenarios
Document [WSS10-INTEROP-01 Scenario 1 – section 4.4.4] (http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf
).
This is a real requirement for this use case
scenario in the field, too. If a client does not have its own private key then
the Username Token is the only way for authentication. If the server cannot
accept digested password, then encrypted password is the only way to secure
authentication. The client does not have key for signature, SignedEncryptedSupportingTokens
assertion is not an alternative in this scenario.
Related issues:
EncryptedSupportingTokens assertion.
Proposed Resolution:
We should provide a simple policy example for
sending encrypted password over the SOAP message, and make a comment on the
example of section 2.1.1.1 is not a secure way.
Just like the WSS 1.0 Interop scenario document, a
more secure example of handle Username Token should be followed after section
2.1.1.1.
_______________________________________________________________________
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.