Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-08-24
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-08-17
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-08-14
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-06-15
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on Authors
2015-06-12
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-06-12
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-06-11
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-06-11
16 (System) IANA Action state changed to In Progress from On Hold
2015-06-11
16 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-06-10
16 (System) RFC Editor state changed to EDIT
2015-06-10
16 (System) Announcement was received by RFC Editor
2015-06-09
16 (System) IANA Action state changed to On Hold from In Progress
2015-06-09
16 (System) IANA Action state changed to In Progress
2015-06-09
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-06-09
16 Amy Vezza IESG has approved the document
2015-06-09
16 Amy Vezza Closed "Approve" ballot
2015-06-09
16 Amy Vezza Ballot approval text was generated
2015-06-09
16 Amy Vezza Changed consensus to Yes from Unknown
2015-06-09
16 Amy Vezza Ballot writeup was changed
2015-06-09
16 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-05-29
16 Stephen Farrell
[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 …
[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?
2015-05-29
16 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2015-05-13
16 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-16.txt
2015-04-28
15 Stephen Farrell
[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 …
[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)
2015-04-28
15 Stephen Farrell
[Ballot comment]

NEW COMMENTS:

- As some others have said before, this is still not an easy
read and though better, could still do with …
[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?
2015-04-28
15 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2015-04-26
15 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-15.txt
2015-04-15
14 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-14.txt
2015-04-10
13 Stephen Farrell
[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 …
[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).
2015-04-10
13 Stephen Farrell
[Ballot comment]

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

- I really think this would benefit …
[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?
2015-04-10
13 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2015-03-06
13 Stephen Farrell
[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. …
[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
2015-03-06
13 Stephen Farrell Ballot discuss text updated for Stephen Farrell
2015-02-25
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-02-25
13 Tirumaleswar Reddy.K IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-02-25
13 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-13.txt
2015-02-19
12 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-02-19
12 Spencer Dawkins Notification list changed to tram-chairs@ietf.org, tram@ietf.org, draft-ietf-tram-turn-third-party-authz@ietf.org, gonzalo.camarillo@ericsson.com, draft-ietf-tram-turn-third-party-authz.ad@ietf.org, draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org from "Gonzalo Camarillo" <gonzalo.camarillo@ericsson.com>
2015-02-19
12 Kathleen Moriarty
[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 …
[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.
2015-02-19
12 Kathleen Moriarty Ballot comment text updated for Kathleen Moriarty
2015-02-19
12 Stephen Farrell
[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 …
[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
2015-02-19
12 Stephen Farrell
[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 …
[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?
2015-02-19
12 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2015-02-19
12 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-02-19
12 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-02-19
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-02-19
12 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-02-18
12 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-02-18
12 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-02-18
12 Alissa Cooper
[Ballot comment]
= Section 4 =
Is it assumed that once a particular STUN server indicates support for third party authorization, the client should include …
[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.
2015-02-18
12 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-02-18
12 Pete Resnick
[Ballot comment]
3:

OLD
  The value of the scope parameter explained in
  section 3.3 of [RFC6749] MUST be string 'stun'.
NEW …
[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
2015-02-18
12 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-02-18
12 Richard Barnes
[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 …
[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
2015-02-18
12 Richard Barnes Ballot discuss text updated for Richard Barnes
2015-02-18
12 Richard Barnes
[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 …
[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
2015-02-18
12 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2015-02-18
12 Kathleen Moriarty
[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 …
[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.
2015-02-18
12 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-02-18
12 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-02-18
12 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-02-17
12 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2015-02-17
12 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-02-16
12 Christer Holmberg Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg.
2015-02-15
12 Tirumaleswar Reddy.K IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-02-15
12 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-12.txt
2015-02-12
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2015-02-12
11 Jean Mahoney Request for Telechat review by GENART is assigned to Christer Holmberg
2015-02-11
11 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-02-11
11 Spencer Dawkins Ballot has been issued
2015-02-11
11 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2015-02-11
11 Spencer Dawkins Created "Approve" ballot
2015-02-11
11 Spencer Dawkins Ballot writeup was changed
2015-02-11
11 Spencer Dawkins IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-02-09
11 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-11.txt
2015-02-06
10 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-10.txt
2015-02-05
09 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-09.txt
2015-02-05
08 Christer Holmberg Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg.
2015-02-05
08 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tom Taylor.
2015-02-05
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer.
2015-02-04
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-01-31
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tom Taylor
2015-01-31
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tom Taylor
2015-01-28
08 Tirumaleswar Reddy.K IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2015-01-28
08 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-08.txt
2015-01-27
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-01-27
07 Pearl Liang
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 …
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.
2015-01-22
07 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2015-01-22
07 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2015-01-22
07 Jean Mahoney Closed request for Last Call review by GENART with state 'Withdrawn'
2015-01-22
07 Jean Mahoney Request for Last Call review by GENART is assigned to Ben Campbell
2015-01-22
07 Jean Mahoney Request for Last Call review by GENART is assigned to Ben Campbell
2015-01-22
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2015-01-22
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2015-01-21
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-01-21
07 Amy Vezza
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 …
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.


2015-01-21
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-01-21
07 Spencer Dawkins Ballot writeup was changed
2015-01-21
07 Spencer Dawkins Placed on agenda for telechat - 2015-02-19
2015-01-21
07 Spencer Dawkins Last call was requested
2015-01-21
07 Spencer Dawkins Ballot approval text was generated
2015-01-21
07 Spencer Dawkins Ballot writeup was generated
2015-01-21
07 Spencer Dawkins IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2015-01-21
07 Spencer Dawkins Last call announcement was generated
2015-01-21
07 Spencer Dawkins Last call announcement was generated
2015-01-21
07 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-07.txt
2015-01-20
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-01-20
06 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-06.txt
2015-01-16
05 Spencer Dawkins IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2015-01-16
05 Spencer Dawkins IESG state changed to AD Evaluation from Publication Requested
2015-01-15
05 Gonzalo Camarillo
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 …
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).

2015-01-15
05 Gonzalo Camarillo Responsible AD changed to Spencer Dawkins
2015-01-15
05 Gonzalo Camarillo IETF WG state changed to Submitted to IESG for Publication from WG Document
2015-01-15
05 Gonzalo Camarillo IESG state changed to Publication Requested
2015-01-15
05 Gonzalo Camarillo IESG process started in state Publication Requested
2015-01-15
05 Gonzalo Camarillo Intended Status changed to Proposed Standard from None
2015-01-15
05 Gonzalo Camarillo Changed document writeup
2015-01-15
05 Gonzalo Camarillo Notification list changed to "Gonzalo Camarillo" <gonzalo.camarillo@ericsson.com>
2015-01-15
05 Gonzalo Camarillo Document shepherd changed to Gonzalo Camarillo
2014-10-02
05 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-05.txt
2014-09-24
04 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-04.txt
2014-09-05
03 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-03.txt
2014-08-27
02 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-02.txt
2014-07-30
01 Tirumaleswar Reddy.K New version available: draft-ietf-tram-turn-third-party-authz-01.txt
2014-07-21
00 Prashanth Patil New version available: draft-ietf-tram-turn-third-party-authz-00.txt