preauth mechanism functioning at the client-side

[Gopal Paliwal]

Hi Markus,
i did debug the kdc code and the client code and as said by you.
below are my observations.

1) when client sends AS_REQ for the user which requires preauth, the server
code for sending hint to client sends following details in edata:
a.) preauth type (-2) : my declared
b.) preauth type (2): pa_enc_timestamp
c.)type-19: pa_enc_info2

2) client on receiving KRB5_PREAUTH_REQ_ERROR from server, calls the
do_preauth() from preauth2.c which in turn calls krb5_sort_pa_data_seq()
code. I debugged this and could get that the first type which goes in these
calls is (type-2: my declared) and this thing gets repeated for each
padata_type. I even made (type -2) as a preferred preauth type type for a
client.

3) But the client picks up preauth_type 2 only, while sending back 2nd
request to the server.?

I did created module for my declared type the same way as it was there for
type-2 and other ones. could you let me know what is happeing & why type -2
is not being processed.

-gopal





On 8/13/07, Marcus Watts <mdw at spam.ifs.umich.edu> wrote:
>
> > 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
>