Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for TURN

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Oct 2009 18:13:03 +0200

Hi,

We ADs has discussed the deployment case where you deploy the TURN
server on the border between a private domain and the Internet. And
because of the clients being controlled and required to be coming from
that private domain an per client authentication is not required for
using the TURN server.

We note that this may fulfill the security requirements. However, the
current draft is substantially lacking in description of the details
that are needed to handle this case. Both how you reliably determine
that a client really is connecting from the trusted domain and how you
ensure that the client know if it needs to use the authentication
mechanism or not.

I personally don't think documenting this model can be done quickly. I
would note that TURN can be extended in various ways, that include
adding additional security models. So starting work on a separate
document for this solution sounds like a possible way forward.

TURN has been under development under a long time. It is time we publish
TURN. I do note that TURN drafts currently are hold up the following
documents from being published:

C3  AUTH48      draft-ietf-sipping-app-interaction-framework
C3  AUTH48      draft-ietf-sipping-gruu-reg-event
C3  MISSREF     draft-ietf-sipping-v6-transition
C3  AUTH48      draft-ietf-sip-gruu
C3  MISSREF     draft-ietf-mmusic-ice
C3  AUTH48      draft-shacham-sipping-session-mobility
C3  MISSREF*    draft-ietf-sip-ice-option-tag
C3  REF         draft-ietf-behave-stun-test-vectors
C3  AUTH48      draft-ietf-sip-sips
C3  MISSREF     draft-ietf-sip-ua-privacy
C3  AUTH48      draft-ietf-sip-outbound
C3  AUTH48      draft-ietf-sip-record-route-fix

I will give the proponents for the above describe security solution time
to answer. Then I intended to push forward to get TURN approved.

Regards

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 01 Oct 2009 09:26:16 -0700

Magnus Westerlund wrote:
> ...
Due to the still-unaddressed issues raised by the addition of 
"CreatePermission required for each destination address" some number of 
drafts ago, TURN is not really suitable for my particular 
widely-distributed application any more anyway, so failing to address 
the TURN-server-at-border case won't be the reason TURN support is 
removed in favor of an alternative protocol.

I had hoped that TURN would be the UDP-UDP proxy protocol of choice for 
a wide variety of UDP-based protocols, but it has unfortunately narrowed 
in capability so much that it will no longer work for me, so there will 
be at least one more UDP-UDP proxy protocol deployed in the world in 
order to meet my requirements.

Matthew Kaufman

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Oct 2009 18:47:06 +0200

> removed in favor of an alternative protocol.

I think the addition of CreatePermission for each destination is the
result of WG consensus.

> order to meet my requirements.

For me it appears that the security requirements we have on the protocol
prevents it from being applicable to all possible use cases for an UDP
relay protocol.

Cheers

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Thu, 1 Oct 2009 12:53:39 -0400

> ensure that the client know if it needs to use the authentication

Why must this use case be explained in detail? Is there a rule somewhere that 
says "each and every "SHOULD" in a document MUST include a complete discussion 
of the possible use cases for not complying"? If so, then a bunch of RFCs will 
need to be revised...

Just s/MUST/SHOULD/ and be done with it.

The Security Considerations section, in particular section 17.1.1, already 
explain the full implications. People are not stupid. It is plain as day that 
a TURN server offers a service, and authentication is a good idea if you don't 
want people abusing the service.

I don't think having a MUST instead of a SHOULD will impact in any way the 
trust that people will have in this protocol.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Oct 2009 19:17:42 +0200

> trust that people will have in this protocol.

The reason in this case is that it has a huge impact on the security
properties of the protocol. The SHOULD is only applicable if you have an
alternative solution that meets the security requirements. And that is
what we now are proposing.

Especially as we don't seem to have a good mechanism to know where a
TURN server is located and if you can trust it if not using
authentication or not.

Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 01 Oct 2009 10:33:25 -0700

Simon Perreault wrote:
> of the possible use cases for not complying"?

Yes, for security. RFC 2119 is clear on that:

"[RFC 2129] terms are frequently used to specify behavior with security
implications.  The effects on security of not implementing a MUST or SHOULD, or
doing something the specification says MUST NOT or SHOULD NOT be done may be
very subtle. Document authors should take the time to elaborate the security
implications of not following recommendations or requirements as most
implementors will not have had the benefit of the experience and discussion that
produced the specification."

> If so, then a bunch of RFCs will
> need to be revised...
> 

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Simon Perreault <[email-masked]>
Date: Thu, 1 Oct 2009 13:41:49 -0400

On Thursday 01 October 2009 13:33:25 Marc Petit-Huguenin wrote:
> implications.  The effects on security of not implementing a MUST or
> SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be
> done may be very subtle. Document authors should take the time to elaborate
> the security implications of not following recommendations or requirements
> as most implementors will not have had the benefit of the experience and
> discussion that produced the specification."

As I said, this is already fulfilled by section 17.1.1.

What seems to be required by IESG is discussion of one use case for not 
complying with the SHOULD. I think that's not necessary.

Simon

---

From: "Polk, William T." <[email-masked]>
Date: Thu, 8 Oct 2009 12:55:39 -0400

Simon,

As I understand it, the wg is comfortable with deployments that do not require authentication *only* because that TURN server can be protected using filtering on specific interfaces given specific networks architectures, in combination with tightly controlled (usually static) client configuration.   The set of attributes that must be in place for this to be a safe configuration is rather complicated, and I have my doubts about such deployments being fully realized in practice, especially since the document that list of attributes has been documented in various emails, but does not appear in the document.

To be clear, section 4 currently states:

                                                                                                  One reason that a server might not
      require requests to be authenticated is that TURN is being used in
      a carefully controlled environment in which the risks of
      unauthenticated requests by hostile third-parties have been
      mitigated.  See Section 17 for more discussion on this point.

If the wg has consensus that such deployments should be permitted, so be it.  However, it is essential that the document clearly convey the deployment criteria that need to be met for such a deployment.  That is, we need a clear statement of that "carefully controlled environment", and I can't find it in section 17.

Thanks,

Tim

On 10/1/09 1:41 PM, "Simon Perreault" <[email-masked]> wrote:

Simon

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Oct 2009 19:33:20 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Thursday, October 01, 2009 9:54 AM
> To: [email-masked]
> Cc: Tim Polk; Peter Livesey; Marc Blanchet
> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for
> TURN
> 

Perhaps a conditional MUST would be better than a SHOULD.
For example:

   Unless the server can reliably determine that a client
   is connecting from a trusted network, the server MUST demand 
   that all requests from the client be authenticated using this 
   mechanism, or that a equally strong or stronger mechanism for 
   client authentication is used.  Mechanisms for reliably 
   determining that a client is connecting from a trusted network
   are outside the scope of this document.
   
-Dave

---

From: Simon Perreault <[email-masked]>
Date: Thu, 8 Oct 2009 15:39:32 -0400

>    are outside the scope of this document.

+1, especially the latter part. This is not a simple topic, and should be out 
of scope for TURN. It would apply equally to many other protocols.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 08 Oct 2009 13:30:03 -0700

>    are outside the scope of this document.

+1

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2009 15:22:48 +0200

>>    are outside the scope of this document.

Good, I think we can go forward with that.

I have added an RFC-editor note:

Section 4, paragraph 3 (Page 20-21):

