Subject: Re: [tram] draft-johnston-tram-stun-origin-00

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 13 Jan 2014 13:27:03 +0000

I like the draft, it solves the multiple realm problem we were discussing in BEHAVE WG sometime back http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04

   5.  Hosting multiple realms on a single IP address is challenging
       with TURN.  When a TURN server needs to send the REALM attribute
       in response to an unauthenticated request, it has no useful
       information for determining which realm it should send, except
       the source transport address of the TURN request.  Note this is a
       problem with multi-tenant scenarios only.  This may not be a
       problem when TURN server is located in enterprise premises.

My initial comments

1.  Section Security Considerations

Comment 1>  On-path attacker can do much more damage like modifying the payload, dropping the packet etc. The more interesting scenario would be passive attacker sniffing the on-wire packets and can thus determine the value in the ORIGIN header.

Comment 2>  DTLS could also solve the problem with the server_name extension defined RFC6066.
Is there need for ORIGIN STUN attribute if DTLS is used with server_name extension ?

Comment 3>  ORIGN attribute would be typically used before long-term authentication has started. In what scenarios content of ORIGIN attribute will be integrity protected ?

2.  Section STUN usage

Rouge Client can include any domain to which STUN binding response would be received to defeat the purpose. The only way to solve the problem would be to use STUN Auth. Though STUN Auth is typically not used with Public STUN servers, but with STUN servers deployed in the Enterprise premises the situation could change.  http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5 explains the use case of enterprise deploying STUN server.

-Tiru.
From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Friday, January 10, 2014 7:21 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [tram] draft-johnston-tram-stun-origin-00

Hi
I've been reviewing the draft http://www.ietf.org/mail-archive/web/tram/current/maillist.html .
The general idea definitely makes sense.

Large TURN servers may indeed need separate realms for separate groups of users. It would make the administration more structured. Also, the TURN server may provide different level of services for different realms. For example, the "front" TURN server may just redirect with 300 error different origins to different backend servers with different configurations.
One thing that I wish to be included into the draft would be the exact new STUN attribute value (section 2). Without that value, a test/proof of concept implementation cannot be done. I'd suggest a definition like:

#define STUN_ATTRIBUTE_AGENT_ORIGIN (0x802F)
The value 0x802F is in comprehensive-optional range, and it is not taken (yet).
Thanks
Oleg
http://code.google.com/p/rfc5766-turn-server/

---

From: Alan Johnston <[email-masked]>
Date: Mon, 13 Jan 2014 10:23:15 -0600

Tiru,

Thanks for your comments - I'm glad you like the draft.  See below for a
few comments and replies.

- Alan -

On Mon, Jan 13, 2014 at 7:27 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  I like the draft, it solves the multiple realm problem we were
> discussing in BEHAVE WG sometime back
> http://tools.ietf.org/html/draft-reddy-behave-turn-auth-04
>
>
>
> Comment 1>  On-path attacker can do much more damage like modifying the
> payload, dropping the packet etc. The more interesting scenario would be
> passive attacker sniffing the on-wire packets and can thus determine the
> value in the ORIGIN header.
>

That is true.  A passive attacker sniffing a STUN packet would be able to
determine the ORIGIN.  The passive attacker might also be able to sniff DNS
and HTTP traffic which would provide the same information, unless, as we
point out in the draft, HTTPS and DNSSEC are both used.

> Is there need for ORIGIN STUN attribute if DTLS is used with server_name

I'll take a look at RFC 6066 and see if it solves the problem.  Is RFC 6066
widely implemented and used?

>
>
> Comment 3>  ORIGN attribute would be typically used before long-term
> authentication has started. In what scenarios content of ORIGIN attribute
> will be integrity protected ?
>

The ORIGIN attribute will be present both before and after authentication,
so after authentication it will be integrity protected by the
MESSAGE-INTEGRITY attribute, right?

