On Apr 12, 2008, at 7:08 AM, Ben Campbell wrote: > > On Apr 12, 2008, at 4:16 AM, Dean Willis wrote: > >> I think at least one carrier has gotten a workaround in place to >> user caller-ID as an authenticator, but only when the call is >> originating from a mobile in their network and they've handled the >> GSM authentication themselves. > > Actually, I was contemplating an argument that we should just > establish a best current practice that says one should never trust a > phone number, even if it includes a 4474 signature, and that we > didn't need to put anything in the message to indicate that. But > you've just brought up an edge case where someone could really sign > a phone number and mean it, that is, if the gateway is controlled by > the authenticating carrier, it could have some out of band way of > knowing about said authentication. and could in fact trust the > callerid with reasonable strength. > > Therefore, the fact that the From header contains a tel (or > user=phone) URL is not sufficient to for the receiver to infer the > authentication strength. > >
There's a much less "edge" case. It's entirely reasonable to have a phone identified by a phone number where that phone is attached to an IP network instead of the PSTN. ENUM could then be used to provide routing information to the phone. Such a phone could use strong authentication and encryption. How, based on the From field (or any other information) can we differentiate such a phone from a PSTN gateway, consequently knowing when to trust and when not to trust the user part as signed by RFC 4474? I've proposed in a separate message that "user=phone" be the differentiator -- in short, that PSTN gateways add "user=phone", and that IP attached phones not add it. The problem of course is backward compatibility. There are a few bajillion gateways out there that do not add user=phone. Consequently, were my proposal accepted, RFC 4474 could not be used with those gateways until they are repaired. I'm OK with that restriction. -- 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
