An Origin Attribute for the STUN Protocol

Summary: Needs a YES. Has 2 DISCUSSes. Needs 8 more YES or NO OBJECTION positions to pass.

Alissa Cooper Discuss

Discuss (2015-05-11 for -05)
This is a bit of a weird DISCUSS since I didn't manage to ballot when the document was first on the IESG's agenda, so I'm coming in mid-stream.

I support Stephen's DISCUSS. If Alan's proposed changes make it into the document, they would resolve most of my concerns. However, I still see a problem with this proposed new text:

"For STUN requests sent without authentication to a STUN server (i.e.

   STUN binding requests sent to a STUN server), the STUN client SHOULD 

   include the ORIGIN attribute.  The ORIGIN attribute MUST NOT be included 

   if it is a "privacy-sensitive" context, as discussed in the Security Considerations


For requests sent with authentication, I understand that the origin attribute needs to be accurate in order for the client to authenticate. In those cases, the STUN server can rely on the attribute it receives. But for requests without authentication, what prevents the client from lying? And if those requests are not (D)TLS-protected, what prevents them from being modified in transit? I understand Alan to be saying that the justification for the origin in this case is operational troubleshooting, but if the server can't rely on the origin it receives, doesn't that make it risky for the server to act on that information?

My additional concern is about the use of "logging" as a justification for including and origin attribute. Logging in and of itself is not a reasonable justification. Alan's mail discussed the use of the origin for operational troubleshooting, which seems like what might actually be intended instead of "logging." In any event the purpose for the logging either needs to be explained or "logging" should not be listed as a justification.

(Stephen Farrell) Discuss

Discuss (2015-04-21 for -05)
"Analytics" here together with the MUST include
statements could amount to a fancy way to
describe monetizing people's WebRTC calls in ways
that the end user will just not expect. I'd like
to check that we're not doing that, as it'd
arguably run counter to e.g. RFC7258 or to the
general trend towards data minimisation. And
making privacy worse, even by a little, seems
worse than making it better. (Note: I am here
asking about the STUN/TURN server being perhaps
unnecessarily told the origin, not the risk that
someone sees that in-transit, which is handled in
the draft already.)

I do agree that the TURN 401-like challenge
use-case is perhaps needed, but I do not see that
other use cases need to see the origin for them
to work at all.  And I'm not sure that such a
spoofable origin is so useful for that TURN case,
esp. when there's parallel work on an
authenticated equivalent. (I mean the tram 3rd
party thing.) I also don't see that that is
needed for network management reasons - surely
everything needed for network managment is no
more nor less visible to the STUN or TURN servers
when this is used vs. when this is not used. 

So why are we pushing for this?  If it is really
only for so-called "analytics" then is that ok?
(And where can I find a definition of what that

Apologies if this discuss seems somewhat high
level, but as well as the general concern, the
last paragraph of the current tram charter seems
to me to me to say that tram ought not make
privacy worse. But maybe I'm missing the
networking function that needs this - if so, I'm
sure someone will point that out.
Comment (2015-04-21 for -05)
No email
send info

- intro, para 2: STUN only defines two auth modes
that I can see, and you only mention two here -
what's the 3rd one you mean? (Is it DTLS?)

- What if >1 TURN session with different origins
is being setup from same client/browser? Does
that work? (Say two parallel calls, not the case
where the same resource is being accessed at the
same time loaded from different referring web

- I'd suggest to not allow >1 ORIGIN in a STUN
request? But that discussion seems to be in-hand.

- section 2: suggest providng similar examples
for all schemes, http(s),sip & xmpp. 

- 2.1 & 2.2: MUST include web origin - couldn't
there be "private browsing" scenarios where that
MUST would be a problem? I'm not suggesting that
the origin exposes very much but I think a SHOULD
would be more appropriate. 

- 2.1 last para: source here means the webrtc
server right? That's a bit ambiguous and would be
better clarified.

- What is the benefit of sending an empty origin
as opposed to no origin attribute? I don't see
any and the former just advertises that the
client is "privacy sensitive" which seems

Barry Leiba Discuss

Discuss (2015-04-20 for -05)
I have three questions I'd like to discuss.  The discussion might or might not lead to any document changes, so let's please have the discussion first, and see where it leads.

1. In Sections 2.1 and 2.2, I find this combination odd:

a. For non-web origins, you SHOULD (not MUST) send ORIGIN.
b. But for web origins, you MUST send ORIGIN.
c. But that ORIGIN can be empty.

If you're allowed to send an empty origin, and you can sometimes not send ORIGIN at all, why is ORIGIN REQUIRED (but can be empty) in some cases?  How does that help interoperability or security or whatnot?

2. In Sections 2.2 and 2.6, about the SHOULD NOT ("NOT RECOMMENDED"): Why?  What happens if you use it?  Under what conditions might you do so, even though this says you SHOULD NOT?  (Why is it not "MUST NOT"?)

3. In Section 2.7:

   Therefore, if
   a STUN request contains multiple origins, the first origin MUST be
   used and the remaining origins ignored.

For all cases (that's what it says)?  Or was this just meant to apply to SIP and XMPP?  Or SIP, XMPP, and WebRTC?  But not to other HTTP uses?  Or yes to HTTP?  If this really does apply to all cases, why are multiple origins allowed in the first place?
Comment (2015-04-20 for -05)
No email
send info
-- Section 1 --
A minor thing: the citation for STUN in the first two sentences seems odd.  Instead of citing 5389 with the first use of "STUN" in the first sentence, you cite it in the second sentence where it appears to be a reference for "a STUN extension".  I suggest moving the citation to the first sentence, so: "STUN, or Session Traversal Utilities for NAT [RFC5389], is a protocol used...."

It wouldn't be a bad thing to add an informative reference to CORS and to cite it when you mention it.  <>

There is no Section 4.5 in RFC 7376.  Perhaps you mean Section 4, bullet 5?

-- Section 2.1 --

   For STUN requests sent without authentication to a STUN server (i.e.
   STUN binding requests sent to a STUN server), the STUN client MUST
   include the ORIGIN attribute when the origin is a web origin.  For
   other origins, such as SIP or XMPP, the STUN client SHOULD include
   the ORIGIN attribute.

      Note that for privacy reasons, an empty ORIGIN attribute can be
      sent, as described in the Security Considerations.

The "i.e." tells me that the two things are synonymous: that "STUN requests sent without authentication" is the same as "STUN binding requests".  Is that really true?  Is it true that all binding requests are sent without authentication?  Or am I quite misunderstanding what you're trying to say here?

What, exactly, do you mean by "when the origin is a web origin"?  From the previous section, that seems to refer to something sent by a web browser.  But a web browser is just a piece of software, and a web browser could happen to be a SIP or XMPP client, as well.  Do you really mean to refer to origins that use the "http" scheme?  You might clarify this, particularly because it's involved in a "MUST".

   A STUN server can derive additional information for logging and
   analytics about the request through the ORIGIN attribute, such as the
   source of the request.  For example, an enterprise STUN server might
   only reply to STUN binding requests from certain domains.

In the example case, does that mean that such a server would not reply to binding requests that lacked ORIGIN (or had an empty one)?  If so, that would be a good bit of explanation to add.  I don't think that what's in the Security Considerations is enough to answer that question up here.

-- Section 2.2 --

   When the origin is a web origin, TURN [RFC5766] Allocate requests
   MUST include the ORIGIN attribute.  For all other TURN requests,
   including the Send method, the use of the ORIGIN attribute is NOT
   RECOMMENDED.  For other origins, such as SIP or XMPP, TURN Allocate
   requests SHOULD include the ORIGIN attribute.

The order here is odd, and made me read it a few times to be sure that I (thought I) understood it.  I would switch the order of the second and third sentences.  Apart from that, I have the same comments here that I had about Section 2.1.

-- Section 4 --

   DTLS or TLS transport SHOULD be
   used when integrity protection for the ORIGIN attribute is important.

Just curious here: When is integrity protection for it *not* important (and how will the client know that), given that the server might use it to determine whether it should respond, or to affect the authentication challenge?  (And, actually, the first sentence of the next paragraph repeats the SHOULD without the qualifier.  I suggest just removing the qualifier and merging the "TLS/DTLS SHOULD be used" advice from the two paragraphs.

Also, given that Section 2.1 says that the server might use it for logging and analytics, it might be good to add that the server SHOULD NOT rely on information from the ORIGIN attribute in the absence of secure transport.

I suggest factoring out the ends of the last two paragraphs (the parts that start with "In cases where") into a new last paragraph, rather than saying the same thing twice saying the same thing twice.

(Spencer Dawkins) Yes

Comment (2015-04-20 for -05)
No email
send info
Just to keep the IESG in the loop, without revising the document during balloting ...

In discussion in Dallas, the editor agreed to remove this sentence from Section 2. of draft-ietf-stun-origin:

"The size of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation."

This mention of fragmentation had raised the possibility of requiring support for SCTP in STUN and other things that there was no interest in doing, so the decision was to just remove this non-normative statement.  Also, this statement is highly speculative as there are no known use cases where multiple ORIGINs will be included for WebRTC, SIP, or XMPP.

(Jari Arkko) No Objection

Comment (2015-05-13 for -05)
No email
send info
I assume that the changes agreed on a thread about David Black's Gen-ART review will be done in a subsequent revision of the draft. Thanks.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2015-05-14 for -05)
No email
send info
Edit: My comments have been addressed in discussion, with the expectation of some very minor edits.

I agree with all 3 points of Barry's discuss.

I think the normative language in section 2.1 is ambiguous about whether it applies to all stun implementations used by a browser, SIP, or XMPP, or just those that "implement this draft". A thoughtful reader can infer the answer from the fact that the draft does not update STUN, but it might be helpful to clarify.

[Removed some comments that have been explained to my satisfaction]


-- Section 1: 

I agree with Barry that the first reference to STUN should probably go in the previous sentence.

Should reference to " Section 4.5 of [RFC7376]" really be 4.6"? 4.5 talks about a MiTM learning USERNAME.  4.6 talks about hosting multiple realms from the same IP address. (And as Barry mentioned, these are really "List entries 5 or 6 in Section 4")

(Benoît Claise) No Objection

Comment (2015-05-12 for -05)
No email
send info
Here is Tim Chown's OPS DIR review, along the same lines as Stephen and Alissa's DISCUSSES.
The feedback was sent to the authors on April 22nd, and I have not seen any reply so far.


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

I would summarise this document as being Not Ready.

My concern with the draft lies with privacy aspects. While the area is not one that I am particularly familiar with, but there would seem to be additional potential exposure through this method, and the language of the draft seems at odds with the language in RFC6454 (Section 7.3). I would therefore urge the AD to review this aspect, and to determine whether the utility of the draft outweighs the privacy concerns, and if it does, that appropriate privacy ‘knobs’ are included for those who are ‘privacy-sensitive’ (in the language of RFC6454).

I think the rationale and tradeoffs could be more clearly stated in the document. With recent passive pervasive monitoring threats, the IETF is now supposed to be considering whether  given information *needs* to be transmitted in any given protocol.

Would I as a user, for example, be able to toggle a setting that would mean my ORIGIN would always be “null”, as per RFC6454 section 7.3? Is the use of ORIGIN *required*, or is it just ‘desirable’? Would my application fail, or not? It appears from Section 1 that its inclusion is ‘useful’, but not required.

Section 4 talks of TLS for avoiding eavesdropping of ORIGIN in STUN messages, but the privacy concern is not necessarily only with transmission of the information. I think here paragraph 3 of Section 4 is at odds with RFC6454 Section 7.3 - with this draft saying MAY wrt use of a “null” Origin, and RFC6454 saying MUST for use of “null”. The same applies to the end of the last paragraph in Section 4 as well.

The draft should probably use the ‘privacy-senstive’ context terminology of RFC6454, as per Section 7.3, and describe how the user can influence the privacy settings where they which to maximise their privacy.


A point of detail, really, if you update the draft.

   For a web application provider STUN or TURN server, the
   server will have no idea which web pages or sites are sending binding
   requests to the service.  In conventional applications, the SOFTWARE
   attribute would provide some identifying information to the service,
   but that no longer works when the browser is the application.

SOFTWARE attribute: a reference to would be beneficial

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-04-21 for -05)
No email
send info
I support Stephen's Discuss.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection

Roman Danyliw No Record

Martin Duke No Record

Benjamin Kaduk No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record