Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization
draft-ietf-tram-turn-third-party-authz-16

[Ballot comment]

Hiya,

I've cleared my remaining discuss point which was to ask
that the WG consider an alternative (and I think simpler)
scheme based on signatures. Some of that discussion has
happened so there's no reason to hold this up further. (I
hope the discussion of simpler methods continues but
that will depend on people being interested.)

S

OLD COMMENTS:

- As some others have said before, this is still not an easy
read and though better, could still do with more editorial
work.

- Why are 4.1.1 and 4.1.2 still just examples. You need one
to be MTI or you won't get interop. Indeed 4.1.2 says you
SHOULD do 4.1.1! Please just bite the bullet and clearly say
that 4.1.1 is MTI.

- 4.1.1, "HTTPS MUST be used for mutual authentication" is
not a very clear way to say it. You mean that HTTPS MUST be
used and that TLS with mutual authentication based on client
certificates MUST be used. How does the WebRTC server know
what CA the TURN server is going to use? That's another point
of pre-arrangement that will be needed.

- 4.1.1, I thought the web folks frowned upon specifying URI
parameters like that. Shouldn't you at least use a
.well-known URL or something so as to not get on someone
eles's lawn?

- 6.2, PATH_MTU is not the correct term. There are
two paths involved, from WebRTC to browser and from
browser to TURN server and MTUs need not be the same
on those paths.

OLD COMMENTS BELOW HERE, I DIDN'T CHECK
THOSE.

- I really think this would benefit from some wider review
and I don't think it's ready as-is.

- I agree with Richard's discuss points.

- intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true.

- Assuming the AS that can authorize the user shares a
secret with the STUN server chosen by the WebRTC server
seems very brittle. Why would that be true in general?

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

- 4.1.2 - now we're using TLS mutual auth? And how does
the TLS client know which CA to use that'll work with the
TLS server here? I don't think that'll scale will it?

- 4.1.3 - this looks like what the WG/authors really want,
would that be a fair statement?

- 9: Figure 2 should be way up at the top of the document
and not here

- 9: Why 5 seconds?

[Ballot discuss]

Edited discuss ballot after chats around Dallas.

(1)  cleared

(2) Please consider whether a signature based
scheme that does not require pre-shared keys between
the TURN and (in particular) WebRTC server could
be useful to support. (Either in this document or
elsewhere.) There should be use cases where that
offers sufficient accountability for use of TURN and
it ought allow some deployments that are less easy
with this kind of pre-shared keys approach. The
DISCUSS here is to check if the WG want to take
that approach, either now or later. (I've sent a
mail to the WG list, this will clear shortly once
that is discussed.)

(3)  cleared (but see now comments below this is
still badly done IMO)

[Ballot comment]

NEW COMMENTS:

- As some others have said before, this is still not an easy
read and though better, could still do with more editorial
work.

- Why are 4.1.1 and 4.1.2 still just examples. You need one
to be MTI or you won't get interop. Indeed 4.1.2 says you
SHOULD do 4.1.1! Please just bite the bullet and clearly say
that 4.1.1 is MTI.

- 4.1.1, "HTTPS MUST be used for mutual authentication" is
not a very clear way to say it. You mean that HTTPS MUST be
used and that TLS with mutual authentication based on client
certificates MUST be used. How does the WebRTC server know
what CA the TURN server is going to use? That's another point
of pre-arrangement that will be needed.

- 4.1.1, I thought the web folks frowned upon specifying URI
parameters like that. Shouldn't you at least use a
.well-known URL or something so as to not get on someone
eles's lawn?

- 6.2, PATH_MTU is not the correct term. There are
two paths involved, from WebRTC to browser and from
browser to TURN server and MTUs need not be the same
on those paths.

OLD COMMENTS BELOW HERE, I DIDN'T CHECK
THOSE.

- I really think this would benefit from some wider review
and I don't think it's ready as-is.

- I agree with Richard's discuss points.

- intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true.

- Assuming the AS that can authorize the user shares a
secret with the STUN server chosen by the WebRTC server
seems very brittle. Why would that be true in general?

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

- 4.1.2 - now we're using TLS mutual auth? And how does
the TLS client know which CA to use that'll work with the
TLS server here? I don't think that'll scale will it?

- 4.1.3 - this looks like what the WG/authors really want,
would that be a fair statement?

- 9: Figure 2 should be way up at the top of the document
and not here

- 9: Why 5 seconds?

[Ballot discuss]

Edited discuss ballot after chats around Dallas.

(1) Please fix the crypto as per Richard's discuss. (I think
the plan here is for Rich Salz to help with that, which
I'm confident will work out ok.)

(2) Please consider whether a signature based
scheme that does not require pre-shared keys between
the TURN and (in particular) WebRTC server could
be useful to support. (Either in this document or
elsewhere.) There should be use cases where that
offers sufficient accountability for use of TURN and
it ought allow some deployments that are less easy
with this kind of pre-shared keys approach. The
DISCUSS here is to check if the WG want to take
that approach, either now or later.

(3) I think the plan is to take out some of the options
that are not needed so as make interop more likely.
Please do so. (I think we discussed taking out the
DKSPP stuff at least, but the more options we can
get rid of, the better).

[Ballot comment]

- COMMENTS below are unchanged since before Dallas.
We can look over then as we go.

- I really think this would benefit from some wider review
and I don't think it's ready as-is.

- I agree with Richard's discuss points.

- intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true.

- Assuming the AS that can authorize the user shares a
secret with the STUN server chosen by the WebRTC server
seems very brittle. Why would that be true in general?

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

- 4.1.2 - now we're using TLS mutual auth? And how does
the TLS client know which CA to use that'll work with the
TLS server here? I don't think that'll scale will it?

- 4.1.3 - this looks like what the WG/authors really want,
would that be a fair statement?

- 9: Figure 2 should be way up at the top of the document
and not here

- 9: Why 5 seconds?

[Ballot discuss]

(No relevant change I could see in -13)

(1) Making none of 4.1.x mandatory to implement will
result in a lack of interop. What is the developer
supposed to implement? Why is it ok to not say?  (For
example, defining 4.1.1 and 4.1.2 simply so as to appear
"more secure" whilst really expecting 4.1.3 to be used,
but not saying so, would seem like a bad plan to me.)

(2) What is the status of Appendix B? Am I supposed to
implement that? What does "Client could..." mean?

(3) In the secdir review [1] discussion, I see the authors
mention adding ECC, but I see nothing in the draft. I
don't believe that that discussion has really ended and
would like to continue it. Why is the WebRTC server not
simply signing something for the STUN server to verify?

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05423.html

[Ballot comment]
Thanks for your work on this draft and addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html

1. At the end of the new text on DTLS and TLS, you may want to add a reference to https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp, which is also close to publication.  The cipher suite recommendations appear to be in agreement with the BCP from those specified in RFC7350 and the BCP provides other best practices for TLS and DTLS that may be helpful to developers and implementors.

2. I support Richard's discuss on algorithm agility and will add in the following statement from Russ Housley on the same topic:
  COMMENT: Please see draft-iab-crypto-alg-agility.  The use of
  AES_256_CBC and HMAC-SHA-256-128 are hardcoded, and there is no
  means for migration to other algorithms in the future.

[Ballot discuss]


(1) Making none of 4.1.x mandatory to implement will
result in a lack of interop. What is the developer
supposed to implement? Why is it ok to not say?  (For
example, defining 4.1.1 and 4.1.2 simply so as to appear
"more secure" whilst really expecting 4.1.3 to be used,
but not saying so, would seem like a bad plan to me.)

(2) What is the status of Appendix B? Am I supposed to
implement that? What does "Client could..." mean?

(3) In the secdir review [1] discussion, I see the authors
mention adding ECC, but I see nothing in the draft. I
don't believe that that discussion has really ended and
would like to continue it. Why is the WebRTC server not
simply signing something for the STUN server to verify?

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05423.html

