[36611] in Kerberos
Re: [remctl] Proposal for new credential delegation functionality
daemon@ATHENA.MIT.EDU (=?UTF-8?B?UsOpbWkgRmVycmFuZA==?=)
Fri Nov 14 09:31:31 2014
Message-ID: <54661226.5030409@cc.in2p3.fr>
Date: Fri, 14 Nov 2014 15:31:02 +0100
From: =?UTF-8?B?UsOpbWkgRmVycmFuZA==?= <remi.ferrand@cc.in2p3.fr>
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
In-Reply-To: <20141111185707.72edaa29@willson.usersys.redhat.com>
Cc: kerberos@mit.edu
Content-Type: multipart/mixed; boundary="===============1653348994=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============1653348994==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms000605070700080401050606"
This is a cryptographically signed message in MIME format.
--------------ms000605070700080401050606
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
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=20
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=20
the remctl server ? I need this information for=20
gss_acquire_cred_impersonate_name() 3d argument and for=20
gss_init_sec_context() 4th argument.
* Which credentials should I use for=20
gss_acquire_cred_impersonate_name(), gss_init_sec_context() and=20
gss_accept_sec_context(). I'm only dealing with two different=20
credentials for now (client_delegated ones and remctl server ones).
* How should I expect my KDc to behave if it does not support S4U2Proxy=20
? Will it just deny granting a TGS and the GSS libraries will fail with=20
an explicit message ?
For now I'm still working with a test version of=20
heimdal-server-1.6.0-0.9.20140621gita5adc06.el6.x86_64. As expected,=20
this version seem to support S4U2Self operations (I've seen message like =
"2014-11-14T10:47:32 krb5_verify_checksum failed for S4U2Self: Checksum=20
type hmac-md5 is keyed, but the key type aes256-cts-hmac-sha1-96 passed=20
didnt have that checksum type as the keyed type" in the KDC logs, so=20
it's S4U2Self aware).
However, I still don't have any clue about additional principal flags=20
introduced in Heimdal.
* In S4U2Proxy and S4U2Self, is there any kind of *authorization* done=20
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@EXAMPLE.ORG*=20
principal ?
I suppose that more complex operations are involved if the LDAP backend=20
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=20
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@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=
=2Ec#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@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@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@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=C3=B6rnquist
>> =C3=85strand in Heimdal's saying that constrained delegation is suppor=
ted,
>> 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.
>
--------------ms000605070700080401050606
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIczCC
A7YwggKeoAMCAQICAQMwDQYJKoZIhvcNAQEFBQAwLDELMAkGA1UEBhMCRlIxDTALBgNVBAoT
BENOUlMxDjAMBgNVBAMTBUNOUlMyMB4XDTA5MDEyMTA5MDM1MloXDTI5MDEyMDA5MDM1Mlow
NTELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFzAVBgNVBAMTDkNOUlMyLVN0YW5kYXJk
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnKlkarQHIxnDvggIxOIqXe3UKN7+
P6DtkkRrFkc1EzeNdKn1TYPkBRuPCGFM3ndb16n/u2Wdyaw8D/GJe5MioEcPXwa+jnigC3nX
QmVhcmOSQIpbZxD61ic+2HdNHnnbb0sSAFJY4thCBbIzN3fgjWwdvPj28pRYJfeC2YbZXPPY
Ls39cIkEh+850SrYkoxpLxxSZfpgjxB/zI/5XC4U7UyL4J03uNI8lMpQ/UF63vY87K7svVwW
3bDwc5l6gf87M9IAnk2Mxls4LjPDdobKclTbLeIQ/ZJQaJOE7XepiWlRhevglKP5lwgRjCTw
D7o4tCzW12xOY/60MZ/vj6ZapQIDAQABo4HZMIHWMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0O
BBYEFBHj2dFSRxtZsTwbeGZr9KGI7QpbMFQGA1UdIwRNMEuAFFCXtg33rDMXr/EdRjxrO/8A
oOXloTCkLjAsMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEOMAwGA1UEAxMFQ05SUzKC
AQAwDgYDVR0PAQH/BAQDAgEGMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9jcmxzLnNlcnZp
Y2VzLmNucnMuZnIvQ05SUzIvZ2V0ZGVyLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAT+njF+ZM
J/UXalBV6u7PTKq97izddj5ZoC8LaInaQ9AeHSxrEvlnE55lK6SE0jHPgqDK7yLoEGzpzxd8
rK2HhUyK4dV7TObZDrKh5CmeIK8PPnu5fyRMMuCI/nrarBZgoXWuiZyKZp2Uun6rDiAj7ffH
hF2CSBTexNSwxU4sh9SNAxEvNtUpb66ZZxkMjW1aIN/Rn8bLr1XuC8qxWw/vXHT080aJY0d+
LM6/yDANAEb2GOZsPzB+kG4QjR85Sc+TaevInsJnc69Ki/Z8Qijdpd3tr8lVG2Q/VLxhJhDr
kdXp9+7Q9gsL+qaQ3WD0QJ0Lp5z4zi8hOP6rBr/aDXf6ZzCCBLUwggOdoAMCAQICAncXMA0G
CSqGSIb3DQEBBQUAMDUxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRcwFQYDVQQDEw5D
TlJTMi1TdGFuZGFyZDAeFw0xMzEyMTYwOTU2NTRaFw0xNTEyMTYwOTU2NTRaMG4xCzAJBgNV
BAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRAwDgYDVQQLEwdVU1I2NDAyMRUwEwYDVQQDEwxSZW1p
IEZlcnJhbmQxJzAlBgkqhkiG9w0BCQEWGHJlbWkuZmVycmFuZEBjYy5pbjJwMy5mcjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKX2GNdpXGGVVTHINm0/jbX4GhT7ahVCNlJA
vv0cg5oGxw8sJRNKdM6AWvPz7Q93FkxFy9dcPL3R9deXo4FgAF+RCbDtnDorPCqo+Zmk+2M/
FsbGKPcauVsy8wWua3l08GcDLICwYA/urUeI/obeo2xTbhT0FQTNHKvYJPGVTSxEZ332yNBp
yapLOvlg8hMjruFXUQ3cSCrt5fCAH/MJX9klvA0cDBJ79mbss9O+S9YpMsyHTfESoVVuOIE3
y8ulpioMyL/JKAzsQRxTvXY8l0fgITCaMHEAv1CTg2aSaY9+RvyFXZEWeF9Gkx20XN1TNutq
yzRoLLQ7BRqVRceyR5sCAwEAAaOCAZQwggGQMAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEB
BAQDAgSwMA4GA1UdDwEB/wQEAwIF4DB6BglghkgBhvhCAQ0EbRZrQ2VydGlmaWNhdCBDTlJT
Mi1TdGFuZGFyZC4gUG91ciB0b3V0ZSBpbmZvcm1hdGlvbiBzZSByZXBvcnRlciDgIGh0dHA6
Ly9pZ2Muc2VydmljZXMuY25ycy5mci9DTlJTMi1TdGFuZGFyZC8wHQYDVR0OBBYEFHdU+LuD
UWrGGhG87mM7ESwUh9IYMFQGA1UdIwRNMEuAFBHj2dFSRxtZsTwbeGZr9KGI7QpboTCkLjAs
MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEOMAwGA1UEAxMFQ05SUzKCAQMwIwYDVR0R
BBwwGoEYcmVtaS5mZXJyYW5kQGNjLmluMnAzLmZyMEcGA1UdHwRAMD4wPKA6oDiGNmh0dHA6
Ly9jcmxzLnNlcnZpY2VzLmNucnMuZnIvQ05SUzItU3RhbmRhcmQvZ2V0ZGVyLmNybDANBgkq
hkiG9w0BAQUFAAOCAQEAPaW7JB0REr9b8m95MR9FOqa0CusPLcB7ehvms+WhkTPWNYKAbB4R
RUbIiD796zs7pefwPQh7GBvVEaTWIN8bLnSIkfb7cXooH2XLHToUjuMVMrnabfKZ4bWLbA/3
rczLXBTi4/rDh+sHBEOx0jlCAGbKfvy6IeGFJTYTVEeAtrxofXRppf2RM5K7lGuMagvcDu49
HXCstx5wdoHYAwzwBiHhvCmBRQ3mSpHnH+KewJ+LUSeD+xv0Q95ElCr7cPJraI9J+6BFCEoh
7Gy2O9gk51HEVf98JYXdkfVqhOGxegVN+dSJznif8FL/vWXF6KgCTqST1iEv8gzUDAH3zdpJ
jzGCAsswggLHAgEBMDswNTELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFzAVBgNVBAMT
DkNOUlMyLVN0YW5kYXJkAgJ3FzAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDExMTQxNDMxMDJaMCMGCSqGSIb3DQEJBDEWBBRK
HfnI0KH9kCT/gTbtC5DuXIAyfzBKBgkrBgEEAYI3EAQxPTA7MDUxCzAJBgNVBAYTAkZSMQ0w
CwYDVQQKEwRDTlJTMRcwFQYDVQQDEw5DTlJTMi1TdGFuZGFyZAICdxcwTAYLKoZIhvcNAQkQ
AgsxPaA7MDUxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRcwFQYDVQQDEw5DTlJTMi1T
dGFuZGFyZAICdxcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAEC
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAO3qRkzZRQFvJd0uwMCafTZjPshKkx
RQN5KdiV9Kea/XGv17ViGfp6xSGL4xBM+iEsB8L0Bvv3NRiPjDnrJ5ecTDOT8EJFYbwMlbQk
KQFTWHNn3xYj2qYZgT11En9X0aQC/9jJF1Dc/HZmgTUhZs3DM5FElfHgKbCoc3WQZKkgVNCo
rO9O05VCf+fct0ZN6gcf4KqkCgbjV2CeCOH9vvn/u7L24ooTm6Cd2Sg716BsfjkPtn3FkTAE
cuTjmOoA2hemWAxqHyj4VpsrwpKKqbDdFDEYDmZbW7CWxx1RVcb/Di36n25fevsC1RfoZMSR
LK61jYR5RqrSErWZ6tVatV4QAAAAAAAA
--------------ms000605070700080401050606--
--===============1653348994==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1653348994==--
