I'm not sure I agree with that. I think we want something that is better than the PSTN. I just don't think it's the right question to ask.
And specifically, I don't think "identity" for PSTN numbers should be our mandate. > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 19, 2008 11:25 > To: Audet, Francois (SC100:3055) > Cc: Jonathan Rosenberg; IETF SIP List > Subject: Re: [Sip] New I-D on RFC4474 and phone numbers > > 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
