[remctl] Proposal for new credential delegation functionality

[Simo Sorce]

On Tue, 11 Nov 2014 23:19:41 +0100 (CET)
Remi FERRAND <remi.ferrand at cc.in2p3.fr> wrote:

> Ok, I don't have any experience nor knowledge about s4u2proxy for now.
> I've read everything I could find about it, there's not a lot of
> documentation about this (except general concepts)...
> 
> 
> I'm still not very comfortable with those new concepts so please,
> apologize for any mistake below.
> 
> For now, remctl does the following:
> 
> * gss_init_sec_context() in client/open.c
> * gss_accept_sec_context() in server/generic.c
> 
> For my test bed, all I've done is :
> * add the GSS_C_DELEG_FLAG flag in client's gss_init_sec_context.
> * provide a gss_cred_id_t structure to server's
> gss_accept_sec_context in order to retrieve delegated creds.
> * write delegated creds in a new krb5 ccache file and set KRB5CCNAME
> variable in process env just like SSH does.
> 
> For now, I've done uncontrained delegation.
> 
> 
> The only real documentation I could found about "GSSAPI developpment"
> and "s4u2" features is
> http://k5wiki.kerberos.org/wiki/Projects/Services4User#gss_accept_sec_context.
> There's also Simo's post at https://ssimo.org/blog/id_011.html. I've
> searched FreeIPA's code for gss/s4u2 specific parts, but I couldn't
> find any. If you can point some source files or lines, I'll greatly
> appreciate :-).

This may help a little:
https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/src/gp_creds.c#n476

This one does s4u2self+s4u2proxy, you may want to do just the latter.
IIRC in that case all you need to do (with MIT libraries) is to store
delegated_creds you get out of gss_accept_sec_context() (yes even if no
creds were delegated, in that case only the user's evidence ticket is
saved), and then just use gss_init_sec_context() with those creds.

> Even after Simo's post, in the example of Service-for-User-to-Proxy
> (https://ssimo.org/blog/id_011.html), What is quite unclear for me at
> the moment is the workflow that I should adopt for remctl.
> 
> For instance, in a very simple scenario like this one:
> 
> [remctl client / principal "bob at EXAMPLE.ORG]
> owns a forwardable TGT,
> requests command "the_proxy_command" on host "server1"
> 
>   |
>   |
>   V
> 
> [remctl server on host "server1" / service principal
> "service/remctl/server1 at EXAMPLE.ORG"] executes command
> "the_proxy_command". The script "the_proxy_command" does stuff and
> among other things, executes the remctl command "the_final_command"
> on an other host.
> 
>   |
>   |
>   V
> 
> [remctl server on host "otherhost" / service principal
> "service/remctl/otherhost at EXAMPLE.ORG"] executes command
> "the_final_command"
> 
> 
> Questions:
> 
> 1) Simo's blog says "With S4U the user only needs a Forward-able TGT,
> but does not need to actually forward it at all". How could I specify
> that in remctl client's code ? I'm currently only using the
> GSS_C_DELEG_FLAG and I can't find any other way to do so ... . Is
> this done "behind the scenes" and transparent at the GSS level ?

You do not delegate anything from the client, all the server needs is
the regular ticket the client send to the server as proof of
authentication.


> 2) On the remctl server running on host "server1",
> gss_accept_sec_context() will deliver me client's TGT in the
> delegated credentials structure. What extra "gss_*" function should I
> call to use S4U2Proxy ? The server currently obtain a "gss_cred_id_t"
> structure fed by gss_accept_sec_context(). What extra manipulation
> should I do on those creds ?

See above, just store the cred (which is really just a ticket in this
case) and reuse as is in init_context.

> 3) Does the remctl server on host "server1" needs to know "in
> advance" the service name "service/remctl/otherhost" in order to
> obtain a TGS for it ?

No.

> Is the remctl server even responsible for
> retrieving those TGS and providing them to the remctl command
> "the_proxy_command" ? In my current "test bed", as the TGT is stored
> in a ccache file, all of this is not handled by the remctl server.

The middle server will need a ticket to talk to the next server, that
is what you store in the ccache, the init_sec_context in the remctl
client called by "the_proxy_command" is what will perform the TGS
request.

> 4) At CC-IN2P3 we're currently running Heimdal KDCs. I was unable to
> find any attribute to use on a particular principal to allow/disallow
> delegation (same as MIT kerberos *ok_to_auth_as_delegate* attribute).
> Am I missing something ? I've seen a message of Love Hörnquist
> Åstrand in Heimdal's saying that constrained delegation is supported,
> but I couldn't find any documentation about this...

Although Heimdal libraries have some support for S4U2Proxy I have
experience and testing only using MIT KDCs and Client libraries.
Note though that you need a special database driver that can allow the
KDC to perform S4U2Proxy.

Ad does that, as well as FreeIPA, we are working on getting the
necessary support to express S4U2Proxy ACLs ins the MIT LDAP driver:
http://k5wiki.kerberos.org/wiki/Projects/KerberosDelegationACL
This is based on the work done in FreeIPA, but is not yet included in
the MIT code.

> Even after reading MIT's test file
> (https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c)
> dedicated to s4u2proxy, I've not seen any "unusual" gss scenario or
> calls. It basically does gss_init_sec_context() ->
> gss_accept_sec_context() loop, retrieves delegated credetials through
> gss_accept_sec_context() argument and then work in a "standard way"
> with them.
> 
> 
> If anyone could answer my questions, I'll be very grateful.

I hope I addressed your main points, if not ask for more :)

> Thanks guys for your time, It's a new Kerberos side that I'm
> discovering here, and It seems quite hard to find documentation about
> it.

S4U2Proxy does not have a ton of docs indeed ..

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York