Couldn't have put it better myself. +1
Thanks, Alan 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 > > > _______________________________________________ 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
