Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Jun 2011 13:16:19 +0100

Just on DOSETA - that's not currently got any official
home in the IETF so its not something that would be right
to reference at this point (unless the oauth WG wanted to
adopt DOSETA but I'd be very surprised if that were the
case for timing reasons).

However I do agree that keeping in mind that folks may
move towards something like DOESTA in future is a good
plan.

To be clear, as an individual, I do think that "something
like DOSETA" is a really good idea and maybe DOSETA will
turn out to be that something, I don't know.

S.

On 01/06/11 00:57, Mark Nottingham wrote:
> Hi,
> 
> Reading draft -05.
> 
> The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too).
> 
> It would be more robust to calculate an effective request URI, as in [2].
> 
> Also, if you include a hash of the request body, you really need to include a hash of the body media type.
> 
> Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it.
> 
> Regards,
> 
> 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2
> 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3
> 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00
> 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02
> 
> 
> On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote:
> 
>> (Please discuss this draft on the Apps-Discuss <[email-masked]> mailing list)
>>  
>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>>  
>> The draft includes:
>>  
>> * An HTTP authentication scheme using a MAC algorithm to authenticate requests (via a pre-arranged MAC key).
>> * An extension to the Set-Cookie header, providing a method for associating a MAC key with a session cookie.
>> * An OAuth 2.0 binding, providing a method of returning MAC credentials as an access token.
>>  
>> Some background: OAuth 1.0 introduced an HTTP authentication scheme using HMAC for authenticating an HTTP request with partial cryptographic protection of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 scheme was designed for delegation-based use cases, but is widely “abused” for simple client-server authentication (the poorly named ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 and has been reintroduced as a standalone, generally applicable HTTP authentication scheme called MAC.
>>  
>> Comments and feedback is greatly appreciated.
>>  
>> EHL
>> _______________________________________________
>> apps-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 1 Jun 2011 08:00:12 -0700

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Tuesday, May 31, 2011 4:57 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; Ben Adida; [email-masked]; OAuth WG;
> 'Adam Barth ([email-masked])'; HTTP Working Group
> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
> 
> Hi,
> 
> Reading draft -05.
> 
> The "normalized request string" contains the request-URI and values
> extracted from the Host header. Be aware that intermediaries can and do
> change these; e.g., they may change an absolute URI to a relative URI in the
> request-line, without affecting the semantics of the request. See [1] for
> details (it covers other problematic conditions too).
> 

I'll take a look.

> hash of the body media type.

This was suggested before, but are there really attack vectors for this?

The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.).

I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing).

> Generally, I think that people can and will want to include other headers; just
> because *some* developers can't get this right doesn't mean we should
> preclude *all* developers from doing it. It'd be really nice to see this either
> leverage DOSETA [3][4], or at least offer a clean transition path to it.

If someone comes up with a practical and secure way to normalize HTTP request headers, they can either define a new authentication scheme or use the 'ext' parameter to pass the additional values. I would vote for a new scheme. MAC is trivial to implement and interoperate. That simplicity comes at a significant lack of features, and limiting extensibility is a design goal.

EHL

> > * An extension to the Set-Cookie header, providing a method for
> associating a MAC key with a session cookie.
> > Some background: OAuth 1.0 introduced an HTTP authentication scheme
> using HMAC for authenticating an HTTP request with partial cryptographic
> protection of the HTTP request (namely, the request URI, host, and port).
> The OAuth 1.0 scheme was designed for delegation-based use cases, but is
> widely "abused" for simple client-server authentication (the poorly named
> 'two-legged' use case). This functionality has been separated from OAuth 2.0
> and has been reintroduced as a standalone, generally applicable HTTP
> authentication scheme called MAC.
> >

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Jun 2011 10:15:37 +1000

> This was suggested before, but are there really attack vectors for this?

If not having a current, working attack to demonstrate is a valid way to shrug off a security concern, that's great; it'll be a useful approach to many of the discussions I have. :)

> The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.).

The media type is the important part, and it's much more constrained.

> I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body…

That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing.

Cheers,

---

From: Adam Barth <[email-masked]>
Date: Wed, 1 Jun 2011 18:25:54 -0700

