Hi Eran,
> ... Until everyone deploys TLS, including such non-TLS bits in a TLS
> page cause the browser to show a broken TLS state in the address bar.
> For most web users, that's more of a red flag (valid TLS but with some
> resources loaded without TLS) than no TLS at all.
And in fact, in any
> -Original Message-
> From: Tim [mailto:tim-proje...@sentinelchicken.org]
> Sent: Thursday, June 09, 2011 7:42 AM
> To: Robert Sayre
> Cc: Eran Hammer-Lahav; OAuth WG; apps-disc...@ietf.org
> Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC
>
Nico,
> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones
> wrote:
> > 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?)
>
> The fundamental issue is that protecting
On Fri, Jun 10, 2011 at 2:16 PM, Adam Barth wrote:
> On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams wrote:
>> The fundamental issue is that protecting the cookie alone is not
>> enough. On open wifi networks it's a fair assumption that the
>> difficulty of active attacks is about the same as th
On Fri, Jun 10, 2011 at 10:36 AM, Nico Williams wrote:
> [Dropped a few lists.]
>
> On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones wrote:
>> 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
>> propo
[Dropped a few lists.]
On Thu, Jun 9, 2011 at 12:03 AM, Paul E. Jones wrote:
> 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?)
The fundamental issue is that protecti
> Digest has a bunch of problems. See this document
>
> http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2
>
> for a short tour of them.
Thanks for the link. I totally agree with all of this, and in fact
there are more MitM attacks possible than are alluded to in
> 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 th
Tim,
> 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 do
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:n...@cryptonector.com]
Sent: Wednesday, June 08, 2011 10:55 AM
To: Paul E. Jones
On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: Tim [mailto:tim-proje...@sentinelchicken.org]
>> Sent: Wednesday, June 08, 2011 8:32 AM
>
>> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
>> That is not just rhetorical, it is
> -Original Message-
> From: Tim [mailto:tim-proje...@sentinelchicken.org]
> Sent: Wednesday, June 08, 2011 8:32 AM
> 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
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 prov
On Jun 8, 2011 2:09 AM, "Paul E. Jones" 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 th
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 i
On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wrote:
> 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
On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills 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
-disc...@ietf.org" ; "http-st...@ietf.org"
Sent: Tuesday, June 7, 2011 4:41 PM
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication
Scheme
> > A passive attacker can sniff your cookie and thus hijack your session. All
> > you need to accompli
On Tue, Jun 7, 2011 at 8:05 PM, Randy Fischer wrote:
> On Tue, Jun 7, 2011 at 7:09 PM, Nico Williams wrote:
>> 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-G
On Tue, Jun 7, 2011 at 6:41 PM, Tim wrote:
> 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 wo
> > 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 t
On Tue, Jun 7, 2011 at 6:00 PM, Ben Adida wrote:
> On 6/7/11 3:57 PM, Nico Williams wrote:
>>
>> 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 bot
On Tue, Jun 7, 2011 at 5:43 PM, William J. Mills 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 y
Group
; OAuth WG
Sent: Tuesday, June 7, 2011 3:35 PM
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication
Scheme
On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones wrote:
> I fully agree with you that using TLS is usually preferred. That said, we
> encounter situations
On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones wrote:
> 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
On Tue, Jun 7, 2011 at 4:24 PM, Adam Barth wrote:
> I'm not sure that's appropriate for this mechanism. What problem does
> channel binding solve?
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 (we
Nico,
> > 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
On Tue, Jun 7, 2011 at 2:17 PM, Nico Williams wrote:
> On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote:
>> On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote:
>>> I'm completely on-board with session state[*]. My comments were
>>> particularly in regards to threat models. I believe that
>>>
On Tue, Jun 7, 2011 at 1:41 PM, Igor Faynberg
wrote:
> Adam Barth wrote:
>> Sorry. We can't address active attackers using this mechanism. If
>> you need protection from active attackers, please use TLS.
>
> Actually, IPsec will work here (with WiFi networks) just as well. It is
Not really. S
On Tue, Jun 7, 2011 at 1:30 PM, Adam Barth wrote:
> On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote:
>> 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 consider
Adam Barth wrote:
On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote:
On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrote:
...
I'm completely on-board with session state[*]. My comments were
particularly in regards to threat models. I believe that
eavesdroppers and acti
On Tue, Jun 7, 2011 at 10:35 AM, Nico Williams wrote:
> On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrote:
>> 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
On Mon, Jun 6, 2011 at 10:25 PM, Paul E. Jones wrote:
> 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
> authenticati
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.
G
34 matches
Mail list logo
