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

["Hutton, Andrew" <[e-mail]>]

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:[e-mail]]
> Sent: 05 June 2014 15:26
> To: Hutton, Andrew
> Cc: Alan Johnston; [e-mail]
> Subject: Re: [tram] Review of draft-johnston-tram-stun-origin-02
> 
> What would be the purpose of multiple origins ?
> 
> Oleg
> 
> On Jun 5, 2014, at 7:19 AM, "Hutton, Andrew" <[e-mail]>
> wrote:
> 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:[e-mail]] On Behalf Of Alan Johnston
> Sent: 07 May 2014 18:50
> To: Marc Petit-Huguenin
> Cc: [e-mail]
> 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
> <[e-mail]> 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  |  [e-mail]
> 
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram