[Standards] updated STUN discovery proposal
stpeter at jabber.org
Mon Apr 30 13:58:13 CDT 2007
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.
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.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070430/57844ab9/smime-0001.bin
More information about the Standards