[28068] in Kerberos
Re: Preauth mechanism provision in MIT kerberos
daemon@ATHENA.MIT.EDU (Marcus Watts)
Thu Jul 19 22:30:42 2007
To: "Gopal Paliwal" <gopalpaliwal@gmail.com>
In-reply-to: <6a113f920707181615j48b7d6eex1aee65a822835f49@mail.gmail.com>
Date: Thu, 19 Jul 2007 01:51:16 -0400
From: Marcus Watts <mdw@spam.ifs.umich.edu>
Message-Id: <E1IBOuy-0004Ao-4H@spam.ifs.umich.edu>
Cc: kerberos@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Writes "Gopal Paliwal" <gopalpaliwal@gmail.com>:
> Date: Wed, 18 Jul 2007 16:15:00 PDT
> To: "Marcus Watts" <mdw@spam.ifs.umich.edu>, kerberos@mit.edu
> From: "Gopal Paliwal" <gopalpaliwal@gmail.com>
> Subject: Re: Preauth mechanism provision in MIT kerberos
>
> Hi,
>
> The solution you guys provided help me.
> Though I now observe following things on ethereal.
>
> 1)for the first time krb5_AS_REQ goes whenever user enters his username.
> 2) Authentication server responds back by giving error as "PRE_AUTH
> REQUIRED"
> 3) Now new krb5_AS_REQ request gets formed with encrypted time-stamp.
> 4)Authentication server sends krb5_AS_RES this time with session key &
> tickets.
>
> I am curious why first two messages were generated. It makes sense though
> that only authentication server knows that a particular user requires
> pre_auth & the user will be unaware of this fact before it receives
> "PRE_AUTH REQUIRED" error. Still, is there any way where I would be able to
> avoid the flow of first two messages.
>
> Thanks again,
> Gopal
There is absolutely no way the server can force the client
to not send the 1st 2 messages. This is, as you observe,
the way things work.
It *is* possible for the client to just assume the server
will understand timestamp preauth and send it initially.
>From a program, looks like you want to call
krb5_get_init_creds_opt_set_preauth_list
and pass in
KRB5_PADATA_ENC_TIMESTAMP
an example of this is in the MIT source,
clients/kpasswd/ksetpwd.c
A weakness of doing it this way (which you can see evidence of in
ksetpwd.c) is that you have to select an encryption type (and salt)
to use before talking to the kdc.
Another way that seems to want to do this in MIT kerberos 1.5+
is:
kinit -X type=value
or from a program,
krb5_get_init_creds_opt_set_pa
to make this actually work you apparently have to write a preauth
plugin.
-Marcus Watts
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
