Re: [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh requests when using short-term credentials

["Konda, Tirumaleswar Reddy" <[e-mail]>]

The short-term credential mechanism for TURN is discussed in https://tools.ietf.org/html/rfc7635, it addresses both the issues raised by the reporter

a) Section 9 says,  If the access token expires, then the client MUST obtain a new token from the authorization server and use it for new
    allocations.  The client MUST use the new token to refresh existing allocations.  This way, the client has to maintain only
    one token per TURN server.
b) Section 11 discusses frequently changing the nonce.

Cheers,
-Tiru

> -----Original Message-----
> From: tram <[e-mail]> On Behalf Of Magnus Westerlund
> Sent: Friday, January 24, 2020 9:59 PM
> To: [e-mail]; juberti=[e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tram] [BEHAVE] errata 4933: RFC 5766 prevent spoofed refresh
> requests when using short-term credentials
> 
> Hi,
> 
> I think the primary question is if this errata points to an issue that remains
> within the updated TURN specification:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
> 
> So the question to the TRAM WG people.
> 
> Section 21.3.3. (the equivalent to 17.3.3) has the same text. However, I think
> the underlying question is if the existing mechanism and especially for stale
> nonce prevents an insider attacker that otherwise have the user name and
> password for the user can take over an allocation when the nonce expires?
> 
> However, I have the suspistion that the reporter has made an erronous
> assumption as short-term security is not allowed with TURN. Section 4 of RFC
> 5766 do requires long-term or other equal strong mechanism. Thus, another
> aspect is if the nonce actually will expire? Or can a client actually loose their
> allocations when the nonce expires and attacker manages to make the
> request first?
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> On Fri, 2020-01-17 at 10:00 -0800, Justin Uberti wrote:
> > Both a/b seem sensible to me.
> >
> > On Thu, Jan 16, 2020 at 5:27 PM Michael Richardson
> > <[e-mail]>
> > wrote:
> > > https://www.rfc-editor.org/errata_search.php?eid=4933
> > >
> > >     4933> Section 17.3.3 says:
> > >
> > >     4933> An attacker might attempt to disrupt service to other users of
> the
> > >     4933> TURN server by sending Refresh requests or
> > > CreatePermission requests
> > >     4933> that (through source address spoofing) appear to be coming
> from
> > >     4933> another user of the TURN server.  TURN prevents this by
> requiring
> > >     4933> that the credentials used in CreatePermission, Refresh, and
> > >     4933> ChannelBind messages match those used to create the initial
> > >     4933> allocation.  Thus, the fake requests from the attacker will be
> > >     4933> rejected.
> > >     4933> Notes:
> > >
> > >     4933> When using short-term, credentials expire after a specific
> > > amount of time
> > >     4933> (such as 5
> > >     4933> minutes) and clients get new credentials. The restriction
> > > imposed at section
> > >     4933> 17.3.3
> > >     4933> prevents from refreshing allocation or permission using
> > > the new credentials.
> > >
> > >     4933> This RFC approves RFC 5389. So one can use short-term
> credentials.
> > > But
> > >     4933> short-term credentials are useless if it can not be used
> > > to refresh
> > >     4933> allocation or permission.
> > >
> > >     4933> The goal of 17.3.3 can be achieved by sending 438 with the
> > > new nonce.
> > >
> > > a) I think we should accept this as verified.
> > > b) It seems that sending with the new nonce will work.  This requires
> some
> > >    text changes, and we can now perhaps use the errata patcher with
> XML..
> > >    I've asked for the XML (if there is any), and I'll suggest some
> > > changes to
> > >    the text.
> > >
> > > --
> > > Michael Richardson <[e-mail]>ca>, Sandelman Software
> Works
> > > -= IPv6 IoT consulting =-
> > >
> > >
> > >
> > >
> > > --
> > > Michael Richardson <[e-mail]>ca>, Sandelman Software
> Works
> > > -= IPv6 IoT consulting =-
> > >
> > >
> > >
> > > _______________________________________________
> > > Behave mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/behave
> >
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> --
> Cheers
> 
> Magnus Westerlund
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------