[jdev] Alternate MUC Authentication Mechanisms

[Alex Milowski]

On Thu, Oct 21, 2010 at 4:20 PM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> 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 something simply based on existing authentication method.

The general workflow for these methods are for the client to respond
to a service challenge.  As such, the flow of elements withint the
stanzas are going to be very similar to the SASL elements in RFC 3920.

Certainly, I would prefer the error response with the non-authorized
to contain challenge response element with a mechanism named.  That
would avoid having to send the "auth" element when, in some cases,
there is no initial seed.

>
> However, I prefer a mechanism that doesn't have a significant additional round-trip burden.   Round-trips are very expensive in some systems.
>
> One of the nice things about the approach I suggest is that it introduces zero additional round-trips.
>

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.  As time can't be synchronized
across the various systems, you can' avoid having the service send the
nonce that is then used in the response.  As such, I don't think a
client-side timestamp helps that much with replay attacks.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics