Hi Tom, Please see inline > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@xxxxxxxxx] > Sent: Thursday, February 05, 2015 12:32 AM > To: Tirumaleswar Reddy (tireddy); ops-dir@xxxxxxxx; Prashanth Patil > (praspati); Ram Mohan R (rmohanr); Justin Uberti; Gonzalo Camarillo; > Spencer Dawkins; The IETF > Subject: Re: OPS-DIR review of draft-ietf-tram-turn-third-party-authz-08 > > Removed the WG from the distribution list, since the original E-mail made the > points I figured they needed to see. > > Responses with [PTT] below. > > Tom Taylor > > On 04/02/2015 12:22 PM, Tirumaleswar Reddy (tireddy) wrote: > > 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 will add Operational Considerations section to the draft. > > > [PTT] ACK > >> > >> 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." > > > [PTT] Yes, but I think I would have to re-review to ensure that the mechanism > is well specified. I am worried about the status of the OAuth work (the PoP > mechanism) that you depend on. I get your point now, Thanks for the clarification. Moved text to Appendix. > Does it become a normative reference as a > result of bringing the OAuth interchange into scope ? > > > >> 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 ? > > > [PTT] WebRTC brings in an unnecessary additional complication that > obscures what you are trying to standardize: the interactions between a > STUN/TURN client, a STUN/TURN server, and an OAuth authorization server. > It would be perfectly appropriate to mention in the introduction that the > OAuth authorization server could be collocated with a WebRTC server, but > otherwise WebRTC is irrelevant to what you are standardizing. Okay, added text for clarification. NEW: Some sections in this specification show the WebRTC server as the authorization server, however WebRTC is used for illustrative purpose only. > It just clutters > up your text and distracts the reader. > >> > >> 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. > > > [PTT] ACK > >> > >> 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. > > [PTT] ACK > >> > >> 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. > > > [PTT] Section 6.2 of the document says that ACCESS-TOKEN is a > comprehension-required attribute. You are right, added suggested text to Section 7. I will publish updated draft tomorrow. -Tiru > >> > > [PTT] ACK to all remaining items.