________________________________
From: Hannes Tschofenig <hannes.tschofe...@gmx.net>
To: William Mills <wmills_92...@yahoo.com>
Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; John Bradley
<ve7...@ve7jtb.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, August 10, 2012 12:01 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Hi Bill,
thanks for the feedback. Let's have a look at this use case:
You need to provide me a bit more information regarding your use case. Could
you please explain
1) Who is authenticated to whom?
wjm> the client is authenticated to the server.
2) What plaintext connection are you talking about?
wjm> generally an HTTP connection to a webservice
3) What is the problem with encrypted connections? Is this again the "TLS has
so bad performance" argument?
wjm> Yes, annoying but true. This may change, but we do business with enough
folks that refuse SSL that this is a real problem.
4) Since you are talking about cookies and making them more secure are you
trying to come up with a general solution to better cookie security - a topic
others are working on as well.
wjm> No, I'm pointing out the problems with a simple replayable credential
like cookies as a comparison.
5) What is the threat you are concerned about?
wjm> The vulnerability of plaintext connections: theft of credentials and
tampering.
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers
weaker protection than bearer when the entire argument has always been "Bearer
is so insecure and we need something stronger."
On Aug 9, 2012, at 9:43 PM, William Mills wrote:
> OK, I'll play and start documenting the use cases.
>
> Use case #1: Secure authentication in plain text connections:
>
> Some applications need a secure form authorization, but do not want or need
> the overhead of encrypted connections. HTTP cookies and their ilk are
> replayable credentials and do not satisfy this need. the MAC scheme using
> signed HTTP authorization credentials offer the capability to securely
> authorize a transaction, can offer integrity protection on all or part of an
> HTTP request, and can provide replay protection.
>
> -bill
>
> From: John Bradley <ve7...@ve7jtb.com>
> To: William Mills <wmills_92...@yahoo.com>
> Cc: Dick Hardt <dick.ha...@gmail.com>; "oauth@ietf.org" <oauth@ietf.org>
> Sent: Thursday, August 9, 2012 11:26 AM
> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>
> In Vancouver the question was asked about the future of the MAC spec due to
> it no linger having a editor.
>
> The Chair and AD indicated a desire to have a document on the use-cases we
> are trying to address before deciding on progressing MAC or starting a new
> document.
>
> Phil Hunt is going to put together a summery of the Vancouver discussion and
> we are going to work on the use-case/problem description document ASAP.
>
> People are welcome to contribute to the use-case document.
>
> Part of the problem with MAC has been that people could never agree on what
> it was protecting against.
>
> I think there is general agreement that one or more proof mechanisms are
> required for access tokens.
> Security for the token endpoint also cannot be ignored.
>
>
> John B.
>
> On 2012-08-09, at 1:53 PM, William Mills wrote:
>
>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are
>> libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model
>> and will provide for a single codepath for sites that want to use both
>> Bearer and MAC.
>>
>> From: Dick Hardt <dick.ha...@gmail.com>
>> To: William Mills <wmills_92...@yahoo.com>
>> Cc: "oauth@ietf.org" <oauth@ietf.org>
>> Sent: Thursday, August 9, 2012 10:27 AM
>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>
>>
>> On Aug 9, 2012, at 9:52 AM, William Mills wrote:
>>
>>> I find the idea of starting from scratch frustrating. MAC solves a set of
>>> specific problems and has a well defined use case. It's symmetric key
>>> based which doesn't work for some folks, and the question is do we try to
>>> develop something that supports both PK and SK, or finish the SK use case
>>> and then work on a PK based draft.
>>>
>>> I think it's better to leave them separate and finish out MAC which is
>>> *VERY CLOSE* to being done.
>>
>> Who is interested in MAC? People can use OAuth 1.0 if they prefer that
>> model.
>>
>> For my projects, I prefer the flexibility of a signed or encrypted JWT if I
>> need holder of key.
>>
>> Just my $.02
>>
>> -- Dick
>>
>>
>>
>> _______________________________________________
>> 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