[Ballot comment]

- I really think this would benefit from some wider review
and I don't think it's ready as-is.

- I agree with Richard's discuss points.

- intro: "impossible in web applications" isn't really
true in principle, but impossible in WebRTC as it uses JS
is true.

- Assuming the AS that can authorize the user shares a
secret with the STUN server chosen by the WebRTC server
seems very brittle. Why would that be true in general?

- 4.1.1: Hmmm. How many people use KeyProv I wonder?

- 4.1.2 - which "two servers"? WebRTC can have more
servers than that.

- 4.1.2 - now we're using TLS mutual auth? And how does
the TLS client know which CA to use that'll work with the
TLS server here? I don't think that'll scale will it?

- 4.1.3 - this looks like what the WG/authors really want,
would that be a fair statement?

- 9: Figure 2 should be way up at the top of the document
and not here

- 9: Why 5 seconds?

[Ballot comment]
= Section 4 =
Is it assumed that once a particular STUN server indicates support for third party authorization, the client should include an OAuth token in all future requests to that server? Or is the client expected to check for support again at some point in the future by sending a request without authorization? Just wondering if the case where a server enables and later disables support for third party authz (for some operational reason) is covered.

= Section 6.2 =
"the client MUST NOT examine the ticket"

I think you meant token, not ticket.

[Ballot comment]
3:

OLD
  The value of the scope parameter explained in
  section 3.3 of [RFC6749] MUST be string 'stun'.
NEW
  The string 'stun' is defined by this specification for use as the
  OAuth scope parameter (see section 3.3 of [RFC6749]) for the OAuth
  token.

Are these things not in some IANA registry? How do we avoid scope parameter collisions?

4: s/MUST/needs to

[Ballot discuss]
Let's talk about Section 6.2 and custom crypto.

(1) You have tried to invent your own authenticated encryption, and fallen into the trap of Encrypt-Then-MAC [0].  (EDIT: Actually, it's MAC-then-Encrypt that's bad.  See why you should just use AEAD?)  Please use a real AEAD mode, such as AES-GCM [1].  That will also remove the need for padding, which is fraught with peril as well [2].

(2) It's a bad idea to hard-wire cryptographic algorithms into protocols, because they inevitably go bad [3].  (STUN itself is an anti-pattern here.)  Please add an algorithm indicator to the top of your token structure.  You don't need to create a registry now, since you've only got one value.

That gives you something like the following, much simpler structure:

struct {
  uint8_t algorithm;
  uint16_t length;
  opaque encrypted_block[length];
}

struct {
  uint16_t key_length;
  opaque mac_key[key_length];
  uint64_t timestamp;
  uint32_t lifetime;
}

It also means that you can simplify the key management routines in Section 4.1, since you only need one key.

(3) Section 5 should be more clear about how this mechanism changes STUN processing.  Namely, it adds a third parallel method of computing the message integrity value, which the server MUST use if an ACCESS-TOKEN attribute is present. 

[0] https://eprint.iacr.org/2001/045
[1] http://tools.ietf.org/html/rfc5116
[2] http://en.wikipedia.org/wiki/Padding_oracle_attack
[3] https://tools.ietf.org/html/draft-housley-crypto-alg-agility-00

[Ballot discuss]
Let's talk about Section 6.2 and custom crypto.

(1) You have tried to invent your own authenticated encryption, and fallen into the trap of Encrypt-Then-MAC [0].  Please use a real AEAD mode, such as AES-GCM [1].  That will also remove the need for padding, which is fraught with peril as well [2].

(2) It's a bad idea to hard-wire cryptographic algorithms into protocols, because they inevitably go bad [3].  (STUN itself is an anti-pattern here.)  Please add an algorithm indicator to the top of your token structure.  You don't need to create a registry now, since you've only got one value.

That gives you something like the following, much simpler structure:

struct {
  uint8_t algorithm;
  uint16_t length;
  opaque encrypted_block[length];
}

struct {
  uint16_t key_length;
  opaque mac_key[key_length];
  uint64_t timestamp;
  uint32_t lifetime;
}

It also means that you can simplify the key management routines in Section 4.1, since you only need one key.

(3) Section 5 should be more clear about how this mechanism changes STUN processing.  Namely, it adds a third parallel method of computing the message integrity value, which the server MUST use if an ACCESS-TOKEN attribute is present. 

[0] https://eprint.iacr.org/2001/045
[1] http://tools.ietf.org/html/rfc5116
[2] http://en.wikipedia.org/wiki/Padding_oracle_attack
[3] https://tools.ietf.org/html/draft-housley-crypto-alg-agility-00

[Ballot comment]
Thanks for your work on this draft and addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html

At the end of the new text on DTLS and TLS, you may want to add a reference to https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp, which is also close to publication.  The cipher suite recommendations appear to be in agreement with the BCP from those specified in RFC7350 and the BCP provides other best practices for TLS and DTLS that may be helpful to developers and implementors.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tram-turn-third-party-authz-07  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about some of the IANA actions requested in the IANA Considerations
section of this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA
must complete.

In the STUN Attributes subregistry of the Session Traversal Utilities for NAT (STUN)
Parameters registry located at:

http://www.iana.org/assignments/stun-parameters/

two new STUN attributes are to be registered as follows:

Value: [ TBD-at-registration ]
Name: THIRD-PARTY-AUTHORIZATION
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Name: ACCESS-TOKEN
Reference: [ RFC-to-be ]

Question: which range or ranges in the STUN Attributes registry the above two new
attributes should be registered?  The registry defines the following ranges:

Range Registration Procedures Note
0x0000-0x3FFF IETF Review comprehension-required range
0x4000-0x7FFF Designated Expert comprehension-required range
0x8000-0xBFFF IETF Review comprehension-optional range
0xC000-0xFFFF Designated Expert comprehension-optional range

It appears that section 6 defines the new attributes to be in two different
ranges, comprehension-optional and comprehension-required.  Is that
correct?  If so, please either add the ranges in the IC section or add
a pointer to section 6 in the IC section. 

Further, if a new attribute is in the comprehension-optional range,
the authors need to define which of the comprehension-optional ranges,
0x8000-0xBFFF or 0xC000-0xFFFF, the new attribute should be registered.
So, if the authors pick "0x8000-0xBFFF" of the comprehension-optional range,
IETF Review registration rule will be used.  The IC section has no clear texts
about these.


IANA understands that this is the only action that needs to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard


The IESG has received a request from the TURN Revised and Modernized WG
(tram) to consider the following document:
- 'Session Traversal Utilities for NAT (STUN) Extension for Third Party
  Authorization'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document proposes the use of OAuth to obtain and validate
  ephemeral tokens that can be used for Session Traversal Utilities for
  NAT (STUN) authentication.  The usage of ephemeral tokens ensure that
  access to a STUN server can be controlled even if the tokens are
  compromised.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO write up for draft-ietf-tram-turn-third-party-authz-05:

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard, as indicated on the front page of the draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document proposes the use of OAuth to obtain and validate
  ephemeral tokens that can be used for Session Traversal Utilities
  for NAT (STUN) authentication.  The usage of ephemeral tokens
  ensure that access to a STUN server can be controlled even if the
  tokens are compromised.

Working Group Summary:

  The working group had a strong consensus around this draft.

Document Quality:

  There are implementations of this draft. For example, coturn, which
  is an open source implementation of TURN and STUN, includes this
  functionality.
 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Gonzalo Camarillo is the document shepherd.
  Spencer Dawkins is the responsible Area director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has reviewed version 05 of the draft and
  believes it is ready for pub req.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  Given that this document relates to security, the security ADs may
  want to assign a dedicated security reviewer to it.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  Strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No additional reviews are needed.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  The IANA Considerations section registers two STUN attributes and
  seems to be consistent with the body of the document.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  No new IANA registries are defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language is used in the document (beyond the descripcion
  of the token structure in Section 6.2).