[3197] in Kerberos
Re: S/Key and Kerberos
daemon@ATHENA.MIT.EDU (Jeffrey I. Schiller)
Thu Apr 28 18:21:00 1994
Date: Thu, 28 Apr 94 18:03:40 EST
From: jis@MIT.EDU (Jeffrey I. Schiller)
To: marc@cam.ov.com (Marc Horowitz)
Cc: kerberos@MIT.EDU
Reply-To: jis@MIT.EDU
> >> I looked into this with one of the folks here who initially
> >> worked on S/Key, and we determined that you basically can't do it.
>
> I don't know if he's paying attention, but Jeff Schiller at MIT has a
> hack to use S/Key with kerberos. I remember thinking it was clever,
> but I don't remember what the hack was.
Yep, I'm here. Here is how my design works:
Warning: This design uses Public Key Cryptography, but can be
implemented via RSAREF.
You have a new service (called skrbd at the moment) that has a database
of principals and associated S/Key entries (what is normally stored on e
host). [You establish these via a (yet to be designed) Kerberos
authenticated protocol which uses the "change_password" instance]. There
is one well known public key for the skrbd service. The corresponding
private key is stored securely on the host that has the skrbd. The other
secret that skrbd needs is the Kerberos DES key for krbtgt.[LOCALREALM].
The client starts the protocol by fetching the public key from the skrbd
server and the S/Key challenge for the user who is proposing to login.
In the schematic below I represent the "User" who is remote from the
"Client" which is the machine to which the User wants to login and have
Kerberos tickets instantiated for. Keep in mind that we assume that an
attacker may be along either the path User <--> Client or the Path
Client <--> skrbd (or Client <--> Server, but we won't talk about that
here).
User --> Client UserName
Client --> skrbd UserName
skrbd --> Client PublicKey (Kp), S/Key challenge
Client --> User S/Key challenge
The client then generates a random DES key (DK). This key along with the
proper S/Key response is sent to skrbd encrypted in the PublicKey.
User --> Client S/Key One-Time Password
Client --> skrbd {S/Key One-Time password, DES Key (DK)}Kp
skrbd verifies if the supplied One-Time password is correct. Obviously
if it isn't an error condition is signalled. If the password is correct
then skrbd constructs a traditional Kerberos Ticket Granting Ticket.
However rather then supplying this back to the Client workstation
encrypted in the user's regular password, it is encrypted in the
randomly chosen DES Key (DK) which the Client still has.
skrbd --> Client {T,Kc,s}DK
At this point the "normal" Kerberos protocol ensues.
Notes:
1) skrbd does *not* need to run on the same server as the KDC. All it
needs to know is the DES key of the local realm's ticket granting
service. The host running skrbd does need to be protected because if any
of its secrets are compromised an attacker can inpersonate any user.
However restoring security after a compromise only requires changing the
skrbd Public/Private key and the Kerberos ticket granting service key.
This is not a trivial cleanup operation, however you do *not* have to
require the whole realm to get new regular passwords (not even a new
S/Key database needs to be provided because it is not confidential).
2) The Client <--> skrbd path is vulnerable to an active attacker unless
the Client has out of band knowledge of the skrbd Public Key.
3) The Client <--> User path is vulnerable to an active attacker. This
is a fundamental problem of S/Key itself. It can be mitigated if the end
user knows which S/Key challenge number will next be asked and is wary
of challenges that have too low a number [You need to understand how
S/Key works to grock this].
Comments?
-Jeff
P.S. Please cc me directly on responses. Although I receive the Kerberos
mailing list I am often too busy to catch all the traffic on it.
