Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header

From: Brandon Williams <[email-masked]>
Date: Wed, 20 Jan 2016 14:59:33 -0500

I'm a bit late joining this thread, but nevertheless ...

It seems to me that if the application knows the REALM that should be 
used for auth, it's a different use case than the one we're attempting 
to handle with the ORIGIN attribute. If I understand correctly, a core 
purpose for the ORIGIN attribute is to allow the relay to determine 
which authentication REALM to require from the client, which seems to 
imply that the client has multiple options and doesn't already know 
which one to use for this case. If the client already knows the REALM, 
why does it need to tell the server anything in the initial, 
unauthenticated allocation request? Or rather, why does the server need 
to tell it which REALM to use? The only purpose of that allocation 
request becomes receiving a NONCE value.

--Brandon

On 12/14/2015 02:36 PM, Justin Uberti wrote:
> Exactly what Ted said.
>
> The difference between REALM/HOST and ORIGIN is that the application
> needs to set REALM/HOST, but ORIGIN would be auto-set by the browser.
>
> The key outstanding question IMO is whether setting REALM properly is
> actually useful, versus simply having the application include the domain
> in USERNAME. Chrome uses REALM solely to compute HA1 and thereby
> MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" realm ":"
> SASLprep(password)), the benefit of using REALM would be that you can
> use existing password databases that compute HA1 with username/realm
> specified separately. However, I'd like someone who actually has to deal
> with this sort of thing to weigh in.
>
>
>
> On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         In general case, how the user knows his realm ? He may not know it.
>         The user knows the name, the password, and the TURN server's IP
>         address or URL; knowing the realm is the TURN server's
>         responsibility.
>
>     ​If I understood Justin's drift on this, the application needs to
>     know the realm, not the user.  It could be set by the application
>     just as HOST would have been set.
>
>     regards,
>
>     Ted​
>
>
>         And how transferring the realm in an open request is different from
>         transferring the ORIGIN ? Those are metadatas of the same nature.
>
>         On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie <[email-masked]
>         <mailto:[email-masked]>> wrote:
>          > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >>
>          >> One possibly important point: USERNAME isn't sent in the
>         initial ALLOCATE.
>          >> If choosing a correct REALM on the server is important
>         (which was the
>          >> original justification for this work), we need to either
>         send USERNAME in
>          >> the initial ALLOCATE, or send up the preferred REALM.
>          >>
>          >
>          > I'm not seeing a downside to sending up the preferred REALM
>         in the initial
>          > allocate, other than it not re-using the known username@realm
>         convention.
>          > Am I missing something, or is it just spend the bytes and
>         call it done?
>          >
>          > regards,
>          >
>          > Ted
>          >
>          >
>          >
>          >>
>          >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson
>         <[email-masked] <mailto:[email-masked]>>
>          >> wrote:
>          >>>
>          >>> On 14 December 2015 at 13:15, Justin Uberti
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >>> > at that point we're basically coming up with a more
>         standard and
>          >>> > aesthetically pleasing way of doing what could already be
>         done with
>          >>> > USERNAME
>          >>> > (e.g. [email-masked] <mailto:[email-masked]>)
>          >>>
>          >>> Yeah, my thoughts exactly.  In that case it would possibly
>         be better
>          >>> to rely on an @domain convention for USERNAME and be done
>         with it.
>          >>
>          >>
>          >
>          >
>          > _______________________________________________
>          > tram mailing list
>          > [email-masked] <mailto:[email-masked]>
>          > https://www.ietf.org/mailman/listinfo/tram
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=86SFKZkjNvPDRvmAnJfKfxEY9UdfXAj-Gdyipyp7PA0&s=3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM&e=>
>          >
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Jan 2016 13:54:43 -0800

The client can only use the REALM that the server gives it. If the server
is multi-tenant, and only stores password hashes, then it's imperative that
the client uses the same realm as was used to compute the hash.

On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams <
[email-masked]> wrote:

> It seems to me that if the application knows the REALM that should be used
> for auth, it's a different use case than the one we're attempting to handle
> with the ORIGIN attribute. If I understand correctly, a core purpose for
> the ORIGIN attribute is to allow the relay to determine which
> authentication REALM to require from the client, which seems to imply that
> the client has multiple options and doesn't already know which one to use
> for this case. If the client already knows the REALM, why does it need to
> tell the server anything in the initial, unauthenticated allocation
> request? Or rather, why does the server need to tell it which REALM to use?
> The only purpose of that allocation request becomes receiving a NONCE value.
>
> --Brandon
>
>
>>         <
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=86SFKZkjNvPDRvmAnJfKfxEY9UdfXAj-Gdyipyp7PA0&s=3m5fOdab5mDO05WITwdrGq4Kqx4FgdOBjz-6NO5x-wM&e=
>> >
>>          >
>>
>>
>>
>>
>

