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