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