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