RE: [ws-sx] Issue PR012: Need policy example for encryptedusername token

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:] 

Sent: Friday, January 26, 2007
10:50 AM

To: Ashok Malhotra; Anthony
Nadalin; Greg Carpenter; Hal Lockhart; Marc Goodner; 

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:] 

Sent: Friday, January 26, 2007
10:21 AM

To: Anthony Nadalin; Greg
Carpenter; Hal Lockhart; Marc Goodner; Symon Chang; 

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:] 

Sent: Friday, January 26, 2007
9:18 AM

To: Greg Carpenter; Hal Lockhart;
Marc Goodner; Symon Chang; 

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 <>

 

  
  
Greg
  Carpenter <> 

  
01/26/2007 10:45 AM

  
  
  
   

    
    

    
To

    
    
    

    Symon Chang
    <>, ""
    <>

    
   

   

    
    

    
cc

    
    
    

    Marc Goodner
    <>, Hal Lockhart <>

    
   

   

    
    

    
Subject

    
    
    

    [ws-sx] Issue
    PR012: Need policy example for encrypted username token

    
   

  
  
 

  
   

    
    

    
    
    

    
   

  
  

  
 

Issue PR012

From: Symon Chang [mailto:] 

Sent: Wednesday, January 24, 2007 11:17 AM

To: 

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.