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

[Tom Taylor <[e-mail]>]

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:[e-mail]]
>> Sent: Wednesday, February 04, 2015 3:39 AM
>> To: [e-mail]; Tirumaleswar Reddy (tireddy); Prashanth Patil
>> (praspati); Ram Mohan R (rmohanr); Justin Uberti; Gonzalo Camarillo;
>> Spencer Dawkins; The IETF; [e-mail]
>> 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. 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. 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.
>>

[PTT] ACK to all remaining items.