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

From: Tom Taylor <[email-masked]>
Date: Tue, 03 Feb 2015 17:09:13 -0500

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

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

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

3. The first sentence of Section 4 has a lower-case "should". Should 
this be "SHOULD" or perhaps "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.

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?

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.

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?

Tom Taylor

Nits/editorial suggestions
==========================

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.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Feb 2015 20:08:14 +0000

Hi Tom,

Please see inline

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Thursday, February 05, 2015 12:32 AM
> To: Tirumaleswar Reddy (tireddy); [email-masked]; 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:[email-masked]]
> >> Sent: Wednesday, February 04, 2015 3:39 AM
> >> To: [email-masked]; Tirumaleswar Reddy (tireddy); Prashanth Patil
> >> (praspati); Ram Mohan R (rmohanr); Justin Uberti; Gonzalo Camarillo;
> >> Spencer Dawkins; The IETF; [email-masked]
> >> 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:
> >>
> > 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.
> >>
> >> 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
> >>
> >> 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
> 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.
> >
> >>
> >> 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
> >>
> >> 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.