[11234] in Kerberos-V5-bugs
[krbdev.mit.edu #6587] pkinit-obtained tickets can't make TGS
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Sun Nov 29 17:52:19 2009
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6587@krbdev.mit.edu>
Message-ID: <rt-6587-31884.18.0311150894047@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6587'":;"'AdminCc of krbdev.mit.edu Ticket #6587'":;@MIT.EDU
Date: Sun, 29 Nov 2009 22:51:45 +0000 (UTC)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
In krb5 1.7, pkinit AS requests work and you get initial tickets.
However, if you try to make a TGS request with those tickets, it doesn't
work. The failure is as follows:
* process_tgs_req calls kdc_process_tgs_req.
* kdc_process_tgs_req calls krb5int_find_authdata to see if the ticket
should be refused on account of containing FX_ARMOR authdata.
* krb5int_find_authdata calls find_authdata_1.
* find_authdata_1 runs into an AD_IF_RELEVANT container and attempts to
decode it. This decode operation fails.
* find_authdata_1 continues its loop, but never performs another
operation which would change retval from its current failure value.
* The failure propagates up to process_tgs_req, which sets status to
"PROCESS_TGS" and returns an error reply.
The behavior of find_authdata_1 is a bit dodgy, but the real issue is of
course why the decoding of the AD_IF_RELEVANT container fails.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
