STUN security considerations - STUN over DTLS ? about libjuice HOT 2 OPEN

We are using libDataChannel together with libjuice and observed that unencrypted UDP pakets containing the ice-ufrag pair and the fingerprint together with IP and ports are exposed.

You are right, but the exposed information, like ICE ufrag, is public. The only private information is the ICE password which serves to compute the message-integrity attribute. The fingerprint STUN attribute is not here for security and has nothing to do with the WebRTC DTLS fingerprint, it just helps to distinguish STUN packets from application traffic. Public addresses and ports are present in UDP/IP packet headers anyway so any router on the path can see them.

The STUN standard contains the following security consideration in section 16: https://www.rfc-editor.org/rfc/rfc5389#section-16

Since STUN uses the HMAC of a shared secret for authentication and
integrity protection, it is subject to offline dictionary attacks.
When authentication is utilized, it SHOULD be with a strong password
that is not readily subject to offline dictionary attacks.
Protection of the channel itself, using TLS, mitigates these attacks.
However, STUN is most often run over UDP and in those cases, strong
passwords are the only way to protect against these attacks.

The reason for such considerations in the RFC is that STUN is designed as generic protocol that other connectivity protocols can use, especially ICE, but not limited to it. This specific paragraph is a general consideration for protocols using STUN, but does not apply to ICE connectivity checks.

As far as I have seen in the code, the message integrity is checked, but offline dictionary attacks are still possible. Is this correct?

The ICE connection process typically lasts less than 30s, so you can't realistically run an offline attack on the ICE password. Additionally, the ICE password is randomly-generated for each session and cracking it wouldn't serve any purpose other than injecting mapped addresses during connection that the peer would then try to probe. In any case, it is impossible to hijack a media session thanks to the DTLS fingerprint verification.

While writing this I wondered whether it is possible to use DTLS not only for the media data transmission, but also for the STUN messaging. Actually there exists a standard for this, however I have no idea how much effort this would require to be integrated:
https://datatracker.ietf.org/doc/html/rfc7350

This RFC already discuss of DTLS for ICE connectivity checks in section 4.2, and mentions that it doesn't bring benefits and would delay the checks so much by adding round-trips that you'd need to basically redesign everything to perform checks with the DTLS handshake instead.

from libjuice.

Thank you very much for your explanations!

from libjuice.