Subject: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-13: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Fri, 10 Apr 2015 12:38:13 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tram-turn-third-party-authz-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Edited discuss ballot after chats around Dallas.

(1) Please fix the crypto as per Richard's discuss. (I think
the plan here is for Rich Salz to help with that, which 
I'm confident will work out ok.)

(2) Please consider whether a signature based 
scheme that does not require pre-shared keys between
the TURN and (in particular) WebRTC server could
be useful to support. (Either in this document or 
elsewhere.) There should be use cases where that
offers sufficient accountability for use of TURN and
it ought allow some deployments that are less easy
with this kind of pre-shared keys approach. The 
DISCUSS here is to check if the WG want to take
that approach, either now or later.

(3) I think the plan is to take out some of the options
that are not needed so as make interop more likely.
Please do so. (I think we discussed taking out the
DKSPP stuff at least, but the more options we can
get rid of, the better).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- COMMENTS below are unchanged since before Dallas.
We can look over then as we go.

- I really think this would benefit from some wider review
and I don't think it's ready as-is.

- I agree with Richard's discuss points.

- intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true. 

- Assuming the AS that can authorize the user shares a
secret with the STUN server chosen by the WebRTC server
seems very brittle. Why would that be true in general?

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

- 4.1.2 - now we're using TLS mutual auth? And how does
the TLS client know which CA to use that'll work with the
TLS server here? I don't think that'll scale will it?

- 4.1.3 - this looks like what the WG/authors really want,
would that be a fair statement?

- 9: Figure 2 should be way up at the top of the document
and not here

- 9: Why 5 seconds?

---

From: Brandon Williams <[email-masked]>
Date: Fri, 10 Apr 2015 15:58:06 -0400

Hi all,

I will try to touch base with Rich Salz re: Richard's crypto comments 
next week in order to help drive getting his feedback.

--Brandon

On 04/10/2015 03:38 PM, Stephen Farrell wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 11 Apr 2015 01:58:08 +0000

Hi Brandon,

Richard and we have already have discussed the comments further and resolved them, attached updated draft with diff.
Main changes

[1] Removed DKSPP
[2] Removed non-AEAD algorithms; using AEAD modes AES-GCM and aead-aes-cbc
[3] Updated the token format

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Saturday, April 11, 2015 1:28 AM
> Cc: Salz, Rich; [email-masked]; [email-masked]
> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-13: (with DISCUSS and COMMENT)
> 
> Hi all,
> 
> I will try to touch base with Rich Salz re: Richard's crypto comments next
> week in order to help drive getting his feedback.
> 
> --Brandon
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > (1) Please fix the crypto as per Richard's discuss. (I think the plan
> > here is for Rich Salz to help with that, which I'm confident will work
> > out ok.)
> >
> > (2) Please consider whether a signature based scheme that does not
> > require pre-shared keys between the TURN and (in particular) WebRTC
> > server could be useful to support. (Either in this document or
> > elsewhere.) There should be use cases where that offers sufficient
> > accountability for use of TURN and it ought allow some deployments
> > that are less easy with this kind of pre-shared keys approach. The
> > DISCUSS here is to check if the WG want to take that approach, either
> > now or later.
> >
> > (3) I think the plan is to take out some of the options that are not
> > needed so as make interop more likely.
> > Please do so. (I think we discussed taking out the DKSPP stuff at
> > least, but the more options we can get rid of, the better).
> >
> >
> > - I really think this would benefit from some wider review and I don't
> > think it's ready as-is.
> >
> > - intro: "impossible in web applications" isn't really true in
> > principle, but impossible in WebRTC as it uses JS is true.
> >
> > - Assuming the AS that can authorize the user shares a secret with the
> > STUN server chosen by the WebRTC server seems very brittle. Why would
> > that be true in general?
> >
> > - 4.1.2 - which "two servers"? WebRTC can have more servers than that.
> >
> > - 4.1.2 - now we're using TLS mutual auth? And how does the TLS client
> > know which CA to use that'll work with the TLS server here? I don't
> > think that'll scale will it?
> >
> > - 4.1.3 - this looks like what the WG/authors really want, would that
> > be a fair statement?
> >
> > - 9: Figure 2 should be way up at the top of the document and not here
> >
> > - 9: Why 5 seconds?
> >
> >
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 11 Apr 2015 03:07:03 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Saturday, April 11, 2015 1:08 AM
> To: The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]; [email-masked]; draft-ietf-tram-turn-third-
> [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-
> 13: (with DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> (1) Please fix the crypto as per Richard's discuss. (I think the plan here is for
> Rich Salz to help with that, which I'm confident will work out ok.)

Yes, comments from Richard are addressed.

> 
> (2) Please consider whether a signature based scheme that does not require
> pre-shared keys between the TURN and (in particular) WebRTC server could
> accountability for use of TURN and it ought allow some deployments that
> are less easy with this kind of pre-shared keys approach. The DISCUSS here is
> to check if the WG want to take that approach, either now or later.

Passive attacks could occur in TURN due to lack of integrity protection. For example, a passive attacker could monitor Allocate request/response between the client and TURN server and make a Refresh request with a requested lifetime of 0 to delete the allocation. Message integrity of TURN messages ensures that passive attacker cannot spoof subsequent TURN messages.

> 
> (3) I think the plan is to take out some of the options that are not needed so
> as make interop more likely.
> Please do so. (I think we discussed taking out the DKSPP stuff at least, but
> the more options we can get rid of, the better).

Yes, DKSPP is removed from the draft.

> - I really think this would benefit from some wider review and I don't think
> it's ready as-is.

This draft is also reviewed in OAuth WG.

> - intro: "impossible in web applications" isn't really true in principle, but
> impossible in WebRTC as it uses JS is true.

NEW:
   However, in web applications
   like WebRTC [I-D.ietf-rtcweb-overview] where JavaScript uses the
   browser functionality to make real-time audio and/or video calls, Web
   conferencing, and direct data transfer, ensuring this secrecy is
   typically not possible.

> 
> - Assuming the AS that can authorize the user shares a secret with the STUN
> server chosen by the WebRTC server seems very brittle. Why would that be
> true in general?

The AS and WebRTC server are in the same administrative domain of the application provider. The user never sends the session key learned  from the AS to the STUN server it only uses the session key to compute  message integrity of STUN request and to validate the  message integrity of  the STUN response. The STUN server will only know the session key if it can decrypt the token.

> - 4.1.1: Hmmm. How many people use KeyProv I wonder?

Already removed DKSPP.
 
> - 4.1.2 - which "two servers"? WebRTC can have more servers than that.

The STUN server and the AS. As far as the STUN server is concerned, it only deals with the AS of interest for key establishment. The AS could be the application server itself or could be a Key management  function syncing the keying material to the WebRTC servers.

NEW:
   The STUN and AS servers could choose to use REST API over HTTPS to
   establish a symmetric key.

> 
> - 4.1.2 - now we're using TLS mutual auth? And how does the TLS client know
> which CA to use that'll work with the TLS server here? I don't think that'll
> scale will it?

We presume the two parties involved know what CA to consider when using the REST APIs  they would have to do this to trust each other. Please note that the AS is allocating symmetric keys meant exclusively for  that STUN Server, so some level of co-ordination is already involved.

> 
> - 4.1.3 - this looks like what the WG/authors really want, would that be a fair
> statement?

As per our discussion we have changed the specification to recommend REST 

NEW:

   Note : The mechanism specified in Section 4.1.2 compared to REST
   lacks encryption and HMAC algorithm agility.  Hence a STUN server and
   authorization server implementation SHOULD support REST explained in
   Section 4.1.1.

> - 9: Figure 2 should be way up at the top of the document and not here

In the previous versions it was in the top of the document but moved down after comments received from the WG that WebRTC is only an  example usage of third party authorization.

> - 9: Why 5 seconds ?

STUN messages can be sent over UDP, 5 seconds is to accommodate packet loss and RTO interval.

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 13 Apr 2015 00:04:34 -0700

I noticed that the encrypted token has odd number of bytes, because
the nonce_length is just one byte. I'd suggest to make it two bytes.
Saving a byte by making the data size odd usually does not work well.
It is really not saving any space or CPU cycles.

Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 13 Apr 2015 00:47:04 -0700

I noticed another problem in the draft:

In the version 13, there was a formal explanation how the keys can be
derived from the original K parameter (the keying material); due to
that formal algorithm, both AS and STUN servers can perform the same
actions over the K and obtain the same keys. That algorithm was based
upon HKDF. In the version 14, that algorithm is omitted, and instead a
reference to section 5.2.2.1 of [I-D.ietf-jose-json-web-algorithms] is
added. But that section explains only how to derive AUTH and RS keys
for the AES_CBC_HMAC_SHA algorithm. In the case if other algorithms
are used, the derivation of keys from the K is not defined, and that
makes AS and STUN server inter-operation problematic. The required
STUN server authenticated encryption algorithm is A256GCMKW and it has
no defined key derivation procedure in the version 14 of the draft.

I propose to restore the HKDF-based universal key derivation procedure
for GCM and other algorithms.

Overall, I see that sections 4.1 and 4.1.1 have lots of legacy from
the previous draft version 13, and it creates a somewhat messy
wording. I'd suggest to re-write those two sections from scratch,
because just changing/replacing some words in the historical text
eventually creates a cryptic text that different people may understand
differently. For example, the new 4.1.1 text can be understood so that
AUTH and RS keys must always be 256 bites both (and we know that this
is not really the case). I think that closing the old text and writing
the new one (with clear understanding in mind what we want) would do
the trick.

Thanks
Oleg

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 11 Apr 2015 11:25:28 +0000

Great.  Brandon, I'm not sure if you still need me, but let's sync up next week :)

I will read the new draft pretty soon.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Friday, April 10, 2015 9:58 PM
> To: Williams, Brandon
> Cc: Salz, Rich; [email-masked]; [email-masked]; [email-masked]; Stephen
> Farrell ([email-masked])
> Subject: RE: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> Richard and we have already have discussed the comments further and
> resolved them, attached updated draft with diff.
> Main changes
> 
> [1] Removed DKSPP
> [2] Removed non-AEAD algorithms; using AEAD modes AES-GCM and aead-
> aes-cbc [3] Updated the token format
> 
> -Tiru
> 
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-aut
> > > hz
> > > /
> > >
> > >
> > >
> > > (1) Please fix the crypto as per Richard's discuss. (I think the
> > > plan here is for Rich Salz to help with that, which I'm confident
> > > will work out ok.)
> > >
> > > DISCUSS here is to check if the WG want to take that approach,
> > > either now or later.
> > >
> > > - I really think this would benefit from some wider review and I
> > > don't think it's ready as-is.
> > >
> > > - Assuming the AS that can authorize the user shares a secret with
> > > the STUN server chosen by the WebRTC server seems very brittle. Why
> > > would that be true in general?
> > >
> > > - 4.1.2 - now we're using TLS mutual auth? And how does the TLS
> > > client know which CA to use that'll work with the TLS server here? I
> > > don't think that'll scale will it?
> > >
> > > - 4.1.3 - this looks like what the WG/authors really want, would
> > > that be a fair statement?
> > >

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Apr 2015 11:17:09 -0700

> [3] Updated the token format

I read this just now for the first time in a while.  Either I'm a lot
stupider this morning than I normally am, or this draft is very
confused.  There are some serious problems in here.

If you intend to use RFC 5116, please clearly specify the inputs, as
described in Section 2.1:
https://tools.ietf.org/html/rfc5116#section-2.1 Currently, the draft
uses N for the name of the server.  That conflicts with the label that
RFC 5116 uses for the nonce.  Also, the draft is very vague about the
construction of the nonce.  The draft certainly doesn't need to refer
to the CBC AEAD draft.

It does need to deal with algorithm agility and it currently does not.

I apologize for not reviewing this earlier.  Here are more comments.

Section 1 doesn't really explain what the draft provides.

Section 3 claims to be an overview, but it doesn't actually describe
what happens.  It leaves the token acquisition part out of scope.
That's fine, but it doesn't describe how the THIRD-PARTY-AUTHORIZATION
attribute might be used, even in the broadest sense.  It doesn't
explain why it's a server name, or how that name relates to the domain
name of the server (i.e., the one that might have been passed to a DNS
resolver).

Section 4 doesn't permit any additional information to be carried in
the token.  Therefore, the STUN/TURN server is unable to apply any
additional policies that the authorization server might impose, such
as limits on the length of the session, the number of ports allocated,
or the bandwidth that is allocated.  (Or whatever we might later
conceive of.)

It's not clear what Section 4.1.1 is for.  If this is private
communications, then it is far too specific.  If this is intended to
be normative, then it isn't sufficient.  What is the base URI?  What
prevents a random internet denizen from acquiring this symmetric key?
Why these two specific parameters?  Why does the expiration
information in the JWK replicate what HTTP provides?  I'd be far
happier with hand-waving than with this section in place.

Section 5 fails to explicitly state whether the MAC key is used as
input to short term or long term credentials.  It needs to say short
term, I think.

Why does this document use 'kid' rather than USERNAME?  Isn't the
point to get a short term  username+password pair from the
authorization server?

Section 7 seems to imply two layers of authentication: the AEAD and
some HMAC.  I can't work out what is being authenticated.  I'm not
sure that anyone else could either.

The replay protection in Section 7 is not sufficient.  If the intent
is to prevent replay, then the server needs to maintain a
globally-consistent register of the requests that it has seen so that
it can correctly reject replays.  However, I think that the intent is
to permit replay, so perhaps it is the case that casting this as
anti-replay is counter-intuitive.  That said, I believe that this is a
serious DoS vector and we should be recommending that servers at least
account for what has been replayed and limit the number of times a
particular token can be used.

If the intent of the lifetime in the token is to prevent replay, then
this is bad:

  o  The lifetime provided by the TURN server in the Allocate and
      Refresh responses MUST be less than or equal to the lifetime of
      the token.

Tying the two lifetimes together means that you need to have a long
token lifetime in order to support long sessions.  But long token
lifetimes means long periods of exposure to replay and lots of
maintained state.  See earlier point about policies being carried in
the token.

Section 8 seems completely unnecessary.  What resource is being
conserved here?  It's more work to maintain all this state and
validate all those tokens than it is to respond in the affirmative to
STUN request.  (Also, why doesn't STUN usage get a fancy OAuth mapping
table like Section 9?  Is it somehow different?)

In summary, I'm surprised that a document in this state was put before the IESG.

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 13 Apr 2015 22:26:30 -0700

> Section 1 doesn't really explain what the draft provides.

I disagree. It is pretty clear on general description what this draft
is about. At least, it was obvious to me from the very first reading.

> attribute might be used, even in the broadest sense.

It describes it in section 6.1.

> It doesn't

"Server name" is just a logical whatever name. It is not related to
anything that you mentioned; that is just a well-known name, set by
the STUN server administrator. I believe that this is pretty clear
from the text.

> or the bandwidth that is allocated.  (Or whatever we might later

I believe that extra token information is a very very bad idea - it
kills the whole interoperability thing in the draft. If we are adding
"extra" information to the token, we can as well just kill the draft
and tell the STUN server developers "do whatever you want, secure the
stuff somehow, we do not care".

> be normative, then it isn't sufficient.

That is something that I agree with.

>  What is the base URI?  What

I suppose that's pretty clear that the AS and STUN server mutual
communications are protected by TLS certificates that they trust.

> input to short term or long term credentials.  It needs to say short

No. The whole document is about the LONG-TERM credentials. That's
pretty clear for everybody who followed the STUN security, and it is
getting mentioned in the text many times (just search for "long-term"
on the page).

> sure that anyone else could either.

I am afraid that you simply need more time to read that document.

Thanks
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 14 Apr 2015 06:02:34 +0000

> From: Oleg Moskalenko [mailto:[email-masked]]
> Sent: Tuesday, April 14, 2015 10:57 AM
> To: Martin Thomson
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]; [email-masked];
> Brandon Williams; [email-masked]; Salz, Rich; Stephen Farrell
> ([email-masked])
> I believe that extra token information is a very very bad idea - it kills the
> whole interoperability thing in the draft. If we are adding "extra"
> information to the token, we can as well just kill the draft and tell the STUN
> server developers "do whatever you want, secure the stuff somehow, we do
> not care".

It was discussed in the WG and decision was not to carry any extra token information so as to keep the token size small. In future an out-of-band communication mechanism b/w STUN and authorization server to exchange the token related metadata can be defined similar to the OAuth 2.0 Token Introspection method defined in https://tools.ietf.org/html/draft-ietf-oauth-introspection-07. 

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 13 Apr 2015 23:11:52 -0700

