OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-sx] Issue PR012: Need policy example for encrypted usernametoken


Hi Symon, (also a question for Martin below)

Thanks for suggested use case to add to the WS-SP Examples document. I think
it clearly fits within the guidelines of the doc abstract in that it is a known interop
use case scenario, and as you explain, it adds significant useful protection and expands
the breadth of WSS10 UsernameToken coverage.

The only drawback is that it is tied to adding a new element that you ref
in Issue PR013.

I did a little research and am suggesting a possible alternative mechanism
to address this problem. Issue 115 resulted in the following text being
added to WS-SP section 5.3.1 description of UsernameToken:

  "When the UsernameToken is to be encrypted it SHOULD be listed as a 680
    SignedEncryptedSupportingToken (Section 8.5), EndorsingEncryptedSupportingToken (Section 8.6) or 681  
    SignedEndorsingEncryptedSupportingToken (Section 8.7). 682"

It would appear to me that based on section D.4 that refers back here that
if the UsernameToken was included as an EndorsingEncryptedSupportingToken
that this would do the job. I am saying this based on Martin's suggestion
that was part of the basis for adding this text to 5.3.1:

    http://www.oasis-open.org/archives/ws-sx/200610/msg00053.html

The only concern I have with this is that I do not understand how a
UsernameToken can be an "Endorsing" token, which according to
sections 8.3 and 8.6:

    "Endorsing tokens sign the message signature"

If the endorsing token is a UsernameToken, I do not understand how
it can "sign the message signature", or have I missed something here?

Possibly the text in 5.3.1 is meant to imply signing is obviously not
required in this case? (This is the question for Martin!)

In any event, I also agree with Ashok, that if you want to add this example
that it would be desirable if you could supply a suggested section
that we could just drop into the document if the TC agrees that the
example should be added.

Also, I think that the issue about how this token gets encrypted within
the guidelines of ws-sp needs to be addressed either by adding the
new Supporting token type or the mechanism possibly that resulted
from issue 115 or some other mechanism.

Also, it would probably be useful to understand why going to WSS 1.1
and using the symmetric key mechanisms there would not be an
acceptable alternative.

    Thanks,
    Rich


Ashok Malhotra wrote:

OK.  If you write the policy for this usecase, we will add it to the usecases document.

All the best, Ashok


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.

All the best, Ashok


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
Inactive hide details for Greg Carpenter <gregcarp@microsoft.com>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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]