Subject: [Sipping] Consent framework

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 20 Feb 2005 09:53:55 +0200

Folks,

we have submitted a new revision of the consent framework. Until it 
appears in the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-ietf-sipping-consent-framework-01.txt

All the open issues are cleary marked as "OPEN ISSUE" in the draft. We 
would appreciate feedback on them.

The main changes are that now SIP PUBLISH is used to upload permission 
documents (before XCAP was used) and that clients place the URIs 
received by the relay (each URI identifies a particular translation at 
the relay) in a header field, instead of in the Request-URI.

Using a header field seems to clearer in multi-relay scenarios like the 
one shown in Figure 5 of the document, but we woule like to discuss the 
merits of both approaches.

Thanks,

Gonzalo

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2005 14:25:42 -0500

In principle the consent framework should apply to endpoints registering 
contacts with the registrar for their AoR, and the proxy responsible for 
that AoR. In fact, section 8.3 aludes to this.

But are we seriously imagining that devices which register with an AoR 
must still explicit consent to all callers?

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.

	Paul

---

From: David R Oran <[email-masked]>
Date: Wed, 23 Feb 2005 09:52:19 -0500

On Feb 22, 2005, at 2:25 PM, Paul Kyzivat wrote:

> In principle the consent framework should apply to endpoints 
> registering contacts with the registrar for their AoR, and the proxy 
> responsible for that AoR. In fact, section 8.3 aludes to this.
>
> 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.
>
I also wonder if there isn't a downside to explicit consent requests 
being sent back to a UAC. It reveals information (Contact URIs) that 
otherwise might remain invisible to a caller/subscriber. It's clearly 
required to make the general scheme work, but does have consequences.

Do people think this is a concern? I'm not sure myself, but I thought 
I'd raise it just to rattle the cage a bit.

Dave.

> 	Paul
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Feb 2005 09:59:14 -0500

Gonzalo Camarillo wrote:

> 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).
> 
> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Feb 2005 10:23:38 +0200

Hi Paul,

> that AoR. In fact, section 8.3 aludes to this.

Yes, Section 8.3 talks about Intermediate Relays.

etc...

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Feb 2005 21:22:59 +0200

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.

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.

Thanks,

Gonzalo

Paul Kyzivat wrote:
> 
> Gonzalo Camarillo wrote:
> 
> 
>>> But are we seriously imagining that devices which register with
>>> an
> 
> AoR
> 
>> Yes, Section 9 should deal with installing permissions in advance.
> 
> That
> 
>> likely, you will want to use some type of wildcarding mechanism for
>> 
> 
> the
> 
>>>  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.
>> 
>>  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...
>> 
>> 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).
>> 
>> If we do not consider that a REGISTER gives implicit permissions,
>> we
> 
> do
> 
>> not have this problem.
> 
> 
> 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.
> 
>  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.
>