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
