On Jan 17, 2017, at 9:57 AM, Douglas E Engert <deengert at gmail.com> wrote:> On 1/16/2017 2:09 PM, Ron Frederick wrote: >> I?m working on an implementation of ?gssapi-with-mic? authentication for my AsyncSSH package and trying to get it to interoperate with OpenSSH. I?ve gotten it working, but there seems to be a discrepancy between the OpenSSH implementation and RFC 4462. Specifically, RFC 4462 says the following in section 3.4: >> >> Since the user authentication process by its nature authenticates >> only the client, the setting of mutual_req_flag is not needed for >> this process. This flag SHOULD be set to "false". > > Note it says "SHOULD" not "MUST". Previous versions of SSH clients and mods to OpenSSH > have always set mutual_req_flag.[Ron] Thanks - I did see that, but shouldn't that mean it should work correctly when my client is connecting to sshd whether or not I set the mutual auth flag? That doesn?t appear to be the case. Are you saying that OpenSSH?s sshd is intentionally rejecting the request when it sees the mutual_auth flag is not set? I see some code in OpenSSH which suggests it might be trying to do that, but I?m never actually getting an auth failure here. The connection just hangs. When tracing it, it looks like OpenSSH?s sshd feeds the token I send into its accepting context and gets back no token to send (which would be correct), but then it never seems to complete the rest of the state machine when I send the final message from the client. The issue may be the way the code is structured: /* Now, if we're complete and we have the right flags, then * we flag the user as also having been authenticated */ if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { if (ssh_gssapi_getclient(ctx, &gssapi_client)) fatal("Couldn't convert client name"); } return (status); The fatal() call there only happens when ssh_gssapi_getclient() fails, but not when one of the outer conditions fails. Normally, when the state is not complete, just returning here would be fine, but if the context is already complete and it?s just the flags that are wrong, no error is returned. I would still expect some reaction when it later received the follow-on message from the client, though.>> However, when I try to have my implementation not set this flag and just send a GSSAPI_TOKEN message immediately followed by a GSSAPI_MIC message without waiting for a server token (since the authentication is complete as soon as the client token is sent when mutual auth is disabled), I get a failure from OpenSSH: >> > > From the above comment, you are assuming that there will be no other tokens exchanged. > > After the gss_init_sec_context, you need to send any token from gss_init_sec_context > and if the status in not complete (or not an error) wait to receive the next token and call gss_init_sec_context > in a loop. > > GSS is not Kerberos specific and some other gss mechanisms will exchange multiple tokens.[Ron] Understood. However, when I don?t set the mutual_auth flag, my client context initialized with gss_init_sec_context() sets the ?complete? flag immediately after I create it and get the first outbound token out of it. It does not return the ?continue? result indicating that it wants a token back from the server. So, the only thing the code can do at that point is to send either MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE or MSG_USERAUTH_GSSAPI_MIC, depending on whether the integrity flag ends up set in the completed context, and that doesn?t work with OpenSSH?s sshd. I?m only able to get it to work if I set the mutual_auth flag. In that case, I get the outbound token and a ?continue? result to wait for sshd?s token, which I do and then feed to the context. After that, both sides return ?complete? and I?m able to send MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE or MSG_USERAUTH_GSSAPI_MIC to finish the authentication. Perhaps there's something else I?m missing when I create my client security context. However, if that?s the case, I haven?t figured out what it is. When creating the client context, I?m also setting the integrity flag and have an option to set the delegate_creds flag (and it works both with & without that, properly forwarding the creds when it is set), and I?m also explicitly setting the mechanism to the Kerberos OID. -- Ron Frederick ronf at timeheart.net
On 1/17/2017 3:18 PM, Ron Frederick wrote:> On Jan 17, 2017, at 9:57 AM, Douglas E Engert <deengert at gmail.com <mailto:deengert at gmail.com>> wrote: >> On 1/16/2017 2:09 PM, Ron Frederick wrote: >>> I?m working on an implementation of ?gssapi-with-mic? authentication for my AsyncSSH package and trying to get it to interoperate with OpenSSH. I?ve gotten it working, but there seems to be a >>> discrepancy between the OpenSSH implementation and RFC 4462. Specifically, RFC 4462 says the following in section 3.4: >>> >>> Since the user authentication process by its nature authenticates >>> only the client, the setting of mutual_req_flag is not needed for >>> this process. This flag SHOULD be set to "false". >> >> Note it says "SHOULD" not "MUST". Previous versions of SSH clients and mods to OpenSSH >> have always set mutual_req_flag. > > [Ron] Thanks - I did see that, but shouldn't that mean it should work correctly when my client is connecting to sshd whether or not I set the mutual auth flag? That doesn?t appear to be the case. > > Are you saying that OpenSSH?s sshd is intentionally rejecting the request when it sees the mutual_auth flag is not set? I see some code in OpenSSH which suggests it might be trying to do that, but I?m > never actually getting an auth failure here. The connection just hangs. > > When tracing it, it looks like OpenSSH?s sshd feeds the token I send into its accepting context and gets back no token to send (which would be correct), but then it never seems to complete the rest of > the state machine when I send the final message from the client.It may have a token to send, input_gssapi_token() calls ssh_gssapi_accept_ctx(...,&send_tok,...) then later in 2 places if (send_tok.length != 0) it sends a packet with the token. The code is also setup to handle multiple tokens being exchanged.> > The issue may be the way the code is structured: > > /* Now, if we're complete and we have the right flags, then > * we flag the user as also having been authenticated > */ > > if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && > (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { > if (ssh_gssapi_getclient(ctx, &gssapi_client)) > fatal("Couldn't convert client name"); > } > > return (status);Yes it looks like it requires GSS_C_MUTUAL_FLAG and GSS_C_INTEG_FLAG and if its not, then it never calls ssh_gssapi_getclient and does not give an error message either so the connection hangs. I think you have uncovered a bug. So I would recommend you have your client set GSS_C_MUTUAL_FLAG to avoid the issue.> > The fatal() call there only happens when ssh_gssapi_getclient() fails, but not when one of the outer conditions fails. Normally, when the state is not complete, just returning here would be fine, but > if the context is already complete and it?s just the flags that are wrong, no error is returned. I would still expect some reaction when it later received the follow-on message from the client, though. > > >>> However, when I try to have my implementation not set this flag and just send a GSSAPI_TOKEN message immediately followed by a GSSAPI_MIC message without waiting for a server token (since the >>> authentication is complete as soon as the client token is sent when mutual auth is disabled), I get a failure from OpenSSH: >>> >> >> From the above comment, you are assuming that there will be no other tokens exchanged. >> >> After the gss_init_sec_context, you need to send any token from gss_init_sec_context >> and if the status in not complete (or not an error) wait to receive the next token and call gss_init_sec_context >> in a loop. >> >> GSS is not Kerberos specific and some other gss mechanisms will exchange multiple tokens. > > [Ron] Understood. However, when I don?t set the mutual_auth flag, my client context initialized with gss_init_sec_context() sets the ?complete? flag immediately after I create it and get the first > outbound token out of it. It does not return the ?continue? result indicating that it wants a token back from the server. So, the only thing the code can do at that point is to send > either MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE or MSG_USERAUTH_GSSAPI_MIC, depending on whether the integrity flag ends up set in the completed context, and that doesn?t work with OpenSSH?s sshd. I?m > only able to get it to work if I set the mutual_auth flag. In that case, I get the outbound token and a ?continue? result to wait for sshd?s token, which I do and then feed to the context. After that, > both sides return ?complete? and I?m able to send MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE or MSG_USERAUTH_GSSAPI_MIC to finish the authentication. > > Perhaps there's something else I?m missing when I create my client security context. However, if that?s the case, I haven?t figured out what it is. > > When creating the client context, I?m also setting the integrity flag and have an option to set the delegate_creds flag (and it works both with & without that, properly forwarding the creds when it is > set), and I?m also explicitly setting the mechanism to the Kerberos OID. > -- > Ron Frederick > ronf at timeheart.net <mailto:ronf at timeheart.net> > > >-- Douglas E. Engert <DEEngert at gmail.com>
On Jan 17, 2017, at 6:01 PM, Douglas E Engert <deengert at gmail.com> wrote:> On 1/17/2017 3:18 PM, Ron Frederick wrote: >> On Jan 17, 2017, at 9:57 AM, Douglas E Engert <deengert at gmail.com <mailto:deengert at gmail.com>> wrote: >>> On 1/16/2017 2:09 PM, Ron Frederick wrote: >>>> I?m working on an implementation of ?gssapi-with-mic? authentication for my AsyncSSH package and trying to get it to interoperate with OpenSSH. I?ve gotten it working, but there seems to be a >>>> discrepancy between the OpenSSH implementation and RFC 4462. Specifically, RFC 4462 says the following in section 3.4: >>>> >>>> Since the user authentication process by its nature authenticates >>>> only the client, the setting of mutual_req_flag is not needed for >>>> this process. This flag SHOULD be set to "false". >>> >>> Note it says "SHOULD" not "MUST". Previous versions of SSH clients and mods to OpenSSH >>> have always set mutual_req_flag. >> >> [Ron] Thanks - I did see that, but shouldn't that mean it should work correctly when my client is connecting to sshd whether or not I set the mutual auth flag? That doesn?t appear to be the case. >> >> Are you saying that OpenSSH?s sshd is intentionally rejecting the request when it sees the mutual_auth flag is not set? I see some code in OpenSSH which suggests it might be trying to do that, but I?m >> never actually getting an auth failure here. The connection just hangs. >> >> When tracing it, it looks like OpenSSH?s sshd feeds the token I send into its accepting context and gets back no token to send (which would be correct), but then it never seems to complete the rest of >> the state machine when I send the final message from the client. > > It may have a token to send, input_gssapi_token() calls ssh_gssapi_accept_ctx(...,&send_tok,...) > then later in 2 places if (send_tok.length != 0) it sends a packet with the token. > The code is also setup to handle multiple tokens being exchanged.Right - when I set mutual_auth, it does have a token to send in this case, and after that both sides are complete. I agree that the code appears like it would handle multiple tokens on both sides as well, which might be useful if this code is ever used with something other than Kerberos. My implementation also supports this.> The issue may be the way the code is structured: >> >> /* Now, if we're complete and we have the right flags, then >> * we flag the user as also having been authenticated >> */ >> >> if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && >> (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { >> if (ssh_gssapi_getclient(ctx, &gssapi_client)) >> fatal("Couldn't convert client name"); >> } >> >> return (status); > > Yes it looks like it requires GSS_C_MUTUAL_FLAG and GSS_C_INTEG_FLAG > and if its not, then it never calls ssh_gssapi_getclient and does not give an error message either > so the connection hangs. I think you have uncovered a bug.Thanks for confirming this!> So I would recommend you have your client set GSS_C_MUTUAL_FLAG to avoid the issue.Yes - this is working fine, and I may just leave it that way, but I wanted to get to the bottom of the issue. Now that I have both client-side and server-side GSSAPI auth working in AsyncSSH, I was able to confirm that my own implementation can correctly handle mutual_auth being disabled, and it?s still able to properly complete the authentication of the client and get a proper client principal name in the server to validate with only the single token passing from the client to the server and no token in response. I also tested my code with integrity disabled where it sends an EXCHANGE_COMPLETE message instead of the MIC message, and confirmed that this works when I connect to myself. Unfortunately, there?s no way to get OpenSSH to handle this at the moment, either as a client or as a server. The integrity check seems like a good thing to have, so I?ll probably leave that enabled on my client in all cases for now. However, I have made my server code work in both cases, in case there are clients out there that request this authentication without the integrity check. I?ll do the same for mutual_auth, enabling it in my client to make sure I can interoperate with OpenSSH, but allowing other clients to disable it when connecting to my server code. -- Ron Frederick ronf at timeheart.net