[Standards] updated STUN discovery proposal

Evgeniy Khramtsov xramtsov at gmail.com
Tue May 1 12:29:30 UTC 2007

Peter Saint-Andre wrote:

> And:
>    Furthermore, for servers that are not authenticating shared secret
>    requests, it is RECOMMENDED that short-term credentials be
>    constructed in a way such that they do not require memory or disk to
>    store.
>    This can be done by intelligently computing the username and
>    password.  One approach is to construct the USERNAME as:
>          USERNAME = <prefix,rounded-time,hmac>
>    Where prefix is some random text string (different for each shared
>    secret request), rounded-time is the current time modulo 20 minutes,
>    and hmac is an HMAC [13] over the prefix and rounded-time, using a
>    server private key.
>    The password is then computed as:
>          password = <hmac(USERNAME,anotherprivatekey)>
>    With this structure the server can verify that the username was not
>    tampered with using the hmac present in the username.
> Peter

I have already told about it here: 
http://mail.jabber.org/pipermail/standards/2007-March/014456.html :)
//Jean-Louis Seguineau had posted about Google's aproach here: 
(you can decode base64 token in that stanza and look into it)
I think we have to use short-term credentials since we cannot demand 
from third-party STUN-servers to authenticate the users with long-term 
jids/passwords. Also the short-term authentication is quite simple to 
implement :) We don't need to use Shared Secret transaction for the 
short-term password creation since it is not required by the STUN/TURN 
I-D. All we need is some Private Key which is shared between XMPP and 
STUN/TURN servers - this is a simplest interaction between them. Thus, 
we can use a JID as a USERNAME and the Private Key as an 
"anotherprivatekey" in the example above. Then we can transfer computed 
password to the client in the disco/pubsub stanza. I'm not a security 
expert, so I can't tell about lifetime of the Private Key (btw, STUN I-D 
doesn't have hard requirements on the upper limit). However, Google uses 
12 hours and we can rely on their experience :)

Any suggestions?

More information about the Standards mailing list