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

  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.