Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27

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

Hi Ben,

Please see inline

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Saturday, July 13, 2019 7:19 AM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: Christopher Wood <[e-mail]>; [e-mail]; draft-ietf-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Tiru,
> 
> Thanks for all the updates, including further downthread with Chris.
> Just a couple notes inline...
> 
> On Wed, Jul 10, 2019 at 12:40:37PM +0000, Konda, Tirumaleswar Reddy wrote:
> > Hi Ben,
> >
> > Thanks for the review. Please see inline.
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <[e-mail]>
> > > Sent: Wednesday, July 10, 2019 2:01 AM
> > > To: Konda, Tirumaleswar Reddy
> <[e-mail]>
> > > Cc: Christopher Wood <[e-mail]>; [e-mail];
> > > draft-ietf- [e-mail]; [e-mail]; [e-mail]
> > > Subject: Re: [tram] Secdir last call review of
> > > draft-ietf-tram-turnbis-27
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > Chris, thanks for the review.  Some more questions/comments inline
> > > as I prepare to ballot on this document...
> > >
> > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > > > Hi Christopher,
> > > >
> > > > Thanks for the detailed review. Please see inline
> > > >
> > > > > -----Original Message-----
> > > > > From: tram <[e-mail]> On Behalf Of Christopher
> Wood
> > > > > via Datatracker
> > > > > Sent: Monday, July 8, 2019 1:59 AM
> > > > > To: [e-mail]
> > > > > Cc: [e-mail]; [e-mail];
> > > > > [e-mail]
> > > > > Subject: [tram] Secdir last call review of
> > > > > draft-ietf-tram-turnbis-27
> > > > >
> > > > > This email originated from outside of the organization. Do not
> > > > > click links or open attachments unless you recognize the sender
> > > > > and know the content is safe.
> > > > >
> > > > > Reviewer: Christopher Wood
> > > > > Review result: Has Nits
> > > > >
> > > > > I have reviewed this document as part of the security
> > > > > directorate's ongoing effort to review all IETF documents being
> > > > > processed by the IESG. These comments were written primarily for
> > > > > the benefit of the security area directors.
> > > > > Document editors and WG chairs should treat these comments just
> > > > > like any other last call comments.
> > > > >
> > > > > The summary of the review is: Ready with nits
> > > > >
> > > > > Summary:
> > > > >
> > > > > In general, the document is well written and clearly founded in
> > > > > operational experience. The security considerations are
> > > > > thorough, providing examples where necessary to highlight
> > > > > important problem areas. It draws a clear line between issues
> > > > > best addressed by applications outside of TURN, and provides
> > > > > sufficient detail for those issues in scope. My comments and
> > > > > questions are, hopefully, mostly
> > > nits.
> > > > >
> > > > > General comments:
> > > > >
> > > > > - TURN server authentication in the case of (D)TLS is
> > > > > underspecified. Are servers assumed to have WebPKI certificates,
> > > > > OOB-trusted raw public keys, or something else? Is there a
> > > > > preferred
> > > form of authentication?
> > > > > Relatedly, in
> > > > > Section 3.2, how do clients authenticate the server?
> > > >
> > > > Server certificate validation is discussed in
> > > > https://tools.ietf.org/html/draft-
> > > ietf-tram-stunbis-21#section-6.2.3.  I have modified the text as follows:
> > > >
> > > > If (D)TLS transport is used between the TURN client and the TURN
> > > > server, the cipher suites, server certificate validation and
> > > > authentication of TURN server are discussed in Section 6.2.3 of
> > > > [I-D.ietf-tram-stunbis]
> > >
> > > That helps, but it would still be nice to give some indication of
> > > what certificate
> > > PKI(s) are expected to be used.  Is anything other than the Web PKI
> > > under consideration ?
> >
> > No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-
> 21#section-6.2.3, It discusses to verify the certificate path and identity of the
> server.
> >
> > >
> > > > >- Section 3.7: Could
> > > > > TURN servers not chunk data from stream-oriented transports (TCP
> > > > >or
> > > > >TLS)  to a preferred MTU size before relaying to peers?
> > > > > Specifically, there are likely
> > > > > some cases wherein the server could deal with the client data
> > > > >messages  larger than the recommended 500B limit. On that point,
> > > > >should servers even  accept data larger than this recommended size ?
> > > > >-
> > > >
> > > > Please see
> > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15
> > > > for TCP-to-UDP relay. If the PMTU is not known, and on legacy or
> > > > otherwise unusual networks,
> > > > 500 byte limit for application data is recommended.
> > > >
> > > > > Section 3.9: There may be
> > > > > cases where the TLS connection post TCP connection establishment
> > > > > fails. It would therefore seems prudent to not declare victory
> > > > > for one connection over the other until TLS connects, too. -
> > > >
> > > > Agreed, Eric (as part of ISEG review) suggested to simplify the
> > > > text. I have
> > > updated the text as follows:
> > > >
> > > >    o  For TCP or TLS-over-TCP, the results of the Happy Eyeballs
> > > >       procedure [RFC8305] are used by the TURN client for sending its
> > > >       TURN messages to the server.
> > >
> > > Is the editor's copy available for viewing somewhere?  It would be
> > > good to see this (and other changes) in context.
> >
> > Yes, Please see https://github.com/tireddy2/TURNbis
> >
> > >
> > > > > Section 3 could benefit from a
> > > > > subsection on replays and the nonce role. In particular, as
> > > > > later discussed in the security considerations, some of these
> > > > > attacks are not new to TURN and should therefore be dealt with
> > > > > by the application protocol (SRTP). This section might also
> > > > > describe nonce rotation policies with more specificity, as this
> > > > > is underspecified in the
> > > document.
> > > >
> > > > It is discussed in Section 5 in the specification, the server
> > > > should expire the
> > > nonce at least once every hour during the lifetime of the allocation.
> > > >
> > > > >- Section 3 could also benefit from  discussion about cleartext
> > > > >versus encryption transports between clients and  servers.
> > > >
> > > > It is discussed in
> > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-
> > > 27#section-21.1.6.
> > >
> > > There's not much discussion about potential information  leakage via
> > > (e.g.) USERNAME/USERHASH, and really just a claim that the peer
> > > address is the "primary protocol content".
> >
> > Agreed, added the following paragraph :
> >
> > If the TURN client and server use the STUN Extension for Third-Party
> > Authorization [RFC7635], the username does not reveal the real user's
> identity, the USERNAME attribute carries an ephemeral and unique key
> identifier, and the key identifier can change per call.
> > If the TURN client and server use the STUN long-term credential
> > mechanism and the username reveals the real user's identity, the
> > client need to either use (D)TLS transport between the client and the
> server or use the USERHASH attribute instead of the USERNAME attribute to
> anonynmize the username.
> >
> > >
> > > > > Encrypting the nonce, username, realm, etc., among other things,
> > > > > has obvious benefits. - Why are SOFTWARE and FINGERPRINT
> > > > > attributes recommended?  It seems like clients should be
> > > > > discouraged from sending these if anything, especially if not
> > > > > used to make allocation decisions on the server.
> > > >
> > > > Username may not be the user identity, Please see
> > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and
> > > unique key identifier. Further, username can be anonymized (please
> > > see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4).
> > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN
> > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21.
> > >
> > > These mechanisms  are partial mitigations but can still be
> > > susceptible to cross- connection correlation attacks.
> >
> > The use of FINGERPRINT is not mandatory, the TURN client and server may
> include the FINGERPRINT attribute.  Note that ICE
> (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT
> attribute. Added the following line for SOFTWARE attribute (TURNbis is using
> the same behavior defined in RFC5766 to use SOFTWARE attribute)  :
> >
> > SOFWATE attribute can reveal the specific software version of the TURN
> client and server to eavesdropper and it might possibly allow attacks against
> vulnerable software that is known to contain security holes. If it is important
> to prevent an eavesdropper from learning the software version, TURN can
> be run over (D)TLS.
> 
> The later suggestion was:
> 
> % We want to avoid double encryption of application data, and SOFTWARE
> attribute has
> % been sent in clear text all these years in the field, and no attack has been
> % detected based on SOFTWARE field. I can revise the text as follows:
> % If the software version is known to contain security vulnerabilities, TURN
> SHOULD be % run over (D)TLS to prevent leaking the SOFTWARE attribute in
> clear text.
> 
> I think some of the concern is over the risk of so-called "zero-day"
> exploits, where the attacker knows of a version-specific flaw but the
> defenders do not (and have zero days notice to protect against it).  Such a
> concern would suggest to avoid sending SOFTWARE over enencrypted
> transport regardless of the state of known vulnerabilities, but in the end it is
> a matter of local policy.

Agreed, fixing and releasing a patch will take some time and meanwhile the policy can be modified to use temporarily use (D)TLS.  I can add the following text:
If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS till the patch is in place to fix the flaw.

> 
> 
> >
> > >
> > > > - Section 5: When servers receive data that exceeds an
> > > > allocation’s
> > > > > bandwidth quota, servers silently discard this data. This means
> > > > > there’s no allocation-based flow control mechanism between
> > > > > client and server beyond what’s provided by the transport protocol,
> right?
> > > >
> > > > Yes, UDP does not include a congestion control mechanism.
> > > >
> > > > > This seems fine, though
> > > > > perhaps some discussion of why this design decision was made
> > > > > would be helpful. For example, I could imagine explicit signals
> > > > > from servers to clients that indicate server state would reveal
> > > > > information about other allocations on the server, which might
> > > > > be problematic. -
> > > >
> > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient
> > > > Capacity)
> > > do not reveal information of which other users are using the TURN server.
> > >
> > > At least the latter seems to give some indication that many other
> > > users are using the server at the  time (so that it's overloaded),
> > > though not information about *which* users that is.
> >
> > Yes, similar to 503 HTTP error response.
> >
> > >
> > > > > Section 7.2 suggests that
> > > > > servers can redirect client allocation requests to other servers.
> > > > > Can this create a loop, wherein two TURN servers redirect to one
> another?
> > > >
> > > > The client detect and stop the loop, it is similar to HTTP redirection.
> > >
> > > Where is this specified?
> >
> > It is specified in the last paragraph of
> > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10
> >
> > <snip>
> > If the client has been redirected to a server to which it has already
> > sent this request within the last five minutes, it MUST ignore the
> > redirection and consider the transaction to have failed.  This
> > prevents infinite ping-ponging between servers in case of redirection
> > loops.
> > </snip>
> 
> Thanks for the pointer; as you saw in my ballot position I was quite pressed
> for time this week and only was able to look at the diff.

No problem, thanks for help.

Cheers,
-Tiru

> 
> -Ben