Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 29 October 2010 14:24 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390E33A689D; Fri, 29 Oct 2010 07:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c+VDa1FcLsR; Fri, 29 Oct 2010 07:24:38 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 47DC13A686D; Fri, 29 Oct 2010 07:24:37 -0700 (PDT)
Received: by wyb28 with SMTP id 28so3193640wyb.31 for <multiple recipients>; Fri, 29 Oct 2010 07:26:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OX6xqPlAyy0QXwmSF2cWSKN/ezd2zny2426/I8WFYLM=; b=pcZqI9O8PPykURoLAwqAeCu32iVqgBJo70Jxl1/H/AQSifU5VWW/9+v87G4ybjBOZt xuKS///N+0dewvzffJw8ZWM0SDxayZEpmvr1DIs3jnjSCGQqYejI6ZPrKCO2/tNaenfC cN8JRTj8GCgRM1w8PxQDI3vilMTE+nleqOG+s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=E2Irq2sZgWO80y0yqqcS4EZZvdr+T0K4vsWIHWrvRuikku8eMrDBC/xffrn/qDvyxd TTzgIefQpbX+h+vn9OU0VT+/wAnXtAgdB9DQImId51bsXDjOIGwpbcv7jyC3W5Ddgf1k 8qnQv6nRBdsu24Nv3w9YnHzPzfBt1QPX2e6Sw=
Received: by 10.227.143.146 with SMTP id v18mr758235wbu.63.1288362391200; Fri, 29 Oct 2010 07:26:31 -0700 (PDT)
Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id a17sm2114235wbe.0.2010.10.29.07.26.25 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Oct 2010 07:26:28 -0700 (PDT)
Message-ID: <4CCAD98E.1040300@gmail.com>
Date: Fri, 29 Oct 2010 16:26:22 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4CC9503D.2000809@gmail.com> <4CCA470B.20601@stpeter.im> <4CCA7BED.1020907@gmail.com> <4CCAD810.4060508@stpeter.im>
In-Reply-To: <4CCAD810.4060508@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 29 Oct 2010 14:24:42 -0000
Hi Peter, I'm fine with your proposals. Thanks, Yaron On 10/29/2010 04:20 PM, Peter Saint-Andre wrote: > Hi Yaron, a few additional comments and text proposals inline. > > On 10/29/10 1:46 AM, Yaron Sheffer wrote: >> Hi Peter, >> >> On 10/29/2010 06:01 AM, Peter Saint-Andre wrote: >>> Thanks for your careful and thorough review. To maintain forward >>> momentum, this is Part 1 of my reply, up through the end of Section 4. I >>> shall endeavor to reply regarding the remainder of your review in the >>> next 24-48 hours. >>> >> Thanks a lot for using my comments and misunderstandings to improve the >> document. >> >> I have removed pieces of this mail where I fully accept your >> response/changes. >> >>>> - 4.3: How is TLS negotiated for the additional streams? >>> >>> Each stream is separately secured. >>> >>>> How is it bound >>>> to the SASL negotiation that (apparently) only takes place once? >>> >>> It isn't, because each stream is separately secured (preferably by means >>> of TLS + SASL). >>> >>> I propose that we clarify these matters by modifying the following >>> paragraphs from Section 4.3 ("Directionality"): >>> >>> ### >>> >>> 4.3. Directionality >>> >>> An XML stream is always unidirectional, by which is meant that XML >>> stanzas can be sent in only one direction over the stream (either >>> from the initiating entity to the receiving entity or from the >>> receiving entity to the initiating entity). >>> >>> Depending on the type of session that has been negotiated and the >>> nature of the entities involved, the entities might use: >>> >>> o Two streams over a single TCP connection, where the security >>> context negotiated for the first stream is applied to the second >>> stream. This is typical for client-to-server sessions, and a >>> server MUST allow a client to use the same TCP connection for both >>> streams. >>> >>> o Two streams over two TCP connections, where each stream is >>> separately secured. In this approach, one TCP connection is used >>> for the stream in which stanzas are sent from the initiating >>> entity to the receiving entity, and the other TCP connection is >>> used for the stream in which stanzas are sent from the receiving >>> entity to the initiating entity. This is typical for server-to- >>> server sessions. >>> >>> o Multiple streams over two or more TCP connections, where each >>> stream is separately secured. This approach is sometimes used for >>> server-to-server communication between two large XMPP service >>> providers; however, this can make it difficult to maintain >>> coherence of data received over multiple streams in situations >>> described under Section 10.1, which is why a server MAY return a >>> <conflict> stream error to a remote server that attempts to >>> negotiate more than one stream (as described under >>> Section 4.8.3.3). >>> >>> This concept of directionality applies only to stanzas and explicitly >>> does not apply to first-level children of the stream root that are >>> used to bootstrap or manage the stream (e.g., first-level elements >>> used for TLS negotiation, SASL negotiation, Server Dialback >>> [XEP-0220], and Stream Management [XEP-0198]). >>> >>> The foregoing considerations imply that while completing STARTTLS >>> negotiation (Section 5) and SASL negotiation (Section 6) two servers >>> would use one TCP connection, but after the stream negotiation >>> process is done that original TCP connection would be used only for >>> the initiating server to send XML stanzas to the receiving server. >>> In order for the receiving server to send XML stanzas to the >>> initiating server, the receiving server would need to reverse the >>> roles and negotiate an XML stream from the receiving server to the >>> initiating server over a separate TCP connection. >>> >> Perhaps add a final sentence: "This separate TCP connection is then >> secured using a new round of TLS and/or SASL negotiation." > > Yes, that's good. Paragraph updated with your text. > >>> ### >>> >>>> - 4.8.3.18: what are the security implications of a "redirect"? >>> >>> Of<see-other-host/>? Seemingly underspecified. :( >>> >>>> Should >>>> the client apply the same policy, e.g. for using TLS, as for the >>>> original server? >>> >>> Yes. >>> >>>> Which "to" identity to use? >>> >>> The 'to' address of the initial stream header would still be the DNS >>> domain name of the XMPP service to which the initiating entity is trying >>> to connect (see also draft-saintandre-tls-server-id-check). >>> >>>> Can redirection occur >>>> before the recipient is even authenticated? >>> >>> Yes. >>> >>> I propose that we modify the description as follows: >>> >>> The server will not provide service to the initiating entity but is >>> redirecting traffic to another host under the administrative control >>> of the same service provider. The XML character data of the<see- >>> other-host/> element returned by the server MUST specify the >>> alternate hostname or IP address at which to connect, which MUST be a >>> valid domainpart or a domainpart plus port number (separated by the >>> ':' character in the form "domainpart:port"). If the domainpart is >>> the same as the source domain, derived domain, or resolved IP address >>> to which the initiating entity originally connected (differing only >>> by the port number), then the initiating entity SHOULD simply attempt >>> to reconnect at that address. Otherwise, the initiating entity MUST >>> resolve the hostname specified in the<see-other-host/> element as >>> described under Section 3.2. >>> >>> I also propose that we add the following paragraph to the end of the >>> section: >>> >>> When negotiating a stream with the host to which it has been >>> redirected, the initiating entity MUST apply the same policies it >>> would have applied to the original connection attempt (e.g., a policy >>> requiring TLS), MUST specify the same 'to' address on the initial >>> stream header, and MUST verify the identity of the new host using the >>> same reference identifier(s) it would have used for the original >>> connection attempt (in accordance with [TLS-CERTS]. Even if >>> receiving entity returns a<see-other-host/> error before the >>> confidentiality and integrity of the stream have been established >>> (thus introducing the possibility of a denial of service attack), the >>> fact that the initiating entity needs to verify the identity of the >>> XMPP service based on the same reference identifiers implies that the >>> initiating entity will not connect to a malicious entity; however, to >>> reduce the possibility of a denial of service attack, the receiving >>> entity SHOULD NOT return a<see-other-host/> error until after the >>> stream has been protected (e.g., via TLS). >>> >> ... and the sending entity SHOULD maintain a running redirect counter, >> and give up after a certain number of successive redirects. >> >> Also, the mitigation you propose in the last sentence only helps if "An >> entity MAY have a policy where it only accepts<see-other-host> elements >> from authenticated peers. > > Thanks. I propose that we change this paragraph to: > > When negotiating a stream with the host to which it has been > redirected, the initiating entity MUST apply the same policies it > would have applied to the original connection attempt (e.g., a policy > requiring TLS), MUST specify the same 'to' address on the initial > stream header, and MUST verify the identity of the new host using the > same reference identifier(s) it would have used for the original > connection attempt (in accordance with [TLS-CERTS]. Even if > receiving entity returns a<see-other-host/> error before the > confidentiality and integrity of the stream have been established > (thus introducing the possibility of a denial of service attack), the > fact that the initiating entity needs to verify the identity of the > XMPP service based on the same reference identifiers implies that the > initiating entity will not connect to a malicious entity; however, to > reduce the possibility of a denial of service attack, the receiving > entity SHOULD NOT return a<see-other-host/> error until after the > stream has been protected (e.g., via TLS) and the receiving entity > MAY have a policy of following redirects only if it has authenticated > the receiving entity. In addition, the initiating entity SHOULD give > up after a certain number of successive redirects (e.g., at least 2 > but no more than 5). > >>>> - 4.9: Don't we resend the "stream" header again after completing the >>>> TLS negotiation (Sec. 4.2.3). >>> >>> For sure. I propose that we change this: >>> >>> [ ... channel encryption ... ] >>> >>> [ ... authentication ... ] >>> >>> [ ... resource binding ... ] >>> >>> to: >>> >>> [ ... stream negotiation ... ] >>> >> I'm not sure. Since we start the example with two<stream> elements, it >> would make sense to show the additional (4?)<stream> elements further >> down. Although the "simple" examples would no longer fit a page. Maybe >> add a "really simple" example with no security? > > These examples are included to provide a high-level illustration of what > a session would look like, so I think eliding the whole stream > negotiation process is fine. However, I think it would be good to add a > forward reference to Section 9 so that the reader knows where to go for > detailed examples. Thus propose modifying the first paragraph of Section > 4.9 as follows: > > This section contains two highly simplified examples of a stream- > based connection between a client and a server; these examples are > included for the purpose of illustrating the concepts introduced thus > far, but the reader needs to be aware that these examples elide many > details (see Section 9 for more complete examples). > > Peter >
- [secdir] SecDir review of draft-ietf-xmpp-3920bis… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Florian Zeitz
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Jeffrey Hutzelman
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Matthew Wild
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Philipp Hancke
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre