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

[William Mills <[e-mail]>]

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 <[e-mail]>
To: William Mills <[e-mail]> 
Cc: David Waite <[e-mail]>; "[e-mail]" <[e-mail]> 
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 <[e-mail]>
>To: William Mills <[e-mail]> 
>Cc: David Waite <[e-mail]>; "[e-mail]" <[e-mail]> 
>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 <[e-mail]>
>>To: [e-mail] 
>>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 <[e-mail]> 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 <[e-mail]>
>>>>To: William Mills <[e-mail]> 
>>>>Cc: Dick Hardt <[e-mail]>; "[e-mail]" <[e-mail]> 
>>>>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 <[e-mail]>
>>>>>To: William Mills <[e-mail]> 
>>>>>Cc: "[e-mail]" <[e-mail]> 
>>>>>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
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
OAuth mailing list [e-mail] https://www.ietf.org/mailman/listinfo/oauth 
>>>
_______________________________________________
>>>OAuth mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>_______________________________________________
>>OAuth mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>_______________________________________________
>>OAuth mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>