[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Web Services Security Username Token Profile
Generally, I don't think it is a good idea to coerce Password tokens to behave like other types of tokens that require proof of possession or evidence of holding the (signing) key. I do, however, appreciate the motivation of securely binding the Password token to a part of SOAP message such that we can protect the integrity of token association with the message indepedent of the transport protocol used to transmit the SOAP message. We can also argue that encryption of password is required independent of transport security. However, in practice, the SSL/TLS transport is sufficient in both of these problem domains. I'm also concerned that we do not want to generate signature using PBE algorithm (using the Password in Password token) if it will imply not being compatible with W3C XML Signature which specifies use of DSA (required) and RSA algorithms (optional). Perhaps we could consider this as new token profile, but keep the basic password token profile scope as is. thanks, Zahid -----Original Message----- From: Gene Thurston [mailto:gthurston@amberpoint.com] Sent: Wednesday, January 29, 2003 12:10 PM To: 'Web Services Security' Subject: RE: [wss] Web Services Security Username Token Profile Colleagues, [.......] (General) Discussion: Overall, while I think that this token profile will be widely used (perhaps the first one to be widely used, since folks are generally familiar with, and have large databases of, username/password pairs), I see that its main weakness is the lack of binding the token to the message "request" or "response" (that is, some part of the message body which represents what the username is "saying". While it is true that using a secure transport (such as HTTP over SSL) can provide this, there is an alternative approach, which in some sense fits in better with the overall WS-Security processing model of using signatures to provide this "binding". (Of course, signatures also provide evidence of the "claims" asserted by the presence of various tokens.) So, I think another profile here, surrounding the Username token goes something like this: * Username token only carries the username. (The implicit claim here is that the user named is the "sender", I suppose.) * A signature is included using a PBE algorithm, and signs that portion of the body that the "sender" is stating ... typically, the message Body. * The signature may also sign the timestamp header (described in Appendix A of the Web Services Security: SOAP Message Security specification) to combat replay attacks. (Side note: Shouldn't we add a general <wsu:Nonce> element as a header which can be used by *all* types of tokens?) * The <ds:KeyInfo> element of the signature will use a <wsse:SecurityTokenReference> to the Username token. * The "key" associated with that token will be generated based on the mutually shared secret password (or equivalent) using a standard PBE algorithm. It seems to me that the user interaction in this scenario will still look the same: Need a username and password. But, that the processing model is now a lot more consistent with the other kinds of security tokens we expect to see. Basically, while I don't believe we have come right out and said so, I think *all* of the token types we have considered can be thought of as "Key Holders" ... either a key is explicitly embedded in the token (ala, X.509 certificates), or a key is somehow implicitly represented or can be generated. Am I way off base here? That's about it. Thanks for playing! - Gene Thurston - AmberPoint, Inc. -----Original Message----- From: Anthony Nadalin [mailto:drsecure@us.ibm.com] Sent: Tuesday, January 28, 2003 6:33 AM To: Web Services Security Subject: [wss] Web Services Security Username Token Profile Here is the UsernameToken update that Phil created it was edited to be in line with the WSS-Core-09 update. (See attached file: WSS-Username-11.pdf) Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC