Subject: [MMUSIC] Question on Authentication in ICE & STUN

From: Avshalom Houri <[email-masked]>
Date: Thu, 26 Feb 2009 17:03:13 +0200

(Question was raised by Uri Segev, CCd)

Section 7.2 of the ICE draft indicates that:
 
   The agent MUST use a short term credential to authenticate the
   request and perform a message integrity check.  The agent MUST
   consider the username to be valid if it consists of two values
   separated by a colon, where the first value is equal to the username
   fragment generated by the agent in an offer or answer for a session
   in-progress.  It is possible (and in fact very likely) that an
   offerer will receive a Binding Request prior to receiving the answer
   from its peer.  If this happens, the agent MUST immediately generate
   a response (including computation of the mapped address as described
   in Section 7.2.1.2.  The agent has sufficient information at this
   point to generate the response; the password from the peer is not
   required.  Once the answer is received, it MUST proceed with the
   remaining steps required, namely Section 7.2.1.3, Section 7.2.1.4,
   and Section 7.2.1.5 for full implementations.  In cases where
   multiple STUN requests are received before the answer, this may cause
   several pairs to be queued up in the triggered check queue.

Because the offerer will receive the Binding request before it knows the 
remote credentials, it doesn't have any way to authenticate the incoming 
request (as specified in the text above).

However, RFC 5389 (STUN), section 10.1.2 (Receiving a Request or 
Indication):

   o  If the USERNAME does not contain a username value currently valid
      within the server:

      *  If the message is a request, the server MUST reject the request
         with an error response.  This response MUST use an error code
         of 401 (Unauthorized).

      *  If the message is an indication, the agent MUST silently
         discard the indication.

   If these checks pass, the agent continues to process the request or
   indication.  Any response generated by a server MUST include the
   MESSAGE-INTEGRITY attribute, computed using the password utilized to
   authenticate the request.  The response MUST NOT contain the USERNAME
   attribute.

This means that the offerer STUN layer should reject the connectivity 
check and not give it to the ICE layer. Furthermore, if it would accept 
it, the server doesn't have a way to provide the response.

Does the ICE spec requires different behavior from the STUN 
implementation?

One more issue related to long term authentication: When the server is 
using a directory which stores only a hashed value of the password, 
compared to an encrypted password which can be retrieved or H(A1), is 
there any way to use long term credentials? (and for that matter also 
digest authentication in SIP)?

--Avshalom

---

From: Youness Alaoui <[email-masked]>
Date: Thu, 26 Feb 2009 12:55:18 -0500

Hi,

> request (as specified in the text above).
Actually, it already has everything it needs to authenticate the
incoming request. Since the incoming request will use the local password
for generating the message-integrity, you can authenticate it without
knowing the remote password.
Also note that the spec says that the first part of the username must be
your local ufrag, so you MUST make sure your ICE implementation will
parse the username to verify the local ufrag part only, not generate the
local:remote and try to compare it with the username.

> it, the server doesn't have a way to provide the response.

No, the USERNAME does contain a valid username value, you just have to
make sure that the ICE layer will parse the USERNAME and tell the STUN
layer if it's valid or not (the RFC 5389 spec doesn't specify how the
validity of the username needs to be verified).
You also have everything you need since the STUN response will be using
the same username and password as the one for the incoming request, so
you still don't need the remote information to validate the message or
respond to it.

> Does the ICE spec requires different behavior from the STUN 
No, you just need to make sure your STUN implementation allows you to
tell it if a username is valid or not and which password is associated
with it, and not have a static list of username/passwords to check.
You can have a look at the way it's implemented in libnice.
Line 188 :
http://git.collabora.co.uk/?p=user/kakaroto/libnice.git;a=blob;f=stun/stunagent.h;h=d47b1712029df3a024a95c4ec2f938347604ea80;hb=e6b909de1952609694a2b886ce4d217f41f9708d#l187
What my STUN layer does is that when you call stun_agent_validate() you
give it a validater callback function that will get called with the
username as argument, it validates the username and provides the
corresponding password back to the STUN agent. You can also set the
callback to stun_agent_default_validater, which takes a simple
username/password structure to associate a username to a password.
What the ICE layer does however is :
Line 2137 :
http://git.collabora.co.uk/?p=user/kakaroto/libnice.git;a=blob;f=agent/conncheck.c;h=36d05bfe2e6e779d305d433a1ffecb4bbf6ff977;hb=e6b909de1952609694a2b886ce4d217f41f9708d#l2137
Which is to set its own validater callback which will only check the
first part of the username and compare it to the ufrag, then give the
local password back to the STUN agent.

> digest authentication in SIP)?

Humm.. I'm not sure if I'm the right person to answer that, but my guess
is that you would have to store the passwords plaintext on the server
otherwise you can't use them for long term authentication (or SIP digest).

Hope that helps.

Youness.

> 
> --Avshalom
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic