New "feature" for Kerberos?

[John Hascall]

Thanks for your reply.  Here's some expansion and a question:

> Flesh out your proposal a bit ; what do you mean by checkpassword?  

  Ok, that was a little bit sloppy on my part.

  Obviously, this only works if you have pre-auth
  turned on for the principal (which we will have for
  everyone shortly) and if you've compiled the KDC to
  do --with-kdc-kdb-update (I have).  What I am think
  about is an alternative to this:

            if (client.fail_auth_count < KRB5_MAX_FAIL_COUNT) {
                client.fail_auth_count = client.fail_auth_count + 1;
                if (client.fail_auth_count == KRB5_MAX_FAIL_COUNT) {
                    client.attributes |= KRB5_KDB_DISALLOW_ALL_TIX;
                }
            }

  in process_as_req() at about line 275 of kdc/do_as_req.c
  (line# from v1.2.6).


> Here are some things that would definitely make MIT unwilling to
> take the changes:

> * If the principal structure were changed; you can store data in
>   tagged data, but extending the principal structure for this is not OK.

  Tagged data is fine.  Is there some way to coordinate what
  KRB5_TL_xxxx number is used.  Or do I just use 7 (which appears
  no be the next unused one) and hope nobody else is using it...

  It looks to me like there is no corresponding mechanism for
  the policy data -- advice?    <=== THE QUESTION


> * If the code did not deal well with upgrades and downgrades.

  I'm assuming you mean version upgrades and downgrades
  (e.g., 1.2.6 to 1.2.7 etc)?


> * Concerns about code quality

  I promise I won't use the XDR library :)


> * Dependence on a particular preauthentication system

  Nope.  It does require preauthentication be on though, of course.


> I do know that we probably don't have time to help you implement such
> a system and certainly integrating it would not be a high priority for
> us.

  Understood.



John