[Standards] updated STUN discovery proposal
Evgeniy Khramtsov
xramtsov at gmail.com
Tue May 1 07:29:30 CDT 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:
http://antecipate.blogspot.com/2006/11/media-relay-hidden-query.html
(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