The draft states that the password is optional. And only when the
password is present are the optional nonce and time stamp present.
So there seems to be a case in which only the login name is present.
Would this be encrypted?
The draft also mentions the use of a secure channel, and one example
shows the UsernameToken including a password "sent as clear text"
"over a confidential channel".
Thinking just now of how I access the WSS member pages, I use a
simple login and password. Will WSS support this quite common
mechanism of secure access?
Phil
Chris Kaler wrote:
>My assumption too was that we would be encrypting the <UsernameToken>
>element. To prevent dictionary and replay attacks, the token contains
>both a <Nonce> and a <Created> timestamp. All of this is encrypted.
>
>-----Original Message-----
>From: Jerry Schwarz [mailto:]
>Sent: Wednesday, March 19, 2003 9:27 AM
>To: Hal Lockhart; Web Services Security
>Subject: Re: [wss] Encrypting a password
>
>
>I have been assuming that the whole UserNameToken would be encrypted,
>not
>individual attributes. I don't know if its possible to encrypt
>individual
>attributes but all the examples in our drafts have been of whole
>elements.
>
>With regards to replay attacks, a UserNameToken can contain a timestamp
>and
>if the whole element is encrypted as I'm assuming then the timestamp
>will
>be as secure as the decryption key so I do't understand what a separate
>signature of the timestamp would add. Although a signature of the
>UserNameToken combined with other parts of the message might protect
>against attacks in which the encrypted UserNameToken is copied into a
>different message.
>
>
>
>At 03:15 PM 3/18/2003, Hal Lockhart wrote:
>
>
>>One of the test scenarios proposed for the interop is to pass a
>>
>>
>username
>
>
>>token with an encrypted password in it. I have been thinking about this
>>
>>
>a
>
>
>>bit recently.
>>
>>I would like to start by proposing a guiding principle. I believe that
>>
>>
>these
>
>
>>scenarios will be noted by many people and it is likely they will be
>>
>>
>taken
>
>
>>as guidelines for applying the constructs found in our specifications,
>>
>>
>in
>
>
>>some cases by those with no involvement in this TC. Therefore I
>>
>>
>propose:
>
>
>>While some of the interop tests may be purely intended to exercise
>>
>>
>features
>
>
>>of the specification, while providing little real world utility, we
>>
>>
>should
>
>
>>not propose any usage which is inherently insecure or represents poor
>>security practice.
>>
>>With this in mind, I have been thinking about encrypting a password. My
>>first observation is that if our goal is merely to test encryption and
>>decryption code for interoperability, we could easily avoid the
>>complications that follow by encrypting some user attribute instead of
>>
>>
>the
>
>
>>password. Unfortunately, the only user attribute we have in hand it the
>>Username. Why not encrypt that? That even has a plausible usecase: a
>>
>>
>user
>
>
>>who wishes to remain anonymous to third parties.
>>
>>Assuming some will still wish to encrypt a password, in the spirit of
>>
>>
>my
>
>
>>principle, I will now examine the security implications of doing so.
>>
>>First let us get clear on the motivating usecase. As Peter Dapkus has
>>pointed out, if the sender and receiver have the ability to exchange
>>encrypted data, they already have available a more secure mans of
>>Authentication than presentation of a password.
>>
>>Therefore, it only makes sense when the password is to be presented to
>>
>>
>a
>
>
>>backend system, such as a database or mainframe, that does not
>>
>>
>understand
>
>
>>the encryption. However, this case has less utility in practice than
>>
>>
>might
>
>
>>be thought. For performance reasons, a connection pool is typically
>>
>>
>used to
>
>
>>access a backend system. These connections would all be logged in to
>>
>>
>the
>
>
>>backend using some privileged account. Therefore the original user's
>>password (and identity) will not be propagated to the backend system.
>>
>>When using an encrypted password, the obvious threat is a replay
>>
>>
>attack.
>
>
>>Assuming the key remains in use for some time, it might be thought that
>>
>>
>the
>
>
>>encrypted form of the password would be the same each time. However,
>>
>>
>XML-ENC
>
>
>>specifies the use of CBC mode for either AES or 3DES. (This is not the
>>
>>
>only
>
>
>>logical possibility in this case, as the typical password is shorter
>>
>>
>than
>
>
>>the 16 octet AES block size.) It further specifies that a different,
>>
>>
>random
>
>
>>Initialization Vector (IV) must be used each time.
>>
>>However, this is not sufficient to prevent replay unless we actually
>>
>>
>check
>
>
>>to see if the IV is a duplicate. If we don't wish to save every IV we
>>
>>
>ever
>
>
>>receive, it is necessary to include a timestamp. It might also be
>>
>>
>desirable
>
>
>>to duplicate the IV into a Nonce element, just to make it easier to
>>
>>
>parse.
>
>
>>Of course, the timestamp is not worth much unless it is signed. If we
>>
>>
>are
>
>
>>doing signing, it would make just as much sense to drop the timestamp
>>
>>
>and
>
>
>>sign over the password and message body. This would leave it up to the
>>application to either detect duplicates or implement idempotent
>>
>>
>semantics.
>
>
>>The more I think about it the more I like encrypting the Username.
>>
>>Hal
>>
>>
>
>
>
>
