ietf
[Top] [All Lists]

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

2015-02-04 14:08:39
Hi Tom,

Please see inline

-----Original Message-----
From: Tom Taylor [mailto:tom(_dot_)taylor(_dot_)stds(_at_)gmail(_dot_)com]
Sent: Thursday, February 05, 2015 12:32 AM
To: Tirumaleswar Reddy (tireddy); ops-dir(_at_)ietf(_dot_)org; 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(_dot_)taylor(_dot_)stds(_at_)gmail(_dot_)com]
Sent: Wednesday, February 04, 2015 3:39 AM
To: ops-dir(_at_)ietf(_dot_)org; Tirumaleswar Reddy (tireddy); Prashanth 
Patil
(praspati); Ram Mohan R (rmohanr); Justin Uberti; Gonzalo Camarillo;
Spencer Dawkins; The IETF; tram(_at_)ietf(_dot_)org
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.

<Prev in Thread] Current Thread [Next in Thread>