[15889] in Kerberos-V5-bugs
[krbdev.mit.edu #8642] etype-info conflated for initial,
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Tue Feb 13 16:26:27 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8642@krbdev.mit.edu>
Message-ID: <rt-8642-48261.19.2540017189446@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8642'":;
Date: Tue, 13 Feb 2018 16:21:07 -0500 (EST)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
It looks like I was wrong about #3. get_in_tkt.c resets ctx->etype
to the AS-REP enctype before processing the final padata list,
although it can then be changed by etype-info in the AS-REP. The
PKINIT client will use the correct enctype unless the KDC sends
etype-info with a different enctype (which would be in violation of
RFC 4120). For robustness it would be better to use the AS-REP
enctype, but there's no immediate bug, and KDCs can omit etype-info
in PKINIT AS-REPs.
The get_etype() callback has some history to it. In release 1.6 when
it was first added (in the form of a get_data_proc request), it
always yielded the AS-REP enctype, or failed with ENOENT if there was
no AS-REP yet. The implementation of FAST in 1.7 (ticket 6436)
changed the callback to the current behavior and used it in encrypted
challenge. Ticket 6976 added the get_as_key() callback and stopped
using get_etype() in encrypted challenge, so only PKINIT currently
uses the callback. But the callback is now documented as returning
the enctype from etype-info before the AS-REP, so we shouldn't
completely revert to the 1.6 behavior.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
