About proxy_impersonator

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

About proxy_impersonator

Weijun Wang
I read the following from https://web.mit.edu/kerberos/krb5-devel/doc/formats/ccache_file_format.html:

   proxy_impersonator

   The presence of this key indicates that the cache is a synthetic delegated credential
   for use with S4U2Proxy. The value is the name of the intermediate service whose TGT
   can be used to make S4U2Proxy requests for target services. This key is not associated
   with any principal.

I wonder what we (Java, as another krb5 vendor) should do when this entry appears in a ccache file. Should this ccache always belong to an intermediate server that works as both an initiator and an acceptor? If the entry is there, does it mean the it should always use S4U2Proxy to request for a ticket to a backend server on behalf of a client and should never request for itself?

A ccache file is meant for sharing between processes. Who wrote this flag and who should use it?

Thanks,
Max


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Greg Hudson
On 2/14/19 8:24 PM, Weijun Wang wrote:
>    proxy_impersonator

> I wonder what we (Java, as another krb5 vendor) should do when this entry appears in a ccache file. Should this ccache always belong to an intermediate server that works as both an initiator and an acceptor? If the entry is there, does it mean the it should always use S4U2Proxy to request for a ticket to a backend server on behalf of a client and should never request for itself?

Basically yes.  (MIT krb5 handles this at the GSSAPI layer, not the
libkrb5 layer, so kvno would try to make regular requests with such a
ccache, probably without success.  But that's probably a limitation, not
a feature.)

> A ccache file is meant for sharing between processes. Who wrote this flag and who should use it?

This variable was introduced by commit
38de4804776a1a1a255b89b104b983fa1f10a664.  I was requested to make
gss_store_cred_into() and similar operations work with creds resulting
from gss_acquire_cred_impersonate_name() as well as synthetic delegated
creds obtained from gss_accept_sec_context().
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Weijun Wang
Sorry about so many questions. I know something about Kerberos but still have difficulties reading the krb5 codes.

So, this is how I understand S4U2Proxy:

1. Intermediate server starts, receives a TGT using its keytab, store it in its own ccache.

2. A client comes in, sends a ticket (A) to this server.

3. The server uses its own TGT and ticket A to get a S4U2Proxy ticket B to a backend.

4. This new ticket B is stored in the ccache.

5. Intermediate server talks to backend on behalf of client, using ticket B.

#3 and #5 can be in different processes since ticket B is already in ccache. Is the ticket A stored somewhere? Or the same process always does #3 right after #2 and throw about ticket A? What does the "delegated proxy credentials" means in your commit message?

Which step writes the proxy_impersonator entry?

Thanks,
Max

> On Feb 15, 2019, at 9:56 AM, Greg Hudson <[hidden email]> wrote:
>
> On 2/14/19 8:24 PM, Weijun Wang wrote:
>>   proxy_impersonator
>
>> I wonder what we (Java, as another krb5 vendor) should do when this entry appears in a ccache file. Should this ccache always belong to an intermediate server that works as both an initiator and an acceptor? If the entry is there, does it mean the it should always use S4U2Proxy to request for a ticket to a backend server on behalf of a client and should never request for itself?
>
> Basically yes.  (MIT krb5 handles this at the GSSAPI layer, not the
> libkrb5 layer, so kvno would try to make regular requests with such a
> ccache, probably without success.  But that's probably a limitation, not
> a feature.)
>
>> A ccache file is meant for sharing between processes. Who wrote this flag and who should use it?
>
> This variable was introduced by commit
> 38de4804776a1a1a255b89b104b983fa1f10a664.  I was requested to make
> gss_store_cred_into() and similar operations work with creds resulting
> from gss_acquire_cred_impersonate_name() as well as synthetic delegated
> creds obtained from gss_accept_sec_context().


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Greg Hudson
On 2/14/19 9:47 PM, Weijun Wang wrote:
> Sorry about so many questions. I know something about Kerberos but still have difficulties reading the krb5 codes.
>
> So, this is how I understand S4U2Proxy:
>
> 1. Intermediate server starts, receives a TGT using its keytab, store it in its own ccache.
> 2. A client comes in, sends a ticket (A) to this server.
> 3. The server uses its own TGT and ticket A to get a S4U2Proxy ticket B to a backend.
> 4. This new ticket B is stored in the ccache.
> 5. Intermediate server talks to backend on behalf of client, using ticket B.

That's one scenario.  The other variant is that in place of step 2, the
intermediate server uses its TGT to make an S4U2Self request to the KDC,
obtaining a ticket from a client of its choosing.  Steps 1, 3, 4, and 5
are the same.

> #3 and #5 can be in different processes since ticket B is already in ccache. Is the ticket A stored somewhere? Or the same process always does #3 right after #2 and throw about ticket A? What does the "delegated proxy credentials" means in your commit message?

In either variant of step 2, the resulting GSS credential is a
composition of the intermediate service TGT and the ticket from the
client (often called an "evidence ticket").  Usually these two tickets
are stored in a memory ccache.  If the application uses one of the GSS
facilities for storing or copy this credential (gss_store_cred(),
gss_store_cred_into(), gss_krb5_copy_ccache()) then the
proxy_impersonator config entry helps identify the stored ccache to
another process.

So step 2 and step 3 can be in different processes, and that is what the
proxy_impersonator entry is about.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Weijun Wang


