Re: [tram] HA1 vs HA1b with TURN

I agree that STUN ORIGIN could work for this. 

I have revised the draft based on list discussion and think these changes will resolve the DISCUSSes blocking the draft.

Feedback from the working group on whether this is the best path forward for STUN Origin would be helpful. 

- Alan -

> On Oct 21, 2015, at 2:12 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
> 
> Hi Daniel
> 
> please see below:
> 
>> On Wed, Oct 21, 2015 at 1:33 PM, Daniel Pocock <daniel@pocock.pro> wrote:
>> 
>> 
>> I've been working with a few projects that use the "HA1b" for DIGEST and
>> HMAC, e.g.
>> 
>> HA1 = H(user:realm:password)
>> 
>> HA1b = H(user@domain:realm:password)
>>    where domain (sometimes) == realm
>> 
>> When a client is configured (user enters their SIP or XMPP address and
>> their password for the first time), the client doesn't really know if it
>> should use the HA1 or HA1b approach.  Many default to HA1 but give the
>> user the option to manually configure an auth username.
>> 
>> Furthermore, when a SIP client sends a request, the request includes
>> things like a request URI, From and To headers that allow the server or
>> proxy to work out which realm to challenge with (if it supports more
>> than one realm).  The initial request to a TURN server doesn't give such
>> clues, consequently, the TURN server typically just has a single realm.
>> RFC 5389 s10.2.1.1 specifies that the client should not send username
>> or realm values with the first request to the server.  It is in these
>> scenarios that HA1b can be particularly useful for virtual hosting on a
>> single TURN server on a single UDP port.
>> 
>> Therefore, a few things come to mind:
>> 
>> - could the client send some attribute in the first request (RFC 5389
>> s10.2.1.1) to inform the TURN server about the full username@domain?
> 
> there is ORIGIN draft:
> 
> https://tools.ietf.org/html/draft-ietf-tram-stun-origin-06
> 
> that is the attribute that you are looking for - it allows building a
> server that supports multiple realms. I am not sure about its future,
> but coturn supports that functionality.
> 
> Also, there is a third-party authorization RFC 7635 that also allows
> multiple realms, but it is rather different from the usual scheme.
> 
> But the TURN server is never using HA1b, that is not a standard
> feature. With ORIGIN, you may have same user names in different
> realms, and those users exist independently because all data and the
> authentication are using realm as part of the key.
> 
>> 
>> - could the TURN server challenge include some attribute telling the
>> client to use the HA1b approach?
> 
> Not in the current scheme.
> 
>> 
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram