I agree that the problem exists. But in the end for any signing based on
number to work there must be a tie to the legal notion of ownership of
e.164 numbers. There is no getting around that. Its just a matter of
whether there is *one* system for tying to ownership, or two.
In this case it doesn't require that dns entries in the e164.ansi tree
be populated. Rather it requires that some CAs support the legal
framework for assigning certs, based on the same definitions of ownership.
It isn't essential that the certs be distributed to the end users owning
the numbers. A SP could act as an agent for the user in managing the
cert and doing the signing. (But an end user who wants to sign his own
requests should be able to get the cert.)
Paul
Jonathan Rosenberg wrote:
> 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-concerns-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.
>>
>
_______________________________________________
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
