Lakshminath,I think that you and EKR are talking past each other in regards to the benefits of the a=fingerprint attribute and the subsequent use of a self-signed certificate in the DTLS handshake. Let us consider your example of using a device to call a calling card gateway and then sending a PIN to authenticate the user to the gateway. You claim that the caller does need to use the a=fingerprint attribute with a self-signed certificate in this case because the gateway doesn't care which device (phone) the user is using. However, the point of the self-signed certificate is NOT to assert the identity of the calling device to the callee. (If you wanted to assert the identity of the calling device you would not use a self-signed cert, but instead a cert signed by a 3rd party whom the callee trusts.) The point of using the self-signed certificate is to bind the media to the signaling.
Let us consider what might happen (in your calling card use-case) if there was no a=fingerprint attribute in the SIP Invite. (Here the calling user is the client in the DTLS handshake.) The user sends a SIP Invite to the gateway. The gateway then sends a HelloRequest to the user. The user then attempts to send a ClientHello to the gateway. However, an attacker (man in the middle) intercepts the message and replaces it with his own ClientHello message. The gateway then sends a ServerHello message, which the attacker replaces with his own ServerHello message. The handshake continues in this manner with the attacker sending Server messages to the user and sending Client messages to the gateway. The end result is that two session keys are generated and both are known to the attacker. (One is shared by the user device and the attacker, and the other is shared by the attacker and the gateway). This means that when the user device starts sending media packets, the attacker can relay these packets to the gateway until the user has finished sending the PIN. Once the PIN has been relayed to the gateway, the attacker will drop all media packets sent by the user device and have a PIN-authenticated session with the calling card gateway.
In summary, without use of the a=fingerprint attribute, an attacker who can play "man in the middle" in the media path can hijack the user's session and maliciously use the user's PIN. However, if the calling device uses the a=fingerprint attribute along with a self-signed certificate, then in order to pull off such an attack, the attacker must be able to play "man in the middle" in both the signaling path and the media path. (And of course playing "man in the middle" in the signaling path is difficult if all signalling proxies use TLS or IPSEC to transport their SIP messages, and is even more difficult if SIP Identity to gaurantee the integrity of the SIP INVITE).
Now perhaps there are deployment scenarios where one is willing to accept vulnerability to the attack described above in exchange for a one-time savings of up to 600 bytes. (Indeed, I can imagine scenarios where such a man in the middle attack is difficult to pull off). My point is merely that there are meaningful security gaurantees that are provided by the a=fingerprint attribute, even in cases where the called party doesn't care about the identity of the calling device.
[Although my personal bias is that attacks like those described above are sufficient to justify the one-time use of a self-signed certificate]
- Matt Lepinski :-> Lakshminath Dondeti wrote:
Well, I don't, at least if the implication is that you don't need to authenticate both sides. On the contrary, as I've observed several times, even where the callee has some in-band authentication mechanism, it's desirable to cryptographically bind the media to the signalling.Where do these requirements that are universally applicable to all scenarios come from? What if the callee (calling card gateway) does not care which phone the calling card user may be using? That is a real scenario!