Hi,
>
> 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.
I have no doubt about how it 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.
Prove knowledge of key by encryption is not a good idea,as you mentioned,
for having to
keep a cache.
> >> > 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?
No.
> -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
