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

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Apr 2018 12:57:12 -0700

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 22 Apr 2018 14:02:31 -0700

Hi Eric,

Thanks for the review, please see my responses inline.

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.

> condition, so it probably needs to be a MUST.

Done.

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

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

Applied.

> You might want to list these in order.

Done.

> Why this restriction? You should be able to use anycast with long-term

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.

> ms". Perhaps you mean greater than equal.

Fixed.

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

> Would it be better to just cite to RFC 7525 here?

Already modified following Peter Saint-Andre review.

> INTEGRITY-SHA256 attribute is not present, then use the same password

Applied.

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

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

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

> So if M-I-SHA256 and M-I appear together, one includes the other but

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.

> Is it an A-label or a U-label?

I do not know.  What would you suggest?

> 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: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Apr 2018 17:22:15 -0700

> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for

I hear what you're saying, but publishing two documents at the same time
which
make contrary recommendations about the same basic protocol is un-good.

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

>       TLS-over-TCP, or authentication are used.

Are you leaving this text in? That seems very confusing.

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

Yes, I know. My point is that while they might have bee sensible when
5389 was published they *now* seem crazily long. Did the WG explicitly
decide not to update them?

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

This would be good to explain.

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

But ultimately no matter what the other protocol provides for demux, STUN
has its
own demux.

> I do not know.  What would you suggest?

I believe Alexey raised this separately, so I would refer to his comments.

>    future version of STUN is necessary.

I still don't understand the capabilities you seem to believe the attacker
has.
Can you describe the exact attack.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 23 Apr 2018 11:16:52 -0700

> make contrary recommendations about the same basic protocol is un-good.

Sure, but wouldn't it be simpler to have rfc5245bis using stunbis and have them updating their text, more than adding some tortuous text in stunbis?

> Are you leaving this text in? That seems very confusing.

In isolation yes, but I think it makes sense which the text before the bullet points:

   A STUN usage defines how STUN is actually utilized -- when to send
   requests, what to do with the responses, and which optional
   procedures defined here (or in an extension to STUN) are to be used.
   A usage also defines:

[...]

> decide not to update them?

No, nobody ever suggested that there was an issue there.

New text:

   [...]
   containing the subjectAltName of that certificate.  The test on the
   MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction is
   authenticated and that the client implements this specification and
   so can process the ALTERNATE-DOMAIN attribute.

> But ultimately no matter what the other protocol provides for demux, STUN

In fact I think that the reason for that item was because FINGERPRINT can also be used to demux STUN traffic, but it is optional.  So an STUN Usage needs to tell if FINGERPRINT is mandatory (like in ICE).

> Can you describe the exact attack.

1. Vulnerability is found in HMAC-SHA1
2. Client Alice still supports M-I and M-I-256, does not know what version of STUN server Bob supports and so send both.
3. On-path attacker removes M-I-256.
5. stunbis server Bob thinks that Alice is an RFC 5389 client and continue with that protocol.