Subject: [Sip] Review of draft-ietf-sip-consent-framework-00.txt

From: Shida Schubert <[email-masked]>
Date: Thu, 05 Oct 2006 14:15:36 -0700

Draft:  draft-ietf-sip-consent-framework-00.txt
Reviewer: Shida Schubert
Review Date: 28 Sept 2006
Review Deadline: 17 Oct 2006
Status: WGLC

Summary: This draft needs some clarification and some security 
considerations before moving forward.

Question for clarification:
----------------------------
1. The Consent-FW allows recipient to grant or deny 
   relay from conducting translation but there is no 
   mentioning of how senders are granted to send message to 
   the target-URI which gets translated to one or more 
   messages aimed for each recipient URI in the translation 
   logic. This may not be needed if sender is limited to a unique sender 
   but since one can set "any" as sender in consent format, 
   it can become quite problematic.
 
   As there is no authorization policy to restrict a sender 
   from sending the message, any malicious user who has access 
   to the target-URI seems to have the ability to abuse the 
   target-URI and ban-burden the recipients who have granted 
   the translation.
   
   Additional question is, are any users granting the translation 
   also allowed to send the message to the target-URI to request 
   translation? If we look at the mailing list which is very 
   similar in concept you usually are.

2. Section 5.4, 7th paragraph, 2nd sentence describes how 
   the permission document may request permission for any relay
   to forward requests > It's not clear how this works. It 
   sounds as though permission document submitted to the entity
   (relay) represented by the URI contained in the permission document 
   is distributed(propagated) to all the relays?? 
   
    I can understand if you can specify a relay by domains 
   but what does "any" relay really mean? And how would the permission 
   document triggered by "Trigger-Consent" look like? Would it 
   have the "any" as a relay(Original recipient) or only the 
   URI of the original recipient which invoked the "trigger-consent"
   action?

3. Although reading both the permission document and the framework 
   document, one can imagine how the state of the permission would 
   change but there is no recommendation as to when the state should 
   be X in neither of the documents, which I think may be useful if 
   text is added.

4. There is no text on how the permission document should be 
   displayed to the user(What contents to display in case the UA 
   user uses does not support this FW)? It may be out of scope but 
   necessary information to submit the authorization decision may 
   be presented as a recommendation may be useful. 

5. There is no way to express the authentication methods used by 
   relay to authenticate the permission document submitted by the 
   recipient. I think this needs to be communicated somehow or at 
   least one method must be mandatory to implement/support on both 
   the UA/relay supporting this mechanism. 

6. It's possible that user only wants to accept a particular 
   call such as PPT invitation represented as a target-URI on a 
   particular device. Should we allow user to change the recipient URI 
   in the permission document so may be user can change the AoR to GRUU 
   pointing to a particular instance??

7. There is no way to express the reason user rejected the authorization 
   for translation. It's possible that user would have granted the 
   translation if the sender was limited to user A and B or if the recipient
   URI was a particular contact address(GRUU). Should we allow
   the UA to change the permission document at all?

8. Section 5.6.1, does not describe how exactly the identity matching is 
   done? Does it compare the value in FROM header to the recipient URI 
   in the permission document? If so UA better make sure it sets the 
   value recommended and the recommendation better be described here. 
   * UA can obtain a SIP-Identity without putting a proper AoR according 
     to the RFC 4474 AFAIK.

9. Section 5.9 describes the behavior of the relay when the recipient 
   has not granted the translation but the behavior of relay when its 
   not dealing with the URI-list service for a similar situation is 
   unspecified.

10. I think in the security consideration, the authentication of the user 
   who modifies the translation logic should be recommended.
   * AFAIK, the consent-fw allows me to trigger a MESSAGE with 
     permission document to be sent with me pretending to be somebody 
     else. (value of FROM is not authenticated.) It might be attractive 
     enough for malicious user to have the ability to withhold identity 
     and ban-burden others with meaningless messages.

11. This is related to permission documents but, permission documents AFAIR
   does not have any placeholder to describe why the permission is requested.
   I don't remember such element in common policy where one can describe such 
   information. 

General comments:
---------------
  This might simply be my preference, and may not be suitable for FW document 
  but I personally like it when the document is composed to describe each 
  entity's behavior separately. >> UA's behavior, Relay's behavior, Proxy's behavior etc.  

Editorial nits:
----------------
 Section 3:
  - Paragraph 6 last sentence:
   [ ADD "entity performing" before URI-list service if 
     URI-list service describes function rather than an entity ]

   OLD: This relay may be, for instance, a proxy server or a
        URI-list service

   NEW: This relay may be, for instance, a proxy server or an
        entity performing URI-list service

 Section 4:
  - Paragraph 1 last sentence:
   [ REMOVE "permissions" ]
  
   OLD: Section 4.4 describes how potential recipients can grant a 
    relay permissions to add them to the relay's translation logic.

   NEW: Section 4.4 describes how potential recipients can grant a 
    relay to add them to the relay's translation logic.

 Section 4.1: 
  - Paragraph 1 2nd sentence:
   [ADD "or denied" REMOVE "or not"]

   OLD: These permissions indicate if a particular recipient has 
    agreed to receive traffic or not at any given time.

   NEW: These permissions indicate if a particular recipient has 
    agreed or denied to receive traffic at any given time.

  - Paragraph 5 1st sentence:
   [ CHANGE SHOULD to MUST ]
   
   REASON: I don't think the service is of any use unless there 
    is a way for UA to find out the pending status..

 Reference
  > Update the reference to service-uri-services from 05 to 06.
  > Update the reference to consent-format from 00 to 01
 
 Regards
  Shida 

_______________________________________________
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