> It was discussed in the WG and decision was not to carry any extra token information so as to keep the token size small. In future an out-of-band communication mechanism b/w STUN and authorization…

if that extra information is formal and well-defined, then that's
fine. I was against free-formated extra fields.

Thanks
Oleg

---

From: Brandon Williams <[email-masked]>
Date: Tue, 14 Apr 2015 08:37:13 -0400

I don't think OOB communication b/w the STUN and auth servers is a 
solution to the problem of wanting to provide additional details in the 
token. It defeats a large part of the purpose of moving to a token model 
in the first place, which was to avoid the need for these two servers to 
have to communicate directly with each other.

I agree with Martin that it would be useful to have the capability to 
communicate additional information in the token, and I don't recall that 
it was decided that the token wouldn't have this capability (unless by 
decided you mean there wasn't enough interest in the discussion). I 
don't agree that this would necessarily be bad for interoperability, 
provided that individual bits of additional information are never 
required to be present or required to be understood if they are present. 
A list of TLVs at the end of the data space would not be particularly 
difficult to support.

I don't feel strongly enough about providing such a mechanism to push 
for it, but I would be supportive if someone else does.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 14 Apr 2015 09:06:16 -0400

> Passive attacks could occur in TURN due to lack of integrity protection. For example, a passive attacker could monitor Allocate request/response between the client and TURN server and make a Refres…

I think Stephen was thinking primarily about cases with (D)TLS involved 
between the UA and the STUN server. If there's already a security layer 
then perhaps it's enough to prove that the auth server approved the 
communication and it's OK to skip STUN integrity protection altogether. 
My experience suggests that even in a case where (D)TLS isn't involved 
some application providers will not consider the risk of skipping STUN 
HMACs big enough to justify doing it.

> In the previous versions it was in the top of the document but moved down after comments received from the WG that WebRTC is only an  example usage of third party authorization.

A few people from outside the WG have commented on having trouble 
following the flow of the document on their first read, primarily due to 
the lack of a high-level picture early in the document. Moving section 9 
back up toward the top of the document would help by giving readers such 
a high-level overview early on. The discussion might need to be 
generalized a bit in order to serve this purpose, but comments we've 
received on the document's usability indicate that this change would be 
helpful.

--Brandon

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2015 09:45:48 -0700

> is about. At least, it was obvious to me from the very first reading.

I've read it again.  It's clearer on second reading, but still confused.

The abstract says:

   This document proposes the use of OAuth 2.0 to obtain and validate
   ephemeral tokens that can be used for Session Traversal Utilities for
   NAT (STUN) authentication.

But the document doesn't do that at all.  It describes the
communications between the authorization server and the STUN server.
Sort of.

Here's what I'd say:

1. Long-term secrets can't be sent to untrusted TURN clients, such as
a browser using WebRTC. These clients need to be given short-lived
credentials.

2. This document describes how the OAuth framework can be applied to
this problem.
   - A client is directed to an authorization server to retrieve an
access token.  Clients are configured with the authorization server
and the method of retrieval.
   - Clients retrieve a token from the authorization server (using
whatever proprietary method they choose).
   - Clients sends the token in a TURN server in Allocate or Refresh requests.
   - TURN servers use information in the token in authorizing these requests.

3. This document defines the ACCESS-TOKEN STUN attribute that is used
to carry the authorization token provided by an authorization server.

I see no value in standardizing protocol interactions (4.1.1) or the
access token format.  I can't work out how to make the
THIRD-PARTY-AUTHORIZATION work at all.

> It describes it in section 6.1.

Not really.

6.1 says that the presence of the attribute indicates that third party
authorization is needed.  It doesn't describe what the value is *for*.
Given that it's not actually possible to act on the information that
it does provide without some external information, I fail to see the
value of the attribute.

> the STUN server administrator. I believe that this is pretty clear

Are you saying that the value has no protocol value?

> stuff somehow, we do not care".

Well, we can disagree about this.

I also disagree with the idea that this interface between STUN server
and authorization server can be standardized in such a half-hearted
fashion.  If the HTTP interaction is out of scope, then why isn't the
token construction also out of scope?

> communications are protected by TLS certificates that they trust.