>
>
> 2.  Section STUN usage
>
>
>
> Rouge Client can include any domain to which STUN binding response would
> be received to defeat the purpose. The only way to solve the problem would
> be to use STUN Auth. Though STUN Auth is typically not used with Public
> STUN servers, but with STUN servers deployed in the Enterprise premises the
> situation could change.
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.3.5explains the use case of enterprise deploying STUN server.
>

Yes, ORIGIN doesn't replace authentication.  However, in the WebRTC case,
it would require a rogue or hacked browser.  I think this draft helps solve
that use case for enterprise users who are out on the public Internet.  An
enterprise STUN server could use the attribute to determine which STUN
requests from the public Internet it should respond to.

>
>
> -Tiru.
>
> *From:* tram [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Oleg Moskalenko
> *Sent:* Friday, January 10, 2014 7:21 AM
> *To:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* [tram] draft-johnston-tram-stun-origin-00
>
>
>
> Hi
>
> I've been reviewing the draft
> http://www.ietf.org/mail-archive/web/tram/current/maillist.html .
>
> Large TURN servers may indeed need separate realms for separate groups of
> users. It would make the administration more structured. Also, the TURN
> server may provide different level of services for different realms. For
> example, the "front" TURN server may just redirect with 300 error different
> origins to different backend servers with different configurations.
>
> One thing that I wish to be included into the draft would be the exact new
> STUN attribute value (section 2). Without that value, a test/proof of
> concept implementation cannot be done. I'd suggest a definition like:
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 13 Jan 2014 11:07:32 -0800

Hi Alan

please see below:

> MESSAGE-INTEGRITY attribute, right?
I can see the purpose of the ORIGIN in the original ALLOCATE request,
BEFORE the authentication. The ORIGIN tells the server which realm to
choose. So, implicitly, the ORIGIN afterwards (after the initial
authentication and ALLOCATE dialog) is "implied" by the realm and by the
session itself. So, why the ORIGIN has to be included into the messages
after the initial authentication ? It increases the traffic; but more
importantly, it is either redundant (if the ORIGIN value is the same as the
"initial" ORIGIN) or malicious (if the ORIGIN is different from the
"initial" ORIGIN).

I'd suggest to limit the meaningful ORIGIN usage to the initial
authentication messages.  In all other messages, the ORIGIN may (must) be
ignored and it can be used only for the logging purposes.

That leaves the interesting case for re-authentication (when in the middle
of the TURN session the credentials are expiring and we are requesting
re-authentication. I suppose that a practical approach would be that the
TURN server must store the "initial" ORIGIN for the whole length of the
session and ignore any ORIGIN attributes during the subsequent
negotiations. The value of the ORIGIN attribute is not secure (just a hint
that is open to everybody listening) and it makes sense only as the initial
hint.

Thanks
Oleg

---

From: Justin Uberti <[email-masked]>
Date: Mon, 13 Jan 2014 17:00:23 -0800

On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston <[email-masked]>wrote:

> I'll take a look at RFC 6066 and see if it solves the problem.  Is RFC
> 6066 widely implemented and used?
>

I am not sure if this works, since it has the same problem as REALM. IOW,
the server doesn't know what name or REALM to use prior to the ORIGIN being
sent by the client.

> MESSAGE-INTEGRITY attribute, right?

True. One possible implication would be that the TURN server needs to wait
for an authenticated message containing ORIGIN before making a decision, or
perhaps, that ORIGIN should not be included in unauthenticated TURN
messages. (This is all avoided when using DTLS though.)

>> One thing that I wish to be included into the draft would be the exact
>> new STUN attribute value (section 2). Without that value, a test/proof of
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 13 Jan 2014 17:09:16 -0800

> messages. (This is all avoided when using DTLS though.)

Justin, that would not work that way. For authentication, we must know the
realm - and so we need the ORIGIN value before any authentication can be
done. That would be catch 22.

To the contrary, I believe that ORIGIN must appear in unauthenticated
messages only, to signal to the server which realm to choose. In the
already authenticated messages, it has no sense, albeit for logging.

The idea was to provide a hint to the TURN server which realm to choose.
And that hint is totally optional, in comprehension-optional range. The
TURN server may ignore it altogether, or it may use it for whatever realm
choosing algorithm it implements.

That new ORIGIN attribute must not carry any "hard" meaning, and it must
not be scrutinized by the server. That is just a hint (but a valuable one).

Regards,
Oleg

---

From: Alan Johnston <[email-masked]>
Date: Mon, 13 Jan 2014 20:34:06 -0600

I agree with Oleg.

ORIGIN is useful for logging and also as a hint for realm selection.  It is
up to the server what to do with it.  A common behavior is what he
describes: before authentication, the TURN server may find it very useful.
 After authentication, less so, but it could still be logged.  Also,
remember that there isn't necessarily a 1:1 relation between origins and
realms.  So in cases where a realm is shared among a number of origins,
logging the origin may still be useful for the server.

I'm reluctant to define too strict usage of ORIGIN.  I think it makes sense
to say it should not be used where we can't come up with any use cases
(such as the short-term authenticated ICE usage of STUN), but I think we
should allow it for all other STUN uses, both before and after
authentication.  This is simpler and will cover the widest set of (current
and future) use cases.  The exception is where we can show that it somehow
does real harm.

- Alan -

On Mon, Jan 13, 2014 at 7:09 PM, Oleg Moskalenko <[email-masked]>wrote:

>> The ORIGIN attribute will be present both before and after
>>> authentication, so after authentication it will be integrity protected by
>>> the MESSAGE-INTEGRITY attribute, right?
>>>
>>
>> True. One possible implication would be that the TURN server needs to
>> wait for an authenticated message containing ORIGIN before making a
>> decision, or perhaps, that ORIGIN should not be included in unauthenticated
>> TURN messages. (This is all avoided when using DTLS though.)
>>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 14 Jan 2014 04:38:04 +0000

I agree with Oleg response.

-Tiru.
From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Tuesday, January 14, 2014 12:38 AM
To: Alan Johnston
Cc: Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tram] draft-johnston-tram-stun-origin-00

Hi Alan
please see below:

On Mon, Jan 13, 2014 at 8:23 AM, Alan Johnston <[email-masked]<mailto:[email-masked]>> wrote:

The ORIGIN attribute will be present both before and after authentication, so after authentication it will be integrity protected by the MESSAGE-INTEGRITY attribute, right?

I can see the purpose of the ORIGIN in the original ALLOCATE request, BEFORE the authentication. The ORIGIN tells the server which realm to choose. So, implicitly, the ORIGIN afterwards (after the initial authentication and ALLOCATE dialog) is "implied" by the realm and by the session itself. So, why the ORIGIN has to be included into the messages after the initial authentication ? It increases the traffic; but more importantly, it is either redundant (if the ORIGIN value is the same as the "initial" ORIGIN) or malicious (if the ORIGIN is different from the "initial" ORIGIN).
I'd suggest to limit the meaningful ORIGIN usage to the initial authentication messages.  In all other messages, the ORIGIN may (must) be ignored and it can be used only for the logging purposes.

That leaves the interesting case for re-authentication (when in the middle of the TURN session the credentials are expiring and we are requesting re-authentication. I suppose that a practical approach would be that the TURN server must store the "initial" ORIGIN for the whole length of the session and ignore any ORIGIN attributes during the subsequent negotiations. The value of the ORIGIN attribute is not secure (just a hint that is open to everybody listening) and it makes sense only as the initial hint.
Thanks
Oleg

---

From: Justin Uberti <[email-masked]>
Date: Tue, 14 Jan 2014 09:52:26 -0800

> done. That would be catch 22.

Yes, the server needs to decide which REALM to use based on the initial,
unauthenticated ORIGIN - I was suggesting that implementations could wait
for the authenticated ORIGIN if they needed to make other decisions where
the authentication is important.

I agree it's probably best for servers not to do this though (see below).

> not be scrutinized by the server. That is just a hint (but a valuable one).

Agree it's best if we treat ORIGIN as a hint, essentially an identifier of
the web application in use, similar to how SOFTWARE might be used to
identify a native application.