[Sipping] Re: Expert review of draft-camarillo-sipping-profile-key-00.txt

[Gonzalo Camarillo <[e-mail]>]

Hi Miguel Angel,

thanks for your review. I have put together a new revision of the draft
that addresses all your comments. Please, let me know if you have any
further comments on this revision. Until it appears in the archives, you
can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-camarillo-sipping-profile-key-01.txt

Thanks,

Gonzalo

Miguel Garcia wrote:
> Hi:
> 
> I have been requested to perform an expert review, on behalf of
> SIPPING, on the following draft:
> 
> draft-camarillo-sipping-profile-key-00.txt
> 
> Following the template in RFC 3427:
> 
> 1.  A designated expert (as defined in RFC 2434 [4]) MUST review the 
> proposal for applicability to SIP and conformance to these 
> guidelines.  The Expert Reviewer will send email to the Transport 
> Area Directors on this determination.  The expert reviewer can cite
> one or more of the guidelines that haven't been followed in his/her
> opinion.
> 
> I am the designated expert and I am cc:ing the RAI ADs in this email.
> 
> 
> 2.  The proposed extension MUST NOT define SIP option tags, response 
> codes, or methods.
> 
> The document defines the P-Profile-Key header field. No option tags, 
> response codes, or methods, are defined. Thus, the requirement is
> met.
> 
> 3.  The function of the proposed header MUST NOT overlap with current
>  or planned chartered extensions.
> 
> The P-Profile-Key header field does not relate to any ongoing or
> planned chartered extensions, and therefore satisfies this
> requirement.
> 
> 4.  The proposed header MUST be of a purely informational nature, and
>  MUST NOT significantly change the behavior of SIP entities which 
> support it.  Headers which merely provide additional information 
> pertinent to a request or a response are acceptable.  If the headers
> redefine or contradict normative behavior defined in standards track
> SIP specifications, that is what is meant by significantly different
> behavior.
> 
> The P-Profile-Key header field allows a first proxy to provide a
> second proxy with the key to be used by this second proxy to query
> the user database for a given profile. Therefore, it is an
> optimization to avoid a second lookup in a database. Session
> establishment is not affected by the presence or absence of this
> header. Therefore, this header field does not contradict any
> normative behavior defined somewhere else.
> 
> 5.  The proposed header MUST NOT undermine SIP security in any sense.
>  The Internet Draft proposing the new header MUST address security 
> issues in detail as if it were a Standards Track document.  Note 
> that, if the intended application scenario makes certain assumptions
> regarding security, the security considerations only need to meet the
> intended application scenario rather than the general Internet case.
> In any case, security issues need to be discussed for arbitrary usage
> scenarios (including the general Internet case).
> 
> The document indicates that the header is to be applied to the IMS 
> environment, within trusted elements (e.g., belonging to the same 
> administrative domain) where protection is achieved by means of IPsec
> or physical protection of the network.
> 
> It seems that the draft just merely indicates what the security 
> considerations are when the header is applied to the initially
> planned environment, namely, IMS. Perhaps the draft should discuss
> the consequences of applying this header to a public environment,
> where the data contents could be spoofed. It is my opinion than, even
> if the contents of this header could be spoofed, it does not offer
> any benefit for mounting an attack (e.g., against the database). In
> other words, a malicious entity could equally mount the attack
> without accessing to the P-Profile-Key header field value.
> 
> 6.  The proposed header MUST be clearly documented in an (Individual 
> or Working Group) Informational RFC, and registered with IANA.
> 
> The reviewed document is intended to become the informational RFC 
> required by this consideration. Acceptance of this document for 
> publication as an informational RFC will address this requirement.
> 
> 7.  An applicability statement in the Informational RFC MUST clearly 
> document the useful scope of the proposal, and explain its 
> limitations and why it is not suitable for the general use of SIP in
> the Internet.
> 
> The reviewed document contains an applicability statement, although 
> merely indicates that it is believed that the header is only useful
> in IMS due to the IMS architectural design. However, the document
> does not discuss why this header is not applicable to the public
> Internet, even there were a use case for it. I believe the
> P-Profile-Key header field is not applicable to the Internet because
> it requires the second proxy to trust the first, in that the value of
> the header is accurate, and there isn't a general available mechanism
> for proxies to trust other proxies. Luck of this trust would allow a
> first proxy to forge the contents of the P-Profile-Key header so that
> the second proxy either retrieves a wrong service profile from the
> user database (if the key points to a different profile), or the
> query to the user database fails (if the key does not exist).
> Besides, the assumption is that the architecture provides for two
> proxies accessing the same user database, something that may not be a
> common scenario in the Internet.
> 
> 8. Other comments
> 
> I have also other technical comments.
> 
> 8.1) The document introduces the concept of Public Service Identities
>  and  Wildcarded Public Service Identities in Section 2, however, the
>  definition of them occurs after its first usage. I would recommend
> to expand these two terms prior to any usage, perhaps in a new
> missing section: Terminology.
> 
> 8.2) Section 2, 4th paragraph uses (twice) the term "Wildcarded
> Public User Identity". I believe this is a typo and should instead
> refer to "Wildcarded Public Service Identity".
> 
> 8.3) The last paragraph in Section 4 provides an example of the 
> P-Profile-Key database that misses the 'sip:' scheme part of the URI:
> 
> 
> P-Profile-Key: <chatroom-!.*!@example.com>
> 
> 8.3) The acronyms HSS, I-CSCF, S-CSCF, should be expanded at their
> first occurrence (so, in the second paragraph in Section 5).
> 
> 8.4) I believe reference [1] is available in a more updated version
> than 3.14.0, January 2004. You should refer to version 7.0.0 dated
> June 2006. The same also applies to other referred 3GPP
> specifications.
> 
> 
> Miguel Garcia Designated reviewer for
> draft-camarillo-sipping-profile-key-00.txt
> 
> 
> 


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