Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 Jun 2014 14:19:37 +0000

Hi,

I had another read through this draft and hope we can move this forward and adopt the draft soon.

I only have one additional comment at this time and that is that I assume it should be possible for the client to include more than one origin in the Origin header field and if so the procedures around this should explained in the draft.

Regards
Andy

From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: 07 May 2014 18:50
To: Marc Petit-Huguenin
Cc: [email-masked]
Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02

Marc,

Thanks for the review.  See my comments below.

- Alan -

On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>> wrote:
A1. Intended Status: Informational

Shouldn't this be Standard Track?

Yes.

A2. Section 1, 2nd paragraph, last sentence: "as generating the response..."

I do not think that the reason for no authentication for the NAT
Discovery Usage is because it is less work, but because there is no
resource to protect so adding more work does not make sense.

I disagree that there is *no* resource to protect.  A STUN server might be minimal resources, but not none.  If a simple authentication scheme were available, I'm sure some people would use it so they could minimize the cost of their server footprint by ensuring that only authenticated users were utilizing it.  I will add some text pointing out that the minimal resources.

A3. Section 1, 8th paragraph

I do not think that the ORIGIN should be used to select the certificate
when (D)TLS is used.  First it does not work with DANE, as when an SRV
(and probably NAPTR too, but that's undefined yet) RR redirects to a
different domain, the domain to be checked with is the host name, not
the service domain (see draft-ietf-dane-srv).  For non-DANE cases, I
think that the correct way to select the certificate is to use SNI.

The draft does not suggest that ORIGIN be used to select certificates - as Oleg pointed out it isn't possible.  This paragraph was describing how RFC 6066 does not solve the problem, as had been suggested on the list.

So I would suggest to restrict the normative use of ORIGIN only to
select realms.

A4. Section 2.2. ORIGIN attribute usage

The text does not say if the ORIGIN attribute should/can be provided
after the authentication (i.e. refresh, data packets, etc...)

Currently, the text says SHOULD include, for a conformant client.  For logging, it has value even after the initial authentication.

A5. Section 2.2.  Mandatory support for server

How a TURN server that requires the usage of ORIGIN can signal this?

Right now there is no way to do this.  I agree with Oleg that it is up to the server what to do if ORIGIN is no present.

A6. Section 2. Other Usages

I think that other STUN Usages should be listed after section 2.3:

- Media Keep-Alive Usage (Section 20 of RFC5245)
- SIP Keep-Alive Usage (RFC 5626)
- NAT Behavior Discovery Usage (RFC 5780)

I'll take a look at these scenarios.  I suspect that it would be a reasonable usage for client-to-server usages, but not for peer-to-peer usages.

A7. Section 4, 3rd paragraph: "If the STUN MESSAGE-INTEGRITY attribute
is present, the contents of the ORIGIN attribute are integrity protected."

Which never happen in the usages listed in the document:  for section
2.1, there is never an integrity protection, and for 2.2, the ORIGIN is
needed to select the realm, so the ORIGIN is sent before it can be
protected.  Perhaps 2.2 should say that if ORIGIN was sent to select the
realm, it MUST be repeated at identical on the second Allocate (the one
that has an M-I) and that the server MUST reject it if it is not
identical to the first one.  Not sure it matters though.

I agree that there is no integrity protection of the ORIGIN attribute (or any other attribute) until after authentication.  However, ORIGIN can be used both before and after authentication.  I'll review this text and make sure this is clear.  I don't believe we need any special rules, as this applies to any STUN attribute.

Nits
----

- Section 2, 2nd paragraph: "The number used for the this in the ..."

Does not parse.

The middle "the" shouldn't be there.

--
Marc Petit-Huguenin
Developer  |  Jive Communications, Inc.
Jive.com  |  [email-masked]<mailto:[email-masked]>

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 5 Jun 2014 07:26:21 -0700

What would be the purpose of multiple origins ?

Oleg

> On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" <[email-masked]> wrote:
> 
> Hi,
>  
> On Tue, May 6, 2014 at 5:55 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> Jive.com  |  [email-masked]
> 
> 
> [email-masked]
> [email-masked]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 5 Jun 2014 14:48:53 +0000

Multiple Origins for HTTP Requests are covered in http://tools.ietf.org/html/rfc6454#section-7.2 I just assumed the same would apply to the usage in this context.

Andy

> -----Original Message-----
> From: Oleg Moskalenko [mailto:[email-masked]]
> Sent: 05 June 2014 15:26
> To: Hutton, Andrew
> Cc: Alan Johnston; [email-masked]
> I only have one additional comment at this time and that is that I
> assume it should be possible for the client to include more than one
> origin in the Origin header field and if so the procedures around this
> should explained in the draft.
> 
> Regards
> Andy
> 
> 
> 
> 
> I disagree that there is *no* resource to protect.  A STUN server might
> be minimal resources, but not none.  If a simple authentication scheme
> were available, I'm sure some people would use it so they could
> minimize the cost of their server footprint by ensuring that only
> authenticated users were utilizing it.  I will add some text pointing
> out that the minimal resources.
> 
> The draft does not suggest that ORIGIN be used to select certificates -
> as Oleg pointed out it isn't possible.  This paragraph was describing
> how RFC 6066 does not solve the problem, as had been suggested on the
> list.
> 
> 
> Currently, the text says SHOULD include, for a conformant client.  For
> logging, it has value even after the initial authentication.
> 
> 
> Right now there is no way to do this.  I agree with Oleg that it is up
> to the server what to do if ORIGIN is no present.
> 
> I'll take a look at these scenarios.  I suspect that it would be a
> reasonable usage for client-to-server usages, but not for peer-to-peer
> usages.
> 
> I agree that there is no integrity protection of the ORIGIN attribute
> (or any other attribute) until after authentication.  However, ORIGIN
> can be used both before and after authentication.  I'll review this
> text and make sure this is clear.  I don't believe we need any special
> rules, as this applies to any STUN attribute.
> 
> Nits
> ----
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 5 Jun 2014 12:55:46 -0700

If we do want to support multiple origins per request then we have to
state, clearly, three things:

  1) Use cases.
  2) How we use multiple origins when we process the request.
  3) How we format multiple origins in the request - as comma-separated
