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

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 01 Apr 2015 06:47:22 -0600

On 03/31/2015 01:43 PM, Justin Uberti wrote:
> Especially for short-term auth, do we need to send the entire 256-bit MAC?
> I am concerned that some implementations will be slow to switch to stun-bis
> because of the increased size (and thereby bandwidth) needed for
> connectivity checks.
> 
> Would it make sense to allow use of a truncated SHA-256 MAC (e.g. 80 bits
> or less), similar to how this is done in SRTP?

Per my calculations, worst case (Binding response with an IPv4 address family) for using MESSAGE-INTEGRITY-SHA256 instead of MESSAGE-INTEGRITY is a 20% increase in size.

> 
> On Tue, Mar 31, 2015 at 5:42 AM, Marc Petit-Huguenin <[email-masked]>
> wrote:
> 
> Changelog:
> 
> o  Remove SCTP.
> o  Remove DANE.
> o  s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
> o  Remove Salted SHA256 password hash.
> o  The RTO delay between transactions is removed.
> o  Make clear that reusing NONCE will trigger a wasted round trip.
> 
> Remaining TODO list:
> 
> 1.  Add reference to RFC 5769 (stun vectors).
> 2.  Add flow diagram for long-term authentication.
> 3.  Add vectors for SHA256 password hash.
> 
> On 03/27/2015 01:55 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-04.txt
>>>>       Pages           : 55
>>>>       Date            : 2015-03-27
>>>>
>>>> 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-04
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-04
>>>>
>>>>
>>>> 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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 1 Apr 2015 13:40:18 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-
> Huguenin
> Sent: Wednesday, April 01, 2015 6:17 PM
> To: Justin Uberti
> Cc: [email-masked]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-04.txt
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> > or less), similar to how this is done in SRTP ?

In practice the maximum truncation for HMAC-SHA2 is 128-bit as discussed in https://tools.ietf.org/html/rfc4868#section-2.6; DTLS-SRTP http://tools.ietf.org/html/rfc5764#section-4.1.2 discusses 80 bit of authentication tag but only for HMAC-SH1.

-Tiru

> 
> Per my calculations, worst case (Binding response with an IPv4 address
> family) for using MESSAGE-INTEGRITY-SHA256 instead of MESSAGE-
> INTEGRITY is a 20% increase in size.
> 
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJVG+jaAAoJECnERZXWan7EVZEP/1rUib4L8Mtg+H+S7+s6kGR
> k
> ZIw+VX2GRig2ITNS7BuPowGxxrCpZoXSPtY6qCGYDEBFlFaLrQ3Tq3XG9ZkOTnnl
> bRXnz/sAZYR2qKzloW+n4ektevgAaO97Tz6KeL0A+Dnl+8Qw5tKejcvxIyR2g5R2
> uhwMB6h7wj3VN1IdndgufDwTQlUxYs4/MHUXCYjETP6gjv+tePHYNd2xvupqU8
> mo
> m1q9X+xMFwWK4H2Saa87a7sB2wTa2wYpRefNFZaLpXF30DORiEPQs7kCAGTPT
> Ay/
> USgfUXO55VJfcSTGKHmBrDlBCwJmPWUIQTQxRU4T4juTMNjD/hLOYDdlwI5C/N
> Nf
> 7iXPczXES0brVwkeMLHpsdF6lnkWpB6D+ZQ+EpGbRaJaJl6Sa5M3a4MLwh0QKy
> dl
> BupZpnLfOVsrcbRTvvbOmGOPLMVH2vJUqxCMfPytqiP8DY1/9b2FxX5cTSbGWK
> qG
> yVOtYBXx01vpeStj/zXRJji6krCec6qEl+bXrtuqfaF4WAl4sQaw6Qt073wIrSg1
> wT3Xr43OxLnwfQmZsuP0Fkp3Oy7INsMEZD9FHAwDl3AmGi5zDnt4pS4HxI64hl8
> 0
> K5CCKG+ijVfCXhJtVD85nHAjNrtNMmZn/fjUw6ptyz2JaDPTw7VoEvYMWA+zujN
> V
> EmjFDIedX3BMETmhtXLK
> =RNXa
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 1 Apr 2015 16:52:10 +0000

For the long-term credential mechanism it's not clear how the client determines to pick MI or MI2. I thought the server in 401 error response conveys that it supports MI or MI2 or both and the client picks one of the algorithms supported by the server for message integrity of subsequent requests. 

-Tiru

> Sent: Tuesday, March 31, 2015 6:12 PM
> To: [email-masked]
> > submission until the htmlized version and diff are available at
> tools.ietf.org.
> >
> iQIcBAEBCAAGBQJVGpYgAAoJECnERZXWan7EQxUQAJb3cerMgz+k34+9ms3eX
> wVd
> vaLxOY4jla7j9Gf4O9Xmyd0wKo3VgG9xnfeil95Y/hBMkoIgiwC1iRMEJT0hH9jO
> fe4ekjjuO81wuPyiGOJA7CvsM+dKqc9Y3v+KE43SbYkgoFS12U2m/+0u+emdT4lJ
> olbAnJhl3s6+XCH1HqaSd1S7LGl3f2y1eHPLxkvpLQXZFyHZYJo1JNt0yKR/UZWu
> JJauXVMMqlVMjauAiY7eWOlNOpM15a7+YZ7ShED/eTForBwWyOMfcqZ+kk1at
> 8Fi
> b4XfN+bHOvotoxgJ9myZZvlkMZwmne/XGLkr9HIQgJGMYlbattLpAEoaDApBnxK
> x
> HYQhl9VECis4TGxUWPSvHgoIP6tHxpomSJ1eD0XDzqqad1ZWqK8OsTy8NZdLgK
> 1n
> H0xaz5QVPaB8k2uVvcmGwzKdsIfUbkFQudTjV8FuuSobsh7QeLL50o8oFdABW/
> 1g
> 201Z7aPmYsseti4JGKpCO5j9VNxjNTxbB3XaAketkRA8afHAUuR8JMFUFLi4Rinv
> MJLaOaKciFfWrBo1FqqoGCqoy7dC8+UN3LFx6Nn9ygpNZt/n8cVNVniRk4hYkbi0
> XOmIzvWtLURupJSr/Wo29K0gsmKJq2MWOK5TFxEyer9i0fArH5W7H8ueirtvWw
> gc
> vH8+lFtAOQSjokR/eUhT
> =/KmB

---

From: Justin Uberti <[email-masked]>
Date: Wed, 1 Apr 2015 12:58:24 -0700

20% seems like a nontrivial increase given that we aren't adding any new
functionality.

Truncating to 128-bit (16 bytes) would at least prevent any blowup over the
existing M-I attribute.

On Wed, Apr 1, 2015 at 5:47 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> family) for using MESSAGE-INTEGRITY-SHA256 instead of MESSAGE-INTEGRITY is
> a 20% increase in size.
>
> >
> iQIcBAEBCAAGBQJVG+jaAAoJECnERZXWan7EVZEP/1rUib4L8Mtg+H+S7+s6kGRk
> uhwMB6h7wj3VN1IdndgufDwTQlUxYs4/MHUXCYjETP6gjv+tePHYNd2xvupqU8mo
> m1q9X+xMFwWK4H2Saa87a7sB2wTa2wYpRefNFZaLpXF30DORiEPQs7kCAGTPTAy/
> USgfUXO55VJfcSTGKHmBrDlBCwJmPWUIQTQxRU4T4juTMNjD/hLOYDdlwI5C/NNf
> 7iXPczXES0brVwkeMLHpsdF6lnkWpB6D+ZQ+EpGbRaJaJl6Sa5M3a4MLwh0QKydl
> BupZpnLfOVsrcbRTvvbOmGOPLMVH2vJUqxCMfPytqiP8DY1/9b2FxX5cTSbGWKqG
> wT3Xr43OxLnwfQmZsuP0Fkp3Oy7INsMEZD9FHAwDl3AmGi5zDnt4pS4HxI64hl80
> K5CCKG+ijVfCXhJtVD85nHAjNrtNMmZn/fjUw6ptyz2JaDPTw7VoEvYMWA+zujNV
> EmjFDIedX3BMETmhtXLK
> =RNXa

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 01 Apr 2015 14:02:50 -0600

