[28281] in Kerberos
Re: preauth mechanism functioning at the client-side
daemon@ATHENA.MIT.EDU (Gopal Paliwal)
Thu Aug 16 14:09:32 2007
Message-ID: <6a113f920708161109u10383a22v4e3378dc40f54c62@mail.gmail.com>
Date: Thu, 16 Aug 2007 11:09:10 -0700
From: "Gopal Paliwal" <gopalpaliwal@gmail.com>
To: "Marcus Watts" <mdw@spam.ifs.umich.edu>
In-Reply-To: <E1IKfmc-0006XR-C3@spam.ifs.umich.edu>
MIME-Version: 1.0
Content-Disposition: inline
Cc: krbdev@mit.edu, kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@spam.ifs.umich.edu> wrote:
>
> > Date: Mon, 13 Aug 2007 12:01:13 PDT
> > To: "Marcus Watts" < mdw@spam.ifs.umich.edu>
> > cc: kerberos@mit.edu, krbdev@mit.edu
> > From: "Gopal Paliwal" < gopalpaliwal@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
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
