Preauth mechanism provision in MIT kerberos

[Douglas E. Engert]

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 <mdw at spam.ifs.umich.edu> wrote:
>> John Washington <jawashin at uiuc.edu> sent:
>>> Date:    Wed, 18 Jul 2007 08:46:49 CDT
>>> To:      Mike Dopheide <dopheide at ncsa.uiuc.edu>
>>> cc:      kerberos at mit.edu
>>> From:    John Washington <jawashin at uiuc.edu>
>>> 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 at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444