Hi,
[email protected] writes:
> Hi, Hannes,
>
>> The Client and the Resource Server need to obtain this session key somehow.
>> Only two mechanisms exist:
>>
>> a) Key Transport
>> b) Key Agreement
>>
>> Here a key transport based mechanism is used and that's not uncommon.
> I have no doubt about that.
> My concern is may be there are some better ways to do proof-of-posession,
> or proof-of-knowledge of keys.
Keep in mind that this is a short-lived session key that's valid only
for this client<->RS Instance. The MAC Key is tied to the Access Token,
which is (hopefully!) tied to the client_id. The MAC key is a
throw-away key. Future access tokens would use *different* MAC Keys.
Please take a look at the Kerberos Authenticator for prior art that
explains how this works.
> For example, as I wrote in the review of draft-tschofenig-oauth-security-00:
> client send H(R) in token request to AS, AS includes the H(R) in the token,
> and client sends (token,R) to RS,
> RS can verify the access capablity by recalculating H(R) and checking access
> toekn,
> by feature of hash, RS can trust R provider,this method does not use
> pre-shared key between AS and RS.
Sure, this works for a single request. However it also means you need
to have the AS involved in *every* request because you cannot reuse R.
Another option would be:
AS sends an Access token, encrypted to the RS, and includes a MAC
Session Key (Kms). The Client can send the token, a Nonce (N), and N
encrypted with Kms ({N}Kms) to prove posession of Kms. Of course to
protect replay attacks the RS has to keep a cache of all Nonces used
under Kms.
>> > Since distributing shared keys between AS and RS is already a
>> cubersome work,
>> > sending key to client implies the key is only one time thing, that
>> will further increase the complexity.
>> >
>> An authentication and key exchange protocols is a complex thing.
>> No doubt about that.
>
> But Oauth is aimed at simple solutiion and better user experience.
> An AKE and be complex, but some AKE can be simpler than others, depending on
> requirements.
Do you have a particular use-case in mind?
-derek
--
Derek Atkins 617-623-3745
[email protected] www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
