Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-13: (with DISCUSS and COMMENT)

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Monday, April 13, 2015 11:47 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Brandon Williams; [e-mail]; Salz, Rich; Stephen Farrell
> ([e-mail]); [e-mail]; [e-mail]
> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> party-authz-13: (with DISCUSS and COMMENT)
> 
> On 10 April 2015 at 18:58, Tirumaleswar Reddy (tireddy)
> <[e-mail]> wrote:
> > Richard and we have already have discussed the comments further and
> resolved them, attached updated draft with diff.
> > Main changes
> >
> > [1] Removed DKSPP
> > [2] Removed non-AEAD algorithms; using AEAD modes AES-GCM and aead-
> aes-cbc
> > [3] Updated the token format
> 
> 
> I read this just now for the first time in a while.  Either I'm a lot
> stupider this morning than I normally am, or this draft is very
> confused.  There are some serious problems in here.
> 
> If you intend to use RFC 5116, please clearly specify the inputs, as
> described in Section 2.1:
> https://tools.ietf.org/html/rfc5116#section-2.1 Currently, the draft
> uses N for the name of the server.  That conflicts with the label that
> RFC 5116 uses for the nonce.  Also, the draft is very vague about the
> construction of the nonce.  

STUN server name is the associated data (A) and nonce is formed as explained in section 3.2 of [RFC5116]. 

> The draft certainly doesn't need to refer
> to the CBC AEAD draft.

CBC AEAD draft is referred because both AEAD AES GCM and CBC AEAD are supported.
 
> 
> It does need to deal with algorithm agility and it currently does not.

It supports algorithm agility. Please refer to http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-13#appendix-B  for the interaction b/w the client and authorization server where the client signals the algorithms it supports and server selects an HMAC algorithm from the list of algorithms the  client provided and determines length of the mac_key based on the selected HMAC algorithm.

> 
> 
> I apologize for not reviewing this earlier.  Here are more comments.
> 
> Section 1 doesn't really explain what the draft provides.

Please provide more info on details you are looking for to be added in section 1 

> 
> Section 3 claims to be an overview, but it doesn't actually describe
> what happens.  It leaves the token acquisition part out of scope.
> That's fine, but it doesn't describe how the THIRD-PARTY-AUTHORIZATION
> attribute might be used, even in the broadest sense.  It doesn't
> explain why it's a server name, or how that name relates to the domain
> name of the server (i.e., the one that might have been passed to a DNS
> resolver).

Section 6.1 is clear on this.

> 
> Section 4 doesn't permit any additional information to be carried in
> the token.  Therefore, the STUN/TURN server is unable to apply any
> additional policies that the authorization server might impose, such
> as limits on the length of the session, the number of ports allocated,
> or the bandwidth that is allocated.  (Or whatever we might later
> conceive of.)
> 
> It's not clear what Section 4.1.1 is for.  If this is private
> communications, then it is far too specific.  If this is intended to
> be normative, then it isn't sufficient.  What is the base URI?  What
> prevents a random internet denizen from acquiring this symmetric key?
> Why these two specific parameters?  Why does the expiration
> information in the JWK replicate what HTTP provides?  I'd be far
> happier with hand-waving than with this section in place.

It is private communication and this section is only an example of how this could be achieved.

> 
> Section 5 fails to explicitly state whether the MAC key is used as
> input to short term or long term credentials.  It needs to say short
> term, I think.

Yes, it's mentioned that mac_key is used as input

<snip>

   The STUN client includes a MESSAGE-INTEGRITY attribute
   as the last attribute in the message over the contents of the STUN
   message.  The HMAC for the MESSAGE-INTEGRITY attribute is computed as
   described in section 15.4 of [RFC5389] where the mac_key is used as
   the input key for the HMAC computation.  The STUN client and server
   will use the mac_key to compute the message integrity and do not
   perform MD5 hash on the credentials.

</snip>

> 
> Why does this document use 'kid' rather than USERNAME?  Isn't the
> point to get a short term  username+password pair from the
> authorization server ?

This document uses username, kid is signaled in the username attribute.

> 
> Section 7 seems to imply two layers of authentication: the AEAD and
> some HMAC.  I can't work out what is being authenticated.  I'm not
> sure that anyone else could either.

It's only one layer of authentication either AEAD AES GCM or AEAD CBC HMAC.

> 
> The replay protection in Section 7 is not sufficient.  If the intent
> is to prevent replay, then the server needs to maintain a
> globally-consistent register of the requests that it has seen so that
> it can correctly reject replays.  However, I think that the intent is
> to permit replay, so perhaps it is the case that casting this as
> anti-replay is counter-intuitive.  That said, I believe that this is a
> serious DoS vector and we should be recommending that servers at least
> account for what has been replayed and limit the number of times a
> particular token can be used.
> 
> If the intent of the lifetime in the token is to prevent replay, then
> this is bad:
> 
>   o  The lifetime provided by the TURN server in the Allocate and
>       Refresh responses MUST be less than or equal to the lifetime of
>       the token.
> 
> Tying the two lifetimes together means that you need to have a long
> token lifetime in order to support long sessions.  But long token
> lifetimes means long periods of exposure to replay and lots of
> maintained state.  See earlier point about policies being carried in
> the token.

Replay attacks are not possible because of nonce, an attacker trying to replay message with ACCESS-TOKEN attribute can be mitigated by frequent changes of nonce value as discussed in https://tools.ietf.org/html/rfc5389#section-10.2.

> 
> Section 8 seems completely unnecessary.  What resource is being
> conserved here?  

Section 8 is required for the client to authenticate the STUN server.

> It's more work to maintain all this state and
> validate all those tokens than it is to respond in the affirmative to
> STUN request.  (Also, why doesn't STUN usage get a fancy OAuth mapping
> table like Section 9?  Is it somehow different?)

The mapping to STUN is also similar 
Client -> STUN client; Resource server -> STUN server;
Resource owner -> Authorization server.

-Tiru

> 
> In summary, I'm surprised that a document in this state was put before the
> IESG.