Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Marc Petit-Huguenin <petithug@acm.org> Sun, 22 April 2018 21:02 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1431200F1; Sun, 22 Apr 2018 14:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioXa7uh7bG0d; Sun, 22 Apr 2018 14:02:42 -0700 (PDT)
Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47444126D85; Sun, 22 Apr 2018 14:02:42 -0700 (PDT)
Received: from [IPv6:2601:648:8301:730f:407e:9f96:b05f:7bbb] (unknown [IPv6:2601:648:8301:730f:407e:9f96:b05f:7bbb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0B188AE844; Sun, 22 Apr 2018 23:02:38 +0200 (CEST)
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org>
Date: Sun, 22 Apr 2018 14:02:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5OLvpxuAyIWJl4oB9AupIasxFR4xtVdce"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/hk-qDFKQ1ikWP7ha_3r-ZI5X_JU>
Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Apr 2018 21:02:46 -0000

Hi Eric,

Thanks for the review, please see my responses inline.

On 04/16/2018 12:57 PM, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tram-stunbis-16: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D5132
> 
> 
> Can you please indicate how you addressed the points Matt Miller
> raised in his secdir review about the use of MD5.

From my response on 2018-03-11:

> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but the
> hash length of MD5 is 16 bytes (128 bits).  I think this is merely a typo,
> since the purpose appears to be for backwards compatibility with existing
> systems.

Fixed.

>
> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential)
> and Section appear to define the same functional algorithm, but with subtle
> syntax differences.  As far as I can tell, they are actually the same
> algorithm; would it not be acceptable to have Section 9.2.2 point to
> Section 17.5.1.1 for the algorithm description?
>
>

This is going into the IANA registry so I left things there.  I fixed the discrepancy with section 9.2.2.

I also fixed the definition of the key for SHA-256, which must use OpaqueString for the realm.

> 
> 
> 
> DETAIL
>>      by the agent sending the indication.  It primarily serves to
>>      correlate requests with responses, though it also plays a small role
>>      in helping to prevent certain types of attacks.  The server also uses
>>      the transaction ID as a key to identify each transaction uniquely
>>      across all clients.  As such, the transaction ID MUST be uniformly
>>      and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
> 
> I didn't realize this was a SHOULD. ICE depends on it as a security
> condition, so it probably needs to be a MUST.

Done.

> 
> 
>>      For a request or indication message, the agent MUST include the
>>      USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes
>>      in the message unless the agent knows from an external indication
>>      which message integrity algorithm is supported by both agents.  In
>>      this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST
>>      be included in addition to USERNAME.  The HMAC for the MESSAGE-
> 
> This text appears to conflict with S 7.3 of 5245-bis, which says:

[text missing]

Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for stunbis does not apply.

> 
> 
>>      STUN Security Feature it is understood that the corresponding STUN
>>      Security Feature bit in the "nonce cookie" is set to 1.
>>
>>      For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
>>      security feature, it is implied that the "Password algorithms" bit,
>>      as defined in Section 17.1, is set to 1 in the "nonce cookie".
> 
> I'm not sure I understand the bid down attack here or the proposed
> defense.  Can you please walk through what the assumed attacker
> capabilities are, what the client and server capabilities are, how the
> bid down attack works, and how this protects against it?

The plan is to add an annex to the document explaining that.  I'll finish to process the other reviews from the IESG and then come back to that.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>>
>>      In keeping with its tool nature, this specification defines an
>>      extensible packet format, defines operation over several transport
>>      protocols, and provides for two forms of authentication.
>>
>>      STUN is intended to be used in context of one or more NAT traversal
> 
> Nit: "in the context"

Applied.

> 
> 
>>      of [RFC0791].  Unless otherwise noted, numeric constants are in
>>      decimal (base 10).
>>
>>      All STUN messages comprise a 20-byte header followed by zero or more
>>      Attributes.  The STUN header contains a STUN message type, magic
>>      cookie, transaction ID, and message length.
> 
> You might want to list these in order.

Done.

> 
> 
>>      The STUN usage must specify which transport protocol is used, and how
>>      the agent determines the IP address and port of the recipient.
>>      Section 8 describes a DNS-based method of determining the IP address
>>      and port of a server that a usage may elect to use.  STUN may be used
>>      with anycast addresses, but only with UDP and in usages where
>>      authentication is not used.
> 
> Why this restriction? You should be able to use anycast with long-term
> AUTH for (say) TURN.

https://www.ietf.org/mail-archive/web/behave/current/msg03582.html

I think that the decision of permitting Anycast should be left to each STUN Usage.  Basic STUN Usage does not use authentication and use only a one round trip for the Binding transaction, so Unicast can be used.

OTOH, TURN and ICE should probably say something about that, so I added a new bullet point in Section 13:

   o  If Anycast addresses can be used for the server in case TCP or
      TLS-over-TCP, or authentication are used.

> 
> 
>>      First, the initial value for RTO SHOULD be greater than 500 ms.  The
>>      exception cases for this "SHOULD" are when other mechanisms are used
>>      to derive congestion thresholds (such as the ones defined in ICE for
>>      fixed rate streams), or when STUN is used in non-Internet
>>      environments with known network capacities.  In fixed-line access
>>      links, a value of 500 ms is RECOMMENDED.  Second, the value of RTO
> 
> I note that above you say "greater than 500 ms" but here you say "500
> ms". Perhaps you mean greater than equal.

Fixed.

> 
> 
>>      transaction over UDP or DTLS-over-UDP is also considered failed if
>>      there has been a hard ICMP error [RFC1122].  For example, assuming an
>>      RTO of 500ms, requests would be sent at times 0 ms, 500 ms, 1500 ms,
>>      3500 ms, 7500 ms, 15500 ms, and 31500 ms.  If the client has not
>>      received a response after 39500 ms, the client will consider the
>>      transaction to have timed out.
> 
> I note that these recommendations now seem crazily long. I assume the
> WG had consensus on this, but I wanted to note it.

Not just the WG, also the IESG that approved RFC 5389 too as, but for the addition of "or DTLS-over-UDP", this is the same text than in RFC 5389.

> 
> 
>>      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be
>>      implemented and other cipher suites MAY be implemented.  Perfect
>>      Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS
>>      cipher suites.  Cipher suites with known weaknesses, such as those
>>      based on (single) DES and RC4, MUST NOT be used.  Implementations
>>      MUST disable TLS-level compression.
> 
> Would it be better to just cite to RFC 7525 here?

Already modified following Peter Saint-Andre review.

> 
> 
>>
>>      o  If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
>>         value for the message integrity as described in Section 14.6,
>>         using the password associated with the username.  If the MESSAGE-
>>         INTEGRITY-SHA256 attribute is not present, and using the same
>>         password, compute the value for the message integrity as described
> 
> This text is a bit unclear. I think you mean "If the MESSAGE-
> INTEGRITY-SHA256 attribute is not present, then use the same password
> to compute the..."

Applied.

> 
> 
>>      a nonce.  The nonce provides the replay protection.  It is a cookie,
>>      selected by the server, and encoded in such a way as to indicate a
>>      duration of validity or client identity from which it is valid.  The
>>      client retries the request, this time including its username and the
>>      realm, and echoing the nonce provided by the server.  The client also
>>      includes a message-integrity, which provides an HMAC over the entire
> 
> Nit: "a message integrity attribute". 

Applied.

> Also, how do I know which one to
> use?

This is explained later in Section 9.2.3.2.:

   The choice between the two
   attributes depends on the attribute received in the response to the
   first request.

> 
> 
>>      ALTERNATE-SERVER where authentication of the response is not possible
>>      or practical.  If the transaction uses TLS or DTLS and if the
>>      transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute
>>      and if the server wants to redirect to a server that uses a different
>>      certificate, then it MUST include an ALTERNATE-DOMAIN attribute
>>      containing the subjectAltName of that certificate.
> 
> 1. Why is MESSAGE-INTEGRITY-SHA256 relevant here?

ALTERNATE-DOMAIN exists only since stunbis, so the MESSAGE-INTEGRITY-SHA256 acts as a flag indicating that 1) the transaction is authenticated and 2) that the client understand that new attribute.

