CODEWITHSUNDEEP
webrtcstun
asinix
asinix

Reputation: 1058

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

RFC 8445 states in relevant parts:

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

But RFC 5389 on STUN describing the computation of the MESSAGE-INTEGRITY field and specifically short-term credentials, states:

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

QUESTION: For calculating HMAC for message-integrity, neither the key nor the text over which HMAC is computed references any username fragments. Also, username does not play a role in fingerprint computation. So my question is: Where does username come into play in the STUN short-term credential mechanism when there is no trace of username in the request? Of course, ufrag and upassword are exchanged through SDP but how are they used to authenticate/validate a binding request?

Upvotes: 0

Views: 479

Answers (1)

Sean DuBois
Sean DuBois

Reputation: 4272

You are right the username has no impact on the MessageIntegrity, but it should be in the STUN packet under the username attribute.

You can see that here we assert that on the inbound message the username is a.localUfrag+":"+a.remoteUfrag

Upvotes: 1

Related Questions