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 115: Universal Encryption of Username Token seemswrong.


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.


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