Re: 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. 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