[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Web Services Security Username Token Profile
Colleagues, 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 [16] encoded, SHA-1 hash value, of the UTF8 [17] 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 - AmberPoint, Inc. -----Original Message----- 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