Jiri, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jiri Kuthan > Sent: 28 March 2009 20:02 > To: [email protected] > Cc: Francois Audet > Subject: [Sip] francois' comments and why RFC4474 not used in > the field > > As we were running out of time in the meeting, I wanted to > follow up on an argument which Francois has made: RFC 4474 > works if the identity provider and verifiers are "next to > each other", thus we have no problem with this RFC. > > /* hope I didn't misinterpret, let me know should that be > the case */ > > I'm worried this is only a wishful thinking. While perfectly > logical, still even in such constrained setups some bizzar > ALGs do in my experience appear in the middle, change SDP > and make thus the identity worthless. > > I think the bottom line is the protocol is not really end-to-end. > It makes quite some assumptions about the quality of underlying > network (particularly about not changing SDPs) as opposed to > trying to deal with lack of it. In fact, SDP payloads are > changed at quite a number of devices: proxy servers, B2BUAs, > SBCs, you name it. Assuming there is nothing in the way > which won't change SDP is just NOT ROBUST. > > Other way to look at it is it is function overloading. You ask > for identity and get message integrity -- consequently when > the latter fails, the former, which you really initially wanted, > fails too. ekr's argument is certainly right that a message > of certain origin but uncertain content is close to worthless. > OTOH, the particular piece, IP address and port numbers in SDP > are certainly not to be covered by a message integrity checks. > In fact, for accepting calls based on who is calling, as > a minimalistic application example, one does not need > message integrity. > > In conclusion, I do not think that RFC4474 can be of any help > (other than in controlled environments which beats its purpose) > as long as IP/port in SDP are message-integrity-protected. [JRE] Exactly. Moreover, when media are secured by some means (SRTP in the case of RTP) and if SDP contains a fingerprint of the certificate used to secure the media, there is absolutely no need to sign the IP address/port. They can quite happily change without impacting the security of media. Of course, if media isn't secured, it is a slightly different matter, but I doubt that signing the IP address and port really buys us much. So you might as well not include IP address and port in the signature, and if they are changed by intermediate SBCs, no problem.
John _______________________________________________ Sip mailing list https://www.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