---

From: Brandon Williams <[email-masked]>
Date: Mon, 25 Jan 2016 12:25:00 -0500

Sure, the client can only use the REALM the server gives it. I know 
that. But the suggestion in the thread seems to be that the client would 
dictate to the server what the REALM is, not the other way around.

If the client sends ORIGIN or HOST, it's effectively asking to know what 
REALM to use. If it sends REALM, it's asking a somewhat different 
question (is this REALM value OK?). If the service is available for 
multiple HOST values with a different REALM on each, then HOST really 
must be sent. There are other use cases that REALM could apply to. I'm 
just not sure it can be used as a replacement for ORIGIN. I think HOST 
works better for that.

Or was the suggestion that both HOST and REALM would be sent together?

--Brandon

On 01/22/2016 04:54 PM, Justin Uberti wrote:
> The client can only use the REALM that the server gives it. If the
> server is multi-tenant, and only stores password hashes, then it's
> imperative that the client uses the same realm as was used to compute
> the hash.
>
> On Wed, Jan 20, 2016 at 11:59 AM, Brandon Williams
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     It seems to me that if the application knows the REALM that should
>     be used for auth, it's a different use case than the one we're
>     attempting to handle with the ORIGIN attribute. If I understand
>     correctly, a core purpose for the ORIGIN attribute is to allow the
>     relay to determine which authentication REALM to require from the
>     client, which seems to imply that the client has multiple options
>     and doesn't already know which one to use for this case. If the
>     client already knows the REALM, why does it need to tell the server
>     anything in the initial, unauthenticated allocation request? Or
>     rather, why does the server need to tell it which REALM to use? The
>     only purpose of that allocation request becomes receiving a NONCE value.
>
>     --Brandon
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                  On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie
>         <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>                  <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>                   >>
>                  <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                   >> wrote:
>                   >>>
>                  <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>                   >>> > (e.g. [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>)
>                   >>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bstRUIB98hwOaulLxlErjpDk9i6GF9JdckvEC2nW_1A&s=ebOlAsUznfzVZZWlbNMG-Txv4xWvwe9wcDJp2fcpI8E&e=>
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Jan 2016 09:19:48 -0800

Hmm... I'm not exactly sure what you are proposing.

At this point the only thing that we are trying to do is to ensure proper
REALM selection in a multi-tenant case. This could be done multiple ways:
a) REALM from the client (potentially different from HOST), server either
mirrors this or returns an error (requires new web API)
b) HOST from the client, triggering corresponding REALM from server (no new
APIs)
c) user@realm in USERNAME from client, server either mirrors realm part or
returns an error (no new APIs or protocol, but has implications on how pw
db is set up)

c) is obviously the least work, followed by b) and then a).

What do you prefer?

On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams <
[email-masked]> wrote:

> Sure, the client can only use the REALM the server gives it. I know that.
> But the suggestion in the thread seems to be that the client would dictate
> to the server what the REALM is, not the other way around.
>
> REALM to use. If it sends REALM, it's asking a somewhat different question
> (is this REALM value OK?). If the service is available for multiple HOST
> values with a different REALM on each, then HOST really must be sent. There
> are other use cases that REALM could apply to. I'm just not sure it can be
> used as a replacement for ORIGIN. I think HOST works better for that.
>
>>         <mailto:[email-masked] <mailto:[email-masked]
>> >>>
>>                   >> wrote:
>>                   >>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bstRUIB98hwOaulLxlErjpDk9i6GF9JdckvEC2nW_1A&s=ebOlAsUznfzVZZWlbNMG-Txv4xWvwe9wcDJp2fcpI8E&e=
>> >
>>
>>         <

---

From: Brandon Williams <[email-masked]>
Date: Tue, 26 Jan 2016 14:23:17 -0500

The thread seemed to be discussing REALM and HOST as interchangeable, so 
I thought I might be missing something. Your list of options indicates 
the same difference I was seeing in terms of the server side behavior.

I'm interested in possible use cases for 3rd party auth. In that case, 
USERNAME already has a purpose (it contains the kid value). I think that 
kid@realm could work, but I haven't fully thought it through. a and b 
seem to map more directly to a 3rd party auth use case.

