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

[Eric Rescorla <[e-mail]>]

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.



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.


>      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:


>      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?


----------------------------------------------------------------------
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"


>      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.


>      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.


>      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.


>      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.


>      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?


>
>      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..."


>      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". Also, how do I know which one to
use?


>      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?


>      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.


>      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?


>      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?


>      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