Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Specifically, there are cases where it "isn't in play at all" and cases 
where it "isn't in play end to end".

  -- Justin

On 08/10/2012 11:59 AM, William Mills wrote:
> It's not intended to address anything in TLS other than the fact that 
> we have real use cases where TLS isn't in play.
>
>
> ------------------------------------------------------------------------
> *From:* John Bradley <ve7jtb@ve7jtb.com>
> *To:* William Mills <wmills_92105@yahoo.com>
> *Cc:* David Waite <david@alkaline-solutions.com>; "oauth@ietf.org" 
> <oauth@ietf.org>
> *Sent:* Friday, August 10, 2012 8:09 AM
> *Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>
> No I wasn't talking about changing TLS.  I think the TLS threat has 
> been expressed more as people who turn verification in the client 
> rather than any failure of the TLS protocol or certificates.
>
> The question I was trying to get at was if any of the message signing 
> was intended to protect against clients misconfiguring TLS or Man in 
> the middle attacking communications with the RS or token server.
>
> Part of the reason behind MAC has been expressed as concern that 
> Server TLS doesn't prevent tokens from being intercepted and replayed 
> sufficiently.
>
> Where TLS is used if we believe clients are properly implemented what 
> is the signing getting us.
>
> I think sessions without TLS and TLS terminated on the firewall need 
> to be supported, but there the threat is clearer.
>
> John
>
> On 2012-08-10, at 10:36 AM, William Mills wrote:
>
>> I would say that's true in theory, but practically speaking it's not 
>> gonna happen.  You're stating we need to come up with a better method 
>> for public key than we have now for this to be widely adopted, and I 
>> don't think that's reasonable.
>>
>> If we're gonna improve on the current PKI that is SSL certificates we 
>> should do that separately.
>>
>> ------------------------------------------------------------------------
>> *From:* John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>
>> *To:* William Mills <wmills_92105@yahoo.com 
>> <mailto:wmills_92105@yahoo.com>>
>> *Cc:* David Waite <david@alkaline-solutions.com 
>> <mailto:david@alkaline-solutions.com>>; "oauth@ietf.org 
>> <mailto:oauth@ietf.org>" <oauth@ietf.org <mailto:oauth@ietf.org>>
>> *Sent:* Thursday, August 9, 2012 8:47 PM
>> *Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>
>> Bill,
>>
>> I seem to recall in Paris that client misconfiguration of TLS was a 
>> concern.
>>
>> In MAC the token secret is delivered with the token based on server 
>> TLS and HTTP basic authentication.
>>
>> If this is OK and we trust the client to do TLS server certificate 
>> verification correctly that needs to go in as one of our base 
>> assumptions.  Or conversely additional protection of the token 
>> endpoint needs to be considered for key distribution.
>>
>> John B.
>> On 2012-08-09, at 7:19 PM, William Mills wrote:
>>
>>> AS would still be required to be HTTPS as per the spec.
>>>
>>> ------------------------------------------------------------------------
>>> *From:* David Waite <david@alkaline-solutions.com 
>>> <mailto:david@alkaline-solutions.com>>
>>> *To:* oauth@ietf.org <mailto:oauth@ietf.org>
>>> *Sent:* Thursday, August 9, 2012 4:02 PM
>>> *Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>>
>>> For #1:
>>> Does the use of plain HTTP to talk to protected resources provide 
>>> significant value when using an AS that requires HTTPS? Or am I 
>>> misunderstanding, and this use case would also include new modes for 
>>> non-TLS communication with the AS?
>>>
>>> For #2:
>>> Would the signature protection just cover HTTP parameters, or would 
>>> it extend to covering any request data, such as a PUT binary 
>>> file? Would the integrity protection only cover requests, or would 
>>> you also have integrity protection of the response?
>>>
>>> -DW
>>>
>>> On Aug 9, 2012, at 1:37 PM, Justin Richer <jricher@mitre.org 
>>> <mailto:jricher@mitre.org>> wrote:
>>>
>>>> Use case #2: signature protection over plain HTTP parameters
>>>>
>>>> MAC gives us message-level signing in a way that doesn't require 
>>>> all the parameters to be packed into an extra structure, like 
>>>> JWT/SAML do. TLS gives no application-layer verification of 
>>>> integrity of parameters, nor does it give you the ability to know 
>>>> who presented those parameters (unless you're doing mutual TLS, 
>>>> which nobody does). MAC gives you a fairly simple way to protect 
>>>> all parameters on a call to the resource server while still keeping 
>>>> all of those parameters in their native HTTP forms.
>>>>
>>>>
>>>> Use case #3: generic signed HTTP fetch (not directly addressed by 
>>>> MAC spec as of today)
>>>>
>>>> Sometimes you want to create a URL with one service, fix all of the 
>>>> parameters in that URL, and protect those parameters with a 
>>>> signature. Then that URL can be passed to an untrusted service who 
>>>> cannot modify any portion of it. Nor can they re-use the signature 
>>>> portion to protect different parameters. We do this today with a 
>>>> 2-legged OAuth signature across a service URL. The "Client" 
>>>> generates the signed URLs and passes them to a user agent which 
>>>> actually does the fetch to the service.
>>>>
>>>>
>>>>  -- Justin
>>>>
>>>> On 08/09/2012 02: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 <ve7jtb@ve7jtb.com> <mailto:ve7jtb@ve7jtb.com>
>>>>> *To:* William Mills <wmills_92105@yahoo.com> 
>>>>> <mailto:wmills_92105@yahoo.com>
>>>>> *Cc:* Dick Hardt <dick.hardt@gmail.com> 
>>>>> <mailto:dick.hardt@gmail.com>; "oauth@ietf.org" 
>>>>> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto: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.hardt@gmail.com 
>>>>>> <mailto:dick.hardt@gmail.com>>
>>>>>> *To:* William Mills <wmills_92105@yahoo.com 
>>>>>> <mailto:wmills_92105@yahoo.com>>
>>>>>> *Cc:* "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org 
>>>>>> <mailto: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 <mailto:OAuth@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org  <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth