Subject: Re: [Sipping] Consent framework

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2005 19:26:20 -0500

Gonzalo Camarillo wrote:
> Hi Paul,
> 
> there are two issues, both of which are introduced in the Security
> Considerations Section, which I will expand as soon as I get around to it.
> 
> The first thing you want to avoid is that I give permissions for your
> registration. To achieve this, the relay only accepts stuff that is
> signed by you (or on your behalf using SIP identity).
> 
> The second thing you want to avoid is what I explained in my previous
> mail. You do not want me to register your devices under my AoR so that
> the proxy sends you unsolicited traffic every time something addressed
> to my AoR arrives. To avoid this, we use a return routability test. That
> is, the CONSENT request will be routed to the Contact addresses that
> have been registered. The CONSENT carries a token, and if you do not
> know the token, you cannot upload permissions for the translation.

Sorry, maybe I am just being stupid here, but I am not getting this.
Lets contrast two scenarios:

1) sip:exploder.com is a relay. I have prepopulated it with a list 
denoted by sip:[email-masked]. The list contains AoRs, 
sip:[email-masked] and sip:[email-masked]. I would like to send 
MESSAGEs to it and have them exploded.

In this case we are requiring that there be consent from alice and bob 
before exploding to them. I send the CONSENT requests and they go to bob 
and alice. They can each provide consent using PUBLISH messages that 
identify them using the identity draft. Their identities are signed by 
example.com for the addresses [email-masked] and [email-masked]. 
This all makes sense to me.

2) sip:[email-masked] is my AoR. I have a device 
sip:[email-masked] that I want to register with my AoR. I can do 
this using digest authentication. I guess you consider [email-masked] 
to be a relay too, so before requests to [email-masked] can be relayed 
to my pc, there must be consent on behalf of my pc.

But how is that consent achieved?

One possibility is to wait for a request to be directed to my AoR - for 
instance you sending me an INVITE. Then this will be rejected for lack 
of consent. If you are cooperative, then you will send a CONSENT and 
this will send a CONSENT to my pc and then maybe good things will happen 
(more on this below) and eventually you will be able to retry your 
request. This seems like a really bad approach.

The other option provided in the draft (in section 9) is for the target 
to send a CONSENT. In this case it would be my pc, after registering, 
sending a CONSENT to trigger permitting itself to be relayed to. This is 
at least slightly more plausible.

Either way results in my pc receiving a CONSENT with the needed URI for 
publishing consent. It then must PUBLISH a document, identified 
according to the identity draft. But to do that it must either act as 
its own identity server, which requires it to have a cert for 
[email-masked] or pc.paul.example.org, or else there must be an 
identity server it can use that has such a cert. Neither is likely. (In 
fact, probably no credentials exist showing that I am entitled to direct 
my calls at that device. Its even worse in the common case where the 
device only has a transient address from DHCP, and no DNS name at all.) 
So I don't see how it can grant consent with the rules provided.

> Return routability tests do not provide perfect security, but provide
> good enough security in many cases (e.g., MIPv4). I believe that the
> security provided is good enough for this case.

For this to work I think you have to remove the requirement that the 
PUBLISH be identified according to the identity draft in some cases. You 
have to open up a time window from when you send the CONSENT where you 
take a publish without that. Seems pretty loose, but I don't see any way 
around it.

(Perhaps a new mechanism can be used, where a secret is conveyed to the 
relay in the initial CONSENT request/response that is then also conveyed 
in the resulting PUBLISH. If they match, then it proves there was 
cooperation by the consent requestor and the grantor.)

Even then this is probably going to introduce intolerable processing on 
the system. We know there are avalanch restart situations when lots of 
registrations need to be done in a short time. This consent framework 
multiplies the work required to do a registration by a lot - probably an 
order of magnitude. So I just don't think it is going to fly any time soon.

	Paul

> Thanks,
> 
> Gonzalo
> 
> 
> 
> Paul Kyzivat wrote:
> 
>>
>> Gonzalo Camarillo wrote:
>>
>>
>>>> But are we seriously imagining that devices which register with
>>>> an
>>>
>>
>> AoR
>>
>>>> must still explicit consent to all callers?
>>>
>>>
>>> Yes, Section 9 should deal with installing permissions in advance.
>>
>>
>> That
>>
>>> is, you register and then you provide a permission document. Most 
>>> likely, you will want to use some type of wildcarding mechanism for
>>>
>>
>> the
>>
>>> senders (e.g., allow any sender to reach me).
>>>
>>>
>>>> IMO registration can be viewed as another way to give consent to
>>>>  whatever callers the proxy for the AoR decides to accept.
>>>> Consent there is implicit, or is managed at the AoR level rather
>>>> than the individual UAS level.
>>>
>>>
>>> The problem with accepting registrations as an implicit way to give
>>>  consent is that it makes some attacks possible. For example, I
>>> send a REGISTER that binds my AoR (sip:[email-masked]) to a
>>> set of
>>
>>
>> contact
>>
>>> addresses:
>>>
>>> sip:[email-masked] sip:[email-masked] 
>>> sip:[email-masked] sip:[email-masked]
>>>
>>> etc...
>>>
>>> Since the REGISTER applies to my AoR and it was sent by me, it is 
>>> authorized by the registrar. Now, by simply sending a SIP request
>>> to sip:[email-masked], the proxy will fork in parallel to all
>>> the contacts above (which may be a lot of them).
>>>
>>> The problem is that device.example.com belongs to you. What I am 
>>> creating is an applification attack against you.
>>>
>>> If we do not consider that a REGISTER gives implicit permissions,
>>> we
>>
>>
>> do
>>
>>> not have this problem.
>>
>>
>>
>> OK. That makes sense. But then I am not understanding something 
>> fundamental about how the granting of permission works. The draft
>> says that the publication of permission is signed using the identity
>> draft. But which identity is used for authorization of device
>> contacts? The only identity that is likely to be available is that
>> for the same AoR that we are trying to install consent with. This
>> means that the right to
>>
>> install the permissions are tied directly to the same secret needed
>> to register. So this is no more secure than simply treating
>> registration as
>>
>> implicit consent.
>>
>> Now this would not be the case if you could only give consent for the
>>  address that *is* an identity. That would prevent you from
>> registering someone else's AoR as a contact of your AoR. But it would
>> also prevent you from registering your own devices.
>>
>> The basic issue is that there is no way to distinguish *my* devices
>> from
>>
>> somebody else's devices.
>>
>> I don't immediately see any way out of this.
>>
>> Paul
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 21:11:06 -0800

The example looked like only 3rd party registrations were a problem. Did I
get this right? I think 3rd party are not really a registration at all but
more setting up a forwarding list so consent makes sense for that but not
for normal registration which have implicit consent and a revocation
mechanism.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Mar 2005 01:08:22 -0500

> for normal registration which have implicit consent and a revocation

How would one case be distinguished from the other? Either way the 
registrar is being given a URI that is opaque to it. It has no basis to 
say "this one is a device that doesn't need consent, while that one is a 
foreign AoR that does need consent".

It seems to me that Gonzalo wants even the real devices to provide 
consent. But I see no way to achieve that.

	Paul