> That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing.

Yeah, I tried to twist Eran's arm into including the media type in the
body hash too.  It's probably more important for responses than
requests, however.

Adam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 2 Jun 2011 08:44:35 -0700

> Sent: Wednesday, June 01, 2011 5:16 PM
> To: Eran Hammer-Lahav
> If not having a current, working attack to demonstrate is a valid way to shrug
> off a security concern, that's great; it'll be a useful approach to many of the
> discussions I have. :)

No, but its valid as long as it is fully documented. We're not going to solve everything.

> > The problem is that content-type is a pretty flexible header, which means
> normalization of the header will be required (case, parameter order, white
> space, etc.).
> 

So include just the:

	type "/" subtype

forced to lowercase?

> 
> > I would argue that if you are using MAC with body hash and an attacker
> changing the media type can cause harm, you should use additional methods
> to secure the content-type (such as making the body self-describing).
> 
> 

I wasn't suggesting sniffing.

EHL

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Jun 2011 14:16:23 -0700

Stephen,

> case for timing reasons).

I'm confused on two counts.  (To be honest, of course, I'm confused about many 
points, but two of them are relevant to this thread...)

One, of course, is that I've been actively raising DOSETA in various IETF venues 
for the different groups to considering adopting and/or adapting it.  As such, 
discussion of DOSETA permits exploring the possibility of adoption and/or 
adaptation.

The second is that you appear to be stating a policy that a working group is 
only permitted to reference things which are currently and officially IETF work 
items.  I suspect that that is not what you meant, so at the least, please 
clarify what you do mean.

If you really do mean anything like the interpretation I just summarized, please 
explain its basis.

> turn out to be that something, I don't know.

If it is not acceptable to 'reference' DOSETA now and here, then how will the 
determination of its utility be made?

Thanks.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Jun 2011 09:21:42 +1000

>> The media type is the important part, and it's much more constrained.

Think so.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Jun 2011 13:26:28 +0100

Hi Dave,

On 02/06/11 22:16, Dave CROCKER wrote:
> I'm confused on two counts.  (To be honest, of course, I'm confused
> about many points, but two of them are relevant to this thread...)
> 
> One, of course, is that I've been actively raising DOSETA in various
> IETF venues for the different groups to considering adopting and/or
> adapting it.  As such, discussion of DOSETA permits exploring the
> possibility of adoption and/or adaptation.

I don't get the confusion aspect there, but the rest below
might clarify.

> The second is that you appear to be stating a policy that a working
> group is only permitted to reference things which are currently and
> officially IETF work items.  I suspect that that is not what you meant,
> so at the least, please clarify what you do mean.

Right. I wasn't stating any general policy.

What I meant was that the oauth WG needs to get oauth2.0 done
and that seems to require also getting the mac scheme done, so
adding a dependency to something at an early stage of development
(like DOSETA) at this point would not be a good plan for oauth.
That's all. Exploring  whether DOSETA or something similar is
useful is a fine thing to do, its just a bit early for oauth.

> If you really do mean anything like the interpretation I just
> summarized, please explain its basis.
> 
> If it is not acceptable to 'reference' DOSETA now and here, then how
> will the determination of its utility be made?

Following our usual highly-predictable process I guess;-)

I assume that the next step would be for a bunch of interested
folks to figure out where and when it might make sense to do
more on DOSETA.

S.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 6 Jun 2011 23:25:54 -0400

Nico,

Sorry for coming into this so late, but I just saw this message.

I don't have all of the background, but when I saw this message header and
some of the dialog, it seems there is a desire to provide some level of
authentication to requests and/or responses between the clients and servers.

Gonzalo and I worked on this:
https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04

This may not be entirely complete, but the idea was to allow a client and
server to establish an association so that requests and responses could be
authenticated.  Is this something along the lines of what you are
discussing, or is this an entirely different application?

