kdc: cross realm s4u2self handling

Greg Hudson ghudson at mit.edu
Tue Sep 18 17:27:40 EDT 2018

On 09/18/2018 12:12 PM, Isaac Boukris wrote:
> I'd like to start with the last commit in the MIT patch, which
> partially reverts 8a9909ff9ef6b51c5ed09ead6713888fbb34072f commit,
> that I don't fully understand.

That was part of a series of commits made between 1.11 and 1.12, with 
the goal of treating the client request as an immutable object (commit 
9e37d01a0122904776fada43ec65425c375414d8).  Prior to those commits, 
process_tgs_req() would set the request server to the result of the 
server search, which could be a referral.  For the commit you are trying 
to understand, there were two checks against request->server that I was 
concerned with:

* In kdc_util.c:kdc_process_s4u2self_req(), we compare request->server 
against the client principal in the header ticket and error out if it 
doesn't match.

* In tgs_policy.c:check_tgs_nontgt(), we compare the header ticket 
server against the request server and error out if it doesn't match.

I wanted to make sure that leaving request->server alone would not allow 
requests through which would previously have been disallowed.  I was 
only considering within-realm S4U2Self requests, but I believe that in 
the 1.11 code, the check in kdc_process_s4u2self_req() would have 
prevented cross-realm S4U2Self requests from succeeding.  It no longer 
interferes bequest request->server is now the original request server.

I may have unwittingly been preserving a bug rather than an intentional 
restriction, so we can probably relax it.

More information about the krbdev mailing list