[remctl] Proposal for new credential delegation functionality

[Remi FERRAND]

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 :-).


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 ?

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 ?

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 ?
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.

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...


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.

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.

Cheers

Rémi


----- Original Message -----
From: "Russ Allbery" <eagle at eyrie.org>
To: "Simo Sorce" <simo at redhat.com>
Cc: "Rémi Ferrand" <remi.ferrand at cc.in2p3.fr>, kerberos at mit.edu
Sent: Friday, November 7, 2014 8:19:02 PM
Subject: Re: [remctl] Proposal for new credential delegation functionality

Simo Sorce <simo at redhat.com> writes:

> It is a very nice to have, but, it would be really nice if you did not
> use unbounded delegation (ie send the whole TGT) but ratherr allow to
> either just send a ticket (set of tickets) for whatever action may be
> neded, and/or support constrained delegation on the receiving end
> (s4u2proxy).

s4u2proxy feels like the right tool to me.  I don't like the idea of
unconstrained delegation, and constrained delegation where the client
sends a specific ticket requires the client know what ticket to send.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>