Paul

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Nico Williams
> Sent: Friday, May 20, 2011 4:25 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; Ben Adida; Adam Barth ([email-masked]);
> [email-masked]; HTTP Working Group; OAuth WG
> Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
> 
> Additional comments:
> 
>  - Using nonces for replay protection is heavy-duty.  It is difficult to
> implement a reliable, secure, high-performance replay cache.  (It is
> easy to implement just a high-performance replay cache: use
> memcache.)
> 
>    I recommend an option to use sequence numbers at the server's choice,
> understanding, of course, that requests will not be received in
> sequence.  The use of a sliding sequence number window makes it possible
> to do at least as well as when using nonce, and probably faster while
> still being secure.
> 
>  - In an open wifi environment active attacks may not be very difficult,
> thus an option to secure more than just a handful of bits from the
> request, would be nice (all of the request and all of the response,
> say).  The hard part is how to decide when to use one or the other.
> Ideally browsers can request more protection when the network is
> reconfigured such that there's one or more clear wifi interfaces.
> 
> Nico
> --
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 12:35:52 -0500

> discussing, or is this an entirely different application?

I'm completely on-board with session state[*].  My comments were
particularly in regards to threat models.  I believe that
eavesdroppers and active attackers both need to be considered,
particularly as we have so many open wifi networks.

To me the simplest way to address the Internet threat model is to
always use TLS (except, maybe, for images and such elements that have
little or no security value, though one must be careful when making
that determination) and to use channel binding.  See the I-D
referenced below.

[*]  See, for example: http://www.ietf.org/id/draft-williams-rest-gss-00.txt

Nico
--

---

From: Adam Barth <[email-masked]>
Date: Tue, 7 Jun 2011 11:30:12 -0700

> particularly as we have so many open wifi networks.

Sorry.  We can't address active attackers using this mechanism.  If
you need protection from active attackers, please use TLS.

> that determination) and to use channel binding.  See the I-D

Indeed.  This mechanism is for folks who cannot or will not deploy TLS.

Adam

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 16:17:41 -0500

> you need protection from active attackers, please use TLS.

I've already said as much now several times.  However, I want channel
binding to TLS too.

> Indeed.  This mechanism is for folks who cannot or will not deploy TLS.

It has value outside TLS as well.  Particularly if you're using an
authentication mechanism that can provide mutual authentication (which
OAuth doesn't do today, but I hear there's work in progress to add
mutual auth to it).  And then you realize that you might want to do
something similar with other non-OAuth authentication methods, thus
the urge to generalize.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 16:20:51 -0500

On Tue, Jun 7, 2011 at 1:41 PM, Igor Faynberg
<[email-masked]> wrote:
> Adam Barth wrote:
> Actually, IPsec will work here (with WiFi networks) just as well.  It is

Not really.  See RFCs 5660, 5386, and 5387.  If only RFC5660 were
widely implemented... but it's not.

> also true that we COULD develop both the authentication and confidentiality
> mechanisms that would offer protection from both active and passive
> attackers; it is just that we CHOSE (in opinion, correctly) not to do that
> because other Internet protocols already do that.

And rightly so.  As we've learned from SASL, having an option for
security layers (the "SL" in SASL) at multiple network layers only
adds unnecessary complications.

Nico
--

---

From: Adam Barth <[email-masked]>
Date: Tue, 7 Jun 2011 14:24:10 -0700

> I've already said as much now several times.  However, I want channel

I'm not sure that's appropriate for this mechanism.  What problem does
channel binding solve?

Adam

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 7 Jun 2011 17:59:23 -0400

Nico,

> > This may not be entirely complete, but the idea was to allow a client
> > and server to establish an association so that requests and responses
> > could be authenticated.  Is this something along the lines of what you
> > are discussing, or is this an entirely different application?
> 
> particularly in regards to threat models.  I believe that eavesdroppers
> and active attackers both need to be considered, particularly as we have
> so many open wifi networks.
> 
> To me the simplest way to address the Internet threat model is to always
> use TLS (except, maybe, for images and such elements that have little or
> no security value, though one must be careful when making that
> determination) and to use channel binding.  See the I-D referenced
> below.
> 

I fully agree with you that using TLS is usually preferred.  That said, we encounter situations where there were a large number of client/server interactions and the data conveyed is not confidential information in any way.  Using TLS can significantly decreases server performance, particularly when there are a number of separate connections that are established and broken.