single field or multiple origin attributes. As STUN/TURN is a binary
protocol, I think that the second option is better.

The usefulness of multiple origins in TURN is not very obvious to me. I
implemented ORIGIN in a pilot implementation
https://code.google.com/p/coturn/ but I assumed a single ORIGIN field per
request.

Oleg

On Thu, Jun 5, 2014 at 7:48 AM, Hutton, Andrew <[email-masked]>
wrote:

> Multiple Origins for HTTP Requests are covered in
> http://tools.ietf.org/html/rfc6454#section-7.2 I just assumed the same
> would apply to the usage in this context.
>
> Andy
>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 5 Jun 2014 15:28:16 -0500

Andy,

Thanks for your review and comments. 

When you mentioned multiple origins, I thought you were referring to a SIP origin and an HTTP origin, but it seems the HTTP origin has the concept of more than one. I wonder if browsers ever generate this?

I will add some discussion of this in the next version, including Oleg's useful set of issues below. 

- Alan -

> On Jun 5, 2014, at 2:55 PM, Oleg Moskalenko <[email-masked]> wrote:
> 
> If we do want to support multiple origins per request then we have to state, clearly, three things:
> 
>   1) Use cases.
>   3) How we format multiple origins in the request - as comma-separated single field or multiple origin attributes. As STUN/TURN is a binary protocol, I think that the second option is better.
> 
> The usefulness of multiple origins in TURN is not very obvious to me. I implemented ORIGIN in a pilot implementation https://code.google.com/p/coturn/ but I assumed a single ORIGIN field per request.
> 
> Oleg
> 
> 
>  
> 
> 
>> On Thu, Jun 5, 2014 at 7:48 AM, Hutton, Andrew <[email-masked]> wrote: