Subject: [tram] HA1 vs HA1b with TURN

From: Daniel Pocock <[email-masked]>
Date: Wed, 21 Oct 2015 22:33:05 +0200

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?

- could the TURN server challenge include some attribute telling the
client to use the HA1b approach?

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 21 Oct 2015 14:12:51 -0700

Hi Daniel

please see below:

> 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.

> client to use the HA1b approach?

Not in the current scheme.

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 21 Oct 2015 23:12:08 -0700

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 <[email-masked]> wrote:
> 
> Hi Daniel
> 
> please see below:
>