Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

> It could even, theoretically, be included in the Access Token! It certainly could, this is the simplest form of holder of key in fact. From: Derek Atkins To: Hannes Tschofenig Cc: "oauth@ietf.org" Sent: Monday, September 10, 2012 6:14 AM Subject: Re: [OAUT

Re: [OAUTH-WG] draft-ietf-oauth-revocation-00

Revocation endpoint discovery can be handled through standard discovery mechanisms.  I don't think clients should request revocation (see earlier message). From: Hannes Tschofenig To: "oauth@ietf.org WG" Sent: Monday, September 10, 2012 5:25 AM Subject: [OAU

Re: [OAUTH-WG] draft-ietf-oauth-revocation-00

Well, the only way the client would request revocation is if the client thinks the token is compromised, e.g. that the client has done dumb stuff.  In that sense I think the client requesting revocation makes no sense.   I am also not in favor of token introspection endpoints at all, the client

[OAUTH-WG] Comments on Dynamic Registration

Hi. Sorry that I have not been actively monitoring / commenting on the draft. I still have not looked at it in detail, but here are some of the comments that I have now: General Instead of XML, I suggest using a JSON format, as OAuth 2.0 is all JSON at this point. OpenID Connect ha

Re: [OAUTH-WG] OAuth Security Discussions

Since it is prefered to have long lived key shared between AS and RS in this WG, Is there any consideration for this key distribution and its security requirements? oauth-boun...@ietf.org 写于 2012-09-06 22:25:03: > Hi all, > > following the discussions at the last IETF meeting and the weeks

Re: [OAUTH-WG] some comments Re: OAuth Security Discussions

> > > > The example of asymmetrical key is flawed. Without trust (e. > g. Certificate) implemented, Client can use any pk/sk generated by > itself to confirm > > its knowledge of sk. > > It is perfectly fine but there are obviously lots of details > missing. If you look at http://tools.i

[OAUTH-WG] 答复: Re: 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

Derek Atkins 写于 2012-09-10 21:23:12: > Hannes Tschofenig writes: > > > I am sure that we can come up with many different protocols; the > area of key agreement protocols isn't necessarily a new one. > > > > (What by the way is "H(R)" standing for?) > > I'm pretty sure he means Hash of R. E

[OAUTH-WG] 答复: Re: 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

Hannes Tschofenig 写于 2012-09-10 18:26:56: > I guess I figured it out. H(R) is the hash of a random number. Yes. > > The issue with this approach is that the Client can only use the > Access Token once with your approach. access token generally have time limit from a few minutes to 1 hour. a

[OAUTH-WG] 答复: Re: 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

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. > > P

Re: [OAUTH-WG] some comments Re: OAuth Security Discussions

Hi, Hannes, Hannes Tschofenig 写于 2012-09-10 17:39:28: > Hi Zhou, > > > On Sep 7, 2012, at 6:23 AM, zhou.suj...@zte.com.cn wrote: > > > > > 1. Section 4“A Resource Server must not be allowed to accept > access tokens that are not meant for its consumption.” > > says Resource Server a

Re: [OAUTH-WG] draft-ietf-oauth-revocation-00

+1 Am 10.09.2012 15:49, schrieb Justin Richer: That requires the client and/or resource server to run an endpoint of their own at all times, and it requires the AS to keep track of all instances of a client and RS. This isn't likely to be particularly desirable, scalable, or usable. I don't se

[OAUTH-WG] OAuth Assertion Framework draft -05

Draft 05 of the Assertion Framework for OAuth 2.0 has been published. It contains non-normative editorial changes to improve readability. The draft is available at: * http://tools.ietf.org/html/draft-ietf-oauth-assertions-05 An HT

[OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Assertion Framework for OAuth 2.0 Author(s) : Brian Campbell C

Re: [OAUTH-WG] draft-ietf-oauth-revocation-00

That requires the client and/or resource server to run an endpoint of their own at all times, and it requires the AS to keep track of all instances of a client and RS. This isn't likely to be particularly desirable, scalable, or usable. I don't see too much harm in trying to define it, but I do

[OAUTH-WG] Planning for IETF 85

Hi, It's that time again, time to start planning for the next IETF. IETF 85 will take place in November in Atlanta, Georgia. I'd like to ask of all our document editors: 1) will you be attending? 2) how much time do you need to summerize the status of the document? Also, is there anyone who wa

Re: [OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

Hannes Tschofenig writes: > I am sure that we can come up with many different protocols; the area of key > agreement protocols isn't necessarily a new one. > > (What by the way is "H(R)" standing for?) I'm pretty sure he means Hash of R. E.g. you send the SHA-1 Hash of R as a commitment of R

Re: [OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

Hi, zhou.suj...@zte.com.cn 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 doub

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hannes Tschofenig writes: > Hi Zhou, > > here is the story. > > The Authorization Server gives an Access Token to the Client and the client > presents that Access Token to Resource Servers. > This has not changed in comparison to Bearer Tokens. > > However, in addition to just presenting the

[OAUTH-WG] draft-ietf-oauth-revocation-00

The current draft defines an additional endpoint, the token revocation endpoint, so that clients can request the revocation of a particular token. Wouldn't it make sense to also allow Authorization Servers to tell Clients or Resource Servers to revoke tokens? Ciao Hannes __

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi Zhou, On Sep 10, 2012, at 11:46 AM, zhou.suj...@zte.com.cn wrote: > > Hi, Hannes, > Thank you for the clarity. > Yes, it makes sense. > Then http-mac and hot-sk are quite similar. Why do redundant work? > Even though the two solutions fall in the same category does not mean that

Re: [OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

I guess I figured it out. H(R) is the hash of a random number. The issue with this approach is that the Client can only use the Access Token once with your approach. Of course, one could extend the approach to a hash chain and then disclose the reverse hash chain. Still, this approach requir

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Yes, with the solutions in Section 4.3 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 the Client has to use keying material. With the solution in Section 4.1 of the same document they don't. On Sep 10, 2012, at 12:40 PM, zhou.suj...@zte.com.cn wrote: > But in http-mac, an

Re: [OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

Hi Zhou, On Sep 10, 2012, at 12:32 PM, zhou.suj...@zte.com.cn wrote: > > 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 mecha

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hannes Tschofenig 写于 2012-09-10 17:04:48: > Hi Sergey, > > > > In our case we have structured access tokens and MAC key is simply > > treated as an extra token property > > > Since the token is opaque to the Client a key transported inside the > Access Token (hopefully encrypted) can only be

Re: [OAUTH-WG] some comments Re: OAuth Security Discussions

Hi Zhou, On Sep 7, 2012, at 6:23 AM, zhou.suj...@zte.com.cn wrote: > > 1. Section 4“A Resource Server must not be allowed to accept access > tokens that are not meant for its consumption.” > says Resource Server authentication to Client is a must. Here is what I wrote: " An Autho

[OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01

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 a

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi Sergey, > In our case we have structured access tokens and MAC key is simply > treated as an extra token property > Since the token is opaque to the Client a key transported inside the Access Token (hopefully encrypted) can only be meant for consumption by the Resource Server. But you are

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi Zhou, On Sep 10, 2012, at 11:51 AM, zhou.suj...@zte.com.cn wrote: > > And I don't think sending client the mac key or hot-sk is good. 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 t

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi Hannes On 10/09/12 09:06, Hannes Tschofenig wrote: > Hi Zhou, > > here is the story. > > The Authorization Server gives an Access Token to the Client and the client > presents that Access Token to Resource Servers. > This has not changed in comparison to Bearer Tokens. > > However, in addit

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

And I don't think sending client the mac key or hot-sk is good. 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. ZhouSuJing00132831/user/zte_ltd 写于 2012-09-10 16

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi, Hannes, Thank you for the clarity. Yes, it makes sense. Then http-mac and hot-sk are quite similar. Why do redundant work? Hannes Tschofenig 写于 2012-09-10 16:06:34: > Hi Zhou, > > here is the story. > > The Authorization Server gives an Access Token to the Client and the > client

Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi Zhou, here is the story. The Authorization Server gives an Access Token to the Client and the client presents that Access Token to Resource Servers. This has not changed in comparison to Bearer Tokens. However, in addition to just presenting the Access Token by the Client to the Resource

[OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01

Hi, I have a question concerning draft-ietf-oauth-v2-http-mac-01： The propose is that Client obtains MAC credentials (i.e., MAC keys) from Resource Server first, then Client genertate MAC access token using MAC keys, and send MAC access token to RS, RS recalculates MAC access token to ver