[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:firstname.lastname@example.org] Sent: Wednesday, October 11, 2006 6:32 AM To: Hal Lockhart; email@example.com Subject: [ws-sx] Issue 115: Universal Encryption of Username Token seems wrong. Issue 115 -----Original Message----- From: Hal Lockhart [mailto:firstname.lastname@example.org] Sent: Tuesday, October 10, 2006 1:49 PM To: email@example.com 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.