IMO its up to the owner of the UA and his SP whether the UA has the cert
and does the signing, or the SP acts as an agent for the UA, holding the
cert and doing the signing. While I would like it to be possible for a
user to do this himself, most probably won't want to, and most providers
won't want to let them. While sad, it would probably be good enough if I
had to go looking for a provider that would let me manage my own cert.
Similarly, on the verification side I can see how many UASs would prefer
to have a SP do the hard verification and just relay the results on via
a P-A-ID header. It would however be good if a UAS *could* do the
verification itself - which means that the public key must be accessible
to it in some way.
IMO the part that gives me the most worry is if there is reluctance to
*define* ownership. But I don't think I believe that is a real problem.
I will bet that if somebody shows up with a warrant demanding the
disclosure of the owner of some phone number, the SP will be willing and
able to provide an answer, and defend it in court.
I presume the real reluctance is to *disclose* the ownership to anyone
who asks, for both business and legal reasons. But if its not the
identity, but simply the public key or cert that is disclosed, then I
would hope it would be hard to justify keeping it private. But perhaps
that is just wishful thinking on my part.
Paul
Hadriel Kaplan wrote:
> Actually, I'm not even sure it really requires that. It is debatable if you
> truly own your number, and certainly debatable if CA roots would be willing
> to sign off on certs that are given to direct end users if the SP acts as an
> agent middle-man. (that basically breaks their vetting process, no?) On the
> other hand, if you'll allow solely for the UAC's and UAS's local
> providers/enterprise's to do the authentication *and* verification, and give
> up on the UAS being able to verify directly, then it may be more palatable
> and potentially succeed.
>
> For example, if you are willing to ignore DNS' lack of security (assuming
> there is no dnssec), then all you really need is a DNS root to get ownership
> domain names from for the numbers, rather than certs per number or entry. In
> other words let enum return the naptr identifying the owner's domain name,
> rather than a next-hop route resolution or certificate directly. Then just
> check that the 4474-provided cert matches that name. Obviously if DNS is
> subverted, or the DNS request intercepted or response spoofed, it breaks.
> But it's a lot lighter weight and manageable than putting a cert per number
> into the DNS. Heck, even using dnssec it would probably be lighter weight.
>
> Whether providers would be willing to put that ownership info into a public
> dns tree I don't know. But they might be willing to in a non-public tree
> only other providers could use. (since that info is essentially already
> available in SS7) Or even exchange that info with each other. I believe
> that is one possible logical outcome of Peppermint, for example.
>
> -hadriel
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul
>> Kyzivat
>> Sent: Monday, February 18, 2008 4:40 PM
>> To: Jonathan Rosenberg
>> Cc: IETF SIP List
>> Subject: Re: [Sip] New I-D on RFC4474 and phone numbers
>>
>> 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
>
_______________________________________________
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
