Skip to main content

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

Discuss


Yes

(Spencer Dawkins)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Ted Lemon)

Note: This ballot was opened for revision 11 and is now closed.

Richard Barnes Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2015-02-18 for -12) Unknown
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
Spencer Dawkins Former IESG member
Yes
Yes (for -11) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-02-18 for -12) Unknown
= 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.
Barry Leiba Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-02-19 for -12) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2015-02-18 for -12) Unknown
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
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2015-05-29) Unknown
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?
Ted Lemon Former IESG member
No Objection
No Objection (for -12) Unknown