[jdev] Alternate MUC Authentication Mechanisms

[Alex Milowski]

On Thu, Oct 14, 2010 at 4:57 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
> Why would we do authentication-in-registration, rather than define a new
> remote authentication extension? XEP-0077 is already overloaded to a
> great degree, and the two functions of registration and authentication
> seem quite separate to me.

To begin with, I was really thinking of just having the ability to use
digest password mechanisms.  The flow I am think is:

1. The client joining the MUC room sends an
{urn:ietf:params:xml:ns:xmpp-sasl}auth
    element selecting the authentication mechanism in the presence mechanism.

2. The client receives a {urn:ietf:params:xml:ns:xmpp-sasl}challenge element
    via stanza response from the room.

3. The client responds with a {urn:ietf:params:xml:ns:xmpp-sasl}response element
    embedded in a response stanza send to the room.

4. If authentication succeeds, membership in the room proceeds as it normally
    would do so.

The question is what stanza elements should be used for (2) and (3).  These
stanzas would need to be directed at the room.

Alternatively, an iq/@type='set' and iq/@type='response' could be used for 1-4
(two iq set/response messages) as a way to alternatively join the room.  The
nice thing about doing it with iq stanzas is that the existing way of joining
a room doesn't have to change.

In each of these instances, I would want the ability to use e2e signatures on
the stanzas as an additional way to repudiate spoofing or stolen identities
when the credentials to the room have been compromised.


-- 
--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