Re: Seeking consensus on draft-elwell-sip-e2e-identity-important

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