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

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Oct 2006 22:40:09 -0500

Hi,

Here are my comments on draft-ietf-sip-consent-framework-00.

General:

I know this has been discussed, but I have some concerns about the  
fact that permissions are not soft-state. This seems contrary to one  
of the most basic SIP design principles. I will address some specific  
issues below. Assuming we have strong reasons to not use soft-state,  
it would be worth including some text in the draft to motivate that  
decision.

(editorial) Can we consolidate the ABNF rather than have it scattered  
throughout?

Specifics:

3.

>    Since the translation operation is based on local policy or local
>    data (such as registrations), it is the vehicle by which a  
> request is
>    delivered directly to an endpoint, when it would not otherwise be
>    possible to.

(editorial) This is not generally true. The "exploder" use case,  
which is one of the biggest motivators for consent, does not in any  
way prevent a sender from directly sending to a particular recipient  
without going through the exploder. This _only_ seems true for proxy/ 
registrars, and then only when permission is applied at policy- 
execution time rather than policy manipulation time. (Maybe I'm  
missing something.)

4.3

>   There are several mechanisms to implement store-and-forward message
>    services (e.g., with an instant message to email gateway).  Any of
>    these mechanisms can be used between a user agent and its store- 
> and-
>    forward server as long as they agree on which mechanism to use.
>    Therefore, this framework does not make any recommendation on the
>    interface between user agents and their store-and-forward servers.

It is not clear to me if store-and-forward servers are a required  
(i.e. normative) part of the consent architecture, or if they are  
just something that might exist. I infer the first, considering the  
draft always assumes the existence of them, and there are clear  
issues about handling permissions when you can't get a MESSAGE to the  
recipient.

If we are going to normatively require them, then I have some  
heartburn about the fact that there is no specification of how they  
work. I don't expect _this_ doc to specify that, but it should be  
somewhere. In particular, if we are going to architecturally require  
them, we as a community should be concerned about interoperability  
between S&F servers and arbitrary UAs, which this document  
_explicitly_ punts on.

Section 4.3:

> Relays always
>    include SIP URIs and may include HTTP [2] URIs for this purpose.
>    Consequently, recipients provide relays with permissions using SIP
>    PUBLISH requests or HTTP GET requests.

Is there normative text somewhere requiring this? If so, I missed it.

Section 5.3:

(General to section):

(editorial) The organization could use some work. The section opened  
discussing
what bodies go into the MESSAGE request, then talked about  
authentication, then comes _back_ to content of the MESSAGE request.  
I suggest consolidating these.

>   Relays MUST obtain permissions from potential recipients before
>    adding them to their translation logics.

Can we make retroactive normative requirements on things like proxy/ 
registrars? Maybe this should be "Relays that implement this  
framework MUST..."

>    MESSAGE requests sent to request permissions MUST include a
>    permission document and SHOULD include a human-readable part in  
> their
>    bodies.  MESSAGE requests also carry a body part that contains the
>    same information as the permission document but in a human-readable
>    format so that user agents that do not understand permission
>    documents can still process the request and display it in a  
> sensible
>    way to the user.

(editorial) The last clause in the first sentence and the second  
sentence seem partially redundant. Also, we may need more spec on  
second sentence--how is a user whose UA does not understand this  
framework expected to do something useful with it? At least an  
example would be helpful

Section 5.6:

>    A client gives a relay permission to execute the translation
>    described in a permission document by sending a SIP PUBLISH or an
>    HTTP GET request to one of the URIs to grant permissions  
> contained in
>    the document.  Similarly, a client denies a relay permission to
>    execute the translation described in a permission document by  
> sending
>    a SIP PUBLISH or an HTTP GET request to one of the URIs to deny
>    permissions contained in the document.

If I use PUBLISH, what goes in the body? Does it matter? I infer that  
an empty
PUBLISH is just fine--if so some clarifying text would help.

Also, if I deny permissions, and the sender tries again later, do I  
get a new permission request? is there a way to say "never bother me  
again"?

>    Relays need to ensure that the SIP PUBLISH or the HTTP GET request
>    received was generated by the recipient of the translation and  
> not by
>    an attacker.

Normative text?

5.6.3:

> The P-Asserted-Identity [4] mechanism can also be used to
>  authenticate the sender of a PUBLISH request.  However, as discussed
>    in RFC 3325 [4], this mechanism should only be used within networks
>    of trusted SIP servers.

