Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16

Alissa Cooper <alissa@cooperw.in> Thu, 18 February 2016 23:41 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2140E1A8AA1 for <p2psip@ietfa.amsl.com>; Thu, 18 Feb 2016 15:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 wkCyJY7aHJDJ for <p2psip@ietfa.amsl.com>; Thu, 18 Feb 2016 15:41:37 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136D51A888F for <p2psip@ietf.org>; Thu, 18 Feb 2016 15:41:37 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 00658219D0 for <p2psip@ietf.org>; Thu, 18 Feb 2016 18:40:10 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 18 Feb 2016 18:40:10 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qPT2xiPV7uCBrH3VbMfK55S6afQ=; b=r2EVZO 8Tw14PSJuonKwFrOUa2Xo3WI8Q23RFYGWDQn7NktYhV/N73R6CjsHVvIb2BppRYJ 2FK9ThO5kRfYbFTonmm99bcAPhnQ+4awZVpOxP4KxVXvh0YAkLI6OwP1+gQovoDf EBzSz5QqzOVs4oH7ZpTsxEWsllV8vclZfZJPI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qPT2xiPV7uCBrH3 VbMfK55S6afQ=; b=goZKx+Kjmc0qZeFTS3OafNnWSXi6Kk7NnQalXcVsEikjjz3 nLjPBxNpZLjyAXl3axbJDnQwblluJa7ERDLT7HwEK4OrX5jQ0FOU6FbgXIXd14XP vnUwY/fGSyaZiinY3ZfPC1UNmlkH7KZTzdxUqPv/ESmGVFn0WdQAgvO0SNKw=
X-Sasl-enc: rKcE+x/3EW1SJG+Pvpykc+L4HRDuozlILeEAysUd5wl1 1455838810
Received: from dhcp-171-68-20-91.cisco.com (dhcp-171-68-20-91.cisco.com [171.68.20.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ABDFC00012; Thu, 18 Feb 2016 18:40:09 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <56B91C25.2020308@haw-hamburg.de>
Date: Thu, 18 Feb 2016 15:40:08 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC55FA49-3C39-4BB0-8477-B65A8ACF626B@cooperw.in>
References: <D1766CFB-B7CF-4D0B-AB08-09EA5FABAE1C@cooperw.in> <412972789d024091baeda005b8500e47@HUB02.mailcluster.haw-hamburg.de> <56B91C25.2020308@haw-hamburg.de>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/rwG0YFCSRzBLWa1-nQlOT5Uc7b0>
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-sip-16
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 23:41:39 -0000

Hi Thomas,

Checking in on this and the -share doc. When do you expect to respond?

Thanks,
Alissa

> On Feb 8, 2016, at 2:52 PM, Thomas C. Schmidt <t.schmidt@haw-hamburg.de>; wrote:
> 
> Yes, I'll catch up on this asap.
> 
> Cheers,
> Thomas
> 
> On 08.02.2016 23:34, Alissa Cooper wrote:
>> Is anyone in the WG able to respond to these comments and questions?
>> 
>> Thanks,
>> Alissa
>> 
>>> On Jan 15, 2016, at 1:58 PM, Alissa Cooper <alissa@cooperw.in>; wrote:
>>> 
>>> I have reviewed this document in preparation for IETF last call. I have a number of comments and questions that need to be resolved before last call can be initiated. In particular, I have some security concerns about using this in an overlay that allows registrations for any domain.
>>> 
>>> I’ve also included some nits below that should be resolved together with last call comments.
>>> 
>>> 
>>> == Substantive comments and questions ==
>>> 
>>> = Section 3.2 =
>>> 
>>> This section is underspecified and I’m not sure the references to RFC 2533 and RFC 2738 are the appropriate ones. I think what you need to specify here is that the contact_prefs will encode a media feature set comprised of SIP User Agent capabilities, as defined in RFC 3840 and registered in the SIP media feature tag registration tree (assuming that is what is intended).
>>> 
>>> It’s also confusing that you only mention whether sip.schemes is required or not without mentioning whether specifying any other capabilities is required or optional.
>>> 
>>> = Section 3.3 =
>>> 
>>> "Before issuing a Store request to the overlay, any peer SHOULD verify that the AOR of the request is a valid Resource Name with respect to its domain name and the namespaces defined in the overlay configuration document (see Section 3.4)."
>>> 
>>> Why is this SHOULD rather than MUST?
>>> 
>>> = Section 3.4 =
>>> 
>>> (1) I note that this documents refers to a different version of the IEEE Posix spec than draft-ietf-p2psip-share. What’s the reason for the difference?
>>> 
>>> (2)
>>> I find the explanation of the expected behavior here hard to follow. I've suggested a re-write below. There also seems to be one case that is not specified, which is when the "enable" attribute is set to false. Text describing what should happen in that case needs to be added.
>>> 
>>> OLD
>>> A RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions.  For the latter, an enumeration of admissible domain names including wildcarded name patterns of the following form MAY be configured.
>>> 
>>> Example of Domain Patterns: dht\.example\.com .*\.my\.name
>>> 
>>> In this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.name".  When restrictions apply and in the absence of domain patterns, the default behavior is to accept only AORs that exactly match the domain name of the overlay.  Otherwise, i.e., when restrictions are not configured (attribute enable not set), the default behavior is to accept any AOR.  In the absence of a <domain-restrictions> element, implementors SHOULD assume this default value.  Encoding of the domain name complies to the restricted ASCII character set without character escaping as defined in Section 19.1 of [RFC3261].
>>> 
>>> The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements.  A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true.  Each <pattern> element defines a pattern for constructing admissible resource names.  It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]).
>>> 
>>> NEW
>>> A RELOAD overlay can be configured to accept store requests for any AOR, or to apply domain name restrictions.  To apply restrictions, the overlay configuration document needs to contain a <domain-restrictions> element. The <domain-restrictions> element serves as a container for zero to multiple <pattern> sub-elements.  A <pattern> element MAY be present if the "enable" attribute of its parent element is set to true.  Each <pattern> element defines a pattern for constructing admissible resource names.  It is of type xsd:string and interpreted as a regular expression according to "POSIX Extended Regular Expression" (see the specifications in [IEEE-Posix]). Encoding of the domain name complies to the restricted ASCII character set without character escaping as defined in Section 19.1 of [RFC3261].
>>> 
>>> Inclusion of a <domain-restrictions> element in an overlay configuration document is OPTIONAL. If the element is not included, the default behavior is to accept any AOR. If the element is included and the “enable” attribute is not set, the overlay MUST only accept AORs that match the domain name of the overlay. If the element is included and the “enable” attribute is set to true, the overlay MUST only accept AORs that match patterns specified in the <domain-restrictions> element.
>>> 
>>> Example of Domain Patterns: dht\.example\.com .*\.my\.name
>>> 
>>> In this example, any AOR will be accepted that is either of the form <user>@dht.example.com, or ends with the domain "my.name".
>>> 
>>> = Section 8.2.3 =
>>> 
>>> The attack described here seems trivial, and therefore it seems to me that the way SIP usage of RELOAD has been specified here has a gaping hole in it. Basically in any overlay that wants to allow registrations from any domain, the only defense against calls being directed to the wrong recipient is for users to bypass the overlay and do what they would normally do when making a SIP call. Thus in this use case the only thing achieved by using RELOAD is to create a giant vulnerability.
>>> 
>>> Did the WG consider this? What is the value of standardizing this in this way, given this security issue? If the way that SIP usage was specified was limited to overlays with domain restrictions, at least this attack would be limited to bogus registrations of users within the overlay domain(s).
>>> 
>>> = Section 8.2.4 =
>>> 
>>> (1)
>>> By "public" you mean "visible to all nodes in the overlay," correct?
>>> 
>>> (2)
>>> "Methods of providing
>>>   location and identity privacy are still being studied."
>>> 
>>> Is this true, specifically for P2PSIP?
>>> 
>>> 
>>> == Nits ==
>>> 
>>> = Section 1 =
>>> 
>>> s/The REsource LOcation And Discovery (RELOAD)/REsource LOcation And Discovery (RELOAD)/
>>> 
>>> OLD
>>> Two opposite scenarios of deploying P2P SIP services are in the focus of this document: A highly regulated environment of a "single provider" that admits parties using AORs with domains from controlled namespace(s), only, and an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace.
>>> 
>>> NEW
>>> This RELOAD usage may be relevant in a variety of environments, including a highly regulated environment of a "single provider" that admits parties using AORs with domains from controlled namespace(s) only, or an open, multi-party infrastructure that liberally allows a registration and rendezvous for various or any domain namespace.
>>> 
>>> = Section 3.1 =
>>> 
>>> "RELOAD peers MAY store two kinds of SIP mappings”
>>> 
>>> I don’t think you need the normative MAY there, “can” would work.
>>> 
>>> = Section 3.4 =
>>> 
>>> The second line of the example here needs to use .example as the TLD, not .name. Please make the corresponding changes in the text.
>>> 
>>> = Section 5.1 =
>>> 
>>> s/MUST NOT be used and closed/MUST NOT be used and MUST be closed/
>>> 
>>> = Section 6 =
>>> 
>>> I don't think you need the normative MAY here.
>>> 
>>> _______________________________________________
>>> P2PSIP mailing list
>>> P2PSIP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/p2psip
>> 
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip
>> 
> 
> -- 
> 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                   Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °
> 
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip