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

[Peter Saint-Andre <[e-mail]>]

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