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.

I have no expertise in SIP, and am providing this review as a first-level filter for our over-worked security ADs. So, please take my comments accordingly. Also, this review is a day late -- I hope it is still useful.

This document defines a method for exchanging a blob of information between user agents during SIP session establishment (User to User Information, or UUI data) by adding a new SIP header. The data is intended to be opaque to SIP.

There is a related problem statement RFC (6567) that briefly describes 3 different approaches to security, but neither document describes likely threats. They are implicit in the 3 models described in 6567 (e.g. treat the sip layer as "untrusted", treat the sip layer as "trusted", treat the transport domain as "trusted"), but I found myself wishing I had more info about real-world threats and countermeasures.

Given that I am not a SIP expert (and don't have time to become one as part of this review), I don't know if this is an issue or not, but this is an impression I think worth mentioning.

A second question relates to the binding of the UUI to its originator. The security considerations section suggests that the UUI might carry sensitive info requiring privacy or integrity protection, but does not mention origin authentication. There is a hint in the next paragraph (it says "History-Info can be used to determine the identity of the inserter"), but the relative security of this mechanism is not clear to me. Could an attacker forge History-Info? I don't know. What are the consequences of such behavior? I don't know. Seems like a well-written security considerations section would lay these questions to rest.

Again, I have almost zero knowledge of SIP, so maybe answers are obvious to someone steeped in SIP lore, and I apologize if this is the case. But, these are my impressions.

--Scott