Last Call Review of draft-ietf-salud-alert-info-urns-12
review-ietf-salud-alert-info-urns-12-secdir-lc-lepinski-2014-05-15-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The base Sip specification (RFC 3261) includes an Alert-Info header field that
may reference an audio file to be rendered to the user as a ring tone or
ringback tone. Draft-ietf-salud-alert-info-urns updates RFC 3261 to allow the
Alert-info feel to include a URN that indicates the type of ring tone or
ringback tone that is appropriate for the current call, and then the user agent
can use this URN to select an appropriate alert to render to the user (e.g.,
based on the capabilities of user's device and the user's preferences).

From a security point of view, the mechanism specified in this document is very
desirable, since it eliminates the potential security concerns associated with
a request to fetch and render an arbitrary audio file provided by a
(potentially untrusted) remote system.

This document is generally ready for publication. I agree with the authors that
specified usage of the new alert URN namespace does not raise significant new
security concerns. However, I have one minor concern about the security
considerations text, which I discuss below.

The authors correctly note that the use particular alert indicators (that might
reasonably be provisioned within this namespace) may introduce privacy
concerns. For example, the alert-info value might reasonably include
information about the calling party, the calling party's location (e.g., local
vs international) or the calling party's device. (Note that in many cases there
will be as much or more information about the calling party in other SIP
headers, but it is definitely worth noting that this is a header field where
privacy-relevant information may reside.)

Therefore, the security considerations text goes on to say "Such provision
SHALL always be explicitly authorized by the party (caller or callee) the
information in the 'alert' URN refers to."

I find the above text somewhat confusing, and I would appreciate it the authors
could add a bit of text to clarify what they mean. Does this sentence mean that
if I am implementing a User-Agent that I MUST NOT include any URN in the
alert-info field without an explicit authorization from the user? Or perhaps it
means that certain categories of alert URNs (the privacy-relevant ones) MUST
NOT be included in the alert-info field without an explicit authorization from
the user? (If this is the case, then obviously a bit of guidance is needed with
regards to which types of alert URNs require explicit user authorization).

Furthermore, I believe that the above sentence means that if I am implementing
a proxy that I MUST NOT add any alert URN to an outgoing (or incoming) call
without explicit authorization from the user. (Or again, perhaps it only means
certain privacy-relevant alert URNs). I think this paragraph would be more
clear if there were separate normative statement for the behavior of proxies
and user agents.

That is, for these type of privacy considerations, I think it is very helpful
to be very clear/explicit about what information various entities are allowed
to put into this header field (without authorization from the user).

As I final note, it might be reasonable to add a sentence that
reminds implementers that due to the potential privacy implications of the
alert-info header field that when this header is included (or perhaps when
certain categories of alert URNs are placed in this header field), the SIP
message SHOULD be protected via TLS. However, I understand that: (1) There are
a number of practical impediments to the use of TLS to protect SIP traffic; and
(2) Given the privacy-relevant information that is likely contained in other
SIP headers, the recommendation to use TLS is in now ways specific to the
presence of the alert-info field. Therefore, although I think a reminder to use
TLS when possible might be appropriate, I can understand why the authors might
reasonably chose to leave out such text.