Francois Audet wrote:
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.
Thanks for the clarifications. I think we are on the same page then.
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
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.
Well, I'm afraid that 1 is too complicated to work. Bringing TURN/ICE to
work is already quite an enterprise, and as much success I wish to it,
I would be careful and avoid dependency on it (which is generally
a good protocol design practice anyhow).
2 is then probably the safer direction to me. The point is really that
RFC4474 is not having as broad applicability as we have hoped, and
leaving SIP without Identity is going to be real-time irritating,
compared to convenience of Email's off-line irritation.
Some of the RFC 4474 applicability limitations could be lifted by
reducing its integrity protection scope. I'm not sure how popular
will it be then (some have had different opinions on adoptability
of things relying on CA) but it seems worth trying.
I would not dare to restrain ourselves to fixing RFC4474 though.
I'm very much in favor of testing other alternatives. IETF has
had a very successful tradition of testing several approaches.
A more ellaborated email on the topic was BTW recently written
by Dave Crocker:
http://www.ietf.org/mail-archive/web/mmox/current/msg01233.html
Obviously DERIVE (or perhaps non-SIP based reverse verifications)
appears a feasible alternative to me (because easy to deploy and
offering incentives to do so), but given the interest it is quite
certain there will be more different alternatives.
-jiri
_______________________________________________
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
