[4185] in Kerberos
Re: Kerberos w/ one-time passwords?
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Mon Nov 14 17:42:04 1994
To: kerberos@MIT.EDU
Date: Mon, 14 Nov 1994 16:44:15
From: mamros@ftp.com (Shawn Mamros)
jgs@yurt.merit.edu (John Scudder) writes:
>In article <941114100847@cavedog.ftp.com>, Shawn Mamros <mamros@ftp.com> wrote:
>>jgs@yurt.merit.edu (John Scudder) writes:
>[Is there a Kerberos w/ one-time passwords?]
>[...]
>>For V5, it wouldn't require any changes to the protocol, just some
>>use of the optional fields in the protocol (most likely the pre-
>>authentication data field) that already exist.
>>
>>I could easily picture a challenge-response type of system being
>>supported - the request for such a system would have to be transmitted
>>by the client in the pre-authentication field, then the KDC would
>>generate the challenge and proper repsonse, use the response to derive
>>a key in which the "secret" part of the authentication service reply
>>is encrypted, then place the challenge in the pre-authentication field
>>of the reply. kinit would have to be modified to echo out the challenge
>>and receive the response (which, of course, could only happen after
>>a reply comes back from the KDC), and derive the proper key from the
>>response (assuming the response is correct).
>
>I don't see how this could be secure. Please indulge me for a minute:
>
>I did some thinking about how one would integrate s/key into any
>Kerberos-like protocol and hit a wall: The assumption (with s/key) is
>that authentication strings ("passwords," s/key reponses) that the host
>sees are _not_ secret. Since the s/key response is not secret (it may
>be transmitted in the clear across a snoopable wire, and probably is)
>then how can Kerberos trust a session key derived from the s/key
>response? The session key, being derived from non-secure information,
>would itself be non-secure.
I should back up a second here... In my posting earlier, I was assuming
a challenge-response system which still required some notion of a common
"shared-secret", which both KDC and user would know. The difference
between my hypothetical scheme and Kerberos "as-is" would be that,
instead of the shared secret being used to directly encrypt the KDC reply,
the KDC would first generate a random "challenge" which, combined with
the shared secret key, produced a "reply" which would be used as the key
with which to do the encryption. This could be considered a "one-time
password" scheme if what you're trying to prevent is somebody from
brute-force decrypting one or more KDC replies with a single guessed key,
since the key in my hypothetical scheme would change every time as the
challenge changes; thus, the shared secret still remains secret even if
one key is guessed correctly.
However, what you're looking for is something very different: a scheme
with no shared secret. This is what S/Key implements, and I wasn't
meaning to imply that my hypothetical scheme worked in any way similar
to S/Key (it clearly doesn't).
The main problem with getting S/Key and Kerberos to work together is
that Kerberos does require a secure key with which to encrypt part of
the KDC response. It isn't so much that this key has to be any sort
of shared secret - what if the Kerberos database were to contain only
the public half of a public/private key pair, and used the public key
to encrypt the response, which could only be decrypted by the appropriate
private key? - but the requirement is that only the right entity has
the means to decrypt the response. S/Key doesn't provide any ready
means of generating a key secure enough to use for such purposes.
I've dug up a posting Jeff Schiller wrote some months back on this
very topic. He outlines a solution using an out-of-band "auxilliary"
protocol, which could be applied to either V4 or V5. I've appended
his posting on to the end of this one.
-Shawn Mamros
E-mail to: mamros@ftp.com
From: jis@MIT.EDU (Jeffrey I. Schiller)
Newsgroups: comp.protocols.kerberos
Subject: Re: S/Key and Kerberos
Date: 28 Apr 1994 18:04:47 -0400
Organization: comp.protocols.kerberos<->kerberos@mit.edu gateway
Lines: 78
Sender: daemon@cam.ov.com
Message-ID: <9404282203.AA27541@MIT.EDU>
Reply-To: jis@MIT.EDU
NNTP-Posting-Host: pad-thai.aktis.com
> >> 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.
