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

[Miguel Garcia <[e-mail]>]

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



-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland



_______________________________________________
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