On a sparate note, b seems to cover more use cases than a/c, since it 
handles both the case where the client knows the realm ahead of time and 
the case where it needs to be told by the relay. IOW, if we go with just 
one, HOST seems the better choice to me.

--Brandon

On 01/26/2016 12:19 PM, Justin Uberti wrote:
> At this point the only thing that we are trying to do is to ensure
> proper REALM selection in a multi-tenant case. This could be done
> multiple ways:
> a) REALM from the client (potentially different from HOST), server
> either mirrors this or returns an error (requires new web API)
> b) HOST from the client, triggering corresponding REALM from server (no
> new APIs)
> c) user@realm in USERNAME from client, server either mirrors realm part
> or returns an error (no new APIs or protocol, but has implications on
> how pw db is set up)
>
> On Mon, Jan 25, 2016 at 9:25 AM, Brandon Williams
>     that. But the suggestion in the thread seems to be that the client
>     would dictate to the server what the REALM is, not the other way around.
>
>     If the client sends ORIGIN or HOST, it's effectively asking to know
>     what REALM to use. If it sends REALM, it's asking a somewhat
>     different question (is this REALM value OK?). If the service is
>     available for multiple HOST values with a different REALM on each,
>     then HOST really must be sent. There are other use cases that REALM
>     could apply to. I'm just not sure it can be used as a replacement
>     for ORIGIN. I think HOST works better for that.
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>                  needs to set REALM/HOST, but ORIGIN would be auto-set
>         by the
>                  browser.
>
>                  actually useful, versus simply having the application
>         include
>                  the domain
>                  SASLprep(password)), the benefit of using REALM would
>         be that
>                  you can
>                  specified separately. However, I'd like someone who
>         actually has
>                  to deal
>                  On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>
>                           In general case, how the user knows his realm
>         ? He may
>                  not know it.
>                           The user knows the name, the password, and the
>         TURN
>                  server's IP
>                       ​If I understood Justin's drift on this, the
>         application
>                  needs to
>                           And how transferring the realm in an open
>         request is
>                  different from
>                           transferring the ORIGIN ? Those are metadatas
>         of the
>                  same nature.
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>> wrote:
>                           <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>                            >>
>                            >> One possibly important point: USERNAME
>         isn't sent
>                  in the
>                           initial ALLOCATE.
>                            >> original justification for this work), we
>         need to
>                  either
>                           send USERNAME in
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>>
>                            >> wrote:
>                            >>>
>                           <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>                            >>> > aesthetically pleasing way of doing
>         what could
>                  already be
>                           done with
>                            >>> > USERNAME
>                            >>> > (e.g. [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>)
>                            >>>
>                            >>> Yeah, my thoughts exactly.  In that case
>         it would
>                  possibly
>                           be better
>                            >>> to rely on an @domain convention for
>         USERNAME and
>                  be done
>                           with it.
>                            >>
>                            >>
>                            >
>                            >
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=g6KCBNP6ia2BLF1kUm6O9Qo4vF1GUUQ2DJpPoeRYHxg&s=122BpTK5GLl5rnwQECQcXdO0CPIyBmbVxS2thFIoAg4&e=>
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Jan 2016 17:33:49 -0800

For 3p auth, can't you embed realm info into kid (either with @realm or
some bits in kid?)

The only significant issue I see with c) is with existing pw dbs that store
HA1 as defined in
https://en.wikipedia.org/wiki/Digest_access_authentication#Overview.

On Tue, Jan 26, 2016 at 11:23 AM, Brandon Williams <
[email-masked]> wrote:

> The thread seemed to be discussing REALM and HOST as interchangeable, so I
> thought I might be missing something. Your list of options indicates the
> same difference I was seeing in terms of the server side behavior.
>
>>                  MESSAGE-INTEGRITY; since HA1 is defined as MD5(username
>> ":"
>>                  realm ":"
>>                       know the realm, not the user.  It could be set by
>> the
>>                  application
>>                            > allocate, other than it not re-using the
>> known
>>                  username@realm
>>                           convention.
>>                            > Am I missing something, or is it just spend
>> the
>>                  bytes and
>>                           call it done?
>>                            >
>>                            > regards,
>>                            >
>>                            > Ted
>>                            >
>>                            >
>>                            >
>>                            >>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=g6KCBNP6ia2BLF1kUm6O9Qo4vF1GUUQ2DJpPoeRYHxg&s=122BpTK5GLl5rnwQECQcXdO0CPIyBmbVxS2thFIoAg4&e=
>> >
>>
>>         <