[Standards] updated STUN discovery proposal

[Peter Saint-Andre]

Evgeniy Khramtsov wrote:
> 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)

In fact the details seem to be here:

http://mail.jabber.org/pipermail/standards/2007-March/014453.html

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

Well, we can't "demand" that STUN servers share private keys with XMPP 
servers either. :)

Con:

1. May require business level agreement to establish trust between STUN 
server and XMPP server, thus making it more difficult to establish 
third-party STUN servers that can be used by anyone on the XMPP network.

Pro:

1. May require business level agreement to establish trust between STUN 
server and XMPP server, thus making it more difficult to establish 
third-party STUN servers that can be used by anyone on the XMPP network. :)

2. Probably easiest to implement and deploy.

Question:

Is a wire protocol needed between STUN server and XMPP server for key 
refresh, or do they automatically update every 12 hours from a common 
key store? If there's no wire protocol, then we can't have third-party 
STUN servers at all.

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

So in that case, the XMPP server hands out the same password to every 
client?

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

Sounds feasible, but is that workable for implementations and 
deployments that use long-term credentials?

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070501/9ccf3f9b/smime.bin