Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Peter Saint-Andre <stpeter@stpeter.im> Fri, 29 October 2010 14:40 UTC
Return-Path: <stpeter@stpeter.im>
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 76A8D3A69CB; Fri, 29 Oct 2010 07:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 g8yMWcqlooAw; Fri, 29 Oct 2010 07:40:08 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9E6EC3A6A10; Fri, 29 Oct 2010 07:40:06 -0700 (PDT)
Received: from squire.local (dsl-251-219.dynamic-dsl.frii.net [216.17.251.219]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6F83040BB9; Fri, 29 Oct 2010 08:50:14 -0600 (MDT)
Message-ID: <4CCADD37.7070402@stpeter.im>
Date: Fri, 29 Oct 2010 08:41:59 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <4CC9503D.2000809@gmail.com> <4CCA470B.20601@stpeter.im> <4CCA7BED.1020907@gmail.com> <4CCAD810.4060508@stpeter.im> <4CCAD98E.1040300@gmail.com>
In-Reply-To: <4CCAD98E.1040300@gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms070706020401050000000805"
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -0700
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:40:10 -0000
Excellent. I'll try to finish Part 2 today. On 10/29/10 8:26 AM, Yaron Sheffer wrote: > 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