RE: [ws-sx] Issue 115: Universal Encryption of Username Token seems wrong.

["Hal Lockhart" <hlockhar@bea.com>]

Yes, I have no objection to ALLOWING anything to be encrypted. What I
objected to in D.4 # 3 was that the UT was REQUIRED to always be
encrypted in the absence of any specific assertion in the security
policy.

Hal

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: Friday, October 27, 2006 2:01 AM
> To: Marc Goodner; Hal Lockhart; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Issue 115: Universal Encryption of Username Token
> seems wrong.
> 
> Hal,
> 
> Sorry this has taken me so long to respond to. Here is a proposal for
> issue 115;
> 
> Add text to Section 5.3.2 UsernameToken Assertion along the following
> lines;
> 
> In the following cases it is reasonable to encrypt the UsernameToken;
> 
>         1.      When a plaintext password is used
>         2.      When a weak password hash is used
>         3.      When the username needs to be protected (e.g. for
privacy
> reasons)
> 
> In such cases, the username token should be listed as a
> SignedEncryptedSupportingToken (Section 8.5),
> EndorsingEncryptedSupportingToken (Section 8.6) or
> SignedEndorsingEncryptedSupportingToken (Section 8.7).
> 
> Let me know what you think.
> 
> Gudge
> 
> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com]
> Sent: Wednesday, October 11, 2006 6:32 AM
> To: Hal Lockhart; ws-sx@lists.oasis-open.org
> Subject: [ws-sx] Issue 115: Universal Encryption of Username Token
seems
> wrong.
> 
> Issue 115
> 
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Tuesday, October 10, 2006 1:49 PM
> To: ws-sx@lists.oasis-open.org
> Cc: Marc Goodner
> Subject: New Issue: Universal Encryption of Username Token seems
wrong.
> 
> 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/committees/download.php/20578/ws-securitypolic
> y-1.2-spec-ed-01-r10-diff.pdf
> 
> Artifact:  spec
> 
> Type:
> 
> [design]
> 
> Title: Universal Encryption of UsernameToken (as specified by Appendix
> D, d.4, 3.) seems wrong.
> 
> Description:
> 
> Appendix D, Section D.4 is "Elements that are encrypted"
> 
> 3. says "Any wsse:UsernameToken when a transport binding is NOT being
> used."
> 
> This seems wrong on several counts.
> 
> Presumably the intent is to protect a cleartext password.
> 
> 1. It makes no sense to routinely encrypt the Username and has
negative
> effects in some cases.
> 
> 2. When a hashed password is used it makes no sense to routinely
encrypt
> the password.
> 
> 3. When there is no password or password derivation is used, there is
no
> password present and it makes no sense to routinely encrypt what is
> present.
> 
> 4. When a UsernameToken is used as a supporting token to indicate a
> proxied identity in conjunction with a signing token, (see for example
> the WS-I Sample Apps) then it is critical that the signature include
the
> Username, but encrypting it still makes no sense and may cause
problems.
> 
> Note that I am not suggesting we prohibit encrypting these things,
just
> that encryption should not be the default. Encryption of anything in
the
> Security header can still be specified with a EncryptedElements
> assertion.
> 
> Finally, if this section is intended to be normative (see my next
issue)
> then it should use the RFC 2119 keywords rather than a phrase like "
> Elements that are encrypted".
> 
> Related issues:
> 
> The next higher one than this one relating to whether Appendix D is
> normative.
> 
> Proposed Resolution:
> 
> Alter or drop rule D.4, 3.