Preauth mechanism provision in MIT kerberos
Hi Friends, Recently I set up the whole kerberos system using MIT kerberos 1.6.1. When I run the kinit command i observe the results on ethereal. Following is my observation: $>kinit I observe that as soon as I enter above command, ethereal captures 2 packets namely KRB5_AS_REQ and KRB5_AS_RES. After that I type pasword at my end to whuch is used to decrypt the session key(between TGS & Client), I get in response. I assume that for the above case "pre-auth mehanism" in kerberos is not activated. Even when I look at the code & RFC, I observe that preauth mechanism is optional. I wish to activate this mechanism for my set-up so that the password generated key will be used to encrypt the time-stamp at the client side and this encrypted stamp will be carried by the KRB5_AS_REQ to authentication server. That means I should see above message flow on the ethereal only when the user types both its username and password for kinit command. Could any one tell me how do I activate this preauth mechanism in my kerberos if my above assumption is on the correct track. And also point out the files I need to change to activate this mechanism. Thanks in advance. Regards, Gopal Paliwal Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Preauth mechanism provision in MIT kerberos
For an existing principal you can enable preauth from kadmin with: modprinc +requires_preauth principalname I don't know of a way to enable preauth globally aside from setting it for each principal. -Mike Gopal Paliwal wrote: > Hi Friends, > > Recently I set up the whole kerberos system using MIT kerberos 1.6.1. When I > run the kinit command i observe the results on ethereal. > Following is my observation: > $>kinit > I observe that as soon as I enter above command, ethereal captures 2 packets > namely KRB5_AS_REQ and KRB5_AS_RES. After that I type pasword at my end to > whuch is used to decrypt the session key(between TGS & Client), I get in > response. > > I assume that for the above case "pre-auth mehanism" in kerberos is not > activated. Even when I look at the code & RFC, I observe that preauth > mechanism is optional. > > I wish to activate this mechanism for my set-up so that the password > generated key will be used to encrypt the time-stamp at the client side and > this encrypted stamp will be carried by the KRB5_AS_REQ to authentication > server. > That means I should see above message flow on the ethereal only when the > user types both its username and password for kinit command. > > Could any one tell me how do I activate this preauth mechanism in my > kerberos if my above assumption is on the correct track. And also point out > the files I need to change to activate this mechanism. > > Thanks in advance. > > Regards, > Gopal Paliwal > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Preauth mechanism provision in MIT kerberos
Well, you do that and set it as a default for all new priciples. * Mike Dopheide <[EMAIL PROTECTED]> [2007-07-18 08:22]: > For an existing principal you can enable preauth from kadmin with: > > modprinc +requires_preauth principalname > > I don't know of a way to enable preauth globally aside from setting it > for each principal. > > -Mike > > Gopal Paliwal wrote: > > Hi Friends, > > > > Recently I set up the whole kerberos system using MIT kerberos 1.6.1. When I > > run the kinit command i observe the results on ethereal. > > Following is my observation: > > $>kinit > > I observe that as soon as I enter above command, ethereal captures 2 packets > > namely KRB5_AS_REQ and KRB5_AS_RES. After that I type pasword at my end to > > whuch is used to decrypt the session key(between TGS & Client), I get in > > response. > > > > I assume that for the above case "pre-auth mehanism" in kerberos is not > > activated. Even when I look at the code & RFC, I observe that preauth > > mechanism is optional. > > > > I wish to activate this mechanism for my set-up so that the password > > generated key will be used to encrypt the time-stamp at the client side and > > this encrypted stamp will be carried by the KRB5_AS_REQ to authentication > > server. > > That means I should see above message flow on the ethereal only when the > > user types both its username and password for kinit command. > > > > Could any one tell me how do I activate this preauth mechanism in my > > kerberos if my above assumption is on the correct track. And also point out > > the files I need to change to activate this mechanism. > > > > Thanks in advance. > > > > Regards, > > Gopal Paliwal > > > > Kerberos mailing list Kerberos@mit.edu > > https://mailman.mit.edu/mailman/listinfo/kerberos > > > > > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos -- John Washington Security Officer, University of Illinois Urbana-Champaign Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Preauth mechanism provision in MIT kerberos
John Washington <[EMAIL PROTECTED]> sent:
> Date:Wed, 18 Jul 2007 08:46:49 CDT
> To: Mike Dopheide <[EMAIL PROTECTED]>
> cc: kerberos@mit.edu
> From:John Washington <[EMAIL PROTECTED]>
> Subject: Re: Preauth mechanism provision in MIT kerberos
...
> Well, you do that and set it as a default for all new priciples.
...
The only way to set it for existing principals is via 'modprinc'.
For new principals, you can set "default_principal_flags"
inside of kdc.conf [realms] your-realm {}, something like this:
...
acl_file = /var/krb5kdc/kadm5.acl
max_renewable_life = 7d 0h 0m 0s
master_key_type = des-cbc-crc
default_principal_flags = +preauth
...
Note that default_principal_flags is not necessarily
the default for principals you create for keytabs.
Also note that you may not *want* preauth for keytab principals;
it that's set, the keytab isn't useable by principals that
for some reason did not authenticate using preauth.
-Marcus Watts
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
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
On 7/18/07, Marcus Watts <[EMAIL PROTECTED]> wrote:
>
> John Washington <[EMAIL PROTECTED]> sent:
> > Date:Wed, 18 Jul 2007 08:46:49 CDT
> > To: Mike Dopheide <[EMAIL PROTECTED]>
> > cc: kerberos@mit.edu
> > From:John Washington <[EMAIL PROTECTED]>
> > Subject: Re: Preauth mechanism provision in MIT kerberos
> ...
> > Well, you do that and set it as a default for all new priciples.
> ...
>
> The only way to set it for existing principals is via 'modprinc'.
> For new principals, you can set "default_principal_flags"
> inside of kdc.conf [realms] your-realm {}, something like this:
> ...
>acl_file = /var/krb5kdc/kadm5.acl
>max_renewable_life = 7d 0h 0m 0s
>master_key_type = des-cbc-crc
>default_principal_flags = +preauth
> ...
>
> Note that default_principal_flags is not necessarily
> the default for principals you create for keytabs.
> Also note that you may not *want* preauth for keytab principals;
> it that's set, the keytab isn't useable by principals that
> for some reason did not authenticate using preauth.
>
>-Marcus Watts
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Preauth mechanism provision in MIT kerberos
Writes "Gopal Paliwal" <[EMAIL PROTECTED]>: > Date:Wed, 18 Jul 2007 16:15:00 PDT > To: "Marcus Watts" <[EMAIL PROTECTED]>, kerberos@mit.edu > From:"Gopal Paliwal" <[EMAIL PROTECTED]> > 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
Re: Preauth mechanism provision in MIT kerberos
Gopal Paliwal wrote:
> 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.
You really want to keep this initial exchange. As Marcus pointed out
in his response, you could skip them. This is what Java 1.4 (I think it
is fixed in 1.6) did, and it assumed it also knew the salt, which is a
bad assumption. It sends a time stamp encrypted in a key derived from the
password and assumed salt.
Since the KDC does not keep state on the previous AS_REQ it assumes the
client has been informed of the correct salt by the initial exchange
and returns PRE_AUTH_FAILED(24).
We were using AD where the principal name is case insensitive, but the
salt is not. Some users had mixed case names, but would type lower case.
Thus there was no way for the client to know the salt. Even with a non-AD
kdc, the salt might not be the default derived from the principal name.
There are and will be additional pre-auth methods, and the only way
for the client to be informed of what is available is to use the initial
exchange.
>
> Thanks again,
> Gopal
>
> On 7/18/07, Marcus Watts <[EMAIL PROTECTED]> wrote:
>> John Washington <[EMAIL PROTECTED]> sent:
>>> Date:Wed, 18 Jul 2007 08:46:49 CDT
>>> To: Mike Dopheide <[EMAIL PROTECTED]>
>>> cc: kerberos@mit.edu
>>> From:John Washington <[EMAIL PROTECTED]>
>>> Subject: Re: Preauth mechanism provision in MIT kerberos
>> ...
>>> Well, you do that and set it as a default for all new priciples.
>> ...
>>
>> The only way to set it for existing principals is via 'modprinc'.
>> For new principals, you can set "default_principal_flags"
>> inside of kdc.conf [realms] your-realm {}, something like this:
>> ...
>>acl_file = /var/krb5kdc/kadm5.acl
>>max_renewable_life = 7d 0h 0m 0s
>>master_key_type = des-cbc-crc
>>default_principal_flags = +preauth
>> ...
>>
>> Note that default_principal_flags is not necessarily
>> the default for principals you create for keytabs.
>> Also note that you may not *want* preauth for keytab principals;
>> it that's set, the keytab isn't useable by principals that
>> for some reason did not authenticate using preauth.
>>
>>-Marcus Watts
>>
>> Kerberos mailing list Kerberos@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
