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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 21 July 2014 22:21 UTC

Return-Path: <keith.drage@alcatel-lucent.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 CB8311A006B; Mon, 21 Jul 2014 15:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 OUR0eSKLpq9z; Mon, 21 Jul 2014 15:21:53 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DE41A0010; Mon, 21 Jul 2014 15:21:52 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6LMLnF0004172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 17:21:50 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6LMLmBt023929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 00:21:48 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 22 Jul 2014 00:21:48 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Hilarie Orman <ho@alum.mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-cuss-sip-uui-isdn@tools.ietf.org" <draft-ietf-cuss-sip-uui-isdn@tools.ietf.org>
Thread-Topic: Security review of draft-ietf-cuss-sip-uui-isdn-08
Thread-Index: AQHPbUtrL3XuyQ4tCUiRjqvt3knxH5uriSxw
Date: Mon, 21 Jul 2014 22:21:48 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B20CC42@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <201405111817.s4BIHWWk012198@sylvester.rhmr.com>
In-Reply-To: <201405111817.s4BIHWWk012198@sylvester.rhmr.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8peoll5SsG1IscjmGI3C4UAn8XY
X-Mailman-Approved-At: Mon, 21 Jul 2014 18:38:14 -0700
Subject: Re: [secdir] Security review of draft-ietf-cuss-sip-uui-isdn-08
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: Mon, 21 Jul 2014 22:21:59 -0000

Our proposal is to delete the offending sentence in the first paragraph of the security considerations. We spent some time trying to work out why this sentence was written in the first place, and it goes back to the very early days of the author draft. We could not remember. The text makes more sense without this sentence.

Keith 

> -----Original Message-----
> From: Hilarie Orman [mailto:ho@alum.mit.edu] 
> Sent: 11 May 2014 19:18
> To: iesg@ietf.org; secdir@ietf.org; 
> draft-ietf-cuss-sip-uui-isdn@tools.ietf.org
> Subject: Security review of draft-ietf-cuss-sip-uui-isdn-08
> 
> 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
> 
> 
> 
> 
> 
>