I suppose that you mean this: "HTTPS MUST be used for mutual
authentication and confidentiality."  HTTPS doesn't provide client
authentication natively, so I attributed this to a misunderstanding
about what HTTPS could provide.  If you say that this is important,
authorizing access to the long-term key is not given proper treatment.

There's nothing in the security considerations; there should be.

> getting mentioned in the text many times (just search for "long-term"

"long-term" is used in the introduction as part of an explanation that
essentially says that long-term credentials are broken for the WebRTC
use case.  That much is true.

Elsewhere it is used exclusively to describe the long-term credentials
shared between the authorization server and the STUN server.

Nothing is said at all regarding what method to use for STUN MESSAGE-INTEGRITY.

> I am afraid that you simply need more time to read that document.

I did spend more time.  I now understand why I was so confused by the
text.  Why would this document repeat text from a document that it
doesn't even need to cite?

Also, I just noticed that this uses base64.  That's arbitrary.  Does
the client remove that encoding before including the token in the STUN
message?  There's no MUST there, but it seems like it's part of the
process somehow.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 14 Apr 2015 12:53:29 -0700

> I've read it again.  It's clearer on second reading, but still confused.

It requires some time to sink in, I admit. But after some time, you
will see that it correctly describes the procedures needed to get a
third-party authorization for the STUN operations. I agree that this
is not an easiest of the readings.

> communications between the authorization server and the STUN server.

Not true. It also describes how to organize new secure communications
between STUN client and STUN server.

> a browser using WebRTC. These clients need to be given short-lived

In the STUN terminology, there is a very big difference between
"short-lived" and "short-term" credentials. You were formerly used the
second term, now you are using the first one. So it is not clear what
exactly you are talking about.

> THIRD-PARTY-AUTHORIZATION work at all.

I was working on implementation of this thing, and somehow I had no
difficulty understanding that (and I am not an author of the
document).

> Are you saying that the value has no protocol value?

It has a value in security procedures. But the STUN server
administrator is free to set whatever value to the server name, and it
may be not related to DNS or anything. You can set the server name to
"Martin Thomson" and it will be perfectly OK.

> Well, we can disagree about this.

I disagree with the "free-style" extra information in the token. If
that extra information is strictly formalized (a formal meta-data with
definite structure) then I am OK with that.

>From the system and software architecture and design point of view,
the communications between a standard AS and a standard STUN server
are not very relevant - a simple utility can transfer information
between them, and that utility must not be an integral  part of AS or
STUN server. We can take various STUN and AS servers off-the-shelf and
make the communications work between them. The token structure, on the
other hand, affects the core internal functionality of the STUN
server, and this is why it must be strictly specified.

> authorizing access to the long-term key is not given proper treatment.

I am not talking about the client authentication.
HTTPS servers can authorize the clients with the client's certificate
- the same way as the clients can authorize the servers. A dedicated
AS HTTPS server will allow only TLS (HTTPS) connections from a few
authorized STUN servers with known certificates. This is an optional
feature of the TLS protocol (that is used by HTTPS) that can be used
here to secure AS-STUN communications.

> doesn't even need to cite?

give it more time...

> message?  There's no MUST there, but it seems like it's part of the

more clarifications in the text are always welcome.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2015 13:18:28 -0700

> is not an easiest of the readings.

A document that requires multiple readings and repeated admonishments
of "give it more time" is not fit for publication.

> You can set the server name to

OK, you still haven't explained why such a field needs to be defined
in an RFC.  Ideally, the draft should contain that explanation.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 14 Apr 2015 14:20:21 -0700

> of "give it more time" is not fit for publication.

Tell us please how many times did you read RFC 5766 until it fully
sunk. If you tell "once" then I'll not believe you. It may be "zero"
or "many times", but not "once".

> in an RFC.  Ideally, the draft should contain that explanation.

The draft fully explains why we need that field for the sake of
encryption/authorization. I do not believe that it can be explained
clearer.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2015 15:08:21 -0700

> or "many times", but not "once".

I still don't understand RFC 5245.  But that's an *excuse*.  This
doesn't even pass a sanity check.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 14 Apr 2015 15:39:06 -0700

> doesn't even pass a sanity check.

"sanity" may have a very different meaning for different folks :)