Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17

Peter Saint-Andre <stpeter@stpeter.im> Fri, 29 October 2010 14:18 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 01C083A69C0; Fri, 29 Oct 2010 07:18:13 -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 sw6ZnErT3syV; Fri, 29 Oct 2010 07:18:11 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 521733A67E3; Fri, 29 Oct 2010 07:18:08 -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 A80AE40BB9; Fri, 29 Oct 2010 08:28:15 -0600 (MDT)
Message-ID: <4CCAD810.4060508@stpeter.im>
Date: Fri, 29 Oct 2010 08:20:00 -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>
In-Reply-To: <4CCA7BED.1020907@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="------------ms070005020305010703010505"
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:18:13 -0000

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

-- 
Peter Saint-Andre
https://stpeter.im/