Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Mar 2015 03:06:14 -0600

On 02/24/2015 09:51 PM, Tirumaleswar Reddy (tireddy) wrote:
> The cipher suites and other recommendations in http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-09 must be used and there is no need explicitly mention the subset in section 6.2.4

I read draft-ietf-uta-tls-bcp, and it is clear from its introduction that it is a set of advices for deployments and implementations, not a set of advices for new protocols, so I do not think that this is the right usage.  I added an informative reference and made it clear that the advices in this draft should be followed by implementers and deployers, but I did not change section 6.2.4.

> 
> -Tiru
> 
>> -----Original Message-----
>> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-
>> Huguenin
>> Sent: Wednesday, February 18, 2015 4:17 PM
>> To: [email-masked]
>> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt
>>
> All,
> 
> We have requested 40 minutes in Dallas to discuss the modifications
> summarized below.  We plan to release -02 before the cutoff with minor
> edits for the remaining of the TODO list, but we wanted to release a first
> version with the most important modifications ahead of the meeting.  We
> may not have the time to answer every email before Dallas, but we will
> collect the feedback and address it appropriately during the meeting.
> 
> Thanks.
> 
> Changelog:
> 
>    o  Add negotiation mechanism for new password algorithms.
>    o  Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol.
>    o  Add support for SCTP to solve the fragmentation problem.
>    o  Merge RFC 7350:
>       *  Split the "Sending over..." sections in 3.
>       *  Add DTLS-over-UDP as transport.
>       *  Update the cipher suites and cipher/compression restrictions.
>       *  A stuns uri with an IP address is rejected.
>       *  Replace most of the RFC 3489 compatibility by a reference to
>          the section in RFC 5389.
>       *  Update the STUN Usages list with transport applicability.
>    o  Merge RFC 7064:
>       *  DNS discovery is done from the URI.
>       *  Reorganized the text about default ports.
>    o  Add more C snippets.
>    o  Make clear that the cached RTO is discarded only if there is no
>       new transactions for 10 minutes.
> 
> On 02/17/2015 09:32 AM, [email-masked] wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>>>>  This draft is a work item of the TURN Revised and Modernized Working
> Group of the IETF.
>>>>
>>>>         Title           : Session Traversal Utilities for NAT (STUN)
>>>>         Authors         : Marc Petit-Huguenin
>>>>                           Gonzalo Salgueiro
>>>>                           Jonathan Rosenberg
>>>>                           Dan Wing
>>>>                           Rohan Mahy
>>>>                           Philip Matthews
>>>> 	Filename        : draft-ietf-tram-stunbis-01.txt
>>>> 	Pages           : 57
>>>> 	Date            : 2015-02-17
>>>>
>>>> Abstract:
>>>>    Session Traversal Utilities for NAT (STUN) is a protocol that serves
>>>>    as a tool for other protocols in dealing with Network Address
>>>>    Translator (NAT) traversal.  It can be used by an endpoint to
>>>>    determine the IP address and port allocated to it by a NAT.  It can
>>>>    also be used to check connectivity between two endpoints, and as a
>>>>    keep-alive protocol to maintain NAT bindings.  STUN works with many
>>>>    existing NATs, and does not require any special behavior from them.
>>>>
>>>>    STUN is not a NAT traversal solution by itself.  Rather, it is a tool
>>>>    to be used in the context of a NAT traversal solution.
>>>>
>>>>    This document obsoletes RFC 5389.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Mar 2015 03:14:03 -0600

On 02/26/2015 09:56 AM, Oleg Moskalenko wrote:
> On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> 
>>> There is a well-defined association between the hash length and the
>>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384
>>> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the
>>> MESSAGE-INTEGRITY length to determine the algorithm that the peer is
>>> using ?
>>
>> Does not work with SHA-3.
>>
> 
> If there is a requirement to support wide multiplicity of algorithms,
> even SHA-3, then I see two clear choices:
> 
> 1) Leave the algorithm negotiation to the out-of-bound communication
> channel between the client and the server. They can negotiate what
> kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to
> be.
> 2) Implement a usual negotiation scheme, like in TLS. We can introduce
> a new attribute that contains "algorithm ID" and optionally "algorithm
> attribute(s)" (specific to algorithm). The client sends a number of
> supported algorithm attributes to the server, server either rejects or
> picks one and sends back authenticated response with the chosen
> algorithm attribute. If no attribute is included in the client or
> server message, that means default "SHA-1, 160 bits". If a variable
> length hash algorithm chosen, then that's fine, the message recipient
> will just use the MESSAGE-INTEGRITY attribute length (given they
> already agree on a particular algorithm).
> 
> I'd vote for the second approach. That way, we introduce no extra
> round trips, we cover multiple algorithms (including the future ones),
> and we have full backward compatibility.

We do not vote here.  You will have to build a consensus for your solution of choice, and as co-editor I will modify the draft to follow this consensus.

As an individual, I support neither of the solutions you proposed for the following reasons:

- - HMAC-SHA is not broken but going to HMAC-SHA256 is a cautious step I (reluctantly) agree with.
- - Negotiation is more often used to decrease security than to increase it so let's not unless we have no choice (as for the password hash, that is broken).
- - Adding negotiation means that short-term authentication may get an additional round-trip for each ICE's connectivity check.
- - The solution proposed in the draft follows what the authors of RFC 5389 suggested in section 16.3.

- -- 
Marc Petit-Huguenin

---

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Mar 2015 14:25:31 -0700

On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> We do not vote here.  You will have to build a consensus for your solution
> of choice, and as co-editor I will modify the draft to follow this
> consensus.
>
> - - Negotiation is more often used to decrease security than to increase
> it so let's not unless we have no choice (as for the password hash, that is
> broken).
> - - Adding negotiation means that short-term authentication may get an
> additional round-trip for each ICE's connectivity check.
MESSAGE-INTEGRITY is not a critical part of the overall application
security. +1 to keeping it simple.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 Mar 2015 18:19:29 -0700

I agree with Justin&Marc. Negotiation is too much.

It might be nice to signal a preference for sha256, to allow dropping the
sha1. maybe in a=ice-options (once we dispense with aggressive nomination
perhaps). But the extra bytes aren't going to hurt that much.
On Mar 12, 2015 2:26 PM, "Justin Uberti" <[email-masked]> wrote:

>> We do not vote here.  You will have to build a consensus for your
>> solution of choice, and as co-editor I will modify the draft to follow this
>> consensus.
>>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Brandon Williams <[email-masked]>
Date: Mon, 16 Mar 2015 11:53:48 -0400

+1 for keeping it simple

In the TURN context, can the client's inclusion of MI2 be treated as a 
preference? IOW, SHOULD|MUST the server respond with MI2 if the client 
sent it?

On a related note, the current section 15.3 text indicates that the 
client will always send both MI and MI2 in its requests and indications. 
Is it OK for the client to stop sending both for a specific session 
after the first response from the server, which will contain only one or 
the other?

With the lack of explicit negotiation, I think either stunbis or 3rd 
party auth needs to define what the OAuth server and client should do to 
support transition to SHA256. I think it's probably as simple as:
* OAuth server produces a key big enough for SHA256
* client always produces both MI and MI2, using the standard mechanism 
to reduce the SHA256 key for use in SHA1.
* the relay server picks MI or MI2 as it normally would.

Alternatively, the 3rd party auth draft could simply require that all 
three parties support SHA256 and require the client to only send MI2. 
That would be simpler, but would not allow SHA1 for clients/servers that 
wish to use it, so I think it can probably be ruled out.

--Brandon

On 03/14/2015 09:19 PM, Martin Thomson wrote:
> It might be nice to signal a preference for sha256, to allow dropping
> the sha1. maybe in a=ice-options (once we dispense with aggressive
> nomination perhaps). But the extra bytes aren't going to hurt that much.
>
> On Mar 12, 2015 2:26 PM, "Justin Uberti" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>          > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >
>         We do not vote here.  You will have to build a consensus for
>         your solution of choice, and as co-editor I will modify the
>         draft to follow this consensus.
>
>         - - HMAC-SHA is not broken but going to HMAC-SHA256 is a
>         cautious step I (reluctantly) agree with.
>         - - Negotiation is more often used to decrease security than to
>         increase it so let's not unless we have no choice (as for the
>         password hash, that is broken).
>         - - Adding negotiation means that short-term authentication may
>         get an additional round-trip for each ICE's connectivity check.
>     [email-masked] <mailto:[email-masked]>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Mar 2015 13:38:07 -0400

> preference? IOW, SHOULD|MUST the server respond with MI2 if the client

I think it should be a MUST on both ends. The client MUST send MI2, and
the server MUST send MI2 if the client sent it.

> after the first response from the server, which will contain only one or

Maybe this could be tied to the NONCE attribute. Initially you send
both, discover what the server supports, and get a nonce. As long as
you're using that nonce, you can use just MI or MI2 (depending on what
the server supports). When the nonce expires you need to send both to
re-discover what the server supports (in case it changed), and then you
can go back to sending just one.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Mar 2015 02:05:22 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Monday, March 16, 2015 11:08 PM
> To: Brandon Williams; Martin Thomson; Justin Uberti
> Cc: Marc Petit-Huguenin; Oleg Moskalenko; [email-masked]

The algorithm support can be conveyed in SDP, so the client can pick MI1 or MI2.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Mar 2015 02:12:46 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Monday, March 16, 2015 9:24 PM
> To: Martin Thomson; Justin Uberti
> preference? IOW, SHOULD|MUST the server respond with MI2 if the client sent
> it ?

Why can't the TURN server send the algorithms it supports along with the 401 error response and the client picks one of the algorithms it supports (with higher preference for MI2) ?

-Tiru

