Subject: [Sip] Seeking consensus on draft-elwell-sip-e2e-identity-important

From: "Elwell, John" <[email-masked]>
Date: Tue, 03 Mar 2009 16:46:39 +0000

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

---

From: Gilad Shaham <[email-masked]>
Date: Wed, 4 Mar 2009 14:32:08 +0000

Hi John,

I personally think your conclusions are correct. One comment I have is
regarding From and To headers. It's possible that the comment is a bit
ahead of time as this draft is not yet aimed at the solutions, but I
believe that when we come to a solution, the endpoints themselves should
enforce some rules on the From and To headers if they want to support
end-to-end identity.
For example, the endpoints should not (or MUST not) place an IP address
in these fields if they request end-to-end identity to be enabled.
Making this a requirement on the endpoint behalf would help coping with
the dilemma of the intermediate device as to whether or not it should
break the identity.

Thanks,
Gilad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: Tuesday, March 03, 2009 6:47 PM
To: SIP List; Cullen Jennings; Jon Peterson
Subject: [Sip] Seeking consensus on
draft-elwell-sip-e2e-identity-important

Draft 03:

John

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Mar 2009 20:44:11 +0000

> From: Gilad Shaham [mailto:[email-masked]] 
> Sent: 04 March 2009 14:32
> To: Elwell, John; SIP List; Cullen Jennings; Jon Peterson
> Subject: RE: [Sip] Seeking consensus on 
[JRE] That would be good, but on the other hand this sort of fix-up can
in practice be done in the originating domain prior to the
authentication service. In fact replacing an IP address with a domain
name must be done before the authentication service.

John

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Mar 2009 17:07:00 -0600

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Mar 2009 11:52:03 +0000

Cullen,

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 11 March 2009 23:07
> To: Elwell, John
> Cc: SIP List; Jon Peterson
> Subject: Re: [Sip] Seeking consensus on 
> 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