So, we were trying to find a non-TLS solution that still provides a way to ensure the server can identify the user and that both can verify that data has not been tampered in flight.  (It would still be preferred to establish security relations with TLS, though we were open to other solutions.)

Paul

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 17:33:34 -0500

> I'm not sure that's appropriate for this mechanism.  What problem does

CB is not appropriate for OAuth today, no, because OAuth doesn't give
you mutual authentication, which means channel binding can't be done
either (well, not with any security guarantees).

You missed my point however: I don't really want to see a specific
purpose MAC here because I do believe it's generalizable, and if we
don't generalize it now we'll just have more special casing in code
later.  For a general MAC I'd want an option for CB (when TLS is used,
of course).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 17:35:31 -0500

> So, we were trying to find a non-TLS solution that still provides a way to ensure the server can identify the user and that both can verify that data has not been tampered in flight.  (It would sti…

I don't see the point of having a MAC instead of a cookie for HTTP
requests sent without TLS, not unless you cover enough of the request
(and response).  Of course, you'll want two different cookies -- one
for HTTP and one for HTTPS.

I think you've just convinced me that this MAC adds no value whatsoever.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 17:57:00 -0500

On Tue, Jun 7, 2011 at 5:43 PM, William J. Mills <[email-masked]> wrote:
> MAC adds security if the initial secret exchange is secure, and it provides
> a definition for signing payload as part of the request.

Not if the MAC doesn't protect enough of the request _and_ response to
prevent active attacks.  Unless you don't care about those attacks
(which some of you have indicated), in which case why bother with the
MAC at all?

Nico
--

---

From: Ben Adida <[email-masked]>
Date: Tue, 07 Jun 2011 16:00:06 -0700

> (which some of you have indicated), in which case why bother with the

A passive attacker can sniff your cookie and thus hijack your session. 
All you need to accomplish that attack is connect to any open wifi 
network and use Firesheep. It's a good bit harder to be an active 
attacker, even on an open wireless network.

So there is a difference between passive and active network attackers in 
terms of feasibility, and MAC cookies limit the scope of what passive 
attacker can do.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 18:09:34 -0500

On Tue, Jun 7, 2011 at 6:00 PM, Ben Adida <[email-masked]> wrote:
> A passive attacker can sniff your cookie and thus hijack your session. All
> you need to accomplish that attack is connect to any open wifi network and
> use Firesheep. It's a good bit harder to be an active attacker, even on an
> open wireless network.

Yes, but only for resources that you've already stated you don't care about.

If you cared about those resources you'd protect more of the request
_and_ response, or you'd use TLS.  But you don't want to protect the
response and you don't want to use TLS and you don't even want to
protect the request body.  What you're proposing adds a very marginal
degree of security that will be trivial to defeat on open wifi
(particularly once the toolset for doing it gets published).

Are we serious about security?  Or it this just for show?

Or am I missing something?

Nico
--

---

From: Tim <[email-masked]>
Date: Tue, 7 Jun 2011 16:41:31 -0700

> Or am I missing something?

I have to agree with Nico here.  In almost all cases I assert that, on
typical modern networks:

  let P = difficulty of passive attack
  let M = difficulty of active (man-in-the-middle) attack

O(P) = O(M)
.

This isn't to say the "real world" difficulty of an active attack is
just as easy, but it is within a constant factor.  If someone has
published a tool that conducts MitM attacks for the specific protocol
you're dealing with, the difference in difficulty clearly becomes
marginal.  Consider the complexity of the attacks implemented by
sslstrip and yet the relative ease with which you can use it to MitM
all SSL connections.

I didn't bring this up before because I didn't understand any of the
context behind the MAC proposal, but I will now, at risk of sounding
ignorant: 

  What is the MAC Authentication proposal intended to accomplish, in a
security sense, above and beyond HTTP Digest?  

Yes, the HTTP Digest spec is, shall we say, a little rough around the
edges, but would it make more sense to simply *fix* the minor problems
with it and slightly extend it to integrate with OAuth?  Note that it
already does allow for arbitrary encrypted blob values to be attached
to the digest...  Ignoring the integration details for a minute
though, how does MAC improve on Digest from a security persepctive?

tim

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 19:07:39 -0500

> sslstrip and yet the relative ease with which you can use it to MitM

Exactly, and very well put.

Active attacks sound harder, and they do actually require more work,
but in many cases that work can be automated, and once automated there
can be no difference in effort required to mount an active attack
versus a passive one.

Do we suppose that this proposal can get past secdir, IESG, and IETF
reviews as-is?  I doubt it.

Here's another issue: some of you are saying that an application using
this extension will be using TLS for some things but not others, which
presumes a TLS session.  Does using TLS _with_ session resumption
_and_ HTTP/1.1 pipelining for all requests really cost that much more
in latency and compute (and electric) power than the proposed
alternative?  I seriously doubt it, and I'd like to see some real
analysis showing that I'm wrong before I'd accept such a rationale for
this sort of proposal.

Or perhaps the motivation relates to accidental leakage of "secure"
cookies in non-secure contexts.  But why not just fix the clients in
that case?

Nico
--

---

From: Randy Fischer <[email-masked]>
Date: Tue, 7 Jun 2011 21:05:51 -0400

> Or am I missing something?

Well, last I tried it under apache, at least, there was a hard limit
on the length of
a TLS stream.   Since I use HTTP for a storage system for multi-GB files,  I'd
really love to see alternatives.

-Randy Fischer

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 20:22:03 -0500

> really love to see alternatives.

Really?  But if it'd have to be pretty short for the cost of the
subsequent TLS session resumption to add up to so much latency and
compute cost that you'd want to avoid using TLS.  Also, that sounds
like a fixable bug.  If you can implement this MAC proposal, you can
fix that bug.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 22:17:47 -0500

On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills <[email-masked]> wrote:
> It is possible to implement decent security with MAC, it is also possible to

Not as specified.  See earlier posts regarding active attacks.

> screw it up.  It is far more difficult (impossible?) to implement decent
> security with cookies over HTTP.

Assuming well-behaved browsers that understand the distinction between
"secure" and non-secure cookies, and assuming that active attacks are
often no more difficult than passive attacks, what does MAC without
TLS add that cookies don't provide?

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Jun 2011 13:26:05 +1000

This is an interesting discussion, but a bit much to cross-post to four different lists. 

I've set followups to apps-discuss (since it's the most general).

