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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 15 Apr 2015 09:47:52 +0000

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Monday, April 13, 2015 11:47 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Brandon Williams; [email-masked]; Salz, Rich; Stephen Farrell
> ([email-masked]); [email-masked]; [email-masked]
> 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)
> <[email-masked]> 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.

---

From: Brandon Williams <[email-masked]>
Date: Tue, 21 Apr 2015 14:35:02 -0400

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

I'm not sure that key length alone is enough to facilitate the current 
hash agility plan, which is to require a client to send both SHA256 and 
SHA1 HMACs. IMO, either this draft should require 256 bit keys minimum 
and describe what to do to generate a SHA1 key (probably run SHA1 on the 
SHA256 key) or the stunbis editors should commit to providing this 
information in stunbis. I just want to be certain that we will be 
telling implementors what to do somewhere.

--Brandon

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Apr 2015 18:40:07 +0000

> I'm not sure that key length alone is enough to facilitate the current hash
> agility plan, which is to require a client to send both SHA256 and
> SHA1 HMACs. IMO, either this draft should require 256 bit keys minimum and
> describe what to do to generate a SHA1 key (probably run SHA1 on the
> information in stunbis. I just want to be certain that we will be telling
> implementors what to do somewhere.

+1.

It seems that this draft is the place to put "how to turn the 256bit HMAC key into something usable for the sha1 hmac"

Key size is not an unambiguous algorithm identifier.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 22 Apr 2015 01:58:24 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Wednesday, April 22, 2015 12:05 AM
> To: Tirumaleswar Reddy (tireddy); Martin Thomson
> Cc: [email-masked]; [email-masked]; [email-masked]; Salz, Rich; Stephen
> Farrell ([email-masked])
> > 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.
> >
> 

HKDF https://tools.ietf.org/html/rfc5869 can be used to derive the key for SHA1 from 256-bit key but as per the last mail thread http://www.ietf.org/mail-archive/web/tram/current/msg01525.html, I did not see any consensus if TURN client must include MI calculated using both SHA1 and SHA2. 

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 22 Apr 2015 04:11:34 +0000

> From: Salz, Rich [mailto:[email-masked]]
> Sent: Wednesday, April 22, 2015 7:52 AM
> To: Tirumaleswar Reddy (tireddy); Williams, Brandon; Martin Thomson
> Cc: [email-masked]; [email-masked]; [email-masked]; Stephen Farrell
> ([email-masked])
> Subject: RE: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
> > HKDF https://tools.ietf.org/html/rfc5869 can be used to derive the key for
> > SHA1 from 256-bit key
> 
> Too complicated.  Just do a SHA1 on the 256 bit key.

https://tools.ietf.org/html/rfc6194#section-3 discusses problems with SHA1. Is it safe to derive key using SHA1 ?

-Tiru

> 
> --
> Senior Architect, Akamai Technologies
> IM: [email-masked] Twitter: RichSalz

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 22 Apr 2015 04:20:02 +0000

> Sent: Wednesday, April 22, 2015 9:44 AM
> > https://tools.ietf.org/html/rfc6194#section-3 discusses problems with
> SHA1.
> > Is it safe to derive key using SHA1 ?
> 
> Those concerns do not apply here.  Yes, absolutely safe.

Thanks, updated draft in my local copy.

OLD:
   [I-D.ietf-tram-stunbis] will support hash agility and accomplish this
   agility by conveying the HMAC algorithms supported by the STUN server
   along with a STUN error message to the client.  The client then
   signals the intersection-set of algorithms supported by it and the
   STUN server to the authorization server in the 'alg' parameter
   defined in [I-D.ietf-oauth-pop-key-distribution].  The authorization
   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.  Note that until STUN supports hash agility
   HMAC-SHA1 is the only valid hash algorithm that the client can signal
   to the authorization server and vice-versa.

NEW:
   [I-D.ietf-tram-stunbis] supports hash agility and accomplish this agility by computing  message integrity using both HMAC-SHA-1 and HMAC-SHA-256-128.
   The client signals the algorithm supported by it to the authorization server in the 'alg' parameter
   defined in [I-D.ietf-oauth-pop-key-distribution]. The authorization determines length of the mac_key based on the
   HMAC algorithm conveyed by the client. If the client supports 
   both HMAC-SHA-1 and HMAC-SHA-256-128 then it signals HMAC-SHA-256-128 to the authorization server, gets 256-bit key from the authorization server
   and calculates 160-bit key for HMAC-SHA-1 using SHA1 taking the 256-bit key as input.

-Tiru

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2015 02:22:07 +0000

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2015 04:14:14 +0000

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Apr 2015 11:55:42 -0500

Hi, Rich,

> Those concerns do not apply here.  Yes, absolutely safe.

I saw that Tiru has already made that change in a later mail in this
thread, and that's fine. This is just for my education.

I'm not in my native element here, so I'm not questioning your statement,
but could you explain to me (I'm thinking like a sentence, not like a
thesis) on why those concerns don't apply?

Another AD could reasonably ask during balloting or the telechat, because
we all know to twitch when SHA-1 is mentioned, and I'd like to be able to
provide more than a shrug :-)

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Apr 2015 15:44:39 -0500

Hi, Rich,

On Wed, Apr 22, 2015 at 12:13 PM, Salz, Rich <[email-masked]> wrote:

> Sure.  First, look at https://tools.ietf.org/html/rfc6194#section-3  and
> quote that :)
>
> Second, this is not being used as a public signature mechanism, but as a
> private key for an HMAC.

That was my uninformed guess ... and I knew how uninformed it was.

> So you can't modify "original content" to find a collision since you don't
> have the content, and more importantly, you don't have the digest value for
> which the attacker is trying to find a collision.
>
> Hope that helps.
>

Extremely. My uninformed guess was a much less detailed version of that,
and the details are very helpful.

Thank you for investing a moment in helping to raise the average AD IQ!

Spencer

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2015 17:13:42 +0000

> but could you explain to me (I'm thinking like a sentence, not like a thesis) on why those concerns don't apply?

Sure.  First, look at https://tools.ietf.org/html/rfc6194#section-3  and quote that :)

Second, this is not being used as a public signature mechanism, but as a private key for an HMAC.  So you can't modify "original content" to find a collision since you don't have the content, and more importantly, you don't have the digest value for which the attacker is trying to find a collision.

Hope that helps.