[remctl] Proposal for new credential delegation functionality

Rémi Ferrand remi.ferrand at cc.in2p3.fr
Fri Nov 14 09:31:02 EST 2014


Thank you Simo for your detailed answer,

Things are becoming more intuitive, but still, I can't really understand 
the whole picture.

I've created a GIST (https://gist.github.com/riton/bdf6df5b589a20d46c6e)
that only shows the main functions that should be called in remctl and 
all the questions that I'm still unable to solve by myself.

The main questions are:

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

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

* 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 ?
For now I'm still working with a test version of 
heimdal-server-1.6.0-0.9.20140621gita5adc06.el6.x86_64. As expected, 
this version seem to support S4U2Self operations (I've seen message like 
"2014-11-14T10:47:32 krb5_verify_checksum failed for S4U2Self: Checksum 
type hmac-md5 is keyed, but the key type aes256-cts-hmac-sha1-96 passed 
didnt have that checksum type as the keyed type" in the KDC logs, so 
it's S4U2Self aware).
However, I still don't have any clue about additional principal flags 
introduced in Heimdal.

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

Thanks in advance for any help and thanks for your time.

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

Cheers

R.

On 12/11/2014 00:57, Simo Sorce wrote:
> 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.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2940 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20141114/f98ecf11/attachment.bin


More information about the Kerberos mailing list