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. 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.