Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00

From: Dean Willis <[email-masked]>
Date: Tue, 03 Oct 2006 13:41:18 -0500

[email-masked] wrote:
> Major technical comment on section 5.8: the proposed Trigger-Consent 
> mechanism looks like one big hack to me. It does not comply with 
> RFC3515, and appears to be an inappropriate use of REFER. Suggestion: 
> use SUBSCRIBE / NOTIFY
> 
> Technical comment on Trigger-Consent: the ABNF in section 5.11 allows 
> multiple instances of this header. Is this desired? If so, a note on 
> what should be done when multiple instances are present is needed. If 
> not, the ABNF should be adapted ( I suspect the latter is the 
> appropriate choice )
> 
> Minor technical comment on Figure 5 and the example in 5.11: the 
> escaping of the Refer-To URI is invalid, '<' and '>' should be %-encoded 
> too (but: see first comment, suggest to remove this Refer-To header 
> entirely)

Ok, good comments. Anybody else read this draft?

I'm worried that we're not really getting the needed level of review 
here. Suggestions?

--
Dean

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 14 Oct 2006 12:42:50 +0300

Hi,

> RFC3515, and appears to be an inappropriate use of REFER. Suggestion:

we cannot use SUBSCRIBE/NOTIFY because the entity receiving the original
request may not have any means to authenticate itself to the relay that
stores the permission. That's why we need to be able to use the return
routability mechanism described in the draft.

The mechanism to trigger a new MESSAGE request with a permission
document towards the recipient needs to:

1) inform the recipient about the recipient URI of the translation
2) provide a SIP URI that, if touched, will trigger a new MESSAGE request.

Therefore, an alternative solution (which was discussed in the past) to
the REFER approach would be to define the Trigger-Consent header field
so that it contains the recipient URI of the translation and a SIP URI.
The recipient would send a PUBLISH request (instead of a REFER) to that
URI to trigger a new MESSAGE request with a permission document.

The reason why the Trigger-Consent header field needs to carry the
recipient URI of the translation is because a request can go through
more than one translation before reaching the recipient.

>  multiple instances of this header. Is this desired?

I answered this above.

If folks prefer this PUBLISH-based solution over the REFER-based
solution I can edit the draft accordingly.

Cheers,

Gonzalo

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 14 Oct 2006 20:04:31 +0200

Gonzalo,

Thanks for your response.

What I had in mind when I suggested SUBSCRIBE/NOTIFY is the following: the 
relay adds a Trigger-Consent header as described, using a return 
routeability test (ie random username, etc). The receiving client then 
SUBSCRIBEs to that URI, for a TBD event package, providing a Contact as 
usual. The relay then sends a NOTIFY to the client Contact, with a body 
containing the permission document

I believe this scheme has similar security properties as the REFER/MESSAGE 
scheme. A difference is that the permission document gets sent to a Contact 
address instead of an AoR, which seems desirable (if not, how do you ensure 
that it gets sent to the same UA as the INVITE?)

Regards,
Jeroen

Gonzalo Camarillo wrote:
> we cannot use SUBSCRIBE/NOTIFY because the entity receiving the
> original request may not have any means to authenticate itself to the
> relay that stores the permission. That's why we need to be able to
> use the return routability mechanism described in the draft.
>
> Therefore, an alternative solution (which was discussed in the past)
> to the REFER approach would be to define the Trigger-Consent header
> field so that it contains the recipient URI of the translation and a SIP
> URI. The recipient would send a PUBLISH request (instead of a REFER)
> to that URI to trigger a new MESSAGE request with a permission
> document.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 14 Oct 2006 21:09:29 +0300

Hi,

there is a mechanism for relays to send permission documents to
recipients. Creating a second one is not a good idea. We need to reuse
that mechanism.

In any case, what you are proposing seems like the same mechanism
changing the methods. Instead of a PUBLISH followed by a MESSAGE you
would have a SUBSCRIBE followed by a NOTIFY.

Therefore, I believe that the PUBLISH-based solution meets your
requirements and, additionally, reuses the mechanisms already defined in
the framework.

If nobody objects I will edit the draft accordingly.

Thanks,

Gonzalo

Jeroen van Bemmel wrote:
> What I had in mind when I suggested SUBSCRIBE/NOTIFY is the
> following: the relay adds a Trigger-Consent header as described,
> using a return routeability test (ie random username, etc). The
> receiving client then SUBSCRIBEs to that URI, for a TBD event
> package, providing a Contact as usual. The relay then sends a NOTIFY
> to the client Contact, with a body containing the permission document
> 
> 
> I believe this scheme has similar security properties as the 
> REFER/MESSAGE scheme. A difference is that the permission document
> gets sent to a Contact address instead of an AoR, which seems
> desirable (if not, how do you ensure that it gets sent to the same UA
> as the INVITE?)
> 
> Regards, Jeroen
> 
> Gonzalo Camarillo wrote:
>> Hi,
>> 
>>> Major technical comment on section 5.8: the proposed
>>> Trigger-Consent mechanism looks like one big hack to me. It does
>>> not comply with RFC3515, and appears to be an inappropriate use
>>> of REFER. Suggestion: use SUBSCRIBE / NOTIFY
>> 
>> original request may not have any means to authenticate itself to
>> the relay that stores the permission. That's why we need to be able
>> to use the return routability mechanism described in the draft.
>> 
>> 2) provide a SIP URI that, if touched, will trigger a new MESSAGE 
>> request. Therefore, an alternative solution (which was discussed in
>> the past) to the REFER approach would be to define the
>> Trigger-Consent header field so that it contains the recipient URI
>> of the translation and a SIP URI. The recipient would send a
>> PUBLISH request (instead of a REFER) to that URI to trigger a new
>> MESSAGE request with a permission document. The reason why the
>> Trigger-Consent header field needs to carry the recipient URI of
>> the translation is because a request can go through more than one
>> translation before reaching the recipient.
>> 
>>> Technical comment on Trigger-Consent: the ABNF in section 5.11
>>> allows multiple instances of this header. Is this desired?
>> 
>> I answered this above.
>>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 14 Oct 2006 23:38:32 +0200

