[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Web Services Security Username Token Profile
I just read through the Username Token Profile (as submitted initially by Phil Griffin, and updated by Tony), and have tried to itemize my comments. In general, I think this token type will be one of the first, if not the first, token type widely used by industry. I feel this way because I believe that companies have a familiarity with usernames and passwords, and have significant investments in their user repositories (“realms”) which rely on this most common form of authentication. Thus, I would be interested in working with whomever to continue to develop this particular profile.
Here are some comments (including typo’s, suggested
rewording, etc.) on the "Web Services
Security: Username Token Profile", working draft 1.1,
(General) Consistency: In some places we use the term “UsernameToken” without a space, while in others we call it “Username token” with a space and a small ‘t’ on token. (Note, that where we refer to the element name, we clearly need to use the “UsernameToken” or even “wsse:UsernameToken”, but I am referring to other places in the specification. We should pick one way of describing our tokens and stick to it. I would probably try to stick to the “Username token” syntax, and try to do the same in the other Profile documents -- e.g., “X.509 token, Kerberos token, etc.”
(16-17) Correction: Change “Web Services Security (WSS) specification” to “Web Services Security: SOAP Message Security specification”.
(33) Correction: Table of contents says “4 User Name Tokens”, while the real section 4 title is, “UsernameToken Extensions”.
(44-45) Correction: Change “Web Services Security (WSS) specification” to “Web Services Security: SOAP Message Security specification”.
(45) Suggestion: I would add something like the following to the Introduction: “More specifically, it describes how a web service consumer can supply a UsernameToken as a means of identifying the requestor by “username”, and optionally using a password (or shared secret, or password equivalent) to authenticate that identity to the web service producer.”
(66) Correction: Change “WSS-Core documents” to “Web Services Security: SOAP Message Security specification”.
(67) Typo: Missing period at end of sentence.
(70-72) Suggestion: Suggested new wording for the two sentences starting at the end of line 70: “Passwords of type wsse:PasswordText are not limited to actual passwords, although this is a common case. Any password equivalent such as a derived password or S/KEY (one time password) can be used. Having a type of wsse:PasswordText merely implies that the information held in the password is “in the clear”, as opposed to holding a “digest” of the information.”
(74-75) Suggestion: Again, suggested new wording for this sentence: “Passwords of type wsse:PasswordDigest are defined as being the Base64  encoded, SHA-1 hash value, of the UTF8  encoded password (or equivalent).”
(78) Typo: Font used for “<wsse:UsernameToken>” is not consistent.
(79) Suggestion: Change “If either of these is present ...” to “If either or both of these are present ...”
(82) Correction: Change to be: “Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )”
(85) Correction: Suggested wording change: Change “and include the digest of the combination.” to “, digest the combination using the SHA-1 has algorithm, then include the Base64 encoding of that result as the Password (digest).”
(87-89) Suggestion: I suggest replacing the last sentence in this paragraph (the “recommendation”) with something like the following:
“For web service providers to effectively thwart replay attacks, three counter measures are recommended:
1. First, it is recommended that web service providers reject any UsernameToken not using both nonce and creation timestamps.
2. Second, it is recommended that web service producers provide a timestamp “freshness” limitation, and that any UsernameToken with “stale” timestamps be rejected. As a guideline, a value of five minutes can be used as a minimum to detect, and thus reject, replays.
3. Third, it is recommended that used nonces be cached for a period at least as long as the timestamp freshness limitation period, above, and that UsernameTokens with nonces that have already been used (and are thus in the cache) be rejected.”
(95) Clarification/Correction: Change the sentence starting with, “Note that password digests should not be used unless ...”, to “Note that passwords of either type (wsse:PasswordText or wsse:PasswordDigest) can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient.”
(109-110) Correction (I believe): The recommendation listed is really only necessary for passwords of type wsse:PasswordText. I would either change the wording of the recommendation to say, “If the Type attribute is wsse:PasswordText, then it is recommended that this element only be passed when a secure transport is being used.“, or remove it entirely from here and include it under the “Description” of the wsse:PasswordText in the table between lines (116 and 117). I actually prefer the latter.
(Table between 116-117) Suggestion: In the Description of wsse:PasswordDigest, after the word “password” I suggest adding the parenthetical “(and optionally nonce and/or creation timestame)”.
(120) Correction: Change the word “header” to “element”.
(122) Typo: There is an extra slash between “UsernameToken” and “wsse:Nonce”.
(123) Suggestion: After the existing sentence, I suggest adding another sentence: “Each message including a Nonce element should use a new nonce value in order for web service providers to detect replay attacks.”
(125) Typo: There is an extra slash between “UsernameToken” and “wsse:Nonce”.
(130) Typo: There is an extra slash between “UsernameToken” and “wsu:Created”.
(131) Clarification: Should state that this timestamp is to be interpreted as the time the message is being sent from the web service consumer, or perhaps “the creation time of the message”? Maybe a reference to Appendix A of the Web Services Security: SOAP Message Security specification would be best, where it says, “The element is used to indicate the creation time associated with the enclosing context.”
(133) Clarification: I think we should clarify that compliant implementations must be able to process all of the optional elements and attributes describes here, as well. (Maybe we don’t really need to do this, but I don’t think it can hurt and it may remove some ambiguity.)
(152-153) Suggestions: I suggest rewording this sentence to be, “The following example illustrates using a digest of the password along with a nonce and creation timestamp:”
(178) Correction: Change “WS-Security specification” to “Web Services Security: SOAP Message Security specification”.
(184) Correction: Change “WS-Security tokens” to simply “SecurityTokens”.
(184-185) Suggestion: Remove the sentence, “Confidentiality is addressed directly in the Username token by using the privacy mechanisms described in WS-Security.” First of all, confidentiality is not addressed by the Username token, at all. Second, I think we are mixing up “privacy” with “confidentiality”, no?
(186) Suggestion: I think we should modify the phrase “... using message timestamps and caching ...” to be “... using message timestamps, nonces, and caching ...”
(187-188) Clarification/Correction: The sentence, “Token ownership is verified by use of keys and man-in-the-middle attacks are generally mitigated.” seems wrong. First of all, this profile never discusses the use of “keys” at all. (Mind you, it could ... I think Ron has described a mechanism for “signing” messages which contain a Username token by using a Password based encryption (PBE) algorithm where the “key” is generated based on the password. I could argue that this would represent a different “profile” for the Username token, though, since it would not require the use of nonces, timestamps, and digests to protect the password.) Second, I don’t see how man-in-the-middle attacks can be protected based solely on this profile unless either signing takes place, or a secure transport is used. Based just on the mechanisms outlined in this profile, it would seem like a man-in-the-middle could intercept the message, completely replace the SOAP Body, and then forward it on. The service side would proceed to authenticate the requestor based on the Username token information (which is not bound in anyway to the message body), and falsely assume the request (the body) was from the authenticated username. So, we either need to describe how to prevent this (like, with Ron’s PBE signature, for instance, or by use of a secure transport which has an integrity property), or state that it is an issue.
(188) Suggestion: I would suggest adding a rewording of the last sentence here to be something like, “Transport-level security may be used to provide confidentiality and integrity of both the Username token and the entire message body.”
(191) Question: Why is their a “5.1 Normative” section heading here? Are the references to other works considered “normative”?
(192-211) Typo: All of the square brackets around the reference numbers are either completely or partially missing.
(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 -
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