[5914] in Kerberos
Re: Should I restrict 'kinit' access
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Sep 23 15:34:54 1995
To: "Kenneth D. Renard" (ACISD) <kdrenard@ARL.MIL>
Cc: gaskell@dstc.edu.au, kerberos@MIT.EDU, adt@ARL.MIL, hpc-kerberos@ARL.MIL
In-Reply-To: Your message of "Sat, 23 Sep 1995 10:52:02 EDT."
<9509231052.aa12585@SMOKEY.ARL.MIL>
Date: Sat, 23 Sep 1995 15:22:11 EDT
From: Sam Hartman <hartmans@MIT.EDU>
>>>>> "ACISD" == ACISD <Kenneth> writes:
ACISD> On 17 Sep 1995, gaskell@dstc.qut.edu.au wrote:
>> That is one of our concerns with the first stage of the
>> Kerberos protocols. Anyone can get an initial TGT for anyone
>> else, just supposedly they cannot decrypt it, since they don't
>> have the password. To this end, we have designed a system with
>> challenge/response protocols to avoid this threat. We think
>> that the pre-authentication system may also bring in some
>> scalibility or manageability problems. One of our options uses
>> Public-key crypto and another a zero knowledge proof. All use
>> smart cards. Look out for a paper or two, after our prototype
>> works.
ACISD> The Army Research Lab has been investigating similar
ACISD> mechanisms. The "latest and greatest" of which involves
ACISD> public key cryptography and one-time-password (OTP)
ACISD> generators. We pulled the rsaref library out of PGP and
ACISD> integrated SecurID cards for this project. Here is a brief
ACISD> synopsis of the transactions:
ACISD> AS_REQ generation on client (i.e. kinit):
ACISD> Generate a random DES key Client gets OTP from user
ACISD> Encrypt DES key and OTP in public key of the realm's KDC
ACISD> Sends this message in preauthentication field Save random
ACISD> DES key to use for decryption
This significantly breaks interoperability with other realms.
There is a reason the krb_err reply has a data field that should be
field in for pre-authentication required errors.
A significant problem I have seen with all pre-authentication
solutions to date is that they either require the user to use a flag
to kinit, or completely fail to interoperate with other realms. The
right answer, in general, is as follows:
* client makes as_req (without preauth) to KDC.
* KDC returns preauth required error, indicating in the error reply
what preauth method (and possibly parameters to the method--like a
public key for the realm) would be accepted.
* kinit then informs the user preauth is being used and does what is
appropriate for that method.
Naturally, if you incorperate data like the public key into
the preauth required error, this must by authenticated somehow--by a
digital signature or something.
--Sam
