[Standards] updated STUN discovery proposal

[Peter Saint-Andre]

Evgeniy Khramtsov wrote:
> Sean Egan пишет:
> 
>> Some STUN servers *may* require authorization for a binding request,
>> but I agree that's uncommon. 
> 
> 
> This is uncommon in current implementations of STUN servers. But I think 
> we *must* reject unauthorized binding requests just because this will 
> protect STUN clients from forged responses (a probability of this is 
> high enough when UDP transport is used).
> 
>> The real issue is that if you're doing
>> ICE, you also want to do an allocation request, which probably *does*
>> require authorization. The frequency with which you'll want to get
>> STUN authorization credentials along with the server addresses is high
>> enough to return them both in the same request.
> 
> Agreed.

Also agreed.

I find rfc3489bis 
<http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis> a bit 
confusing on the matter of credentials, but it distinguishes between 
long-term credentials and short-term credentials as follows:

    Long Term Credential:  A username and associated password that
       represent a shared secret between client and server.  Long term
       credentials are generally granted to the client when a subscriber
       enrolles in a service and persist until the subscriber leaves the
       service or explicitly changes the credential.

    Short Term Credential:  A temporary username and associated password
       which represent a shared secret between client and server.  A
       short term credential has an explicit temporal scope, which may be
       based on a specific amount of time (such as 5 minutes) or on an
       event (such as termination of a SIP dialog).  The specific scope
       of a short term credential is defined by the application usage.  A
       short term credential can be obtained from a Shared Secret
       request, though other mechanisms are possible.

See also:

    If the client receives a 401 (Unauthorized) response and had not
    included a MESSAGE-INTEGRITY attribute in the request, it is an
    indication from the server that credentials are required.  If the
    REALM attribute was present in the response, it is a signal to the
    client to use a long term shared secret and retry the request.  The
    client SHOULD retry the request, using the username and password
    associated with the REALM (this username and password are assumed to
    be pre-provisioned into the client through some other means).  If the
    REALM attribute was absent in the response, it is a signal to the
    client to use a short term shared secret and retry the request.  If
    the client doesn't have a short term shared secret, it SHOULD use the
    Shared Secret request to obtain one, and then retry the request with
    the username and password obtained as a result.

Since I don't see any hard rules about credentials, I assume that the 
procedures for issuing them are implementation-specific. Therefore a 
password could be issued specifically for that username or could be 
something that is generic but that times out in 5 minutes (etc.). In the 
first case, the credentials could not be provided via pubsub. In the 
second case, the server could provide the credentials via pubsub but 
would need to push out updates every 5 minutes or whatever. Since we 
don't know what policy STUN servers will follow, it seems to me that 
doing this via pubsub is not advisable.

Am I missing something?

/psa



-------------- 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/20070430/57844ab9/smime-0001.bin