Cullen, > -----Original Message----- > From: Cullen Jennings [mailto:[email protected]] > Sent: 11 March 2009 23:07 > To: Elwell, John > Cc: SIP List; Jon Peterson > Subject: Re: [Sip] Seeking consensus on > draft-elwell-sip-e2e-identity-important > > > I continue to believe that we need to to come to some common > understanding of the security problem we are trying to solve and the > constraints on that solution. On one of the close to last > phones calls > involving this draft I asked everyone one on the call what they > thought the problem was. I got no common answer. > > There is a lot of good information in this draft related to the > problem and solutions, but I don't believe this draft gets to what > problem we are trying to solve thus making it very hard to answer a > question like if the solution should involve changing m line or not. > If we all agreed the problem was, just for example, stop MITM from > listening to phone calls while still allowing intermediaries to do > media steering, then I think we could get there. [JRE] That may be a good way to express it. At present, in section 9, it expresses the problem in terms of: "Loss of end-to-end authenticated identification caused by the breaking of SIP Identity signatures on non-E.164-based SIP URIs by B2BUAs in intermediate domains performing legitimate functions such as media steering." and a slightly different statement for the E.164-based case. Then in section 10 it tries to state the requirement in terms of a third party, user 3, which is the MitM in your formulation. So that is not 100 miles away from your suggestion.
When working on slides for IETF74, I will try to take this into account and provide a better problems statement. Other input welcome. John > I know the > problem is > much more complicated than I just said - I'm not suggesting that my > above statement is the right problem statement but just that it is > closer to level we should be looking at the problem at. > > Cullen > > > On Mar 3, 2009, at 9:46 AM, Elwell, John wrote: > > > Draft 03: > > > http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03 > > includes for the first time an analysis of changes to SIP > requests by > > B2BUAs (section 8). Also the Conclusions (section 9) have been > > extended. > > > > I and a number of people who have assisted in revising this draft > > would > > like to seek consensus on a number of the points. We aim to > ask these > > questions in San Francisco, but obviously it would help to get > > opinions > > from the list in advance. > > > > 1. Tolerance to changes of certain elements as a SIP request is > > forwarded through intermediate domains. > > > > Section 8 analyses a number of elements of SIP messages that are > > signed > > by the present RFC 4474 solution to end-to-end (or near end-to-end) > > authenticated identification. For some elements it claims that any > > solution for end-to-end authenticated identification needs to be > > tolerant of changes by intermediate domains, since there > appear to be > > valid reasons why B2BUAs (including but not limited to SBCs) change > > these elements. Picking on some of these: > > > > A) Is there agreement that a solution needs to be tolerant of > > changes to > > IP addresses and ports in c- and m-lines in SDP? In other > words, that > > intermediate domains can legitimately modify these fields (e.g., for > > media steering) and a solution is needed for end-to-end > authenticated > > identification in such circumstances? > > > > B) Is there agreement that a solution needs to be tolerant of > > changes to > > Contact (addr-spec), Call-Id (call-id) and CSeq (digit) > header fields? > > In other words, that intermediate domains can legitimately modify > > these > > fields (e.g., for topology hiding) and a solution is needed for > > end-to-end authenticated identification in such circumstances? > > > > C) Is there agreement that a solution does not need to be > tolerant of > > changes to the addr-spec of From and To header fields? In > other words, > > that intermediate domains should not modify these fields and can > > expect > > to break end-to-end authenticated identification if they do so? > > > > > > 2. Are people in broad agreement with the conclusions in section 9 > > concerning the importance of end-to-end identification and in > > particular > > end-to-end authenticated identification? > > > > 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 > > _______________________________________________ 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
