[krbdev.mit.edu #8642] etype-info conflated for initial, final reply key enctype

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #8642] etype-info conflated for initial, final reply key enctype

Greg Hudson via RT-2
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
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs