Title: RE: [wss] Web Services Security Username Token Profile
Yes, I agree with you, Gene.
We can certainly define specialized versions of KeyInfo
since it is extensible for PBE and in this way achieve
Password token binding similar to other tokens (e.g.,
SAML).
This would be a fine approach for a new token profile
although I am concerned the more tokens we have the
more interop concerns there will be.
thanks,
Zahid
-----Original Message-----
From: Gene Thurston [mailto:]
Sent: Wednesday, January 29, 2003 1:53 PM
To: 'Ahmed, Zahid'; 'Web Services Security'
Subject: RE: [wss] Web Services Security Username Token Profile
Thanks for the comments, Zahid.
I agree that in practice SSL/TLS can, and will often (usually?), be used
to provide these capabilities. I still believe, however, that we should
address cases where transport level security is either not an option, or
for some other reason (application specific, perhaps) is not being used.
On the XML Signature spec, the use of other algorithms will not break
our compliance with the standard. While the spec does define
identifiers for the DSA and RSA algorithms, it is intended to be
extensible: "... the mechanism is extensible; alternative algorithms may
be used by signature applications." This is analogous to the extensions
in the <ds:KeyInfo> element, or the definition of Transform URIs, both
of which we are currently planning to use for SecurityTokenReferences.
I actually have no problem with your idea of keeping the existing
Username token profile (using nonce, creation timestame, digests, etc.),
and perhaps adding a second Username profile which would provide the
binding with the message. This was, in fact, where my thinking was
headed, as well.
I do think, however, that we need to point out the security issues in
the Threat Model, and at least state that secure transports can
alleviate these concerns. (But, then again, if you are using a secure
transport, why bother doing anything more than sending the password in
clear text?)
Thanks, again,
- Gene -
-----Original Message-----
From: Ahmed, Zahid [mailto:]
Sent: Wednesday, January 29, 2003 1:09 PM
To: 'Web Services Security'
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:]
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:]
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
