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

[Eric Rescorla <[e-mail]>]

On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <[e-mail]>
wrote:

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

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.


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

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


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

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

This would be good to explain.


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

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


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

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

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

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