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

Request Review of draft-ietf-salud-alert-info-urns
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-05-13
Requested 2014-04-17
Authors Laura Liess, Roland Jesske, Alan Johnston, Dale Worley, Paul Kyzivat
Draft last updated 2014-05-15
Completed reviews Genart Last Call review of -12 by Alexey Melnikov (diff)
Secdir Last Call review of -12 by Matt Lepinski (diff)
Opsdir Last Call review of -12 by Bert Wijnen (diff)
Assignment Reviewer Matt Lepinski
State Completed
Review review-ietf-salud-alert-info-urns-12-secdir-lc-lepinski-2014-05-15
Reviewed rev. 12 (document currently at 14)
Review result Has Issues
Review completed: 2014-05-15

Review
review-ietf-salud-alert-info-urns-12-secdir-lc-lepinski-2014-05-15

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.