Hi Hannes
On 27/11/12 18:54, Hannes Tschofenig wrote:
Good that you both raise this point. The refresh token mechanism allows us to 
request new access tokens (and new keying material correspondingly since the 
two are tight together) in a dynamic fashion. If you turn the MAC key into a 
long term secret or use it with multiple resource servers then you obviously 
loose the security benefits.

IMHO, the MAC key is the property of the individual access token and thus does not have to be turned into a long term secret. Re using it multiple servers: recall my point about using a given token for the specific deployment/case - if the use of MAC tokens is not the right thing to do in the advanced deployments - lets have some advice on that.

I'd even compare the use of MAC as compared to other more sophisticated tokens to the implicit vs authorization code flow. The former is assumed to be less secure than the latter - nonetheless both are supported by the spec - it is about using the right flow for the right deployment and being aware of the relevant security threats.

Cheers, Sergey


All this is documented in Section 5 of 
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00#section-5

On Nov 27, 2012, at 7:59 PM, William Mills wrote:

Yes!

The other thing that is better in the OAuth 2 model is the refresh capability, 
which makes plain text channel token usage more palatable.

From: "Richer, Justin P."<jric...@mitre.org>
To: William Mills<wmills_92...@yahoo.com>
Cc: "Tschofenig, Hannes (NSN - FI/Espoo)"<hannes.tschofe...@nsn.com>; ext Sergey 
Beryozkin<sberyoz...@gmail.com>; Hannes Tschofenig<hannes.tschofe...@gmx.net>; 
"oauth@ietf.org"<oauth@ietf.org>
Sent: Tuesday, November 27, 2012 9:51 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

An important point to note, that many OAuth1 implementations in the wild screw 
up, is that you still need TLS between the client and the Authorization Server 
to protect the token and secret in transit, even if you don't use TLS during 
the client's calls to the protected resource. Since OAuth2 core mandates TLS at 
the Token Endpoint explicitly for all token types, that's much more clear to 
understand (in my opinion) in implementation.

In case the above is unclear, what I'm trying to say is this: putting a signed 
token like MAC into the OAuth2 framework will give us the capability of OAuth1 
in a clearer, more secure (in the wild) structure. I think it's vitally 
important that we have this functionality, and while I understand the need for 
clear use cases, I don't understand the feet-dragging.

  -- Justin

On Nov 27, 2012, at 12:32 PM, William Mills wrote:

I don't see in that document a significant use case for a signed token, which 
is use over clear text channels.  Bearer tokens have similar security 
properties to HTTP cookies (minus for the moment the XSRF problem).  Signed 
token types can be used over plain text channels without the concern about 
re-use of the token by a 3rd party.  Replay protection is still needed but 
that's not in scope for the token mechanism itself.

It's always been this simple use case that has been my focus for MAC.

Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we 
won't be able to go completely SSL due to the installed base of clients.  Given 
the dynamic I see in the mobile development community I don't see us getting 
all mobile apps into SSL only anytime soon.  MAC and OAuth 1.0 solve the token 
security problem for the last hop to the phone/wi-fi device without SSL for the 
bulk of the application traffic.

-bill


From: "Tschofenig, Hannes (NSN - FI/Espoo)"<hannes.tschofe...@nsn.com>
To: ext Sergey Beryozkin<sberyoz...@gmail.com>; Hannes 
Tschofenig<hannes.tschofe...@gmx.net>
Cc: oauth@ietf.org
Sent: Tuesday, November 27, 2012 4:33 AM
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

Hi Sergey,

I believe we would make faster progress on security topics if could
focus on listing security requirements we have and what threats we want
to mitigate. The reason why we have not finished this topic is simply
because everyone was just talking about specific (but incomplete)
solutions. You are unfortunately falling in the same trap as well.

If you really care about the topic then have a look at the mentioned
document and tell us whether the requirements are complete.
Reading through the document you will notice that there a few more
considerations to pay attention to than just the few listed below.

Ciao
Hannes


-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of ext Sergey Beryozkin
Sent: Tuesday, November 27, 2012 1:23 PM
To: Hannes Tschofenig
Cc:<oauth@ietf.org>
Subject: Re: [OAUTH-WG] What needs to be done to complete MAC

Hi Hannes
On 26/11/12 19:01, Hannes Tschofenig wrote:
Hi Sergey,

as Phil said it would be helpful for us to receive reviews of this
document:
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00

The document lists requirements and threats.


Let me offer two possibly naive reasons why using MAC may help, one of
them is related to the security, another to the ease of HOK support on
the client

1. The most safe way to return MAC token to the client is to use a
two-way TLS due to the mac key also returned to the client. Two-Way
TLS
offers a stronger support for getting the client authenticated along
the
way too

2. Assuming HOK confirmation matters at all (and I believe it does),
IMHO it is much simpler for a basic client implementation to apply a
MAC
signature algo and thus work with the OAuth2 servers expecting HOK
confirmations

One more reason is more about facilitating the further migration to
2.0
which I tried to outline in my response to Phil Hunt

Thanks, Sergey


Ciao
Hannes

On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote:

If we want to get this done we have to get agreements on the
requirements for HOK. Several meetings ago (quebec) the group
indicated
that mac wasn't appropriate to anyone's needs.

Some would argue that OAuth1 users arguably have less security than
the simpler bearer token /tls model in OAuth2. This just shows the
real
issue of demonstrated need has not been properly defined and
understood.

More dialog on use cases is very helpful to moving HOK/MAC/etc
forward.

Phil

On 2012-11-26, at 10:15, Sergey Beryozkin<sberyoz...@gmail.com>
wrote:

Hi

What needs to be done to complete the MAC token spec ? Without
having it signed off it will be difficult to get people working with
OAuth 1.0 convinced to move to 2.0.
I'm seeing another user request for getting OAuth 1.0 support
extended further because the user expects it is more secure, and I
guess
because it is proven to work for people, and I guess because many
OAuth
1.0 users feel that should stay from OAuth 2.0 because of some bad
press.

Without MAC being completed the division will continue, with even
more misleading anti-OAuth2 posts appearing (though I guess some of
the
better posts point to some level of complexity in 2.0).

Is it a matter of a security expert validating the text, fixing
few
typos, and basically signing it off ?

If someone is interested then I can provide the info offline on
how
it MAC supported in our framework to get things tested easily and
such...

Cheers, Sergey

_______________________________________________
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
_______________________________________________
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

Reply via email to