[Standards-JIG] JEP-0070: Transaction ID in Digest method

Peter Saint-Andre stpeter at jabber.org
Tue May 30 19:41:42 UTC 2006

Hash: SHA1

Maciek Niedzielski wrote:
> Peter Saint-Andre wrote:
>>> Maciek Niedzielski wrote:
>>>>> Let's say I want to use JEP-70 with digest method.
>>>>> My web browser sends a hash (eg. MD5) of my JID + transaction ID +
>>>>> something else. A bit later, as the JEP says:
>>>>> "HTTP Server MUST pass the URL, method, JID, and transaction identifier
>>>>> to the XMPP Server for confirmation"
>>>>> How exactly the server may know the transaction identifier, if it was
>>>>> transformed by unidirectional hash function?
>>>>> I think that this ID could be passed via cnonce, since it really matches
>>>>> the original semantics of this argument.
>>> "
>>> When the realm is
>>> "xmpp", the profile defined herein further specifies that prior to
>>> creating the MD5 checksum the username MUST be a valid JID as described
>>> above, that the password MUST be a transaction identifier as described
>>> above
>>> That seems wrong, since there is no "password" entity in digest auth.
>>> Passing the transaction ID via the cnonce seems to be better.
> This unfortunately makes the transaction ID "visible" to others watching
> our connection. If it was invisible (like before, in the not-so-working
> version), confirm this transaction ID via XMPP once, and then trust it
> for some time. If it becomes visible, you need to choose different
> transaction ID for every request (just like in Basic method).
> Having just one XMPP confirmation for multiple request could be a big
> advantage: just imagine opening a website with many images, etc, and
> every of the requiring its own confirmation via XMPP. Even if this is
> automated (user does not confirm manually), I'm afraid it may become
> slow (I think it's faster to check user's password in a file or in a
> database, as it is done now, than to exchange stanzas). And if it is
> done by hand, users will just hate it. And they won't even try to check
> if transaction IDs match or not - they will just press "yes", getting
> more and more annoyed every time they click.

I think that many implementations will build a little XMPP client into
the HTTP client (or a little HTTP client into the XMPP client) so that
the two communication bands are logically distinct but physically
located in the same client. So the end user will never be bothered.

> So - as I suggested in another message in this thread - how about adding
> alternative method of confirming via XMPP, which would ask user to
> provide the same transaction ID as in HTTP request?

Sure. Perhaps you could write up a patch to JEP-0070? :-)


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060530/7d7cb731/attachment.bin>

More information about the Standards mailing list