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

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 06 May 2014 04:55:12 -0600

A1. Intended Status: Informational

Shouldn't this be Standard Track?

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.

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.

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

A5. Section 2.2.  Mandatory support for server

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

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.

Nits
----

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

Does not parse.

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 6 May 2014 09:59:48 -0700

please see inline:

> So I would suggest to restrict the normative use of ORIGIN only to

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

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

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

> 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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 7 May 2014 12:49:45 -0500

Marc,

Thanks for the review.  See my comments below.

- Alan -

> Shouldn't this be Standard Track?
Yes.

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

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

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

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

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

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

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

The middle "the" shouldn't be there.

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