2010-05-19 18:22:17 +00:00
|
|
|
#include "putty.h"
|
|
|
|
|
|
|
|
|
|
#include <string.h>
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
#include <limits.h>
|
2010-05-19 18:22:17 +00:00
|
|
|
#include "sshgssc.h"
|
|
|
|
|
#include "misc.h"
|
|
|
|
|
|
|
|
|
|
#ifndef NO_GSSAPI
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_indicate_mech(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_buf *mech)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
/* Copy constant into mech */
|
|
|
|
|
mech->length = GSS_MECH_KRB5->length;
|
|
|
|
|
mech->value = GSS_MECH_KRB5->elements;
|
|
|
|
|
return SSH_GSS_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_import_name(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
char *host,
|
|
|
|
|
Ssh_gss_name *srv_name)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
OM_uint32 min_stat,maj_stat;
|
|
|
|
|
gss_buffer_desc host_buf;
|
|
|
|
|
char *pStr;
|
|
|
|
|
|
|
|
|
|
pStr = dupcat("host@", host, NULL);
|
|
|
|
|
|
|
|
|
|
host_buf.value = pStr;
|
|
|
|
|
host_buf.length = strlen(pStr);
|
|
|
|
|
|
|
|
|
|
maj_stat = gss->import_name(&min_stat, &host_buf,
|
2019-09-08 19:29:00 +00:00
|
|
|
GSS_C_NT_HOSTBASED_SERVICE, srv_name);
|
2010-05-19 18:22:17 +00:00
|
|
|
/* Release buffer */
|
|
|
|
|
sfree(pStr);
|
|
|
|
|
if (maj_stat == GSS_S_COMPLETE) return SSH_GSS_OK;
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_acquire_cred(struct ssh_gss_library *lib,
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
Ssh_gss_ctx *ctx,
|
|
|
|
|
time_t *expiry)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
gss_OID_set_desc k5only = { 1, GSS_MECH_KRB5 };
|
|
|
|
|
gss_cred_id_t cred;
|
|
|
|
|
OM_uint32 dummy;
|
|
|
|
|
OM_uint32 time_rec;
|
2010-05-19 18:22:17 +00:00
|
|
|
gssapi_ssh_gss_ctx *gssctx = snew(gssapi_ssh_gss_ctx);
|
|
|
|
|
|
|
|
|
|
gssctx->ctx = GSS_C_NO_CONTEXT;
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
gssctx->expiry = 0;
|
|
|
|
|
|
|
|
|
|
gssctx->maj_stat =
|
|
|
|
|
gss->acquire_cred(&gssctx->min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
|
|
|
|
|
&k5only, GSS_C_INITIATE, &cred,
|
|
|
|
|
(gss_OID_set *)0, &time_rec);
|
|
|
|
|
|
|
|
|
|
if (gssctx->maj_stat != GSS_S_COMPLETE) {
|
|
|
|
|
sfree(gssctx);
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* When the credential lifetime is not yet available due to deferred
|
|
|
|
|
* processing, gss_acquire_cred should return a 0 lifetime which is
|
|
|
|
|
* distinct from GSS_C_INDEFINITE which signals a crential that never
|
|
|
|
|
* expires. However, not all implementations get this right, and with
|
|
|
|
|
* Kerberos, initiator credentials always expire at some point. So when
|
|
|
|
|
* lifetime is 0 or GSS_C_INDEFINITE we call gss_inquire_cred_by_mech() to
|
|
|
|
|
* complete deferred processing.
|
|
|
|
|
*/
|
|
|
|
|
if (time_rec == GSS_C_INDEFINITE || time_rec == 0) {
|
|
|
|
|
gssctx->maj_stat =
|
|
|
|
|
gss->inquire_cred_by_mech(&gssctx->min_stat, cred,
|
|
|
|
|
(gss_OID) GSS_MECH_KRB5,
|
|
|
|
|
GSS_C_NO_NAME,
|
|
|
|
|
&time_rec,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL);
|
|
|
|
|
}
|
|
|
|
|
(void) gss->release_cred(&dummy, &cred);
|
|
|
|
|
|
|
|
|
|
if (gssctx->maj_stat != GSS_S_COMPLETE) {
|
|
|
|
|
sfree(gssctx);
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (time_rec != GSS_C_INDEFINITE)
|
|
|
|
|
gssctx->expiry = time(NULL) + time_rec;
|
|
|
|
|
else
|
|
|
|
|
gssctx->expiry = GSS_NO_EXPIRATION;
|
2010-05-19 18:22:17 +00:00
|
|
|
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
if (expiry) {
|
|
|
|
|
*expiry = gssctx->expiry;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
*ctx = (Ssh_gss_ctx) gssctx;
|
2010-05-19 18:22:17 +00:00
|
|
|
return SSH_GSS_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_init_sec_context(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_ctx *ctx,
|
|
|
|
|
Ssh_gss_name srv_name,
|
|
|
|
|
int to_deleg,
|
|
|
|
|
Ssh_gss_buf *recv_tok,
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
Ssh_gss_buf *send_tok,
|
|
|
|
|
time_t *expiry,
|
|
|
|
|
unsigned long *lifetime)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
gssapi_ssh_gss_ctx *gssctx = (gssapi_ssh_gss_ctx*) *ctx;
|
|
|
|
|
OM_uint32 ret_flags;
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
OM_uint32 lifetime_rec;
|
2010-05-19 18:22:17 +00:00
|
|
|
|
|
|
|
|
if (to_deleg) to_deleg = GSS_C_DELEG_FLAG;
|
|
|
|
|
gssctx->maj_stat = gss->init_sec_context(&gssctx->min_stat,
|
2019-09-08 19:29:00 +00:00
|
|
|
GSS_C_NO_CREDENTIAL,
|
|
|
|
|
&gssctx->ctx,
|
|
|
|
|
srv_name,
|
|
|
|
|
(gss_OID) GSS_MECH_KRB5,
|
|
|
|
|
GSS_C_MUTUAL_FLAG |
|
|
|
|
|
GSS_C_INTEG_FLAG | to_deleg,
|
|
|
|
|
0,
|
|
|
|
|
GSS_C_NO_CHANNEL_BINDINGS,
|
|
|
|
|
recv_tok,
|
|
|
|
|
NULL, /* ignore mech type */
|
|
|
|
|
send_tok,
|
|
|
|
|
&ret_flags,
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
&lifetime_rec);
|
|
|
|
|
|
|
|
|
|
if (lifetime) {
|
|
|
|
|
if (lifetime_rec == GSS_C_INDEFINITE)
|
|
|
|
|
*lifetime = ULONG_MAX;
|
|
|
|
|
else
|
|
|
|
|
*lifetime = lifetime_rec;
|
|
|
|
|
}
|
|
|
|
|
if (expiry) {
|
|
|
|
|
if (lifetime_rec == GSS_C_INDEFINITE)
|
|
|
|
|
*expiry = GSS_NO_EXPIRATION;
|
|
|
|
|
else
|
|
|
|
|
*expiry = time(NULL) + lifetime_rec;
|
|
|
|
|
}
|
2010-05-19 18:22:17 +00:00
|
|
|
|
|
|
|
|
if (gssctx->maj_stat == GSS_S_COMPLETE) return SSH_GSS_S_COMPLETE;
|
|
|
|
|
if (gssctx->maj_stat == GSS_S_CONTINUE_NEEDED) return SSH_GSS_S_CONTINUE_NEEDED;
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_display_status(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_ctx ctx,
|
|
|
|
|
Ssh_gss_buf *buf)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
gssapi_ssh_gss_ctx *gssctx = (gssapi_ssh_gss_ctx *) ctx;
|
|
|
|
|
OM_uint32 lmin,lmax;
|
|
|
|
|
OM_uint32 ccc;
|
|
|
|
|
gss_buffer_desc msg_maj=GSS_C_EMPTY_BUFFER;
|
|
|
|
|
gss_buffer_desc msg_min=GSS_C_EMPTY_BUFFER;
|
|
|
|
|
|
|
|
|
|
/* Return empty buffer in case of failure */
|
|
|
|
|
SSH_GSS_CLEAR_BUF(buf);
|
|
|
|
|
|
|
|
|
|
/* get first mesg from GSS */
|
|
|
|
|
ccc=0;
|
|
|
|
|
lmax=gss->display_status(&lmin,gssctx->maj_stat,GSS_C_GSS_CODE,(gss_OID) GSS_MECH_KRB5,&ccc,&msg_maj);
|
|
|
|
|
|
|
|
|
|
if (lmax != GSS_S_COMPLETE) return SSH_GSS_FAILURE;
|
|
|
|
|
|
|
|
|
|
/* get first mesg from Kerberos */
|
|
|
|
|
ccc=0;
|
|
|
|
|
lmax=gss->display_status(&lmin,gssctx->min_stat,GSS_C_MECH_CODE,(gss_OID) GSS_MECH_KRB5,&ccc,&msg_min);
|
|
|
|
|
|
|
|
|
|
if (lmax != GSS_S_COMPLETE) {
|
|
|
|
|
gss->release_buffer(&lmin, &msg_maj);
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* copy data into buffer */
|
|
|
|
|
buf->length = msg_maj.length + msg_min.length + 1;
|
|
|
|
|
buf->value = snewn(buf->length + 1, char);
|
|
|
|
|
|
|
|
|
|
/* copy mem */
|
|
|
|
|
memcpy((char *)buf->value, msg_maj.value, msg_maj.length);
|
|
|
|
|
((char *)buf->value)[msg_maj.length] = ' ';
|
|
|
|
|
memcpy((char *)buf->value + msg_maj.length + 1, msg_min.value, msg_min.length);
|
|
|
|
|
((char *)buf->value)[buf->length] = 0;
|
|
|
|
|
/* free mem & exit */
|
|
|
|
|
gss->release_buffer(&lmin, &msg_maj);
|
|
|
|
|
gss->release_buffer(&lmin, &msg_min);
|
|
|
|
|
return SSH_GSS_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_free_tok(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_buf *send_tok)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
OM_uint32 min_stat,maj_stat;
|
|
|
|
|
maj_stat = gss->release_buffer(&min_stat, send_tok);
|
|
|
|
|
|
|
|
|
|
if (maj_stat == GSS_S_COMPLETE) return SSH_GSS_OK;
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_release_cred(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_ctx *ctx)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
gssapi_ssh_gss_ctx *gssctx = (gssapi_ssh_gss_ctx *) *ctx;
|
|
|
|
|
OM_uint32 min_stat;
|
|
|
|
|
OM_uint32 maj_stat=GSS_S_COMPLETE;
|
|
|
|
|
|
|
|
|
|
if (gssctx == NULL) return SSH_GSS_FAILURE;
|
|
|
|
|
if (gssctx->ctx != GSS_C_NO_CONTEXT)
|
|
|
|
|
maj_stat = gss->delete_sec_context(&min_stat,&gssctx->ctx,GSS_C_NO_BUFFER);
|
|
|
|
|
sfree(gssctx);
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
*ctx = NULL;
|
2010-05-19 18:22:17 +00:00
|
|
|
|
|
|
|
|
if (maj_stat == GSS_S_COMPLETE) return SSH_GSS_OK;
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_release_name(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_name *srv_name)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
OM_uint32 min_stat,maj_stat;
|
|
|
|
|
maj_stat = gss->release_name(&min_stat, srv_name);
|
|
|
|
|
|
|
|
|
|
if (maj_stat == GSS_S_COMPLETE) return SSH_GSS_OK;
|
|
|
|
|
return SSH_GSS_FAILURE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static Ssh_gss_stat ssh_gssapi_get_mic(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_ctx ctx, Ssh_gss_buf *buf,
|
|
|
|
|
Ssh_gss_buf *hash)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
gssapi_ssh_gss_ctx *gssctx = (gssapi_ssh_gss_ctx *) ctx;
|
|
|
|
|
if (gssctx == NULL) return SSH_GSS_FAILURE;
|
|
|
|
|
return gss->get_mic(&(gssctx->min_stat), gssctx->ctx, 0, buf, hash);
|
|
|
|
|
}
|
|
|
|
|
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
static Ssh_gss_stat ssh_gssapi_verify_mic(struct ssh_gss_library *lib,
|
|
|
|
|
Ssh_gss_ctx ctx, Ssh_gss_buf *buf,
|
|
|
|
|
Ssh_gss_buf *hash)
|
|
|
|
|
{
|
|
|
|
|
struct gssapi_functions *gss = &lib->u.gssapi;
|
|
|
|
|
gssapi_ssh_gss_ctx *gssctx = (gssapi_ssh_gss_ctx *) ctx;
|
|
|
|
|
if (gssctx == NULL) return SSH_GSS_FAILURE;
|
|
|
|
|
return gss->verify_mic(&(gssctx->min_stat), gssctx->ctx, buf, hash, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
static Ssh_gss_stat ssh_gssapi_free_mic(struct ssh_gss_library *lib,
|
2019-09-08 19:29:00 +00:00
|
|
|
Ssh_gss_buf *hash)
|
2010-05-19 18:22:17 +00:00
|
|
|
{
|
|
|
|
|
/* On Unix this is the same freeing process as ssh_gssapi_free_tok. */
|
|
|
|
|
return ssh_gssapi_free_tok(lib, hash);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ssh_gssapi_bind_fns(struct ssh_gss_library *lib)
|
|
|
|
|
{
|
|
|
|
|
lib->indicate_mech = ssh_gssapi_indicate_mech;
|
|
|
|
|
lib->import_name = ssh_gssapi_import_name;
|
|
|
|
|
lib->release_name = ssh_gssapi_release_name;
|
|
|
|
|
lib->init_sec_context = ssh_gssapi_init_sec_context;
|
|
|
|
|
lib->free_tok = ssh_gssapi_free_tok;
|
|
|
|
|
lib->acquire_cred = ssh_gssapi_acquire_cred;
|
|
|
|
|
lib->release_cred = ssh_gssapi_release_cred;
|
|
|
|
|
lib->get_mic = ssh_gssapi_get_mic;
|
Support GSS key exchange, for Kerberos 5 only.
This is a heavily edited (by me) version of a patch originally due to
Nico Williams and Viktor Dukhovni. Their comments:
* Don't delegate credentials when rekeying unless there's a new TGT
or the old service ticket is nearly expired.
* Check for the above conditions more frequently (every two minutes
by default) and rekey when we would delegate credentials.
* Do not rekey with very short service ticket lifetimes; some GSSAPI
libraries may lose the race to use an almost expired ticket. Adjust
the timing of rekey checks to try to avoid this possibility.
My further comments:
The most interesting thing about this patch to me is that the use of
GSS key exchange causes a switch over to a completely different model
of what host keys are for. This comes from RFC 4462 section 2.1: the
basic idea is that when your session is mostly bidirectionally
authenticated by the GSSAPI exchanges happening in initial kex and
every rekey, host keys become more or less vestigial, and their
remaining purpose is to allow a rekey to happen if the requirements of
the SSH protocol demand it at an awkward moment when the GSS
credentials are not currently available (e.g. timed out and haven't
been renewed yet). As such, there's no need for host keys to be
_permanent_ or to be a reliable identifier of a particular host, and
RFC 4462 allows for the possibility that they might be purely
transient and only for this kind of emergency fallback purpose.
Therefore, once PuTTY has done a GSS key exchange, it disconnects
itself completely from the permanent host key cache functions in
storage.h, and instead switches to a _transient_ host key cache stored
in memory with the lifetime of just that SSH session. That cache is
populated with keys received from the server as a side effect of GSS
kex (via the optional SSH2_MSG_KEXGSS_HOSTKEY message), and used if
later in the session we have to fall back to a non-GSS key exchange.
However, in practice servers we've tested against do not send a host
key in that way, so we also have a fallback method of populating the
transient cache by triggering an immediate non-GSS rekey straight
after userauth (reusing the code path we also use to turn on OpenSSH
delayed encryption without the race condition).
2018-04-26 06:18:59 +00:00
|
|
|
lib->verify_mic = ssh_gssapi_verify_mic;
|
2010-05-19 18:22:17 +00:00
|
|
|
lib->free_mic = ssh_gssapi_free_mic;
|
|
|
|
|
lib->display_status = ssh_gssapi_display_status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
/* Dummy function so this source file defines something if NO_GSSAPI
|
|
|
|
|
is defined. */
|
|
|
|
|
|
|
|
|
|
int ssh_gssapi_init(void)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|