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

"Scott G. Kelly" <scott@hyperthought.com> Sat, 25 January 2014 15:18 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601941A0253 for <secdir@ietfa.amsl.com>; Sat, 25 Jan 2014 07:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lirsH8eyq17a for <secdir@ietfa.amsl.com>; Sat, 25 Jan 2014 07:18:05 -0800 (PST)
Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) by ietfa.amsl.com (Postfix) with ESMTP id EA6B71A00CA for <secdir@ietf.org>; Sat, 25 Jan 2014 07:18:04 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5C8373C0083; Sat, 25 Jan 2014 10:18:03 -0500 (EST)
X-Virus-Scanned: OK
Received: from app16.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1FCB83C0071; Sat, 25 Jan 2014 10:18:03 -0500 (EST)
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app16.wa-webapps.iad3a (Postfix) with ESMTP id 106F138005E; Sat, 25 Jan 2014 10:18:03 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sat, 25 Jan 2014 07:18:03 -0800 (PST)
Date: Sat, 25 Jan 2014 07:18:03 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "Alan Johnston" <alan.b.johnston@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <CAKhHsXFm1tRCPw2OUmP_QkBsu9ia1fhRrY1o_c9q8fjT8u10EQ@mail.gmail.com>
References: <1369961279.70598635@apps.rackspace.com> <CAKhHsXFm1tRCPw2OUmP_QkBsu9ia1fhRrY1o_c9q8fjT8u10EQ@mail.gmail.com>
Message-ID: <1390663083.06483927@apps.rackspace.com>
X-Mailer: webmail7.0
Cc: draft-ietf-cuss-sip-uui.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-cuss-sip-uui-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2014 15:18:07 -0000

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" <alan.b.johnston@gmail.com>; 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 <scott@hyperthought.com>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
>>
>>
>>
>