Subject: Re: [Curdle] Questions about draft-ietf-curdle-ssh-ext-info-00.txt

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 16 Aug 2016 14:18:09 -0600

Hello Peter,

> Section 2.3, "can send the the following message":
> MAY?  MUST?  SHOULD?

thanks. I changed this in the working version of the draft to MAY.

> Section 2.3, "This message is sent without delay, 
> and immediately after SSH_MSG_NEWKEYS":
>
> Uhh, shouldn't it wait for the NEWKEYS to succeed?
> Otherwise if something goes wrong the sender has
> leaked the info that it's withheld until now because
> it's apparently sensitive.

In the direction from client to server, the client's sending of NEWKEYS indicates the server's authenticity has already been verified, so there is no issue.

In the direction from server to client, any information that's actually sensitive would be postponed until the second EXT_INFO message sent when user authentication is successful. There seems to be little value in mounting an attack to discover the contents of EXT_INFO sent before user authentication, when you can just connect to the SSH server without intent to authenticate, and get the information that way after a normal completed key exchange.

> Section 2.4, "the server MAY send, but is not obligated
> to send, an SSH_MSG_EXT_INFO message immediately before
> SSH_MSG_USERAUTH_SUCCESS":
>
> Before, not after?

Yes, before. Otherwise you get a race condition because the client may want to take different actions after authentication success depending on whether it receives certain information in this second EXT_INFO, or not.

If the message could be sent after USERAUTH_SUCCESS, but might not be sent by the server, then the client has no idea whether it should wait for the server to send this message or not, or how long to wait.

Given that the message is optional - which I think is a good choice, and cannot be changed now anyway because the protocol extension is already deployed to a significant extent - any second EXT_INFO sent by the server must be sent *before* SSH_MSG_USERAUTH_SUCCESS.

> That's going to lead to a pretty strange message flow, the
> client sends a SSH_MSG_USERAUTH_REQUEST and instead of the
> expected SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE
> it gets some random message about extensions.

The EXT_INFO message is not random when received in this context. The client has signaled it is willing to receive it, which includes the requirement and ability to receive it in this context, also.

Note that the specification requires the server to send no more than one or two EXT_INFO messages at the times specified, but the client implementation for handling the second EXT_INFO does not have to enforce that it is followed by USERAUTH_SUCCESS. If it is simpler for the client to simply accept and normally handle any additional EXT_INFO messages received before USERAUTH_SUCCESS, the client can do so without necessarily needing to enforce the number of these additional messages, or that a USERAUTH_SUCCESS message immediately follows. This can be done easily at the same layer that handles the initial EXT_INFO message. Since the server is already authenticated by the client, I don't see risks from allowing this leeway.

> Section 2.4, "If a server sends a subsequent
> SSH_MSG_EXT_INFO, this replaces any initial one, and both
> the client and the server re-evaluate extensions in effect":
>
> This is just asking for trouble, you're requiring both sides
> to be able to sort out and disambiguate conflicting
> extensions in a compatible manner.

If a server implements one or more extensions that require the sending of a second EXT_INFO, it may check the EXT_INFO received from the client to see if the client indicates support for any of those extensions. If it does not, the server does not need to send the second EXT_INFO, and there are no conflicts. But if the client indicates support for such extensions, implementations of such extensions will be able to agree on proper behavior at that time.

The current widely used extension, server-sig-algs, does not have much continued relevance after user authentication is successful, and so does not suffer from extensions being re-evaluated due to a second EXT_INFO.

If you have a suggestion for wording to be inserted that would reduce the chances of compatibility issues due to the second EXT_INFO, please let me know. From my perspective, the current spec seems clear ("a subsequent SSH_MSG_EXT_INFO [...] replaces any initial one", "the client and the server re-evaluate extensions in effect"). But if there's a way we can further clarify this, I'm open to suggestions.

> Section 3.4, "elevation":
>
> What does this extension do?  I was expecting an option of
> which floor you want to get off on, with a negative value
> for the parking garage.

Point taken. I have modified the working version of the draft to insert the words "(as used by Windows)" in the description of this extension.

denis

From: Peter Gutmann 
Sent: Tuesday, August 16, 2016 04:36
To: [email-masked] ; [email-masked] 
Subject: Questions about draft-ietf-curdle-ssh-ext-info-00.txt

I've been looking at this draft and have a few questions...

Section 2.3, "can send the the following message":

MAY?  MUST?  SHOULD?

Section 2.3, "This message is sent without delay, and immediately after
SSH_MSG_NEWKEYS":

Uhh, shouldn't it wait for the NEWKEYS to succeed?  Otherwise if something goes
wrong the sender has leaked the info that it's withheld until now because it's
apparently sensitive.

Section 2.4, "the server MAY send, but is not obligated to send, an
SSH_MSG_EXT_INFO message immediately before SSH_MSG_USERAUTH_SUCCESS":

Before, not after?  That's going to lead to a pretty strange message flow, the
client sends a SSH_MSG_USERAUTH_REQUEST and instead of the expected
SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE it gets some random message
about extensions.  Why not require that the extensions be sent after
failure/success has been indicated?

Section 2.4, "If a server sends a subsequent SSH_MSG_EXT_INFO, this replaces
any initial one, and both the client and the server re-evaluate extensions in
effect":

This is just asking for trouble, you're requiring both sides to be able to
sort out and disambiguate conflicting extensions in a compatible manner.

Section 3.4, "elevation":

What does this extension do?  I was expecting an option of which floor you
want to get off on, with a negative value for the parking garage.

Peter.