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

[Yaron Sheffer <[e-mail]>]

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."
> ###
>
>> - 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.

>> - 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?

> ### END OF PART 1 ###
>
>
>