> On Feb 16, 2019, at 7:03 AM, Greg Hudson <[hidden email]> wrote:
>
> On 2/14/19 9:47 PM, Weijun Wang wrote:
>> Sorry about so many questions. I know something about Kerberos but still have difficulties reading the krb5 codes.
>>
>> So, this is how I understand S4U2Proxy:
>>
>> 1. Intermediate server starts, receives a TGT using its keytab, store it in its own ccache.
>> 2. A client comes in, sends a ticket (A) to this server.
>> 3. The server uses its own TGT and ticket A to get a S4U2Proxy ticket B to a backend.
>> 4. This new ticket B is stored in the ccache.
>> 5. Intermediate server talks to backend on behalf of client, using ticket B.
>
> That's one scenario.  The other variant is that in place of step 2, the
> intermediate server uses its TGT to make an S4U2Self request to the KDC,
> obtaining a ticket from a client of its choosing.  Steps 1, 3, 4, and 5
> are the same.
>
>> #3 and #5 can be in different processes since ticket B is already in ccache. Is the ticket A stored somewhere? Or the same process always does #3 right after #2 and throw about ticket A? What does the "delegated proxy credentials" means in your commit message?
>
> In either variant of step 2, the resulting GSS credential is a
> composition of the intermediate service TGT and the ticket from the
> client (often called an "evidence ticket").  Usually these two tickets
> are stored in a memory ccache.  If the application uses one of the GSS
> facilities for storing or copy this credential (gss_store_cred(),
> gss_store_cred_into(), gss_krb5_copy_ccache()) then the
> proxy_impersonator config entry helps identify the stored ccache to
> another process.
>
> So step 2 and step 3 can be in different processes, and that is what the
> proxy_impersonator entry is about.

Suppose there is only one process, is the intermediate server also forbidden to get a ticket to a backend server on its own? Is this true for any GSS_C_BOTH credential?

Thanks,
Max



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Greg Hudson
On 2/16/19 2:28 AM, Weijun Wang wrote:
> Suppose there is only one process, is the intermediate server also forbidden to get a ticket to a backend server on its own?

If a caller uses an impersonator credential with gss_init_sec_context(),
the GSSAPI layer will always try to make an S4U2Proxy request, not a
regular TGS request.

The same caller may have previously acquired a cred handle which it used
to produce the impersonator cred (either with gss_accept_sec_context()
or gss_acquire_cred_impersonate_name()).  That cred could be used to get
a ticket to another server with a regular TGS request.

> Is this true for any GSS_C_BOTH credential?

No, the GSS_C_BOTH usage is orthogonal.  Impersonator credentials are
typically GSS_C_INITIATE, and a GSS_C_BOTH credential which is not an
impersonator cred can be used to make regular TGS requests.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Weijun Wang


> On Feb 20, 2019, at 6:53 AM, Greg Hudson <[hidden email]> wrote:
>
> On 2/16/19 2:28 AM, Weijun Wang wrote:
>> Suppose there is only one process, is the intermediate server also forbidden to get a ticket to a backend server on its own?
>
> If a caller uses an impersonator credential with gss_init_sec_context(),
> the GSSAPI layer will always try to make an S4U2Proxy request, not a
> regular TGS request.

I see. So my understanding is that this defines a new kind of default credential. It used to be only user -> krbtgt, but it can be also a service -> krbtgt, plus user -> service, and this special proxy_impersonator flag.

BTW, a customer sent me this ccache file:

> Default principal: [hidden email]
>
> #1  Service Principal:  service/[hidden email]
>     Client Principal:   [hidden email]
> #2  Service Principal:  krbtgt/[hidden email]
>     Client Principal:   service/[hidden email]
>
> and
>
> krb5_ccache_conf_data.proxy_impersonator.<no princiapl>
>    Value: service/[hidden email]

So gss_init_sec_context() is called using the default credential, it should

1) notice there is a proxy_impersonator
2) find a TGT matching the service name at #2
3) find the proxy credential matching the service name at #1
4) request ticket to any other service using #2 with #1 as the second ticket

Does the default principal of this ccache file matter? Should #1 always have the same client principal as it?

Thanks,
Max

>
> The same caller may have previously acquired a cred handle which it used
> to produce the impersonator cred (either with gss_accept_sec_context()
> or gss_acquire_cred_impersonate_name()).  That cred could be used to get
> a ticket to another server with a regular TGS request.
>
>> Is this true for any GSS_C_BOTH credential?
>
> No, the GSS_C_BOTH usage is orthogonal.  Impersonator credentials are
> typically GSS_C_INITIATE, and a GSS_C_BOTH credential which is not an
> impersonator cred can be used to make regular TGS requests.
>


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: About proxy_impersonator

Greg Hudson
On 2/25/19 2:59 AM, Weijun Wang wrote:
> So gss_init_sec_context() is called using the default credential, it should
>
> 1) notice there is a proxy_impersonator
> 2) find a TGT matching the service name at #2
> 3) find the proxy credential matching the service name at #1
> 4) request ticket to any other service using #2 with #1 as the second ticket

I don't think code should make assumptions about credential order in a
ccache.  So I would amend the first three steps to:

1) notice there is a proxy_impersonator; get its value
2) find a TGT for (proxy_impersonator value) -> krbtgt/REALM@REALM
(where REALM is the realm of the proxy_impersonator value)
3) find the evidence ticket for (default principal of ccache) ->
(proxy_impersonator value)
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev