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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]