I think we don't need something *better* than the PSTN, though that
would be nice. What I think we need is something that is *not worse*
than the PSTN. The problem is defining what that means.
I think that means at least:
- when you connect via sip you get a callerid for at least those
pstn callers where you would have gotten one if you had a pstn phone
*and* that callerid was "correct".
- callerid is available to callees from sip callers with E.164 AORs
when it hasn't been intentionally blocked and the caller is the
legitimate "owner" of the number.
- the frequency with which "incorrect" (spoofed) callerid is delivered
to callees is no worse, on average, than with pure pstn calls.
I realize this are a bit vague and hard to measure. But I think this is
subjectively what will be required for sip to be widely accepted as a
substitute for pstn phone service.
Paul
Francois Audet wrote:
> Another "solution" is to not do it.
>
> By that I mean, use RFC 4474 for domain-based security, and if you
> insist on using phone numbers, then it's not "secured that way".
>
> Before the flaming start: by definition, if something is addressed by a phone
> number, it is something that is likely to be reacheable through the PSTN.
>
> The way security works in the PSTN is completely different. The media is
> almost
> never encrypted for one. So in the context of SIP, it means there is a
> gateway
> somewhere destroying the end-to-end nature of the encryption.
>
> Even for the Identity, it's different. For one thing, the Identity assertion
> is not end-to-end à-la-RFC 4474.
>
> So, I'm proposing that if you are using phone numbers as your identity, then
> it is not a design requirement of this group to re-invent a "better" identity
> security system for the PSTN.
>
> It's not because something is a problem that it necessarily needs to be
> solved.
>
> My 2 cents.
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Jonathan Rosenberg
>> Sent: Monday, February 18, 2008 11:36
>> To: Paul Kyzivat
>> Cc: IETF SIP List
>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers
>>
>> I agree that something along the lines of enum could solve
>> this problem, and I believe there was a draft that proposed
>> such a thing. This has been discussed since the start of rfc4474.
>>
>> However, I fear that saying, 'use enum' is kind of like
>> saying, we'll just use an All-Knowing Oracle, so lets figure
>> out the interface protocol to the Oracle. The easy part is
>> the interface (the enum mechanism). The actual hard problem
>> is how to get those entries populated. The deployment of
>> public enum has been - shall we say - less than spectacular.
>> I'd hate for that to be our only solution. Not that its
>> obvious what else to do; though I do suggest in my draft how
>> domain based authentication, when combined with whitelists
>> and blacklists, can help.
>>
>> -Jonathan R.
>>
>> Paul Kyzivat wrote:
>>> Jonathan,
>>>
>>> I guess the time has come for this discussion, since John Ewell has
>>> also submitted a draft on this subject.
>>>
>>> I thought the problem was already well known, but perhaps
>> not. IMO the
>>> main thing now is to figure out the *solution* to the problem!
>>> IMO a solution is to use a 4474-style approach, but where the
>>> certificate is tied to just the phone number, not to some arbitrary
>>> domain name. That of course would depend on a model where
>> the "owner"
>>> of the phone number is the one who may obtain the
>> certificate for that number.
>>> My thought is that we already have an algorithmic mapping from an
>>> E.164 phone number to a domain name, defined by enum. If the sender
>>> puts an
>>> E.164 number in From, and can sign it with a cert for the
>> enum mapped
>>> domain name corresponding to that number, then that ought
>> to be valid
>>> proof of the validity of the sender.
>>>
>>> In those places where public enum is in operation, I think there is
>>> already a legal mechanism in place to give the owner of record of a
>>> particular phone number control over the contents of the
>> corresponding
>>> DNS entry. That should also be sufficient to allow a certificate
>>> authority to assign a cert to that same owner.
>>>
>>> Combine all that and you have a complete e2e identity model
>> for phone
>>> numbers, based on public enum. And that can be true even if public
>>> enum isn't used to *route* the calls to that number. So it could be
>>> used for "unlisted" numbers.
>>>
>>> To use this approach the From header should contain either
>> a TEL URI,
>>> or a sip/sips URI containing the enum-mapped domain name
>> corresponding
>>> to the phone number. (I would rather see the TEL used for
>> this - it is
>>> more user friendly.)
>>>
>>> Thanks,
>>> Paul
>>>
>>> Jonathan Rosenberg wrote:
>>>> I just submitted:
>>>>
>> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-rfc4474-conce
>>>> rns-00.txt
>>>>
>>>>
>>>> This is basically a discussion on the security properties
>> of rfc4474
>>>> with phone numbers, and a comparison to rfc3325 in this
>> case. Also a
>>>> discussion on what happens to dtls-srtp.
>>>>
>>>> Comments welcome.
>>>>
>>>> -Jonathan R.
>> --
>> Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
>> Cisco Fellow Edison, NJ 08837
>> Cisco, Voice Technology Group
>> [EMAIL PROTECTED]
>> http://www.jdrosen.net PHONE: (408) 902-3084
>> http://www.cisco.com
>> _______________________________________________
>> Sip mailing list http://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 http://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
