[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pam_krb5 with PKINIT from Heimdal and MIT
>>>>> "Nalin" == Nalin Dahyabhai <firstname.lastname@example.org> writes:
Nalin> On Thu, Oct 12, 2006 at 04:13:06PM -0500, Nicolas Williams wrote:
>> On Thu, Oct 12, 2006 at 04:12:42PM -0400, Nalin Dahyabhai wrote:
>> > The libkrb5 side of things goes through the list of preauth types
>> > suggested by the KDC, and the first preauth type for which it's able to
>> > obtain data is deemed good enough to fire off a request to the KDC.
>> In what order are the pre-auths attempted?
Nalin> Traditionally, it was the order in which they were listed in the e-data
Nalin> accompanying the preauth-required error from the KDC.
>> If we agree that PADATA should be considered to be unordered then a
>> client-side pre-auth preference/precedence order seems necessary.
FTR, I am entirely unconvinced that padata should be unordered. I
think this is a fairly bad idea.
I think it in acceptable for a client to reorder padata with no associated data in a preauth_required error.
I'm open to arguments about why unordered preauth is good, but I'm
concerned that it will limit flexibility for extending Kerberos.
I'm very concerned about a case where one preauth module causes other
preauth modules to be ignored. I think the only case is that you
don't want two replace key modules used in the same request.