OPS-DIR review of draft-ietf-tram-turn-third-party-authz-08

[Tom Taylor <[e-mail]>]

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.