So my previous suggestion was subject to a limited replay attack. In
particular, someone who was able to hijack the C2S, S2S, or the intermediate
server could do a replay. Here's another suggestion that eliminates this
replay attack and doesn't require any additional roadtrips.
This would loo
On Thu, Oct 21, 2010 at 5:05 PM, Kurt Zeilenga wrote:
>
> On Oct 21, 2010, at 4:32 PM, Alex Milowski wrote:
>>
>> For many of these mechanisms to work properly, you need a challenge
>> from the service (the room service in this case) that contains,
>> amongst other things, a nonce from the service
On Oct 21, 2010, at 4:32 PM, Alex Milowski wrote:
>
> For many of these mechanisms to work properly, you need a challenge
> from the service (the room service in this case) that contains,
> amongst other things, a nonce from the service. I think the
> additional chatter can't be avoided.
My sug
On Thu, Oct 21, 2010 at 4:20 PM, Kurt Zeilenga wrote:
>>
>> That's the point of using a nonce and other aspects of various
>> challenge base authentication mechanism. I don't see why we would
>> develop a new method.
>
> Well, it's the "just use SASL" suggestion I am objecting to. I less mind
On Oct 21, 2010, at 3:58 PM, Alex Milowski wrote:
> On Thu, Oct 21, 2010 at 3:53 PM, Kurt Zeilenga
> wrote:
>>
>> I have number of concerns.
>>
>> I am concerned that a client or the user would not know why SASL
>> authentication was being offered, what id to use, etc.. Aside from user
>>
On Thu, Oct 21, 2010 at 3:53 PM, Kurt Zeilenga wrote:
>
> I have number of concerns.
>
> I am concerned that a client or the user would not know why SASL
> authentication was being offered, what id to use, etc.. Aside from user
> confusion, I fear attackers will actually highjack the S2S conne
On Oct 21, 2010, at 12:08 PM, Alex Milowski wrote:
> On Wed, Oct 20, 2010 at 3:29 PM, Kurt Zeilenga
> wrote:
>>
>> If the former, however, I would have significant reservations. SASL
>> mechanisms such as SCRAM is commonly used to authenticate the user's
>> identity to an application servi
On Thu, Oct 21, 2010 at 2:50 PM, Dave Cridland wrote:
>
> But in these cases, the attacker can not only read, but spoof, traffic. In
> which case they can at least insert traffic of their choosing into a
> session.
>
> Also, if they have the challenge and response in the clear, they can perform
>
On Thu Oct 21 22:11:50 2010, Alex Milowski wrote:
On Thu, Oct 21, 2010 at 2:00 PM, Dave Cridland
wrote:
> On Thu Oct 21 20:08:42 2010, Alex Milowski wrote:
>>
>> Most simply, I want to be able to use something like DIGEST
>> authentication to keep the shared secret from being exposed. I
thi
On Thu, Oct 21, 2010 at 2:00 PM, Dave Cridland wrote:
> On Thu Oct 21 20:08:42 2010, Alex Milowski wrote:
>>
>> Most simply, I want to be able to use something like DIGEST
>> authentication to keep the shared secret from being exposed. I think
>> that is a simple request that is fairly straightfo
On Thu Oct 21 20:08:42 2010, Alex Milowski wrote:
Most simply, I want to be able to use something like DIGEST
authentication to keep the shared secret from being exposed. I
think
that is a simple request that is fairly straightforward to
accomodate.
A simple hash scheme doesn't protect ag
On Wed, Oct 20, 2010 at 3:29 PM, Kurt Zeilenga wrote:
>
> If the former, however, I would have significant reservations. SASL
> mechanisms such as SCRAM is commonly used to authenticate the user's identity
> to an application service, they are not intended to be used to establish who
> knows
On Thu, Oct 21, 2010 at 4:28 PM, Will Thompson
wrote:
> On 21/10/10 15:47, Tomasz Sterna wrote:
>>
>> On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
>>
>>>
>>> 1. Assign the new client a fresh resource;
>>> 2. Boot the old connection, granting the resource to the new client;
>>> 3. Refuse
On Thu Oct 21 16:28:04 2010, Will Thompson wrote:
I'd argue that any reasonable client should do the right thing
(that is: not reconnect until explicitly told to) if it's booted
for reason . :)
Entirely agree.
When you've finished fixing all the clients, let me know and I'll
change the be
On 21/10/10 16:44, Kevin Smith wrote:
I've heard that suggested before, but after consideration I think the
server is the sensible place to deal with this.
The exchange:
Can I be bob please?
No.
Can I be bert please?
No.
No.
Can I be euhal.uba.ul339a938udleul.acgruh.u please?
Yes.
On Thu, Oct 21, 2010 at 4:28 PM, Will Thompson
wrote:
> On 21/10/10 15:47, Tomasz Sterna wrote:
>>
>> On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
>>
>>>
>>> 1. Assign the new client a fresh resource;
>>> 2. Boot the old connection, granting the resource to the new client;
>>> 3. Refuse
On 21/10/10 15:47, Tomasz Sterna wrote:
On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
1. Assign the new client a fresh resource;
2. Boot the old connection, granting the resource to the new client;
3. Refuse the new connection.
I don't really think behaviour 3 is very useful.
On czw, 2010-09-16 at 09:38 +0100, Will Thompson wrote:
> 1. Assign the new client a fresh resource;
> 2. Boot the old connection, granting the resource to the new client;
> 3. Refuse the new connection.
>
> I don't really think behaviour 3 is very useful.
a. Protects you from rerunning the same
18 matches
Mail list logo
