Thanks Tom for the review. Please see inline > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@xxxxxxxxx] > Sent: Wednesday, February 04, 2015 3:39 AM > To: ops-dir@xxxxxxxx; Tirumaleswar Reddy (tireddy); Prashanth Patil > (praspati); Ram Mohan R (rmohanr); Justin Uberti; Gonzalo Camarillo; > Spencer Dawkins; The IETF; tram@xxxxxxxx > Cc: Christer Holmberg > Subject: OPS-DIR review of draft-ietf-tram-turn-third-party-authz-08 > > 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". I will add Operational Considerations section to the draft. > > 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. If we remove the below line, would that address your comment ? "The exact mechanism used by a client to obtain a token from the OAuth authorization server is outside the scope of this document." > 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. WebRTC is only used an example in this document to demonstrate its usage. STUN (rfc5389) also references SIP in various places. Please clarify why this is a concern ? > > 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.) It is agreed in the WG that stunbis will be support hash agility and use the technique mentioned in the draft. The paragraph below Figure 2 in Section 3 is outcome of the discussion. > > 3. The first sentence of Section 4 has a lower-case "should". Should this be > "SHOULD" or perhaps "MUST"? Changed to "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. Okay, moved the note to Section 4. > > 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 ? The consensus in the WG is to keep symmetric key establishment procedure outside scope and not to mandate any symmetric key establishment procedure. Please note that the draft will be updated in the next revision to use ECC to address the comment from Yaron Sheffer as part of SecDir review NEW: Elliptic curve cryptography (ECC) with Elliptic Curve Digital Signature Algorithm (ECDSA) or symmetric-key algorithm with Hash based Message Authentication Codes (HMACs) MUST be chosen to ensure that the size of encrypted token is not large because usage of RSA will result in large encrypted tokens which may not fit into a single STUN message. > > 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. Since ACCESS-TOKEN is an comprehension-optional attribute it can be ignored by the server and no need return error. > > 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? Yes, added the recommended delta value in Section 7. > > Tom Taylor > > > Nits/editorial suggestions > ========================== Fixed all the below editorial suggestions. Thanks and Regards, -Tiru > > 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.