Cheers,

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 8 Jun 2011 03:09:29 -0400

Nico,

Cookies would still be employed.  A cookie would be used to identify the particular user, for example.  However, it's important to make sure that the cookie provided by the client to the server is not stolen.  It's important to ensure that the client provided by the server to the client is not modified.  That's the reason for the MAC.  Once we can ensure the integrity of the message exchange, then the existing cookie mechanism can provide us with the secure state management capability we need.

Paul

> From: Nico Williams [mailto:[email-masked]]
> Sent: Tuesday, June 07, 2011 6:36 PM
> To: Paul E. Jones
> Cc: Eran Hammer-Lahav; [email-masked]; Ben Adida; Adam Barth;
> > I fully agree with you that using TLS is usually preferred.  That
> said, we encounter situations where there were a large number of
> client/server interactions and the data conveyed is not confidential
> information in any way.  Using TLS can significantly decreases server
> performance, particularly when there are a number of separate
> connections that are established and broken.
> >
> > So, we were trying to find a non-TLS solution that still provides a
> > way to ensure the server can identify the user and that both can
> > verify that data has not been tampered in flight.  (It would still be
> > preferred to establish security relations with TLS, though we were
> > open to other solutions.)
> 
> (and response).  Of course, you'll want two different cookies -- one for
> HTTP and one for HTTPS.
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 09:54:34 -0500

On Jun 8, 2011 2:09 AM, "Paul E. Jones" <[email-masked]> wrote:
>
> Nico,
>
> Cookies would still be employed.  A cookie would be used to identify the
particular user, for example.  However, it's important to make sure that the
cookie provided by the client to the server is not stolen.  It's important
to ensure that the client provided by the server to the client is not
modified.  That's the reason for the MAC.  Once we can ensure the integrity
of the message exchange, then the existing cookie mechanism can provide us
with the secure state management capability we need.

