I reviewed draft-ietf-tram-turn-third-party-authz-08 as part of the
Operational directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written primarily for
the benefit of the operational area directors. Document editors and WG
chairs should treat these comments just like any other last call comments.
Summary: This document has inconsistencies that need to be fixed before
it can be published.
Operational issues:
To make this feature work, the following pre-configuration is required:
a. In each authorization server, the list of STUN and TURN servers for
which it will grant tokens, and the long-term secret shared with each
b. Similarly, in each STUN or TURN server, the list of authorization
servers from which the clients of that STUN or TURN server may request
tokens, and the associated long-term secret.
c. If manual configuration (Section 4.1.3) is used to establish
symmetric keys, the necessary information has to be configured on each
authorization server and STUN or TURN server. The client presumably
obtains the session key and algorithm from the authorization server in
company with the token.
It would be good to have an Operational Considerations section
summarizing this information and anything else I've missed.
In terms of deployment, incremental deployment is possible, since
default action is specified in the document if either the client or STUN
or TURN server fails to understand the attributes defined in this
document. However, the implication in "Other Issue" 3 below is that the
"should" should be a "MUST".
Other issues:
1. The procedures by which the client obtains the OAuth token are
declared out of scope (middle of first paragraph of Section 3), yet a
fair amount of text in the document deals with this topic. Either the
declaration of scope should be changed or the examples of interaction
between the client and the authorization server and related detailed
procedural statements should be moved to an informative appendix.
Fundamentally this document is not about WebRTC (even though that is the
primary application the authors have in mind) and so WebRTC has no place
in the body of the document. The rewriting would be a fair amount of
work, but I will volunteer to help rework the text if need be.
2. The paragraph below Figure 2 in Section 3 talks of a future
capability, algorithm agility. Part of the description mentions that the
client sends the intersection of the algorithms common to it and the
STUN server to the authorization server. The reason to do this depends
specifically on the statement that the authorization server generates
the session key between the client and resource server in
draft-ietf-oauth-pop-key-distribution (which BTW is expired). I can see
the point of this paragraph in providing a warning to implementors, but
it is probably too speculative unless the depended-upon I-Ds (stunbis
and oauth-pop-key) are very close to completion. At the least, the
sentence relating to the interaction between the client and
authorization server could be removed or made less detailed. (Relates to
the first point above.)
3. The first sentence of Section 4 has a lower-case "should". Should
this be "SHOULD" or perhaps "MUST"? It would also be good to add that
this knowledge of the STUN server's authentication capability may be
available prior to the initial request, or else it is acquired from the
401 Unauthorized response to the initial STUN request as described
below. Maybe the implementation note under Figure 1 belongs down here,
at the more detailed level, rather than in the overview section.
4. The detailed choice of how symmetric key establishment is done is
left open in Section 4.1. Should there be a mandatory-to-implement choice?
5. Perhaps in Section 7 there should be a note that if a STUN server
receives an ACCESS-TOKEN attribute unexpectedly (because it had not
previously sent out a THIRD-PARTY-AUTHORIZATION), it will respond with
an error code of 420 (Unknown Attribute) as specified in Section 7.3.1
of RFC 5389.
6. In Section 9, second bullet, a parameter Delta is shown but no
suggested value is given. Would this be 5 seconds as in Section 7?
Tom Taylor
Nits/editorial suggestions
==========================
General: missing "the"s and occasional "a"s or "an"s throughout the
document. I indicated a number of places but got tired of doing so
eventually. If absolutely necessary I could mark up a copy of the
document with the additions.
1) Abstract:
OLD
The usage of ephemeral tokens ensure
NEW
The use of ephemeral tokens ensures
2) Section 3, first paragraph:
It might be good to add a paragraph before the present one, saying that
the client knows that it can use OAuth with the target STUN server
either through configuration or when it receives the new STUN attribute
THIRD-PARTY-AUTHORIZATION in the 401 Unauthorized response to its
initial STUN request.
OLD
to avail STUN services
NEW
to avail itself of STUN services
OLD
The client is oblivious to the content of the token. The token is
embedded within a STUN request sent to the STUN server.
NEW
The content of the token is opaque to the client. The client embeds the
token within a STUN request sent to the STUN server.
Second-last line: s/it's/its/
3) Section 3, paragraph below Figure 2:
Missing "The" in front of "Authorization server" at the beginning of a
sentence, missing "the" in front of "client" (twice).
Fourth line from the bottom: s/client had provided/the client provided/
4) Last line of Section 3:
OLD
MUST be 'stun' string.
NEW
MUST be the string 'stun'.
5) Section 4, first paragraph:
OLD
using OAuth access token.
NEW
using an OAuth access token.
OLD
The STUN servers
NEW
The STUN server
OLD
additional STUN attribute
NEW
the additional STUN attribute
6) Section 4, paragraph between the two figures 4 and 5: s/i.e/i.e.,/
7) Section 4.1, first sentence: s/resource server/STUN server/
Middle of paragraph:
OLD
The AS-RS, AUTH keys
NEW
The AS-RS and AUTH keys
Missing "The" in front of "AS-RS key" in the next sentence. Missing
"the" in front of "message integrity" later in that sentence.
Second-last sentence:
OLD
The establishment of symmetric key is outside the scope
NEW
The procedure for establishment of the symmetric key is outside the scope
8) Sections 4.1.2 and 4.1.3 have missing instances of "the".
9) Section 4.1.3 first paragraph:
OLD
Mandatory to support authenticated encryption algorithm MUST be
AES_256_CBC_HMAC_SHA_512.
NEW
If manual provisioning is supported, support MUST also be provided for
AES_256_CBC_HMAC_SHA_512 as the authenticated encryption algorithm.
10) Section 5, second-last line: s/doesn't/do not/
11) Section 6.1 third line: s/tie-up/tie-ups/
12) Section 6.2, first paragraph:
OLD
of [RFC5389]), access token length
NEW
of [RFC5389]). The access token length
OLD
is opaque to the client and it
NEW
is opaque to the client and the client
13) Section 6.2, 'lifetime' bullet:
OLD
but the client assumes that
NEW
but the client would assume that
14) Section 6.2, 'encrypted_block' bullet:
s/resource server/STUN server/
15) Section 9, first bullet:
OLD
Since the access token is only valid for a specific period of time,
NEW
Since the access token is valid for a specific period of time,
16) Section 10, first paragraph:
OLD
detect that the transaction ID as used
NEW
detect that the transaction ID was used
17) Reference draft-ietf-tram-auth-problems has been published as RFC
7376 and should be updated. Informative references
I-D.ietf-oauth-pop-architecture and I-D.ietf-oauth-pop-key-distribution
have expired, but I guess there is nothing you can change for the moment.