Who has a rather detailed description about the three key distribution
machanisms?
Please tell me if I am wrong in understanding them only from the ppt and
previouse mac and hotk document:
1. The key distributuon means AS distributing a short-term-key to client
and RS;
2. AS and RS has another way of sharing a long-term-key which is not
covered by the design team;
3. Client-AS and Client-RS may have their ways of authentication not
using the short-term-key;
4. short-term-key is only used for protecting access token from being
stolen or abused by entities other than the client(as bear token);
then there are 3 possible approaches for generating an access token
(suppose short-term-key is irrelevant with long-term-key):
1) access token=F(...,short-term-key) // not secure, and equivalent to
the case that access token being short-term-key
2) access token=F(...,longt-term-key) //pass. for no short-term-key is
invloved
3) access token=F(...,short-term-key,long-term-key)// I guess this case
is the base on which the design team is discussing ?
Based on the above pre-assumption,the following is my opinion on the 3
key distribution mechanisms:
key-transport: in this meachanism short-term-key is transported from AS to
client, then to RS,
short-term-key could be transported inside or outside of
access token, which is no big difference,
the security of this mecha is actually guaranteed by
long-term-key;
key-retrieval: short-term-key is obtained from AS by RS directly, it is
more secure, but need an extra information exchange between RS and AS each
time Client is requesting resource to RS.
key-agreement: short-term-key could be derived from long-term-key and some
other information included in (or accompanying) access token,
this mecha is actually not different from case 2) above,
that is no short-term-key is required to send actually.
oauth-boun...@ietf.org 写于 2013-02-12 17:10:27:
> Here are my notes.
>
> Participants:
>
> * John Bradley
> * Derek Atkins
> * Phil Hunt
> * Prateek Mishra
> * Hannes Tschofenig
> * Mike Jones
> * Antonio Sanso
> * Justin Richer
>
> Notes:
>
> My slides are available here: http://www.tschofenig.priv.at/OAuth2-
> Security-11Feb2013.ppt
>
> Slide #2 summarizes earlier discussions during the conference calls.
>
> -- HTTP vs. JSON
>
> Phil noted that he does not like to use the MAC Token draft as a
> starting point because it does not re-use any of the work done in
> the JOSE working group and in particular all the libraries that are
> available today. He mentioned that earlier attempts to write the MAC
> Token code lead to problems for implementers.
>
> Justin responded that he does not agree with using JSON as a
> transport mechanism since this would replicate a SOAP style.
>
> Phil noted that he wants to send JSON but the signature shall be
> computed over the HTTP header field.
>
> -- Flexibility for the keyed message digest computation
>
> From earlier discussion it was clear that the conference call
> participants wanted more flexibility regarding the keyed message
> digest computation. For this purpose Hannes presented the DKIM based
> approach, which allows selective header fields to be included in the
> digest. This is shown in slide #4.
>
> After some discussion the conference call participants thought that
> this would meet their needs. Further investigations would still be
> useful to determine the degree of failed HMAC calculations due to
> HTTP proxies modifying the content.
>
> -- Key Distribution
>
> Hannes presented the open issue regarding the choice of key
> distribution. Slides #6-#8 present three techniques and Hannes asked
> for feedback regarding the preferred style. Justin and others didn't
> see the need to decide on one mechanism - they wanted to keep the
> choice open. Derek indicated that this will not be an acceptable
> approach. Since the resource server and the authorization server
> may, in the OAuth 2.0 framework, be entities produced by different
> vendors there is an interoperability need. Justin responded that he
> disagrees and that the resource server needs to understand the
> access token and referred to the recent draft submission for the
> token introspection endpoint. Derek indicated that the resource
> server has to understand the content of the access token and the
> token introspection endpoint just pushes the problem around: the
> resource server has to send the access token to the authorization
> server and then the resource server gets the result back (which he then
a
> gain needs to understand) in order to make a meaningful
> authorization decision.
>
> Everyone agreed that the client must receive the session key from
> the authorization server and that this approach has to be
> standardized. It was also agreed that this is a common approach
> among all three key distribution mechanisms.
>
> Hannes asked the participants to think about their preference.
>
> The questions regarding key naming and the indication for the
> intended resource server the client wants to talk to have been
postponed.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