You're still not addressing the issues raised.

Nico
--

---

From: Tim <[email-masked]>
Date: Wed, 8 Jun 2011 08:32:25 -0700

Hi Paul,

> That's the reason for the MAC.  Once we can ensure the integrity of
> the message exchange, then the existing cookie mechanism can provide
> us with the secure state management capability we need.

Maybe I'm missing something in the MAC authentication draft, but I
don't see how it provides integrity for the "exchange".  In
particular, the body of request messages may be optionally hashed to
protect their integrity, but no such facility seems to be provided for
responses from the server.  In many modern web applications, this
could be trivially exploited by an attacker to inject malicious script
into a server response. 

HTTP Digest authentication provides an option (auth-int) for integrity
protection of both requests and responses and for every
request/response after the initial authentication.  In fact if servers
change nonces each time, reuse of hashes becomes difficult.  Some
level of mutual authentication is also provided and the opaque string
can be used to pass arbitrary extra data between clients and servers.
IIRC, this value can be passed *cross domain* based on a defined white
list.

At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
That is not just rhetorical, it is a genuine question.  What is HTTP
Digest missing that you need?  

tim

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 8 Jun 2011 15:26:03 -0700

> analysis showing that I'm wrong before I'd accept such a rationale for

Google has performed detailed analysis of SSL performance after
several optimizations and we have concluded that the answer is 'no
significant overhead' as you suggest. Indeed, in some workload
situations it may be actually cheaper to serve SSL traffic because
there is reduction in network latency by avoiding bad proxies. We have
published some results here:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

-- 
--Breno

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 17:30:16 -0500

> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Sweet!  Thanks for confirming my intuition, and then some.  I like the
idea that using TLS actually reduces latency -- I'd not have imagined
it.

Nico
--

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 9 Jun 2011 01:03:35 -0400

What issues, specifically.  (Messages are all over the place and I don’t know exactly what issues you’re raising.  Is it with the approach we’re proposing or something else?)

Paul

From: Nico Williams [mailto:[email-masked]] 
Sent: Wednesday, June 08, 2011 10:55 AM
To: Paul E. Jones
Cc: [email-masked]; Nico Williams; OAuth WG; HTTP Working Group; Ben Adida; Adam Barth; Eran Hammer-Lahav; [email-masked]
Subject: RE: [http-state] [apps-discuss] HTTP MAC Authentication Scheme

Nico
--

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 9 Jun 2011 01:13:04 -0400

Tim,

> Maybe I'm missing something in the MAC authentication draft, but I don't
> see how it provides integrity for the "exchange".  In particular, the
> body of request messages may be optionally hashed to protect their
> integrity, but no such facility seems to be provided for responses from
> the server.  In many modern web applications, this could be trivially
> exploited by an attacker to inject malicious script into a server
> response.

You are referring to draft-salgueiro-secure-state-management-04?

In that document, Section 6 covers responses from the server.  The server
may hash any part of the message it wishes, including the body and selected
header.  It's possible to also have an empty body and including that in the
hash will ensure that no body is inserted where one shouldn't have been.
 
> protection of both requests and responses and for every request/response
> after the initial authentication.  In fact if servers change nonces each
> time, reuse of hashes becomes difficult.  Some level of mutual
> authentication is also provided and the opaque string can be used to
> pass arbitrary extra data between clients and servers.

We've not looked at HTTP Digest and we were not targeting OAuth with our
document.  Just so that I'm looking at the right "HTTP Digest" text, can you
tell me the document name?  I found several when I did a search.

Paul

---

From: Tim <[email-masked]>
Date: Thu, 9 Jun 2011 07:30:00 -0700

> hash will ensure that no body is inserted where one shouldn't have been.

No, throughout this discussion I'm just looking at:
  http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token

Does this tie in to the secure state management draft?  If so, can you
point me to the section in the MAC draft so I can get up to speed?

> tell me the document name?  I found several when I did a search.

Just the (latest?) RFC:
  http://www.ietf.org/rfc/rfc2617.txt

thanks,
tim