(editorial) I seem to recall the statement being stronger than a non- 
normative should in 3325.

5.6.3:

>    Return routability tests do not provide the same level of  
> security as
>    SIP identity, but they provide a good-enough security level in
>    architectures where the SIP identity mechanism is not available
>    (e.g., the current Internet).

(Editorial) By "good-enough", I think we mean "better-than-nothing"

5.8:

> If a client loses this URI for some reason, it
>    needs to wait until it receives a new request produced by the
>    translation.  Such a request will contain a Trigger-Consent header
>    field with a URI.  That URI will have an escaped Refer-To header
>    field identifying the client (i.e., the recipient of the
>    translation).  The client needs to send a REFER request to the  
> URI in
>    the Trigger-Consent header field in order to receive a MESSAGE
>    request from the relay.  Such a MESSAGE request will contain a
>    permission document with a URI to revoke the permission that was
>    previously granted.

This seems like a fairly kludgy way to work around the fact  
permissions live forever. If permissions were soft-state, then we  
could dispense with the escape-hatch for lost deny URLs. Also, one of  
the likely ways for me to lose the deny URL is if I change to a  
different UA, which may not support this framework _at_all_, leaving  
me now way to remove the permission.

5.10 Registrations

General to section:

This section makes me even more concerned about the fact that  
permission is hard-state. Consider that UA contact addresses tend to  
be _highly_ dynamic, and may identify a completely different UA  
tomorrow. For example, I get assigned an address of 10.0.0.1 by DHCP.  
Tomorrow, _you_ get the same address. The permission still exists  
unless someone removed it.

5.11

>    A relay executing a translation that involves sending a request  
> to a
>    URI from which permissions were obtained previously SHOULD add a
>    Trigger-Consent header field to the request.

If we are to stick with hard-state permissions, I think this should  
be a MUST.

6. IANA Considerations

(editorial) Shouldn't we have some text or a table showing where  
these new header fields are allowed? Also, to show for which methods  
the 470 response is allowed.?

7. Security Considerations

> Therefore, it is RECOMMENDED that relays performing
>    translations implement this framework.

There is a bootstrapping problem here--we seem to be placing a  
normative requirement on devices that have been previously specified,  
such as proxy/registrars If so, this document needs to officially  
update those specs, right?

> As pointed out in Section 5.6.3, when return routability tests are
>    used to authenticate recipients granting or denying permissions,  
> the
>    URIs used to grant or deny permissions need to be protected from
>    attackers.  SIPS URIs provide a good tool to meet this requirement,
>    as described in [12].

The presence of store-and-forward servers, where the interface  
between S&F server and recipient is undefined make introduce security  
issues here. If the last hop is not SIP, then SIPS does not  
necessarily help. If we are going to leave these vague, then we  
should mention this in the security considerations.

_______________________________________________
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: Wed, 25 Oct 2006 16:18:45 +0300

Hi Ben,

thanks for your comments. Answers inline:

> it would be worth including some text in the draft to motivate that

yes, you are right. This has been discussed and the conclusion was that
it should be possible for relays to implement soft-states and relays but
we did not want to increase the complexity of the mechanism in any way.

I agree that we should include more text in the draft explaining this
point. I will add the following explanatory text at the end of Section 4.1:

OLD:

Permissions are valid as long as the context where they were granted
is valid or until they are revoked. For example, the permissions
obtained by a URI-list SIP service that distributes MESSAGE requests
to a set of recipients will be valid as long as the URI-list SIP
service exists or until the permissions are revoked.

NEW:

    In principle, permissions are valid as long as the context where they
    were granted is valid or until they are revoked.  For example, the
    permissions obtained by a URI-list SIP service that distributes
    MESSAGE requests to a set of recipients will be valid as long as the
    URI-list SIP service exists or until the permissions are revoked.

    Additionally, if a recipient is removed from a relay's translation
    logic, the relay SHOULD delete the permissions related to that
    recipient.  For example, if the registration of a contact URI expires
    or is otherwise terminated, the registrar deletes the permissions
    related to that contact address.

    It is also RECOMMENDED that relays request recipients to refresh
    their permissions periodically.  If a recipient fails to refresh its
    permissions for a given period of time, the relay SHOULD delete the
    permissions related to that recipient.

       This framework does not provide any recommendation for the values
       of the refreshment intervals because different applications may
       have different requirements to set those values.

