preauth mechanism functioning at the client-side

[Marcus Watts]

> Date:    Mon, 13 Aug 2007 12:01:13 PDT
> To:      "Marcus Watts" <mdw at spam.ifs.umich.edu>
> cc:      kerberos at mit.edu, krbdev at mit.edu
> From:    "Gopal Paliwal" <gopalpaliwal at gmail.com>
> Subject: Re: preauth mechanism functioning at the client-side
> 
> thanks for suggestions for using negative number.
> It seems to be a right idea to use -ve value till it starts working
> perfectly.
> 
> But, one of my question remains unanswerred.
> why client even after getting hint type-32 and even when i make it a
> preferred_preauth_type still picks up type-2 for requesting to AS with
> preauth data filled. ?
> 
> From where it takes type-2 as a default value?
> 
> Also, is client capable of sending 2-preauth values back to the kerberos
> server in AS_REQ?
> 
> client gives me error like "Looping detected in krb5_get_in_tkt" when I do
> not send type-2 in hint from server to client and just send type-32 instead
> of it.

Looping happens when krb5_get_in_tkt can't get a ticket from the kdc
after submitting a request 16 (MAX_IN_TKT_LOOPS) times.  That means
whatever you sent the kdc just wasn't satisfactory to it.  Probably
that means putting breakpoints in the kdc to see what it thought
was happening when it received the preauth type data from the client
and presumably did whatever server side calculations were supposed to be
happening.  The routine check_padata() is probably a good place to start.

The client shouldn't be just deciding to use KRB5_PADATA_ENC_TIMESTAMP (2)
on its own.  If you see that happening, perhaps your client code
is forcing preauth in some odd manner.  What should be happening (in
MIT) is that when the kdc decides the user needs preauth (missing_required_preauth
returns true), then the routine get_preauth_hint_list() runs and fills
in the response with a list of all available preauth types and
initial server-side data.  That means on the wire you should see this falure:
KRB5KDC_ERR_PREAUTH_REQUIRED (-1765328359)
together with a list of these preauth types:
KRB5_PADATA_ENC_TIMESTAMP (2)	- empty data
KRB5_PADATA_ETYPE_INFO (11)	- list of key types
KRB5_PADATA_ETYPE_INFO2	(19)	- list of key types
KRB5_PADATA_SAM_RESPONSE (13)	- empty data	( really? )
KRB5_PADATA_SAM_CHALLENGE (12)	- (only if KRB5_KDB_REQUIRES_HW_AUTH set)
				initial challenge.

In the MIT code, all methods proceed "in parallel".  For instance, the
client might respond to both KRB5_PADATA_ENC_TIMESTAMP and
KRB5_PADATA_SAM_CHALLENGE, if it saw them.

In the server, pa types can be either required, sufficient, or neither.  If
a required type fails, preauth fails.  Otherwise, if at least one sufficient
type succeeds, preauth succeeds.

In the case of hardware authentication, it appears to be important
for the preauth verify function to set TKT_FLG_HW_AUTH in the ticket
reply, when it succeeds.

				-Marcus Watts