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

[Oleg Moskalenko <[e-mail]>]

please see inline:


On Tue, May 6, 2014 at 3:55 AM, Marc Petit-Huguenin <[e-mail]>wrote:

>
>
> 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.
>
> So I would suggest to restrict the normative use of ORIGIN only to
> select realms.
>

[Oleg] Technically, you cannot use the ORIGIN for the certificate selection
because the (D)TLS negotiation is happening before any TURN ALLOCATE packet
is delivered to the server. Although, I am not sure that I see a use case
for multiple different TLS certificates on the same network service
endpoint, even if it serves multiple 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...)
>


[Oleg] After the initial negotiation, the ORIGIN is optional and can be
used only for logging purposes.


>
> A5. Section 2.2.  Mandatory support for server
>
> How a TURN server that requires the usage of ORIGIN can signal this?
>

[Oleg] I suppose that the server just uses a default realm if the ORIGIN is
absent. If server requires the ORIGIN, then the default realm can be a
bogus realm that has no real users. I do not see a reason to introduce a
new error code here. If the client supports ORIGIN then it just always
includes ORIGIN (as a comprehensive-optional attribute) into the ALLOCATE
request. If the client does not support ORIGIN, then it works with the
default realm. I see no valid reasons why a client that supports ORIGIN
would want to try ALLOCATE without the ORIGIN.


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

[Oleg] That's right, I think that the wording about the MESSAGE-INTEGRITY
must be clarified and/or removed. In the initial ALLOCATE request, the
ORIGIN is not protected. In other requests, the ORIGIN is optional and not
required - but if it is included, then it will be protected (as virtually
any other attribute) but the value of the ORIGIN attribute in those
protected messages really does not matter. I do not see any valid attack
that can be prevented by checking the ORIGIN attribute value and by
protection. It can help only in finding the errors in the software
implementation but that is definitely not a valid purpose of the network
protocol.

Thanks
Oleg