gssapi-with-mic vs gssapi-keyex SSH authentication difference?

[Rufe Glick]

Hello,

I have Kerberos infrastructure set up and GSSAPI enabled in ssh_config/sshd_config of the SSH client/server (GSSAPIAuthentication yes). When I connect to the SSH server using verbose mode I see that SSH client uses 'gssapi-with-mic' mode to authenticate itself. Then if I additionally enable 'GSSAPIKeyExchange yes' setting the SSH client prefers the 'gssapi-keyex' method to authenticate itself.

The questions are what does happen under the hood of both of these methods (in simple terms, please)? And what is the essential difference? Also what kind of keys do they exchange when 'gssapi-keyex' auth method is in use?

--
Best regards,
Rufe

[Benjamin Kaduk]

gssapi-keyex is not a way for the client to authenticate to the server; it
replaces the normal key exchange step that uses the server's
ssh_host_{ecdsa,rsa,dsa}_keys. GSSAPIKeyExchange is a way to avoid the
"leap of faith" initial prompt when sshing to a remote host for the first
time. (That is, "The authenticity of host 'blah' can't be established.
RSA key fingerprint is [hex]. Are you sure you want to continue
connecting (yes/no)?".)

GSSAPIAuthentication is a way for the client to authenticate to the
server; it replaces user ssh keys (e.g., ~/.ssh/id_rsa) and passwords.

-Ben Kaduk

[Greg Hudson]

On 10/31/2014 01:52 PM, Benjamin Kaduk wrote:
> gssapi-keyex is not a way for the client to authenticate to the server; it
> replaces the normal key exchange step that uses the server's
> ssh_host_{ecdsa,rsa,dsa}_keys.

If memory serves, the gssapi-keyex key exchange actually authenticates
both parties to each other. Once you have completed that, you gain
access to the gssapi-keyex userauth method, which does basically nothing
as the user is already authenticated (much like SASL EXTERNAL). The
client could still use a different userauth method to authenticate as
someone else, but it generally prefers gssapi-keyex.

[Tomas Kuthan]

On 10/31/14 18:38, Rufe Glick wrote:
> Hello,
>
> I have Kerberos infrastructure set up and GSSAPI enabled in ssh_config/sshd_config of the SSH client/server (GSSAPIAuthentication yes). When I connect to the SSH server using verbose mode I see that SSH client uses 'gssapi-with-mic' mode to authenticate itself. Then if I additionally enable 'GSSAPIKeyExchange yes' setting the SSH client prefers the 'gssapi-keyex' method to authenticate itself.
>
> The questions are what does happen under the hood of both of these methods (in simple terms, please)? And what is the essential difference? Also what kind of keys do they exchange when 'gssapi-keyex' auth method is in use?
>

> --
> Best regards,
> Rufe
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Hi Rufe,

first step of establishing ssh connection is establishing Transport
Layer. In this step the server is authenticated and keys are exchanged,
that are used to provide integrity and confidentiality. User
authentication is then performed over this secure channel.

There are several Key Exchange Methods, one of which is
GSS-API-Authenticated Diffie-Hellman Key Exchange.

'gssapi-keyex' and 'gssapi-with-mics' are two examples of user
authentication methods. The fundamental difference is, that
'gssapi-keyex' authentication can only be used when the key exchange
earlier was GSS-API-Authenticated Diffie-Hellman Key Exchange and it
reuses the context from the key exchange.

For more information please refer to RFC 4462

Tomas

[Nico Williams]

GSS keyex authenticates the server to the client. The client can then
be authenticated to the server with it tries gssapi-keyex userauth.

Nico
--

[Nico Williams]

GSS key exchange alone does not authenticate the client to the server
because a binding of the GSS security context to the Diffie-Hellman or
RSA key exchange is not sent by the client, only by the server. There
is not much point to authenticating the client at this point anyways
because GSS authentication is not enough: we need a *username* to
authorize the authenticated _principal_ to, and that comes later in
the protocol.

SSHv2 could well have been (and perhaps still could be) optimized
quite a bit. As it is all of this takes quite a few messages: TCP
handshake, version string scream exchange, KEX (one round-trip in the
optimal case, with GSS and Kebreros), userauth (one more round-trip in
the optimal case, with gss-api-keyex). If confidentiality protection
of the client principal and username were not important this could be
reduced by one round trip in an optimized form of the protocol.

Nico
--