On Oct 17, 2010, at 5:06 AM, Kurt Zeilenga wrote:
>
> On Oct 13, 2010, at 4:23 PM, Alex Milowski wrote:
>
>> I've been playing around with Multi-user Chat and I'm wondering if anyone
>> has experience with extending the protocol to include alternate room
>> password mechanisms? Specifically, I'm interest in using something like
>> digest authentication in conjunction with signed stanzas. I'd like to have
>> better guarantees on who is actually in the room.
>
> While one has to demonstrate they know the MUC room password to join, this
> demonstration does not authenticate who they are. Presently, the MUC service
> relies on the subscriber's server to authenticate the subscriber's identity
> in processing of identity-based access controls.
>
> Today's XMPP services places a fair amount of trust in the subscriber's
> server. If we want not to trust the subscriber's server as much as we today,
> protecting the MUC password is the least of our worries. So I'm going to
> assume there are other risks that one desires to mitigate here by using a
> 'digest' method for proving one knows the room's password.
>
> For instance, there is the risk that the password could be sniffed off the
> unencrypted passwords and be used to gain access to rooms not protected by
> identity-based access controls.
>
> So one could extend the MUC specification to allow assertion of a hash over
> the password and subscribingJID. This would effectively block eavesdroppers
> from gaining access to the plain text password, and replay risk is limited to
> entities we already trust (namely the subscriber's server).
>
> One could extend the MUC service to support such hashes fairly easy.
This would look something like:
<iq from='ha...@shakespeare.lit/pda'
id='disco3'
to='darkc...@chat.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq from='darkc...@chat.shakespeare.lit'
id='disco3'
to='ha...@shakespeare.lit/pda'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity
category='conference'
name='A Dark Cave'
type='text'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='muc_sha2_protected'/>
</query>
</iq>
No hash provided:
<presence
from='darkc...@chat.shakespeare.lit'
to='ha...@shakespeare.lit/pda'
type='error'>
<x xmlns='http://jabber.org/protocol/muc'/>
<error type='auth'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
User provides hash:
<presence
from='ha...@shakespeare.lit/pda'
to='darkc...@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'>
<hash algorithm="sha2">hash</hash>
</x>
</presence>
where hash was the base64 encoded sha2 hash over the concat of subscribers'
normalized bare jid, " ", the room's normalized bare jid, " ", and the shared
password.
>
> I note that SASL is about identity proof. Since the room password is not
> about identity proof, SASL itself doesn't seem applicable here, though I
> guess one could (ab)use it here if they like.
>
> -- Kurt
>
>>
>> --Alex Milowski
>>
>> _______________________________________________
>> JDev mailing list
>> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
>> Info: http://mail.jabber.org/mailman/listinfo/jdev
>> Unsubscribe: jdev-unsubscr...@jabber.org
>> _______________________________________________
>
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: jdev-unsubscr...@jabber.org
> _______________________________________________
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
_______________________________________________
