[remctl] Proposal for new credential delegation functionality

[Greg Hudson]

On 11/14/2014 09:31 AM, Rémi Ferrand wrote:
> * How could I know which service principal was used to authenticate to
> the remctl server ? I need this information for
> gss_acquire_cred_impersonate_name() 3d argument and for
> gss_init_sec_context() 4th argument.

gss_acquire_cred_impersonate_name is for S4U2Self.  You do not need to
use S4U2Self if the client authenticated to the intermediate service
using Kerberos.  You only need to use S4U2Proxy.

The fourth argument to gss_init_sec_context is the name of the target
service, not the name of the client.

So, while you can find out which service name was used using
gss_inquire_context, you should not need it.

Once the code is written, the administrator does need to pay some
attention to this.  The server process needs a TGT in order to make the
S4U2Proxy request, and the client principal of this TGT must match the
name of the key used to decrypt the client ticket.  This is perhaps a
bit more restrictive than necessary, and the diagnostics aren't great if
the admin gets it wrong; see:
https://krbdev.mit.edu/rt/Ticket/Display.html?id=8033

> * Which credentials should I use for
> gss_acquire_cred_impersonate_name(), gss_init_sec_context() and
> gss_accept_sec_context(). I'm only dealing with two different
> credentials for now (client_delegated ones and remctl server ones).

Acquire a cred with usage GSS_C_BOTH and the default name.

Pass this cred as the verifier_cred_handle to gss_accept_sec_context and
get a delegated_cred_handle.

Pass that delegated cred as the claimant_cred_handle to
gss_init_sec_context.  Give gss_init_sec_context the target_name of the
service you want to authenticate to as the client.

That is all you have to do for S4U2Proxy with a client-supplied evidence
ticket.

> * How should I expect my KDc to behave if it does not support S4U2Proxy
> ? Will it just deny granting a TGS and the GSS libraries will fail with
> an explicit message ?

Yes.

> * In S4U2Proxy and S4U2Self, is there any kind of *authorization* done
> at the KDC level ? MIT Kerberos as the *ok_to_auth_as_delegate* flag.
> In a MIT KDC for instance, is enabling S4U2Proxy as simple as adding the
> *ok_to_auth_as_delegate* flag to the *service/remctl at EXAMPLE.ORG*
> principal ?
> I suppose that more complex operations are involved if the LDAP backend
> is a prerequisite. Is there any support for ACL such as "principal_A" is
> authorized to proxy this very ticket ... ?

Yes, there is authorization performed at the KDC level.  At present, MIT
krb5 only supports this authorization with the LDAP KDB module using the
AllowedToDelegateTo attribute; the DB2 KDB module will always reject
S4U2Proxy requests.

> Learning how to properly use the GSS with those extensions isn't as
> simple as I expected.

The S4U implementation in MIT krb5 went in at a time when our
documentation infrastructure was still in flux, so it unfortunately did
not receive a proper writeup.  The project page at
http://k5wiki.kerberos.org/wiki/Projects/Services4User can be useful but
is really design notes rather than proper developer-facing documentation.