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