[secdir] Security review of draft-ietf-cuss-sip-uui-isdn-08

"Hilarie Orman" <ho@alum.mit.edu> Sun, 11 May 2014 18:18 UTC

Return-Path: <hilarie@purplestreak.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 970C71A0337; Sun, 11 May 2014 11:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 k2HFu0BiXwQY; Sun, 11 May 2014 11:18:03 -0700 (PDT)
Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id D5B1A1A0334; Sun, 11 May 2014 11:18:03 -0700 (PDT)
Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1WjYJv-0005KU-91; Sun, 11 May 2014 12:17:55 -0600
Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1WjYJs-0001gH-F9; Sun, 11 May 2014 12:17:55 -0600
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s4BIHXUf012320; Sun, 11 May 2014 12:17:33 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s4BIHWWk012198; Sun, 11 May 2014 12:17:32 -0600
Date: Sun, 11 May 2014 12:17:32 -0600
Message-Id: <201405111817.s4BIHWWk012198@sylvester.rhmr.com>
From: Hilarie Orman <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-cuss-sip-uui-isdn@tools.ietf.org
X-XM-AID: U2FsdGVkX18FEWehcIgCZdy5oEimsNW7
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org, draft-ietf-cuss-sip-uui-isdn@tools.ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 13:58:17 -0700)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/oABRTHxf4ELBdaxmz5dQ9R5O1iA
Subject: [secdir] Security review of draft-ietf-cuss-sip-uui-isdn-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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: Sun, 11 May 2014 18:18:05 -0000

Security review of draft-ietf-cuss-sip-uui-isdn-08
Interworking ISDN Call Control User Information with SIP

Do not be alarmed.  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.

This document defines a usage (a new package) of the SIP User-to-User
header field to enable interworking with ISDN services transporting
the ITU-T DSS1 User-user information data element and is limited to
the ISDN UUS1 implicit supplementary service.  Because the element may
contain information related to user privacy, one should consider the
impact of transmitting it in this context.

The document begins by noting the the User-to-User header field is
defined in "A Mechanism for Transporting User to User Call Control
Information in SIP" (draft-ietf-cuss-sip-uui-16).  That document notes
security requirements deriving from an earlier document, RFC6567 SIP
UUI Reqs, which states:

  The next three requirements capture the UUI security requirements.
   REQ-13: The mechanism will allow integrity protection of the UUI.
   ...
   REQ-14: The mechanism will allow end-to-end privacy of the UUI.
   ...

   REQ-15: The mechanism will allow both end-to-end and hop-by-hop
   security models.
   ...

The document under review and draft-ietf-cuss-sip-uui-16 note that
because ISDN offers only hop-by-hop security, the SIP UAs must provide
any necessary authenticity, integrity and privacy protection for
sensitive parts of the UUI.

It is not clear to me if the SIP endpoints are aware of intermediary
ISDNs, nor if they might be unaware of the ISDN transit and thus
misled into thinking that the SIP infrastructure provided adequate
security controls for the protection of UUI data.

The document gives the guidance that "data that is used to assist in
selecting which SIP UA should respond to the call would not be
expected to carry any higher level of security than a media feature
tag".  I'm not sure how to interpret that.  When should the "level of
security" be expected to be lower than a media feature tag?  Or does
it mean something else, like: (a) the data should not be more sensitive
than that in a media feature tag or (b) the data should be protected
(authenticity, integrity, privacy) to at least the level of a media
feature tag or (c) the UUI data and the media feature tag data are so
similar that they should have the same level of protection?

That's my impression from reading over the security considerations.
My apologies if I've missed the point.

Hilarie