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

[Yaron Sheffer <[e-mail]>]

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
>