[19816] in Kerberos_V5_Development
Re: kdc: cross realm s4u2self handling
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 19 18:33:54 2018
To: Isaac Boukris <iboukris@gmail.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <b4751f59-6ea4-1300-2cb8-1880697ceeac@mit.edu>
Date: Wed, 19 Sep 2018 18:33:25 -0400
MIME-Version: 1.0
In-Reply-To: <CAC-fF8RR5k4zGhPcrJ9Xch4HKtB7Yyxzk8_AZFOW4DKPwdHr9g@mail.gmail.com>
Content-Language: en-US
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 09/19/2018 07:08 AM, Isaac Boukris wrote:
> > I may have unwittingly been preserving a bug rather than an intentional
> > restriction, so we can probably relax it.
> Ok, it makes sense now, I can see it'd have failed the comparison in
> kdc_process_s4u2self_req() (thanks for the detailed clarification).
It occurs to me that a within-realm S4U2Self request (i.e. one using a
local TGT header ticket rather than a cross-TGT one) should still fail
if it results in a referral. I will try to put together a test case for
that.
> Note that in my heimdal work, I have assumed that we can skip this
> comparison check when the service isn't local since we are not issuing a
> ticket to self but a referral, so let the KDC of the service do the
> check when it issues the service ticket.
> The reason it came up was, because heimdal has a more relaxed check
> implemented via hdb plugin which allows matching different names, like
> an SPN to a regular principal name, by looking up both name in db and
> calling the plugin callback with both entries, then samba plugin just
> compares the SID to confirm it's the same principal.
> However, when the service is not local, we don't have these db handles
> so we can't do that.
Maybe. I can't find a flaw in your logic--in the cross-realm case, we
aren't issuing a ticket for the requested service name and we don't have
a DB entry for it, so surely it can't matter too much what it was.
> I guess my main question is whether we need to verify this PAC at, or we
> can just discard it, which is more of a Windows question.
I can't think of a reason to verify the PAC in the TGT unless the KDC is
going to use its contents.
> Other than that, what do you think of the pac_verify/sign_ex() routines,
> does it look ok?
I looked over them briefly and don't have a problem with them. If you
submit a PR I will examine them more closely and cross-check against
[MS-PAC] and [MS-SFU].
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