> (editorial) Can we consolidate the ABNF rather than have it scattered

I would prefer to keep it where each header field is introduced.

>> data (such as registrations), it is the vehicle by which a request
>> is delivered directly to an endpoint, when it would not otherwise
>> be possible to.
> 
> without going through the exploder. This _only_ seems true for
> proxy/registrars, and then only when permission is applied at
> policy-execution time rather than policy manipulation time. (Maybe
> I'm missing something.)

you are right. The section you are referring to should discuss both
reasons for consent (amplifications and translations based on local
policy) in a clearer way without confusing them. I will make the
following change:

OLD:

    Thus, an essential aspect of a relay is that of translation.  When a
    relay receives a request, it translates, following its translation
    logic, the Request-URI into one or more additional URIs.  That is,
    the relay can create outgoing requests to one or more additional
    URIs.  The translation operation is what creates the consent problem.

    Additionally, since the translation operation can result in more than
    one URI, it is also the source of amplification.  Servers that do not
    perform translations, such as outbound proxy servers, do not cause
    amplification.

    Since the translation operation is based on local policy or local
    data (such as registrations), it is the vehicle by which a request is
    delivered directly to an endpoint, when it would not otherwise be
    possible to.  In other words, if a spammer has the address of a user,
    [email-masked]', it cannot deliver a MESSAGE request to the UA
    (User Agent) of that user without having access to the registration
    data that maps [email-masked]' to the user agent on which that
    user is present.  Thus, it is the usage of this registration data,
    and more generally, the translation logic, which must be authorized
    in order to prevent undesired communications.  Of course, if the
    spammer knows the address of the user agent, it will be able to
    deliver requests directly to it.

NEW:

    Thus, an essential aspect of a relay is that of translation.  When a
    relay receives a request, it translates, following its translation
    logic, the Request-URI into one or more additional URIs.  That is,
    the relay can create outgoing requests to one or more additional
    URIs.  The translation operation is what creates the consent problem.

    The consent problem is created by two types of translations:
    translations based on local data and translations that involve
    amplifications.

    Translation operations based on local policy or local data (such as
    registrations) are the vehicle by which a request is delivered
    directly to an endpoint, when it would not otherwise be possible to.
    In other words, if a spammer has the address of a user,
    [email-masked]', it cannot deliver a MESSAGE request to the UA
    (User Agent) of that user without having access to the registration
    data that maps [email-masked]' to the user agent on which that
    user is present.  Thus, it is the usage of this registration data,
    and more generally, the translation logic, which must be authorized
    in order to prevent undesired communications.  Of course, if the
    spammer knows the address of the user agent, it will be able to
    deliver requests directly to it.

    Translation operations that result in more than one URI are a source
    of amplification.  Servers that do not perform translations, such as
    outbound proxy servers, do not cause amplification.

>>  these mechanisms can be used between a user agent and its
>> store-and- forward server as long as they agree on which mechanism
>> to use. Therefore, this framework does not make any recommendation
>> on the interface between user agents and their store-and-forward
>> servers.
> 
> 

yes, I agree a clarification is needed. I propose to add the following
text at the end of Section 4.3:

NEW TEXT:

    Even though store-and-forward servers perform a useful function and
    they are expected to be deployed in most domains, some domains will
    not deploy them from day one.  However, user agents and relays in
    domains without store-and-forward servers can still use this consent
    framework, although with some limitations.  In particular, relays in
    these domains are not able to request permissions from users that are
    off-line.

> Section 4.3:
> 
>> Relays always include SIP URIs and may include HTTP [2] URIs for
>> this purpose. Consequently, recipients provide relays with
>> permissions using SIP PUBLISH requests or HTTP GET requests.
> 
Yes, it is in Section 5.4:

    URIs to Grant Permission: URIs that recipients can use to grant the
       relay permission to perform the translation described in the
       document.  At least one of these URIs MUST be a SIP or SIPS URI.
       HTTP and HTTPS URIs MAY also be used.

>  discussing what bodies go into the MESSAGE request, then talked
> about authentication, then comes _back_ to content of the MESSAGE
> request. I suggest consolidating these.

Done.

> Can we make retroactive normative requirements on things like 
> proxy/registrars? Maybe this should be "Relays that implement this 
> framework MUST..."

Fixed.

>> their bodies.  MESSAGE requests also carry a body part that
>> contains the same information as the permission document but in a
>> human-readable format so that user agents that do not understand
>> permission documents can still process the request and display it
>> in a sensible way to the user.
> 

I propose the following modification:

OLD:

    MESSAGE requests sent to request permissions MUST include a
    permission document and SHOULD include a human-readable part in their
    bodies.  MESSAGE requests also carry a body part that contains the
    same information as the permission document but in a human-readable
    format so that user agents that do not understand permission
    documents can still process the request and display it in a sensible
    way to the user.

NEW:

    MESSAGE requests sent to request permissions MUST include a
    permission document and SHOULD include a human-readable part in their
    bodies.  The human-readable part contains the same information as the
    permission document (but in a human-readable format), including the
    URIs to grant and deny permissions.  User agents that do not
    understand permission documents can still process the request and
    display it in a sensible way to the user, as they would display any
    other instant message.  This way, even if the user agent does not
    implement this framework, the (human) user will be able to manually
    click on the correct URI in order to grant or deny permissions.

>> HTTP GET request to one of the URIs to grant permissions contained
>> in the document.  Similarly, a client denies a relay permission to 
>> sending a SIP PUBLISH or an HTTP GET request to one of the URIs to
>> deny permissions contained in the document.
> 
> an empty PUBLISH is just fine--if so some clarifying text would help.
> 
Yes, I agree. I have added the following sentence at the end of that
paragraph:

    Requests to grant or deny permissions contain an empty body.

> get a new permission request? is there a way to say "never bother me

No, we do not describe the "never bother me again" functionality.

>> received was generated by the recipient of the translation and not
>> by an attacker.
> 
> Normative text?

I have replaced "need to" with "MUST".

>> authenticate the sender of a PUBLISH request.  However, as
>> discussed in RFC 3325 [4], this mechanism should only be used
>> within networks of trusted SIP servers.
> 
> (editorial) I seem to recall the statement being stronger than a 
> non-normative should in 3325.

yes, but this is a reference to the normative text in 3325. That is, I
do not want to generate a new normative statement here. I just want to
point to the already existing one in 3325. This way, if that statement
is updated somehow (e.g., by a new RFC), we do not have to revise this
RFC as well.

> 5.6.3:
> 
> 
>> Return routability tests do not provide the same level of security
>> as SIP identity, but they provide a good-enough security level in 

Done. I have replaced "good-enough" with "better-than-nothing"

> 5.8:
> 
>> If a client loses this URI for some reason, it needs to wait until
>> it receives a new request produced by the translation.  Such a
>> request will contain a Trigger-Consent header field with a URI.
>> That URI will have an escaped Refer-To header field identifying the
>> client (i.e., the recipient of the translation).  The client needs
>> to send a REFER request to the URI in the Trigger-Consent header
>> field in order to receive a MESSAGE request from the relay.  Such a
>> MESSAGE request will contain a permission document with a URI to
>> revoke the permission that was previously granted.
> 

I already addressed this comment above. Now relays are recommended to
implement soft-states.

> unless someone removed it.

I already addressed this comment above. Now relays are recommended to
implement soft-states. Additionally, we have added text explaining that
when a translation is terminated, the permissions related to it are
deleted. We also added an example of how when a registration is
terminated, the permissions are deleted. Therefore, in your example, the
permissions would be deleted as soon as you unregistered the contact URI
you got from DHCP.

> 
> 5.11
> 
>> A relay executing a translation that involves sending a request to
>> a URI from which permissions were obtained previously SHOULD add a 

I will leave it as a SHOULD, considering the recommendation about
soft-states we have added.

> the 470 response is allowed.?

My personal opinion is that those tables are typically out of date
shortly after they are created and, thus, are useless most of the time.
I would prefer not to add them.

>> Therefore, it is RECOMMENDED that relays performing translations
>> implement this framework.
> 

well, I guess this is something for the ADs to decide. In any case, we
do not need to modify the draft in any way in order to have this RFC
update any other RFC. That would be handled by the RFC editor.

>> the URIs used to grant or deny permissions need to be protected
>> from attackers.  SIPS URIs provide a good tool to meet this
>> requirement, as described in [12].
> 

Good point.  I have added the following text at the end of that paragraph:

   When store-and-forward servers are used, the interface between a user
   agent and its store-and-forward server may not be based on SIP. In
   such case, SIPS cannot be used to secure those URIs. It MUST be
   possible for store-and-forward servers to deliver encrypted and
   integrity-protected messages to their user agents.

I have posted a working copy of the new revision of this draft at:

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

Cheers,

Gonzalo

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Oct 2006 09:52:14 -0500

>       have different requirements to set those values.

That helps, thanks.

> I would prefer to keep it where each header field is introduced.

OK.

>    outbound proxy servers, do not cause amplification.

That helps, thanks.

>    these domains are not able to request permissions from users  

I'm still a little queasy with this one. I will respond in a separate  
email to keep it separate from the other issues.

>       HTTP and HTTPS URIs MAY also be used.

OK, thanks.

>> request. I suggest consolidating these.

Thanks.

>> proxy/registrars? Maybe this should be "Relays that implement this  

Thanks.

>    click on the correct URI in order to grant or deny permissions.

Thanks, that helps.

>>> in the document.  Similarly, a client denies a relay permission  
>>> to execute the translation described in a permission document by

Thanks.

> No, we do not describe the "never bother me again" functionality.

OK, it is probably not worth pursuing at this point.

>>> Relays need to ensure that the SIP PUBLISH or the HTTP GET  
>>> request received was generated by the recipient of the  
>>> translation and not
>>> by an attacker.
>> Normative text?
>

Thanks

> is updated somehow (e.g., by a new RFC), we do not have to revise this

OK

> Done. I have replaced "good-enough" with "better-than-nothing"

Thanks

> I already addressed this comment above. Now relays are recommended to

OK

> permissions would be deleted as soon as you unregistered the  

OK

>>> a URI from which permissions were obtained previously SHOULD add  
>>> a Trigger-Consent header field to the request.

OK

> I would prefer not to add them.

Do you object to the format or the content of such tables?

> update any other RFC. That would be handled by the RFC editor.

OK

>
>>> As pointed out in Section 5.6.3, when return routability tests  
>>> are used to authenticate recipients granting or denying permissions,

Can we put normative requirements on the piece of the architecture  
that may or may not exist? This is sort of like pinning the tail on  
the rumor of a donkey. My point was really that we need to document  
that the security issue exists, depending on what these devices do,  
rather than to state what they must do.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Oct 2006 16:15:29 -0500

I'm separating my response about the consent-framework store and  
forward issue from the other issues, since I think this one needs  
more discussion. Specific's inline

[...]

>    these domains are not able to request permissions from users  

I'm still uncomfortable with this. The proposed text still implies  
that S&F servers are needed for a "complete" consent-framework  
solution, and that the framework essentially fails without them.

1) Specify consent-framework behavior from the assumption that no  
such thing exists, at least in the common case. That is, talk in some  
detail about what you do when the MESSAGE requests fail, and whether  
you should retry later, how often to retry, etc. We could point out  
that if an S&F type server were present, then an offline target  
should not cause the MESSAGE request to fail, but that would be about  
all we could say about them.

2) Recognize that the consent-framework has an architectural  
dependency on S&F servers, and have one of the related WGs go down  
the path of specifying one, to be normatively referenced here.

I realize that option 2 is not a tenable solution, as it would block  
progress on the consent-framework for some time. My opinion is that  
we should go with option 1. If at some time in the future we  
standardize an S&F server, we could discuss their use in more detail  
in a separate draft.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Oct 2006 10:24:29 +0300

Hi Ben,

>>> 6. IANA Considerations (editorial) Shouldn't we have some text or
>>> a table showing where these new header fields are allowed? Also,
>>> to show for which methods the 470 response is allowed.?
>> 
>> shortly after they are created and, thus, are useless most of the
>> time. I would prefer not to add them.
> 

many people complain that the format of those tables make them difficult
to understand, but I was talking about their content. As soon as a new
method o a new response code is created, those tables are typically out
of date. Usually, it is enough if drafts explain header fields'
restrictions using normative text.

In any case, I do not think we need such tables for this particular draft.

>> When store-and-forward servers are used, the interface between a
>> user agent and its store-and-forward server may not be based on
>> SIP. In such case, SIPS cannot be used to secure those URIs. It
>> MUST be possible for store-and-forward servers to deliver encrypted
>> and integrity-protected messages to their user agents.
>> 
>> 
> 

I believe putting a requirement on the type of store and forward server
that can be used with this framework is completely OK. However, if you
would like to remove the normative MUST, we can do that. Feel free to
edit the paragraph I proposed so that you are happy with it.

Thanks,

Gonzalo