> -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 04, 2007 3:19 AM > To: Dan Wing; [email protected] > Cc: [EMAIL PROTECTED] > Subject: RE: [Sip] SIP Identity using Media Path > > 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?
Yes -- you could accomplish exactly that by only validating the signature over the headers and not doing the HIP/ICE/DTLS-SRTP/TLS media path validation. However, this means you have transitive trust of all the SIP proxies along the path. It also means you don't think an attacker has captured a valid, signed Invite, and is replaying it towards you. > 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? Right. (Although I have variously convinced myself there is still a mafia fraud attack problem with the ICE technique, and have convinced myself there isn't such an attack. I'll need to leave that analysis until later when I have sufficient time to write it up. Today I think there isn't a problem (because the public key is authenticated by A's signature, which prevents a man-in-the-middle from doing a mafia fraud attack by replacing the A's public key with his own public key.) > More below. > > John > > > -----Original Message----- > > From: Dan Wing [mailto:[EMAIL PROTECTED] > > Sent: 04 July 2007 09:46 > > To: Elwell, John; [email protected] > > Cc: [EMAIL PROTECTED] > > 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). Right. To combat this attack, Identity (RFC4474) relies on IP address and port numbers. However, NATs, TURN, and SBCs reduce the value of the IP address and port numbers as a unique identifier of a flow before the RFC4474 replay window has expired. SIP-Identity-Media doesn't use IP addresses -- rather, it has the endpoints prove they know the private key associated with their public key. This allows SBCs to rewrite m/c lines, and also removes the risk, inherient in RFC4474, that an attacker will be able to get your recently-used transport address assigned to them by the same NAT or TURN server. -d > > 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
