Open Stack

On 01/24/2013 04:06 AM, David Chadwick wrote:
>
>
> On 24/01/2013 00:50, Adam Young wrote:
>>>
>>> By the way, introducing holder of key into tokens solves the bearer
>>> problem and does not require SSL/TLS. What it requires is simply that
>>> the client signs the message containing the token with the key and
>>> includes a nonce/timestamp in the signed message so that the recipient
>>> can validate that the user is the holder of the token and the token
>>> has not been replayed.
>> Are you saying that the whole web requests would then be signed? Yes,
>> that would work, and would be very effecient, but it would require
>> extending all of the HTML aware parts to allow for signatures. I think
>> that would be a  very valuable extension.
>
> The body of the POST needs to be signed. This does not stop a MITM, 
> but then neither does SSL if you have a forged cert in the name of the 
> sender.
>
> David

Just thinking this through:

Keystone still is the authority on keys and signing, so I think this 
might actually prevent a man-in-the-middle attack.  The key signed in 
the token is the one used to sign the message.  The token is signed by 
the keystone server.  The token is authenticated against keystone.   So 
a man in the middle either has to try to use the secret key associated 
with the public key from the token, which they won't have access to, or 
they have to inject their own key.

If they inject their own key, they need to get a new token.  Which means 
they would need to convince Keystone that they are the original user, 
and that keystone should sign a different key.  That is a pretty high 
barrier to overcome.


Am I missing something?