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. -jiri _______________________________________________ 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
