On Jul 15, 2008, at 10:48 AM, Hadriel Kaplan wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Cullen Jennings
>
> I asked some folks on this thread a few years ago for an example
of a
> real deployment where it would not be possible to use 4474 as long
as
> the SBC implemented 4474. I'm still waiting for an example of
where it
> actually is broken.
If the From is an E.164, then you're right transit providers can re-
sign it anew, changing the From domain to their own. There are
several problems with this, though:
a) It has a deployment problem; we'd need all intermediaries
which change anything signed by 4474 to all support 4474 re-signing,
for 4474 to be deployable. Otherwise the signature will constantly
fail. If it constantly fails, no one will try to use it. If no one
tries to use it, the intermediaries have no reason to implement re-
signing. Ergo, Catch-22.
b) It changes the From URI. Of course many intermediaries
already do that for other reasons, but it's not like we should
*require* them to do it if the only reason they would need to is to
re-sign a message.
c) We shouldn't *want* to force the intermediaries to re-
sign. It just makes it hop-by-hop trust. Unless of course you
believe the things being changed by the intermediaries are such that
they MUST NOT be changed by intermediaries for the purposes of
identity, because they are inherent to the meaning/value of
"Identity". For some things I don't believe you or anyone really
feel that - for example call-id and cseq. The questionable one
would be SDP.
d) Re-signing is expensive; it's both validating the
received one, and signing it again. The transit provider business
is about low cost. So they'll just delete the identity headers
rather than resign, if they even do anything.
That's a good list. Someone should make sure to capture the above so
that we can see how 4474 compares to any other solution that is
capable of providing end to end secure assertion about who's phone a
user is talking and collaborating with.
> Hadriel hypothesized a type of situation where it
> could be broken. That was the case where service provider A passed
> call to B who passed call C and they were not using E.164 numbers
but
> were using email style addresses and the one in the middle wanted to
> do media steering or restrict what codecs where allowed.
Well, to be fair the one in the middle could have any number of
reasons for changing things which would break the signature. Call-
id obfuscation, CSeq number re-writing due to various b2bua
functions, changing SDP for transcoding or dtmf interworking, etc.
You or your company knows all the reasons as well as I do. :)
Just to be clear, I'm aware of lots of situations where the service
provider A and C might want to do the extra things you mention but I
am not aware of real deployments where service provider B needs to do
the things beyond media steering and codec restriction. I'm happy to
be educated.
-hadriel
Cullen <in my individual roll>
_______________________________________________
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
