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

From: "Guylain Lavoie" <[email-masked]>
Date: Thu, 26 Feb 2009 10:44:40 -0500

Hello  Avshalom,
 
When a binding request is sent, it  must be authenticated with the
password of the STUN server side . In this case, the answerer will
authenticate the binding request it sends to the offerer using the
password provided by the offerer .   
The STUN server in the context of ICE will need to be a little more
intelligent than just searching for the specific username in its
database. Instead, it will need to parse the username and retrieve the
local username fragment to find the correct password to use.
In our ICE implementation, the STUN server implementation has a hook to
request to its manager (the ICE implementation) what is the password
associated with the username. The ICE implementation must then split the
username and find the correct password. This allow the STUN layer to
still be compliant with the specification while offering more
flexibility.
 
Best Regards,
Guylain
 
Guylain Lavoie
Technical Product Manager
M5T, a Division of Media5 Corporation
Web: http://www.m5t.com <blocked::http://www.m5t.com/> 
Email: [email-masked] <blocked::mailto:[email-masked]> 
Tel: +1-819-829-1008, ext: 662
Fax: +1-819-829-1342

________________________________

From: Avshalom Houri [mailto:[email-masked]] 
Sent: February 26, 2009 10:03 AM
To: [email-masked]
Cc: Uri Segev
Subject: [MMUSIC] Question on Authentication in ICE & STUN

(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