Re: [secdir] secdir review of draft-ietf-cuss-sip-uui-10

["Scott G. Kelly" <[e-mail]>]

Hi Alan,

It appears that the modifications answer the questions I raised, but I again want to emphasize my lack of experience with SIP. One nit with the second paragraph of the security considerations section - it says 

   One model treats the SIP layer as untrusted and requires end-to-end
   integrity protection and/or encryption.  This model can be achieved
   by providing these security services at a layer above SIP.  In this
   case, applications are encouraged to use their own integrity
   mechanisms such as encrypting the UUI data before passing it to the
   SIP layer.

Encryption is not an integrity mechanism. One way to fix this would be to change that last sentence to something like 

   In this case, applications are encouraged to use their own integrity
   and/or encryption mechanisms.

Thanks,

Scott

On Thursday, January 23, 2014 11:44am, "Alan Johnston" <[e-mail]> said:

> Scott,
> 
> Thanks for your review of the draft.  We made some edits based on your
> comments a while back, so I'm pinging you to make sure they address your
> concerns.
> 
>      http://tools.ietf.org/html/draft-ietf-cuss-sip-uui
> 
> Thanks!
> - Alan -
> 
> 
> On Thu, May 30, 2013 at 7:47 PM, Scott G. Kelly <[e-mail]>wrote:
> 
>> 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
>>
>>
>>
>