Following Steve's Question - Re Tokens in SPNEGO

[Alexander Bokovoy]

Hi William,

On pe, 29 touko 2020, William Brown via samba-technical wrote:
> Hi there,
> 
> Thinking to Steve's question yesterday, it would be interesting to
> know from the experts on this mailing list an answer. How what would
> opaque token authentication look like in Samba? How would a passdb
> support this style of authentication? How would a client get the token
> to pass through?
> 
> It would be great to know more about this and explore some of these thoughts. 

My current thinking is around reusing existing infrastructure in the
protocol. SMB3 authenticates with SPNEGO[1]. SPNEGO allows to have multiple
authentication mechanisms advertised, with most common ones being krb5
and NTLM. These are not the only ones, a common extension mechanism
called NEGOEX can be used as well[2].

NEGOEX is basically a way to tunnel some method of authentication known
to both client and server through SPNEGO. It doesn't need need to
require a third party (like KDC) to broker an authenticity of the
parties. MIT Kerberos supports NEGOEX since version 1.18, there are also
patches for Heimdal.

MIT Kerberos has a sample negoex GSSAPI plugin:
https://github.com/krb5/krb5/blob/master/src/plugins/gssapi/negoextest/main.c

It is used within this test:
https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_negoex.py
which, in turn, runs a very simple GSSAPI application that imports a
target service name, initializes the security context to it using SPNEGO
mechanism and then imitates an application accepting this security
context, all using defaults.

The negoextest plugin implements a simple counter of iterations before
accepting the token as its security context handle -- it is decremented
and then the value is encapsulated into an output token that is passed
back to the application.

On the target application side, when input from a client is accepted by
the negoextest plugin, the plugin unwraps a token and decides whether to
continue ping-ponging with a client by decrementing the token's hops or
completing the exchange.

Nothing in this exchange requires Kerberos KDC to exist. Whatever
gss_init_security_context() / gss_accept_security_context() consider
needed to implement a correct exchange will be accepted by GSSAPI.

We are not limited by the way how gss_accept_security_context()
implementation does its verification of the context but we should
consider how we derive information that Samba needs afterwards: NT
security token. 

Right now we get this information either from MS-PAC record in the
Kerberos ticket or from NTLMSSP negotiation. It is something that NEGOEX
plugin would need to implement so that an application after accepting
the security context would be able to do

  gss_inquire_name(..., &attrs);

  find an attribute with the right name

  gss_get_name_attribute(..., name, attribute, ..., &value, ...);

  extract NT security token or something that can be used to construct
  it from the value with the right name


[1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-SPNG/d2ccb21f-be95-426e-88b3-020bd39158f1
[2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-SPNG/fe1b1adc-07f6-40c0-a36b-b4f75be2695e

-- 
/ Alexander Bokovoy