From: Symon Chang
[mailto:sychang@bea.com]
Sent: Friday, January 26, 2007
10:50 AM
To: Ashok Malhotra; Anthony
Nadalin; Greg Carpenter; Hal Lockhart; Marc Goodner; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue PR012:
Need policy example for encrypted username token
Use case 2.1.2.1 the plain text password
is protected by SSL. Use case 2.1.3 is good, but it required the client to have
certificate for signature.
If SSL is the recommended way to protect
plain text password, then we don’t need to have WSS. If the client has
the private key, it can use X509 Token Profile for authentication instead.
Therefore, both use case does not apply to the scenario that I requested. The
use case I want is plain text password, and the client does not have the key to
sign. This should be a very common use case for Web Services, isn’t it?
Also, I think the security is a far more
important issue than interoperability. Why we cannot show a best security
practice in the Example Document, and only shown an insecure example in section
2.1.1.1 for interoperability?
Best Regards,
Symon
Chang
From: Ashok Malhotra
[mailto:ashok.malhotra@oracle.com]
Sent: Friday, January 26, 2007
10:21 AM
To: Anthony Nadalin; Greg
Carpenter; Hal Lockhart; Marc Goodner; Symon Chang; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue PR012:
Need policy example for encrypted username token
I’m not sure what is meant by
“the example document” but the usecases document that we have
submitted contains usecase 2.1.2.1 and 2.1.3 which feature encrypted username
tokens.
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Friday, January 26, 2007
9:18 AM
To: Greg Carpenter; Hal Lockhart;
Marc Goodner; Symon Chang; ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue PR012:
Need policy example for encrypted username token
Why is this a must to have example ? as there are lots
of things that the we have done in the interop that are not shown as examples.
I would have expected this to have shown up as a interop issue if it was
important
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Greg Carpenter <gregcarp@microsoft.com>
Greg
Carpenter <gregcarp@microsoft.com>
01/26/2007 10:45 AM
|
To
|
Symon Chang
<sychang@bea.com>, "ws-sx@lists.oasis-open.org"
<ws-sx@lists.oasis-open.org>
|
cc
|
Marc Goodner
<mgoodner@microsoft.com>, Hal Lockhart <hlockhar@bea.com>
|
Subject
|
[ws-sx] Issue
PR012: Need policy example for encrypted username token
|
|
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.