Re: francois' comments and why RFC4474 not used in the field

I think our views are not that appart.

See belows.  

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email protected]] 
> Sent: Saturday, March 28, 2009 13:02
> To: [email protected]
> Cc: Audet, Francois (SC100:3055)
> Subject: francois' comments and why RFC4474 not used in the field
> 
> As we were running out of time in the meeting, I wanted to 
> follow up on an argument which Francois has made: RFC 4474 
> works if the identity provider and verifiers are "next to 
> each other", thus we have no problem with this RFC.
> 
> /* hope I didn't misinterpret, let me know should that be the case */

First part is currect, but I didn't say "thus we have no problem with
this RFC."

As you say, it only works if the identity provider and the verifier are
"next to each other". A federation of Enterprises for example. Or between
service providers.

However, one of the most predominant model today doesn't work like this.
A domain is often relying on a third party, a "service provider".

So it's really not "end-to-end". That was the point I was trying to make.

RFC 4474 appears to work fine for end-to-end identity: unfortunately,
many deployment models (perhaps the majority) and in fact, not end-to-end,
but mediated. In a typical scenario, each end would have it's own
"service provider", so 2 intermediaries.

> I'm worried this is only a wishful thinking. While perfectly 
> logical, still even in such constrained setups some bizzar 
> ALGs do in my experience appear in the middle, change SDP and 
> make thus the identity worthless.

Yes, I agree 4474 doesn't work if there are intermidiaries.

> I think the bottom line is the protocol is not really end-to-end.

EXACTLY!


> It makes quite some assumptions about the quality of 
> underlying network (particularly about not changing SDPs) as 
> opposed to trying to deal with lack of it. In fact, SDP 
> payloads are changed at quite a number of devices: proxy 
> servers, B2BUAs, SBCs, you name it. Assuming there is nothing 
> in the way which won't change SDP is just NOT ROBUST.
> 
> Other way to look at it is it is function overloading. You 
> ask for identity and get message integrity -- consequently 
> when the latter fails, the former, which you really initially 
> wanted, fails too. ekr's argument is certainly right that a 
> message of certain origin but uncertain content is close to worthless.
> OTOH, the particular piece, IP address and port numbers in 
> SDP are certainly not to be covered by a message integrity checks.
> In fact, for accepting calls based on who is calling, as a 
> minimalistic application example, one does  not need message 
> integrity.
> 
> In conclusion, I do not think that RFC4474 can be of any help 
> (other than in controlled environments which beats its 
> purpose) as long as IP/port in SDP are message-integrity-protected.

Here is what I think:

RFC 4474 can work in the following situations:

1 - Enterprise-to-Enterprise: i.e., the network as a dumb pipe. The enterprises
have their own SBCs modifying SIP/SDP (or they can use ICE).

2 - Subscriber on Service provider A to Subscriber on service provider B: 
i.e., the "domain" for the first subscriber is actually that of the subscriber.
This can work for "residential users" and small enterprises.

3 - Any permutation of the above.

In all those cases, there is effectively end-to-end identity.

RFC 4474 does NOT work if it's not end-to-end. For example, if 
the "Enterprise" has it's own domain, but it relies on it's 
service provider to perform a number of functions. NAT traversal,
topology hiding, etc.

So, what can we do?  I see 2 possibilities:

1 - Make it end-to-end. This means tackling one by one the problem areas.
    Use TURN/ICE instead for relying on SDP payload manipulation. Use
    Call-ID and Contact headers that don't reveal topology, etc.

2 - Create a non end-to-end Identity assertion mechanism that is different
    from RFC 4474 and more secure than P-Asserted-Identity. I have a 
    feeling that it won't be trivial. We may have to define the 
    trust relationship between the ends and the intermediaries. 

What I was trying to say in the meeting is that for "end-to-end
identity", 4474 appears to work. But if the problem we are trying to
solve is NOT end-to-end identity, but strong mediated identity, then,
let's just say so. It's just a DIFFERENT problem to solve.

_______________________________________________
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