RE: [Sip] SIP Identity using Media Path

["Elwell, John" <john.elwell@xxxxxxxxxxx>]

Dan,

Thanks for the explanation. However, I am still not certain I have quite
"got it" yet. Let me explain what I think it is doing, and you can
confirm or deny.

A sends an INVITE request with SDP offer containing ICE candidates and a
password. A's local proxy adds the Identity-Media header field. B
receives the INVITE request and knows, from the From and Identity-Media
header fields, that it has comes from A, and therefore that the password
has come from A. So if nobody has been able to eavesdrop on the INVITE
request, this gives proof of ownership of STUN requests demonstrating
possession of that password. Right?

However, the assumption that there is no eavesdropping is not a safe
assumption (even if SIPS is use, I think we are all familiar with its
limitations). By conveying a public key rather than a password,
eavesdropping is not a problem. Right?

More below.

John

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: 04 July 2007 09:46
> To: Elwell, John; sip@xxxxxxxx
> Cc: ietf-rtpsec@xxxxxxx
> Subject: RE: [Sip] SIP Identity using Media Path
> 
> > 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.
[JRE] The Identity header field would prevent this (although the
Identity-Media header field does not).

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