OLD:
[RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server SHOULD
   demand that all requests from the client be authenticated using this
   mechanism, and the client MUST be prepared to authenticate requests
   if required.

      In general, it is strongly recommended that servers require
      requests to be authenticated, as the security of TURN can
      otherwise be quite weak.  One reason that a server might not
      require requests to be authenticated is that TURN is being used in
      a carefully controlled environment in which the risks of
      unauthenticated requests by hostile third-parties have been
      mitigated.  See Section 17 for more discussion on this point.

NEW:

   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  Unless the server
   can reliably determine that a client is connecting from a trusted
   network, the server MUST demand that all requests from the client be
   authenticated using this mechanism, or that a equally strong or
   stronger mechanism for client authentication is used.  Mechanisms for
   reliably determining that a client is connecting from a trusted
   network are outside the scope of this document.

   [remove note]

I think this implements Dave's proposal in the document. If you see some
issues with only doing changes here please indicate so ASAP.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2009 10:34:25 +0200

Hi,

I have had more discussion with Cullen and Tim about this. To get TURN
done I have added the following RFC-editor note that requires TURN to
use a authentication mechanism. The proponents for the trusted network
is going to need to write up the solution in a separate document that
updates the TURN spec. This as we ADs thinks this cannot be done quickly
and actually requires some substantial additions to the document. Please
note that we are not against such work. Only that it not hold up the
publication.

Thus we need to move forward with what there is agreement on between the
WG and the ADs. With the below RFC-editor note, this document can be
approved, as both Tim and Cullen has cleared.

Any suggestions for correction to the note that implements the must use
authentication are welcome ASAP.

Note to RFC Editor

Section 2.2, first paragraph:

OLD:

   To create an allocation on the server, the client uses an Allocate
   transaction.  The client sends a Allocate request to the server, and
   the server replies with an Allocate success response containing the
   allocated relayed transport address.  The client can include
   attributes in the Allocate request that describe the type of
   allocation it desires (e.g., the lifetime of the allocation).  Since
   relaying data may require lots of bandwidth, the server typically
   requires that the client authenticate itself using STUN's long-term
   credential mechanism, to show that it is authorized to use the
   server.

NEW:

   To create an allocation on the server, the client uses an Allocate
   transaction.  The client sends a Allocate request to the server, and
   the server replies with an Allocate success response containing the
   allocated relayed transport address.  The client can include
   attributes in the Allocate request that describe the type of
   allocation it desires (e.g., the lifetime of the allocation). Since
   relaying data has security implications, the server requires that the
   client authenticate itself, typically using STUN's long-term
   credential mechanism, to show that it is authorized to use the
   server.

OLD:

NEW:

   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server MUST
   demand that all requests from the client be authenticated using this
   mechanism, or that a equally strong or stronger mechanism for client
   authentication is used.

   [remove paragrap]

Section 6.2, First bullet point in paragraph 2:

OLD:

1.  The server SHOULD require that the request be authenticated using
       the Long-Term Credential mechanism of [RFC5389].

NEW:

1.  The server MUST require that the request be authenticated. Using
       the Long-Term Credential mechanism of [RFC5389] unless another
       mechanism is signaled.

Section 16, Third paragraph:

OLD:

   The server follows the recommended practice in this specification of
   requiring all requests to be authenticated.  Thus when the server
   receives the initial Allocate request, it rejects the request because
   the request does not contain the authentication attributes.
   Following the procedures of the Long-Term Credential Mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.

NEW:

   Servers requires any request to be authenticated. Thus when the
   server receives the initial Allocate request, it rejects the request
   because the request does not contain the authentication attributes.
   Following the procedures of the Long-Term Credential Mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.

Section 17, second paragraph:

OLD:

   Note: Most of the attacks on TURN are mitigated by the server
   requiring requests be authenticated using the Long-Term Credential
   mechanism of STUN.  Thus it is strongly recommended that servers
   demand that requests be authenticated.  However, in certain
   deployments, the use of this mechanism may be unnecessary.  An
   example might be a deployment where access to the TURN server is
   available only through a network where their are fairly tight
   controls over what devices can connect to the network (and by whom)
   and what software these devices can use.  Tightly-run corporate
   networks can arguably fall into this category.

NEW:

   Most of the attacks on TURN are mitigated by the server
   requiring requests be authenticated. Thus this specification requires
   the use of authentication. The mandatory to implement mechanism is the

   Long-Term Credential mechanism of STUN. Other authentication
   mechanisms of equal or stronger security properties may be used.
   However, it is important to ensure that they can be invoked in an
   inter-operable way.

Best Regards

Magnus

Magnus Westerlund skrev:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
> 

-- 

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 Oct 2009 07:59:39 -0400

On Friday 16 October 2009 04:34:25 Magnus Westerlund wrote:
> use a authentication mechanism.

If I understand this clearly, Dave's suggestion, which clearly got WG 
consensus, is reversed in favour of IESG's previous position? Did I miss 
anything?

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Oct 2009 15:37:43 +0200

> consensus, is reversed in favour of IESG's previous position? Did I miss 

What happened was another round of me discussing this topic with Tim and
Cullen. That made me realize a few things. Maybe I should have explained
better in my previous email about the reversal.

Dave's proposal got support from the proponents of the border deployment
scenario. There was no one else really providing input. Thus, I wouldn't
call it WG consensus. Especially as there has been strong views on this
prior in the WG. Cullen claims this discussion simply has worn out all
the one that thinks authentication is needed. Especially in regards that
BEHAVE has moved onto new topics. I think there is a clear point to
this. Thus, we would need to gather a forum where this can be discussed
and actually achieve consensus.

Secondly, Tim was not that happy with the proposed text unless the
border deployment was more substantiated in the document. Cullen
requires a spec that is sufficient to implement the border deployment
with all its issues. I agree that there are issues in this deployment
that needs to be worked out. Thus, border deployment scenario needs
description.

We have discussed this document for several months since the last
update. We are not making progress. TURN now blocks 10+ documents from
being published as RFCs. It was time for me to use the decision power I
have been given.

As a result of the above I mad a decision that gets TURN published. I
will also support BEHAVE taking on a new WG document that describes how
you can deploy TURN on the border and because of that can configure
authentication mechanism differently. Thus I am not preventing the
proponents for the border deployment scenario to get what they want,
only that we do it without blocking TURN from publication for usage in
other scenarios.

Best Regards

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 Oct 2009 10:41:47 -0400

Magnus,

Thanks for the explanation. I honestly wasn't sure if I was reading the 
changed text properly. It seemed to me that Dave's suggestion had made 
everyone happy. Oh well... There is a time for discussion, and there is a time 
for publishing stuff. Now is time for publishing stuff.

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Oct 2009 09:36:51 +0200

> for publishing stuff. Now is time for publishing stuff.

I am sorry that Cullen hasn't taken the time expressing his comments on
the list, and that discussion mostly happened on phone conferences
within the IESG.

Cheers

Magnus Westerlund