> 
> On a related note, the current section 15.3 text indicates that the client will
> always send both MI and MI2 in its requests and indications.
> Is it OK for the client to stop sending both for a specific session after the first
> response from the server, which will contain only one or the other?
> 
> With the lack of explicit negotiation, I think either stunbis or 3rd party auth
> needs to define what the OAuth server and client should do to support transition
> to SHA256. I think it's probably as simple as:
> * client always produces both MI and MI2, using the standard mechanism to
> reduce the SHA256 key for use in SHA1.
> Alternatively, the 3rd party auth draft could simply require that all three parties
> support SHA256 and require the client to only send MI2.
> That would be simpler, but would not allow SHA1 for clients/servers that wish to
> use it, so I think it can probably be ruled out.
> 
> --Brandon
> 
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 17 Mar 2015 09:06:46 -0400

> The algorithm support can be conveyed in SDP, so the client can pick MI1 or MI2.

Any particular reason why adding such complexity would be necessary?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 17 Mar 2015 09:16:02 -0400

Le 2015-03-16 22:12, Tirumaleswar Reddy (tireddy) a écrit :
> Why can't the TURN server send the algorithms it supports along with
> the 401 error response and the client picks one of the algorithms it
> supports (with higher preference for MI2) ?

Two reasons:

- This would leave us open to a downgrade attack. Unauthenticated
information about the server not supporting MI2 cannot be trusted by the
client.

- There's no reason to have any kind of "preference". If the server
supports MI2, the client MUST use MI2. (Well I guess you could call that
"preference", but we need to be clear.)

Simon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 17 Mar 2015 09:25:30 -0400

> Why can't the TURN server send the algorithms it supports along with the 401 error response and the client picks one of the algorithms it supports (with higher preference for MI2) ?

If the server understands MI2, then it must by definition support 
SHA256. It's not a question of whether it supports SHA256, but rather of 
whether it should follow the client's preference. If the client prefers 
not to use SHA256, it just won't send MI2.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Mar 2015 14:50:52 +0000

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2015 6:46 PM
> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Martin Thomson; Justin
> Uberti
> - This would leave us open to a downgrade attack. Unauthenticated information
> about the server not supporting MI2 cannot be trusted by the client.

Client signals back the algorithms received from the server. Server checks the algorithms conveyed by the client matches the set it had initially sent to detect algorithm downgrade attack.

> 
> - There's no reason to have any kind of "preference". If the server supports MI2,
> the client MUST use MI2. (Well I guess you could call that "preference", but we
> need to be clear.)

Agreed.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Mar 2015 14:59:32 +0000

> Sent: Tuesday, March 17, 2015 6:37 PM
> >>> In the TURN context, can the client's inclusion of MI2 be treated as
> >>> a preference? IOW, SHOULD|MUST the server respond with MI2 if the
> >>> client sent it?
> >>
> >> I think it should be a MUST on both ends. The client MUST send MI2,
> >> and the server MUST send MI2 if the client sent it.
> >
> Any particular reason why adding such complexity would be necessary ?

It is not complex compared to the client and server logic to deal with both MI1 and M12 for every message, handling error cases like validation of MI1 succeeds but MI2 fails or vice-versa etc.

-Tiru

---

From: Simon Perreault <[email-masked]>
Date: Tue, 17 Mar 2015 11:19:11 -0400

> Client signals back the algorithms received from the server. Server checks the algorithms conveyed by the client matches the set it had initially sent to detect algorithm downgrade attack.

Not backwards compatible with current TURN clients.

In summary, I think there are three possibilities:

a) We accept downgrade attacks as a fact of life. Use whatever works.

b) We give up backwards compatibility and always use MI2 without
fallback to MI.

c) We signal support for MI2 in a separate channel (e.g., SDP).

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Mar 2015 16:15:37 +0000

> Sent: Tuesday, March 17, 2015 8:49 PM
> > Client signals back the algorithms received from the server. Server checks the
> algorithms conveyed by the client matches the set it had initially sent to detect
> algorithm downgrade attack.
> 

MIM device can cause downgrade attack even by removing MI2 and thus force the client/server to use MI1. Downgrade attacks can be mitigated either using (D)TLS or option c).

-Tiru

> 
> b) We give up backwards compatibility and always use MI2 without fallback to
> MI.
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 17 Mar 2015 12:21:24 -0400

> MIM device can cause downgrade attack even by removing MI2 and thus force the client/server to use MI1. Downgrade attacks can be mitigated either using (D)TLS or option c).

I know what you mean, but just to be clear:

- Option b) implies that that the server refuses to process requests
without MI2 so there can't be a downgrade attack.

- Option c) gives SDP as an example, but DTLS would also be considered a
"separate channel".

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 17 Mar 2015 16:26:16 +0000

> Sent: Tuesday, March 17, 2015 9:51 PM
> > MIM device can cause downgrade attack even by removing MI2 and thus force
> the client/server to use MI1. Downgrade attacks can be mitigated either using
> (D)TLS or option c).
> 
> - Option b) implies that that the server refuses to process requests without MI2
> so there can't be a downgrade attack.
> 

Yes, We are in agreement.

-Tiru