[6811] in Kerberos
Re: Combining Kerberos/DCE with SecureId/SKey authentication
daemon@ATHENA.MIT.EDU (Howard Chu)
Mon Mar 4 04:13:56 1996
To: kerberos@MIT.EDU
Date: 4 Mar 1996 00:50:22 -0800
From: hyc@troy.la.locus.com (Howard Chu)
In article <x63f7t7o4x.fsf@strobe.weeg.uiowa.edu>,
Ed Hill <edhill@strobe.weeg.uiowa.edu> wrote:
>The Kerberos model works great when you have a kerberos client to authenticate
>to and then pass your tickets around the net. I'm using both DCE and Kerberos
>from my desktop to bounce around machines within our net.
>But, when I dial in from home or from another insecure net without DCE/Kerberos
>clients, I don't want to run kinit or dce_login since I would have to type in
>my DCE/Kerberos over an insecure net, defeating the purpose of having DCE or
>Kerberos installed.
>I can install S/Key or SecureID systems on hosts that would allow me to connect
>using non-reusable passwords, but I don't want to have to install two
>authentication packages on each system. What I would really like is to have a
>single proxy that I have install S/Key on that I can connect to, and then get
>my Kerberos or DCE tickets.
>I understand that this is not possible, without embedding your DCE/Kerberos
>password somewhere on that system.
>How do others solve this problem - do you solve it? In the Kerberos FAQ it
>mentions that it would be possible to incorporate a challenge-response type of
>password authentication, but is anyone really working on it. Are there people
>out there who try to solve this problem? If so how?
>-Ed Hill (ed-hill@uiowa.edu)
>Systems Administrator - Information Technology Services - University of Iowa
>"I am Homer of Borg, prepare to be assim... Ooooooooh donuts!"
This problem has annoyed me for a long time. To fix it the *right* way, you
basically have to add a new keytype, and have the KDC perform the S/Key
computation itself. Then your kinit or dce_login program also have to support
S/Key. That is, the KDC can use your Kerberos password as your S/Key secret
password; it then just needs to keep track of how many times an S/Key login
is performed. When the KDC receives an S/Key-style authentication request, it
just has to do the MD4 or MD5 crunch the proper number of times, and encrypt
the TGT using this result. The kinit or dce_login programs need an option
switch or some other way of recognizing that you want an S/Key style login;
they don't have to do anything special other than inform the KDC of this
option, and display the challenge information, which the KDC would also have
to pass along. After that, the key verification is the same as for the
normal DES keytype.
Of course it doesn't need to be exactly the same as S/Key that exists today.
In particular, I would change the password input format - do away with the
hex input and 6-English-words options, and only accept base-85 encoding or
something similar. Ideally your response to the challenge can be entered
very quickly (e.g., by having your comm program paste it in for you) to
lessen the possibility that a snooper can complete your password entry
before you're able to finish typing it.
I'm not quite sure how this would be accomodated by the current K5 protocol.
I think the challenge string could be included in the optional pa_data
(pre-authentication data) field of the KDC reply, as long as no other
pre-authentication schemes need that field. In the KDC itself, or actually
in the key database, you need a new field to store the one-time-password
iteration. On the client side, you need a replacement for the
krb5_get_in_tkt function that breaks up the authentication attempt into
two steps, just as the DCE authentication library does. The first step is
to ask for a TGT using the one-time-password scheme, and return the result
(including the one-time password number) to the caller. This needs to
get back to a password prompt for the user, and then the newly obtained
password can be used to decrypt the KDC reply and so on. The client-side
code to accomplish all this is trivial, because it doesn't need to do anything
special - e.g., it doesn't need to do any MD4 crunching, as an S/Key client
must. All of the hard work is in the KDC, and even that's not so bad. The
really tough part is deploying this new feature...
This scheme also has a distinct advantage over the current S/Key implementation
in that a single process (the KDC) manipulates the iteration counter, so
you eliminate the danger of two simultaneous requests being able to use the
same key.
Of course I just now realized the hole in the above scheme - no one has told
the KDC that it's OK to decrement the counter. I guess it did seem too easy
up till now. Ok, so to avoid denial-of-service you can't just decrement it
every time someone asks for a TGT. I guess you need some kind of pre-auth.
Back to square one? You could hold off on decrementing the counter until the
TGS actually receives a TGT using the current number, but then the possibility
arises for multiple entities to get TGTs with the same number. Expanding on
this scheme, the TGS can save the timestamp of the first TGT it sees that uses
the current number, and treat other TGTs with the same number but different
timestamp as invalid. The drawback here is that you have to keep state
information for every one-time-password TGT that you issue, until the TGTs
themselves expire. Also, if a snooper has a faster computer than you, then
they can obtain a TGT before you, catch your one-time-password on the wire,
decrypt their TGT, and send a service request to the TGS before you do,
invalidating your TGT in the process.
Clearly I've taken a wrong turn in this line of thinking; perhaps someone
else can get it back on track...
--
Howard Chu Principal Member of Technical Staff
hyc@locus.com PLATINUM technology, Locus Laboratory
