The token may or may not need to be encrypted on top of being signed. All tokens red to be signed.
If the Key is asymmetric or using DH key agreement it would not need to be encrypted. If it is a symmetric key then yes you need to use encrypted key transport. The JOSE working group is working on a clean method of using JOSE fro Key transport. We should align with that. In some ways ECDH-ES would be perfect for this, but I am realistic about adoption. If we fall back to regular DH then if RS's have a way of communicating there DH info to the AS then when the client requests a token providing it's DH info the server can place that in the token and return the RS's info in a separate parameter to the client and the key is never sent over the wire, so no encryption needed. One problem is that who the intended RS is may be a touch vague in OAuth. (This affects both key transport and agreement.) so the AS may not know what the RS is if it is not explicit in the scope. That may lead us to make asymmetric keys (including the public key of the client) as the default as that is the only one that works with both known and unknown RS. You could design a DH floe to work where the RS on request failures provides its DH info and then the client passes that and it's info to the AS in the token request. That works but sort of messes up the flow. John B. On 2013-02-12, at 7:06 AM, William Mills <wmills_92...@yahoo.com> wrote: > For key exchange that's true for symmetric key, but no key exchange is > required for public key signing by the client. > > There's so many possibilities here, but I think the best is that the key > materiel is conveyed in the token. The key could be included directly, or > another way to implement would be that a salt is included in the token and > then the secret is some crypto hash of the token contents and a shared secret > between the AS and the PR. > > If we we must pick one I'd say include the signing key as part of the > encrypted token itself. Completely self contained then. > > From: Hannes Tschofenig <hannes.tschofe...@gmx.net> > To: William Mills <wmills_92...@yahoo.com> > Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; IETF oauth WG > <oauth@ietf.org> > Sent: Tuesday, February 12, 2013 1:44 AM > Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - > 11th February 2013 > > Hi Bill, > > On Feb 12, 2013, at 11:27 AM, William Mills wrote: > > > Is key distribution how AS and PR share keys for token > > encryption/decryption or specifically about the keys for the HOK tokens? > > > In order for the client to compute the keyed message digest it needs to have > the session key. This session key is sent from the authorization server to > the client and everyone on the call agreed that this has to be standardized. > > The resource server who receives the message from the client also needs to > have the session key to verify the message. How the resource server obtains > this session key was subject for some discussion on the call. I presented > three different ways of how the resource server is able to obtain that key. > We have to decide on one mandatory-to-implement mechanism. The open issue is > which one? > > > For the MAC token spec, I don't actually care whether we use JSON or now, > > but I'm in full agreement that we do NOT duplicate any HTTP info into the > > JSON. Just signatures of that stuff. > > > I believe the folks on the call also agreed with you on that aspect that the > content of the HTTP message should not be replicated in the JSON payload > itself. > > Ciao > Hannes > > > From: Hannes Tschofenig <hannes.tschofe...@gmx.net> > > To: IETF oauth WG <oauth@ietf.org> > > Sent: Tuesday, February 12, 2013 1:10 AM > > Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - > > 11th February 2013 > > > > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