> 
> 
>>      o  What authentication and message-integrity mechanisms are used.
>>
>>      o  The considerations around manual vs. automatic key derivation for
>>         the integrity mechanism, as discussed in [RFC4107].
>>
>>      o  What mechanisms are used to distinguish STUN messages from other
> 
> Why is this required? It seems like that's a generic STUN feature.

That text is identical to the text in RFC 5389.  RFC 5764/7983 is one such mechanism, but there is nothing that prevent another protocol stack to use a different mechanism (inference, shim, etc...)

> 
> 
>>      to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to
>>      calculating the HMAC over the STUN message, up to and including the
>>      attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute.  Such
>>      adjustment is necessary when attributes, such as FINGERPRINT, appear
>>      after MESSAGE-INTEGRITY-SHA256.  See also Appendix B.1 for examples
>>      of such calculations.
> 
> So if M-I-SHA256 and M-I appear together, one includes the other but
> not vice versa?

Yes, it is based on the text in RFC 5389 that says that everything after MESSAGE-INTEGRITY but FINGERPRINT must be ignored.  An RFC 5389 just ignore MESSAGE-INTEGRITY-SHA256.

Conversely stunbis says that everything after MESSAGE-INTEGRITY-SHA256 but FINGERPRINT must be ignored, keeping the possibility in stun-ter to add yet another MESSAGE-INTEGRITY attribute after that.

> 
> 
>>      transport protocol uses TLS or DTLS.
>>
>>      The value of ALTERNATE-DOMAIN is variable length.  It MUST be a UTF-8
>>      [RFC3629] encoded sequence of less than 128 characters (which can be
>>      as long as 509 bytes when encoding them and as long as 763 bytes when
>>      decoding them).
> 
> Is it an A-label or a U-label?

I do not know.  What would you suggest?

> 
> 
>>      that is not readily subject to offline dictionary attacks.
>>      Protection of the channel itself, using TLS or DTLS, mitigates these
>>      attacks.
>>
>>      STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256,
>>      which is subject to bid down attacks by an on-path attacker.
> 
> By an on-path attacker who can forge HMAC-SHA1 in real-time? That's a
> pretty serious adversary, so you should clarify here
> 

New text:

   STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256,
   which is subject to bid down attacks by an on-path attacker that
   would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the
   MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability.
   Protection of the channel itself, using TLS or DTLS, mitigates these
   attacks.  Timely removal of the support of MESSAGE-INTEGRITY in a
   future version of STUN is necessary.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug