[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Web Services Security Username Token Profile
Addressed in draft 2 of WSS-UsernameToken Profile
Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
|---------+---------------------------->
| | Gene Thurston |
| | <gthurston@amberp|
| | oint.com> |
| | |
| | 01/29/2003 02:09 |
| | PM |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'Web Services Security'" <wss@lists.oasis-open.org> |
| cc: |
| 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, Sunday,
26 January 2003 (WSS-Username-11.pdf). The numbers in parentheses
represent the line numbers from the PDF file. A lot of these are simple
typos, clarifications, corrections ... but some of them are a little more
substantive. I would especially appreciate any feedback on the last one,
below, which discusses something that I think Ron brought to my attention
in Baltimore -- use of a signature with the Username token instead of
supplying the password (or digest). Anyway, here goes:
(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-----
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