[16676] in Kerberos-V5-bugs
[krbdev.mit.edu #8972] krb5_init_creds_step() can make synchronous
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Thu Dec 17 00:27:43 2020
From: "Greg Hudson via RT" <rt-comment@krbdev.mit.edu>
In-Reply-To:
Message-ID: <rt-4.4.4-104516-1608182857-1343.8972-4-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8972":;
Date: Thu, 17 Dec 2020 00:27:37 -0500
MIME-Version: 1.0
Reply-To: rt-comment@krbdev.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Thu Dec 17 00:27:37 2020: Request 8972 was acted upon.
Transaction: Ticket created by ghudson@mit.edu
Queue: krb5
Subject: krb5_init_creds_step() can make synchronous TGS requests for FAST
armor TGTs
Owner: Nobody
Requestors: ghudson@mit.edu
Status: new
Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8972 >
get_in_tkt.c calls krb5int_fast_as_armor(), which calls fast_armor_ap_request()
if the DO_FAST flag is set. To get the armor TGT, fast_armor_ap_request() calls
krb5_get_credentials() with no special flags. Under ordinary circumstances,
this just fetches the client-realm TGT from the cache. However, after a realm
referral, krb5_get_credentials() may be asked to retrieve a TGT for another
realm, in which case it will make TGS requests.
This behavior is intentional, but it does not honor the stepwise contract of
krb5_init_creds_step() (which was implemented later than the FAST code).
Instead of using the sequential API, we should create a TGS state machine to be
referenced from the AS step machine, and step through it until it is complete.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
