Skip to main content

Last Call Review of draft-ietf-cuss-sip-uui-10
review-ietf-cuss-sip-uui-10-secdir-lc-kelly-2013-06-07-00

Request Review of draft-ietf-cuss-sip-uui
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-05-29
Requested 2013-05-16
Authors Alan Johnston , James Rafferty
I-D last updated 2013-06-07
Completed reviews Genart Last Call review of -10 by Joel M. Halpern (diff)
Genart Telechat review of -14 by Joel M. Halpern (diff)
Secdir Last Call review of -10 by Scott G. Kelly (diff)
Opsdir Telechat review of -14 by Jouni Korhonen (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-cuss-sip-uui by Security Area Directorate Assigned
Reviewed revision 10 (document currently at 17)
Result Has issues
Completed 2013-06-07
review-ietf-cuss-sip-uui-10-secdir-lc-kelly-2013-06-07-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.

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