使用 STUN 绑定请求对 ICE 连接检查的消息完整性计算进行说明

Question

RFC 8445 在相关部分指出：

 7.2.2.  Forming Credentials

        A connectivity-check Binding request MUST utilize the STUN short-term
        credential mechanism.

        The username for the credential is formed by concatenating the
        username fragment provided by the peer with the username fragment of
        the ICE agent sending the request, separated by a colon (":").

        The password is equal to the password provided by the peer.

        For example, consider the case where ICE agent L is the initiating
        agent and ICE agent R is the responding agent.  Agent L included a
        username fragment of LFRAG for its candidates and a password of
        LPASS.  Agent R provided a username fragment of RFRAG and a password
        of RPASS.  A connectivity check from L to R utilizes the username
        RFRAG:LFRAG and a password of RPASS.  A connectivity check from R to
        L utilizes the username LFRAG:RFRAG and a password of LPASS.  The
        responses utilize the same usernames and passwords as the requests
        (note that the USERNAME attribute is not present in the response).

但是 STUN 上的 RFC 5389 描述了 MESSAGE-INTEGRITY 字段的计算，特别是短期凭证，指出：

  For short-term credentials:
                      key = SASLprep(password)

问题：为了计算消息完整性的 HMAC，计算 HMAC 的密钥和文本都不会引用任何用户名片段。此外，用户名在指纹计算中不起作用。所以我的问题是：当请求中没有用户名的踪迹时，用户名在 STUN 短期凭证机制中发挥什么作用？当然，ufrag 和 upassword 是通过 SDP 交换的，但是它们如何用于 authenticate/validate 绑定请求？

Answer 1

你是对的，用户名对MessageIntegrity没有影响，但它应该在用户名属性下的STUN数据包中。

您可以看到 here 我们断言在入站消息中用户名是 a.localUfrag+":"+a.remoteUfrag

使用 STUN 绑定请求对 ICE 连接检查的消息完整性计算进行说明

Clarification on Message-Integrity calculation for ICE connectivity Check using STUN binding request

webrtc

stun