Gonzalo,

I agree that PUBLISH is an improvement over REFER, although a PUBLISH with 
an empty body is uncommon. Another alternative could be a new 6xx response 
code (or a new header to be used in an error response), i.e. one meaning 
"Decline and please send me the permissions document again."

Perhaps it is already intended, but the current text in section 5.8 does not 
spell out that the URI in the Trigger-Consent header should be hard to guess 
(to prevent a DoS attack in which an attacker requests someone elses 
permissions document, and then revokes relay permissions). Ideally, it would 
not even contain the target towards which the permissions documents will get 
sent. The relay could encode this association into the URI, such that an 
attacker cannot change the target

The above works better with PUBLISH, the information that would normally go 
in the Refer-To header can then remain implicit

Regards,
Jeroen

Gonzalo Camarillo wrote:
> requirements and, additionally, reuses the mechanisms already defined
> in the framework.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 15 Oct 2006 09:30:41 +0300

Hi,

> I agree that PUBLISH is an improvement over REFER, although a PUBLISH 
> with an empty body is uncommon. Another alternative could be a new 6xx 
> response code (or a new header to be used in an error response), i.e. 
> one meaning "Decline and please send me the permissions document again."

error responses may not reach the relay if there was a proxy between the 
relay and the recipient.

Regarding requests without body, empty HTTP GETs are common when one 
needs to simply 'touch' a URI, like in this case.

> Perhaps it is already intended, but the current text in section 5.8 does 
> not spell out that the URI in the Trigger-Consent header should be hard 
> to guess (to prevent a DoS attack in which an attacker requests someone 
> elses permissions document, and then revokes relay permissions). 
> Ideally, it would not even contain the target towards which the 
> permissions documents will get sent. The relay could encode this 
> association into the URI, such that an attacker cannot change the target

The recipient URI appears in the Trigger-Consent header field only for 
the information of the recipient. The relay will send the MESSAGE with 
the permission document to the recipient URI of the permission document. 
Nothing can change that.

> The above works better with PUBLISH, the information that would normally 
> go in the Refer-To header can then remain implicit

as I said in my previous posting, that information is there in case a 
request traverses more than one relay and, thus, gets more than one 
Trigger-Consent entries. This way, the recipient knows which particular 
permission each Trigger-Consent entry can revoke.

Cheers,

Gonzalo

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 15 Oct 2006 17:05:31 +0200

Gonzalo,

> the permission document to the recipient URI of the permission
> document. Nothing can change that.
>
>> The above works better with PUBLISH, the information that would
>> normally go in the Refer-To header can then remain implicit
>
> Trigger-Consent entries. This way, the recipient knows which
> particular permission each Trigger-Consent entry can revoke.

So you're saying that whatever is in the Refer-To header of the REFER 
request (following the mechanism in the current draft), is ignored? The 
relay will send the MESSAGE to the recipient URI?

If this information is ignored, I would suggest a different ABNF for the 
Trigger-Consent header (for use with PUBLISH):
Trigger-Consent: 
<sip:uri-to-publish@relay>;target="sip:recipient.example.com"

This allows the client to know which permission document it applies to, 
without putting it in the URI (where it is ignored anyway)

Regards,
Jeroen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 15 Oct 2006 23:05:41 +0300

Hi,

> <sip:uri-to-publish@relay>;target="sip:recipient.example.com"

yes, this is what I suggested in my previous email.

Thanks,

Gonzalo

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Oct 2006 21:57:06 -0500

On Oct 14, 2006, at 4:42 AM, Gonzalo Camarillo wrote:

[snip]

> solution I can edit the draft accordingly.

I am reviewing in a separate email, but I will state here that I do  
like the publish approach better than the refer approach--but why use  
the
additional step of the Trigger-Consent? Why not just send the "deny"  
URL in each translated request, and let the recipient skip the step  
of requesting
a new permissions document just to get the deny URL? (I'm sure there  
is a very good reason that we have already discussed.)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Oct 2006 08:55:43 +0300

Hi Ben,

> like the publish approach better than the refer approach

good.

> --but why use the additional step of the Trigger-Consent? Why not
> just send the "deny" URL in each translated request, and let the
> recipient skip the step of requesting a new permissions document just
> to get the deny URL? (I'm sure there is a very good reason that we
> have already discussed.)

yes, it was discussed. That would require the relay to use SIPS for
*all* its outgoing requests. Otherwise, attackers could get their hands
on the URI to revoke permissions and perform a DoS attack.

Cheers,

Gonzalo