another similar enctype issue

Nicolas Williams Nicolas.Williams at
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.


>     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


More information about the krbdev mailing list