Dean Willis wrote:
>
> On Apr 14, 2008, at 11:05 PM, Paul Kyzivat wrote:
>>
>>
>> Dean Willis wrote:
>>> On Apr 14, 2008, at 11:54 AM, Eric Rescorla wrote:
>>
>>>> Where I think your analysis is wrong is principally in two respects:
>>>>
>>>> 1. A verified attestation of a meaningless identity is not a useful
>>>> form of authentication. Thus, it's useless for Bob to have a 4474
>>>> signature from the PSTN gateway unless he knows that that E.164
>>>> number can only be signed by that gateway. If he will accept as
>>>> equally valid a signature from any GW (and importantly, treat those
>>>> two entities as the same), then he is not in fact requiring
>>>> authentication in any meaningful way. Above, you're treating as
>>>> single-sided authentication cases which really are unauthenticated.
>>>>
>>> Well, if Bob accepts signatures from just any old domain, he's
>>> certainly screwed.
>>
>> How is Bob to decide who to accept signatures from? It is presumably a
>> function of the SPs of the people who call him. So are people just to
>> say "I'll accept ATT, Verizon, and Sprint" and leave it at that???
>
> It comes down to contractual liability. Who do I have reason to believe
> I can sue if the identity has been falsified? In simplest terms, this
> means "somebody with whom I have a contract", either formal and
> personal, or informal and general. An example of the first sort is a
> specific contract with a service provider. An example of the second sort
> is an implicit contract with a root CA whose cert's are included in my
> commercial OS's browser distribution.
>
> Most likely, people will accept signatures from providers with whom they
> have contractual agreements to provide those signatures; in short,
> signatures from their service providers. I believe that they will also
> be willing to accept transitive signatures. By this I mean signatures
> that are initiated by some other service provider, with whom the
> recipient;s service provider has made contacts of mutual authentication.
>
> So if I'm an AT&T customer, I'll accept an AT&T signature. Assume you,
> as a Sprint customer call me. Your call goes out with a Sprint
> signature. Would I trust this directly? Probably not. But if AT&T and
> Sprint have a deal by which AT&T is also willing to add their own
> signature attesting to their trust of Sprint's signature, I'll trust
> AT&T's signature even though it is being applied to a Sprint ID. Of
> course, I'd personally like to see BOTH signatures preserved, since I
> might have an independent agreement with Sprint that AT&T is not aware of.
>
> Fewer people are likely to accept signatures of the second sort, and
> quite probably commercially-supplied software will not do so as a
> default. For example, I expect that if I buy a consumer phone from AT&T
> that it will treat signatures asserted by AT&T (or possibly by AT&T and
> other companies with whom it has contracted) differently than it will
> treat signatures by unrelated third parties.
I buy the "contractual" approach. But the logistics still seem fuzzy to
me. I don't really expect that the phones are going to be presenting the
identity of the signers, at least as a matter of course. The user
interface will need to be much simpler than that to be useful to most
people. So it would seem that the policy will need to reside in the
phone or in the provider.
But that raises a new set of questions about the kinds of service we
would like to see possible. Personally, I don't want to be trapped into
buying my phones from my service provider. I remember the way it was
when the Bell system was a monopoly and you had to rent your phones from
them. And of course that is pretty much the way it is with cell phones
in the US. And it sucks.
*Perhaps* it can be worked out in such a way tht you can buy your phone
and configure it using some service that helps with the decisions and
then leaves the phone to enforce them. But that requires some thought.
> As a user, I'm also more likely to respect signatures from firms that I
> know and do business with than ones from firm's I don't. That's called
> "reputation".
>
> So for example, I might accept a signature from a Cisco Systems cert
> issued by Verisign for a call (although as a more-astute-than-average
> user, I might wonder if the topic of the call were unrelated to the
> business of Cisco Systems, for example it the caller claimed to be from
> my bank. But frankly, if I get a phish call from somebody who's using a
> Cisco Systems cert issued by Verisign, I probably have grounds for a
> lawsuit against Cisco anyhow.
Ah, the Willis vs Cisco case. How deep are your pockets?
>>>> 2. If you, as one side of the conversation, wish to know who you are
>>>> talking to, you need to enforce it yourself. You can't get it as a
>>>> side effect of offering your own credentials.
>>> As I've repeatedly said, the problem is not in knowing who you;re
>>> talking to. It's in knowing whether somebody else is listening in.
>>
>> I buy into this, since it is often not too hard to convince yourself
>> of who you are talking to by voice, manner of speaking, etc.
>
> It is also to differentiate the several levels of "who I am talking to".
>
> For example, assume I as an AT&T customer get a call from some random
> phone number, through a gateway operated by AT&T. I don't really need to
> know the identity of the calling party to deal with media security
> issues and apply DTLS-SRTP. All I need to know is the identity of the
> operator of the gateway, because I'm concerned about detecting MITMs
> between me and that gateway. What happens on the other side of it is
> outside of my control.
>
> For the typical case wherein I might rent a phone number from AT&T,
> where AT&T is the gateway operator of record for that phone number, all
> I need for SRTP-DTLS to work flawlessly (and provide full MITM control)
> is a signature that asserts an AT&T identity and covers the media
> fingerprint in the SDP.
>
>
> EKR is quite correct that this is NOT the general case (although it is
> still a case that I think needs to be solved).
>
> Let's consider a broader problem; perhaps it isn't my service provider's
> gateway that is sourcing the call. There might be many operators who
> provide an inverse-gateway service, where their PSTN users dial a fixed
> telephone number, enter a PIN, then enter a new destination number or
> use ten-key-spelling to enter my SIP username URI (example:
> sip:[EMAIL PROTECTED]).
>
> When such a request shows up at my phone with some random signature on
> it, how am I to know that this is the "original" signature or whether it
> has been replaced by by some signaling-and-media MITM? Answer: I can't.
> If the source of the call (in this case a phone number) isn't
> cryptographically or contractually related to the domain of the signer,
> I have nothing to go on.
>
> So if company A provides such gateway services to Alice, and Alice calls
> me, but company B intercepts her INVITE and replaces SDP, fingerprints,
> and Identity signature with a Company B signature, and given that I have
> no reason to expect Alice to have used company A instead of company B,
> then I can't detect the attack at all. I see that Alice called me from
> company B. Now, I might be able to ask Alice in-band "Hey, what company
> did you use to call me" and check for a mismatch. This is the "gateway"
> equivalent of the ZRTP-style fingerprint check. But we can't really
> expert normal people to do this consistently.
>
> But back to "reputation:. If I think company B is a reputable gateway
> services provider, then I might well choose to believe their signature
> at least to the extent of using it to detect media-tapping MITMs, even
> if I didn't trust it to give me a real caller ID. It may not give me
> end-to-end security, but at least it lets me know if somebody between B
> and me has tapped the call.
>
> And this gets back to the core of the argument: As a receiver of
> Identity headers, having such a header from a reputable signer is useful
> (for media integrity checks) even if the "username" part of that
> identity header is explicitly not trustworthy.
IMO this discussion is starting to get to the heart of the issue.
That is to identify the kinds of identity service that would be useful
to people and that we have the possibility of providing. Both conditions
are necessary:
- must be useful to people (which implies it is comprehensible)
- must be feasible to deliver
Thanks,
Paul
_______________________________________________
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
