There is a difficult line to walk here:
On one hand the GW operator doesn't want to be held liable for asserting
an address it can't verify.
OTOH the UAS (should) want *some* assurance of the identity of the
caller before displaying it as caller id.
If the UAS won't display without a trusted signature, and the GWs won't
provide a signature for anything from the PSTN, then sip phones won't
ever get callerid for calls from the PSTN.
If the UAS on the open internet will display anything (e.g. From)
without any verification information, then I think we will, in a
practical sense, have something that is far worse than the PSTN is
today. (Maybe not worse than the PSTN will be when we have more IP
interconnects with it.)
Paul
Dean Willis wrote:
> On Apr 4, 2008, at 2:50 PM, Hadriel Kaplan wrote:
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>>> Elwell, John
>>>
>>> There seems to be some interest in adding some indicator to the URI
>>> or
>>> to the header field to warn of the limited guarantee of
>>> authenticity or
>>> the opposite (i.e.,lack of such an indicator would mean the
>>> guarantee is
>>> low, i.e., the identity has not been verified).
>> I haven't thought about this since it was last on the list, and I
>> think I was a proponent of it at that time, but why were we thinking
>> this would ever be set? I mean if I'm a clid spoofer, why would I
>> ever want to add such a param?? Isn't it like a "spam=yes" flag
>> you're describing, and then expecting potential spammers to set it?
>> I've forgotten the train of thought which lead to this param as a
>> viable solution.
>
> The Identity header essentially signs the From. It's traceable back to
> whoever made the signature. So, if you were an identity server, you
> could spoof any kind of caller ID you might want. But we'd know it was
> you doing it . . .
>
> What we're looking for is a way for an RFC 4474 identity server to say
> something about how strong it believes its assertion to be. Sure, it
> could lie, but then we wouldn't trust it in the future. It's much
> better if it volunteers the information to us that it doesn't REALLY
> know who the caller is, since it has only the caller-ID information to
> go from.
>
> If an identity server were to fully RFC 4474 "sign" a message rom a
> PSTN, it's even possible that the identity server operator could be
> held legally liable for inaccuracy in the asserted identity. In other
> words, if a caller-ID spoofer made a call through the example.com
> gateway, and the example.com identity server attaches an Identity
> header on to the resulting INVITE that asserts the spoofed telephone
> number identity, then someone injured (defrauded) by the caller could
> claim negligence on the part of the example.com identity server and
> sue for damages.
>
> This is why things like identity servers (and CAs) have statements of
> policy that describe their procedures and the strength of claim being
> made. Those published policies are legal contracts with the users of
> the certificates. It's part of why x.509 certs are so big and have so
> many things like subject-alt-names and extended key usage. SIP
> identity services need the same sorts of legal flexibility. Being able
> to sign a request on the basis of "I swear to you that it came through
> my gateway, but I don't know who it really came from, so I make no
> assertions about this identity other than that the request came
> through my gateway with the calling-party-ID information described
> herein" is really, really important.
>
> --
> Dean
>
> _______________________________________________
> 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
