another similar enctype issue
Nicolas Williams
Nicolas.Williams at sun.com
Mon Oct 3 15:33:31 EDT 2005
On Mon, Oct 03, 2005 at 03:10:25PM -0400, Sam Hartman wrote:
> No, similarity should be used wehn searching for keys, but you do
> sometimes need to fix up the enctype as you have noticed.
Yes, but the similarity checking (to search for "canonical" enctypes)
should be done above the actual KDB plug-in.
> Will> 2. The KDC is then using the enctype found in the client key
> Will> (des-cbc-md5) which may not be a literal match to that
> Will> requested in the AS_REQ (des-cbc-crc). See
> Will> return_etype_info2(). This appears to be a bug as the
> Will> client code is doing a literal comparion of the padata
> Will> enctype in the AS_REP with those it requested.
>
> This is in fact a bug.
Yes.
> Will> 3. The KDC is returning only a PA-ETYPE-INFO2 even though
> Will> the AS_REQ only contains des-cbc-crc. That appears to
> Will> violate the text in rfc4120 below:
> *sigh*
:)
Also, I think there ought to be a way to keep state between consuming
padata and producing padata other than the request object itself; the
check/return padata functions ought to output/consume a void * or
something.
Nico
--
More information about the krbdev
mailing list