> For the long-term credential mechanism it's not clear how the client determines to pick MI or MI2. I thought the server in 401 error response conveys that it supports MI or MI2 or both and the clie…

That's negotiation, and we do not do negotiation for the HMAC.

A stunbis client sends both MI and MI256 (fka MI2), in that order.  A stunbis server responds with MI256, RFC 5389 servers responds with MI.  Subsequent requests uses either MI or MI256 depending on the response.

Since -04 a client may know beforehand that the server supports MI or MI256, in which case it can directly use either of them (that's for short term authentication where a to-be-defined SDP/ICE option may permit to pass this information).

stun-ter will deprecate MI.

- -- 
Marc Petit-Huguenin

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 2 Apr 2015 02:36:04 +0000

> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Thursday, April 02, 2015 1:33 AM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> > For the long-term credential mechanism it's not clear how the client
> determines to pick MI or MI2. I thought the server in 401 error response
> conveys that it supports MI or MI2 or both and the client picks one of the
> algorithms supported by the server for message integrity of subsequent
> requests.
> 

In long-term authentication, server is already sending realm, nonce attributes; so another attribute to tell the client about the algorithms it supports will help the client to choose an algorithm instead of sending both MI and MI256. If in future NNN number of algorithms are supported it avoids NNN MI attributes.

> 
> A stunbis client sends both MI and MI256 (fka MI2), in that order.  A stunbis
> server responds with MI256, RFC 5389 servers responds with MI.
> Subsequent requests uses either MI or MI256 depending on the response.
> 
> Since -04 a client may know beforehand that the server supports MI or
> MI256, in which case it can directly use either of them (that's for short term
> authentication where a to-be-defined SDP/ICE option may permit to pass
> this information).

Yes, but it does not solve the problem for TURN.

-Tiru

> iQIcBAEBCAAGBQJVHE7qAAoJECnERZXWan7EMIwP/R0PnKE4l2dd+3y1w7P7B7
> x0
> S7mHCjkTt7SIFt6oR1DaFY9XxOCdO9L11NvZATfwV1OF3iILnbzI3k3wZpTPbPhX
> onWp0pZpCHZmnPiNbOblMpc9I4Ap6U5TJwh602zSK+YcSI6+997CZ+SCvYRxEdJ
> 4
> uCax+n8hW/Y/0Ywk9ErEh6ewMHGE2khea0poDFiLT8nSpDOAXtjs7A17jS5DQZf
> N
> 9+lFGQ2ftR+fX7+AYKf6JsGEMBcmghMu/xrgmco2mz91R8zHfHT4i1LFhDFKqDG
> U
> QVSL9c6IjsKi69Gu3/udJ50Uq68WcPVISSmVAcxOQg3t+Cp0XHenNJu4uRY3fNTN
> OYD/g6vAssztQ44F1Flm32/FxQKXYxbo32u4eYTeP7S5FrN6CxfVNwhZbFmB0zs6
> VYG2UZz5XcAh2HFqAydTWbgWxzcGBFMgrSAeiJm8olrUH4R/vGcLneF+Y82+B8
> CK
> 9gChEuj5q2pXV/QmaHGJndLkAQeH15Fhtrwwxoc8A5PgYJpYcu3xwWOnSeagXd
> fj
> 6d8C1W9y7lMlowPB7DwQ+heDxxcL5tC+phD8u9M+OIX+KL9iBMqc2RdD4iKSkr
> 8z
> SMQdYcB9QoeirgdztPL/Eb33WDLrlLYO2H8c274kJF79HUGq6jFycy0UH1K2hoXY
> EZzbcx7NEQGnC4y4W2Y5
> =JpUe

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 1 Apr 2015 19:51:15 -0700

That's right, we already have a sort of negotiation for the long-term credentials. It can be used for signaling the server algorithm, in a comprehension - optional attribute. The default will be sha1. That way, we have full backward compatibility and only one integrity token.

Oleg

---

From: Simon Perreault <[email-masked]>
Date: Thu, 02 Apr 2015 08:30:09 -0400

> In long-term authentication, server is already sending realm, nonce attributes; so another attribute to tell the client about the algorithms it supports will help the client to choose an algorithm…

The plan presented in Dallas is to have at most 2 MI attributes. When/if
HMAC-SHA1 gets broken, we will deprecate MI. Then when/if we start
having doubts with HMAC-SHA256, we'll create a third MI. And so on and
so forth. So at most we will have 2 MI attributes in a single message,
not NNN.

I don't see the problem with having 2 MI attributes in Allocation
requests. Also keep in mind it's only for the first request: Refresh
requests will use only one MI attribute. For connectivity checks it is
different but we have that figured out with SDP signalling.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 2 Apr 2015 13:55:15 +0000

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Thursday, April 02, 2015 6:00 PM
> To: Tirumaleswar Reddy (tireddy); Marc Petit-Huguenin; [email-masked]
> >> > determines to pick MI or MI2. I thought the server in 401 error
> >> > response conveys that it supports MI or MI2 or both and the client
> >> > picks one of the algorithms supported by the server for message
> >> > integrity of subsequent requests.
> >> >
> > In long-term authentication, server is already sending realm, nonce
> attributes; so another attribute to tell the client about the algorithms it
> supports will help the client to choose an algorithm instead of sending both
> MI and MI256. If in future NNN number of algorithms are supported it avoids
> NNN MI attributes.
> 
> HMAC-SHA1 gets broken, we will deprecate MI. Then when/if we start having
> doubts with HMAC-SHA256, we'll create a third MI. And so on and so forth.
> So at most we will have 2 MI attributes in a single message, not NNN.

Thanks for the clarification.

> 
> I don't see the problem with having 2 MI attributes in Allocation requests.

It may be problem if the client with multiple interfaces discovers multiple TURN servers on each interface and the client has to send 2MI attributes to each discovered TURN server.
I don't understand How it is better than the approach of server signaling the algorithms it supports to the client ?
Why not add algorithm agility just like other protocols do so that there is no need to add new MI every few years ?
We should consider the guidance given in https://tools.ietf.org/html/draft-iab-crypto-alg-agility-02

> Also keep in mind it's only for the first request: 
> Refresh requests will use
> only one MI attribute. For connectivity checks it is different but we have that
> figured out with SDP signalling.

-Tiru

---

From: Simon Perreault <[email-masked]>
Date: Thu, 02 Apr 2015 10:34:02 -0400

> It may be problem if the client with multiple interfaces discovers multiple TURN servers on each interface and the client has to send 2MI attributes to each discovered TURN server.

Really? We're talking about an extra 24 bytes on one packet per
interface per TURN server. That's much less than what's required for
connectivity checks. And keep in mind that the goal is real-time
audio/video!

> I don't understand How it is better than the approach of server signaling the algorithms it supports to the client ?

My understanding from discussions is that negotiation is neither
necessary nor desirable. We don't want to end up in the same situation
as TLS. I see avoiding negotiation as the major reason why this approach
is being proposed.

> We should consider the guidance given in https://tools.ietf.org/html/draft-iab-crypto-alg-agility-02

Adding a new MI attribute *is* agility. The alternative is adding a new
negotiation-sub-attribute every few years. Doesn't change anything
fundamentally.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 2 Apr 2015 15:12:02 +0000

> Sent: Thursday, April 02, 2015 8:04 PM
> > It may be problem if the client with multiple interfaces discovers multiple
> TURN servers on each interface and the client has to send 2MI attributes to
> each discovered TURN server.
> 
> Really? We're talking about an extra 24 bytes on one packet per interface
> per TURN server. That's much less than what's required for connectivity
> checks. And keep in mind that the goal is real-time audio/video!

Yes, but why not avoid this overhead ?

> 
> > I don't understand How it is better than the approach of server signaling
> the algorithms it supports to the client ?
> 
> My understanding from discussions is that negotiation is neither necessary
> nor desirable. We don't want to end up in the same situation as TLS. I see
> avoiding negotiation as the major reason why this approach is being
> proposed.

What is the problem with negotiation ?

> > We should consider the guidance given in
> > https://tools.ietf.org/html/draft-iab-crypto-alg-agility-02
> 

An approach where server signals algorithm ID it supports (HMAC algorithm ID are defined by IANA https://tools.ietf.org/html/rfc4868#section-4) and the client picks one of them it supports; conveys the algorithm it selected in the new MI2 attribute solves the problem. In this approach there is no need to add new MI attribute or new attributes for hash agility.
We used similar approach for PCP authentication https://tools.ietf.org/html/draft-ietf-pcp-authentication-07#section-5.8

-Tiru

---

From: Brandon Williams <[email-masked]>
Date: Thu, 02 Apr 2015 14:02:34 -0400

Considering the fact that the current draft calls for negotiation of the 
key derivation function, which seems a little unusual to me, I'm having 
trouble understanding why the WG is opposed to hash algorithm 
negotiation, which is more typical and could easily be folded into the 
existing KDF negotiation mechanism. That said, the current KDF 
negotiation only applies to the long-term credential method, not 
short-term, so maybe that answers my question. On the other hand, 
negotiation would be present for short-term credentials, I think, it 
would just be assumed to be out of band.

Also, in my opinion, the currently defined method _is_ a negotiation 
mechansim. The client offers two options, the server picks one, and 
that's what's used for the rest of the session. I think the negotiation 
needs to be made a little more reliable, but I don't object to this 
being the method of choice.

At the meeting, I didn't fully understand the argument that adding a new 
HMAC algorithm identifier to a registry would be just as much work 
adding a new MI attribute. It doesn't seem that updating a registry 
should require as much overhead as publishing a draft to add a new 
attribute. Am I missing something about that? Or was the argument that 
the implementation overhead would be roughly equal?

--Brandon

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 02 Apr 2015 14:27:47 -0400

Le 2015-04-02 14:02, Brandon Williams a écrit :
> that's what's used for the rest of the session.

Yes and no. I see it as a backwards-compatibility mechanism. If you
support MI2, then you use MI2. You have no choice. In my understanding,
egotiation implies choice and configurability. For example on a TLS
server or client you configure the crypto suites you are willing to use
and their priorities for negotiation. I would prefer not having to
configure this sort of thing in STUN.

> attribute.

It depends. The registration rules for the STUN attributes registry are
either "IETF Review" or "Designated Expert". In theory we could create a
new HMAC algorithm identifier registry with a bar lower than "Designated
Expert". The question is whether we would really want such a low bar.

Or we could reuse an existing IANA registry and automatically import
quite a few algorithms into STUN. Or modify an existing one and add an
"allowed in STUN" column. Or, since we're doing STUN-bis, we could take
a range of STUN attributes and lower the bar further, maybe even to
"First Come First Served".

The point is that a new STUN attribute is not necessarily harder to get
than a new HMAC algorithm identifier.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 2 Apr 2015 18:42:05 +0000

> Sent: Thursday, April 02, 2015 11:58 PM
> To: Brandon Williams; Tirumaleswar Reddy (tireddy); Marc Petit-Huguenin;
> [email-masked]
> Yes and no. I see it as a backwards-compatibility mechanism. If you support
> MI2, then you use MI2. You have no choice. In my understanding, egotiation
> implies choice and configurability. For example on a TLS server or client you
> configure the crypto suites you are willing to use and their priorities for
> negotiation. I would prefer not having to configure this sort of thing in STUN.
> 
> > At the meeting, I didn't fully understand the argument that adding a
> > new HMAC algorithm identifier to a registry would be just as much work
> It depends. The registration rules for the STUN attributes registry are either
> "IETF Review" or "Designated Expert". In theory we could create a new HMAC
> algorithm identifier registry with a bar lower than "Designated Expert". The
> question is whether we would really want such a low bar.
> 
> Or we could reuse an existing IANA registry and automatically import quite a
> few algorithms into STUN. Or modify an existing one and add an "allowed in
> STUN" column. Or, since we're doing STUN-bis, we could take a range of
> STUN attributes and lower the bar further, maybe even to "First Come First
> Served".
> 
> The point is that a new STUN attribute is not necessarily harder to get than a
> new HMAC algorithm identifier.

HMAC algorithm identifiers are already provided by IANA https://tools.ietf.org/html/rfc4868#section-4

-Tiru