RE: [Sip] SIP Identity using Media Path

["Dan Wing" <dwing@xxxxxxxxx>]

> The mechanism described for ICE seems to provide an 
> alternative to ICE's
> password-based mechanism for correlating binding requests with
> offer-answer exchanges.

It's not an alternative to ICE's username and password; the new 
attributes (PK-CHALLENGE, PK-RESPONSE) would be used in addition 
to the existing STUN attributes used by ICE's connectivity
checks.  The ICE username/password would still be used for
message integrity and to associate a flow with an endpoint's
SDP answer.

> I have not seen any motivation for this
> alternative.

The motivation is proving you know the private key 
associated with the public key.  It's only after that
proof that you can be assured the Invite wasn't captured
by an attacker, had its SDP replaced with the attacker's
IP address, and replayed to you.

All of the proof of identity techniques described in the
paper exchange a public key over the media path (HIP, DTLS-SRTP,
TLS) or in the SIP signaling path (ICE).  Then, over the media 
path, the remote party proves he knows the private key 
associated with that public key.  This proof of knowledge of
the private key is part of the handshake for HIP, DTLS,
and TLS; what the paper does is describe how ICE can do 
something similar.  The primary purpose of ICE in that
family of proof of identity techniques is to provide a 
modicum of SBC-survivable identity if RTP (or SRTP 
with Security Descriptions) is used.  Things are obviously
much more secure if DTLS-SRTP, TLS, or HIP are used,
as this ensures nothing is going to inject RTP packets
into the stream; using RTP can't ensure that.


(Crypto experts will point out there is a mafia fraud 
attack problem with the ICE technique as described 
in the paper.  That is true, but if you're not going 
to run SRTP using a secure keying mechanism you're 
suffering the same risk of someone injecting RTP into
your stream as the mafia fraud attack.)

-d