[5912] in Kerberos
Re: Should I restrict 'kinit' access
daemon@ATHENA.MIT.EDU (Kenneth D. Renard" (ACISD))
Sat Sep 23 11:07:13 1995
Date: Sat, 23 Sep 95 10:52:02 EDT
From: "Kenneth D. Renard" (ACISD) <kdrenard@ARL.MIL>
To: gaskell@dstc.edu.au, kerberos@MIT.EDU
Cc: adt@ARL.MIL, hpc-kerberos@ARL.MIL
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.
The Army Research Lab has been investigating similar mechanisms. The "latest
and greatest" of which involves public key cryptography and one-time-password
(OTP) generators. We pulled the rsaref library out of PGP and integrated
SecurID cards for this project. Here is a brief synopsis of the transactions:
AS_REQ generation on client (i.e. kinit):
Generate a random DES key
Client gets OTP from user
Encrypt DES key and OTP in public key of the realm's KDC
Sends this message in preauthentication field
Save random DES key to use for decryption
AS_REQ receipt on KDC:
Decrypt preauth message with private key of KDC
Extract client-generated random DES key
Extract and verify OTP (only a yes or no answer is required)
AS_REP generation:
Create normal TGT message
Encrypt in client-generated random DES key
Send back to client
AS_REP receipt:
Decrypt response with saved DES key.
Advantages:
Rather simple to implement.
Key used to encrypt AS_REP is randomly generated and likely stroger
than hashed password. AS_REP decryption brute force attack
success rate severely dimished.
OTP is only authentication token required. No static passwords.
This is important for unencrypted remote authentication via
untrusted networks.
Disadvantages:
Non-standard preauth-type required.
More powerful KDC required to handle public key decryption.
Current Status:
Prototype KDC is running. [Kerberos V Beta 5]
Support for second OTP exchange exists (to re-sync SecurID cards).
This can also be generalized to a challenge-response type
of system.
Should completely incorporate RSA as encryption type.
Need to use ASN.1 encoding of messages for portability.
If there is enough interest, generalize OTP interface.
-Ken Renard
Army Research Lab
APG, MD
