[4175] in Kerberos
Re: Kerberos w/ one-time passwords?
daemon@ATHENA.MIT.EDU (John Scudder)
Mon Nov 14 11:56:16 1994
To: kerberos@MIT.EDU
Date: 14 Nov 1994 16:21:04 GMT
From: jgs@yurt.merit.edu (John Scudder)
(I haven't read the v5 spec in detail. If this is all in the spec,
please let me know and I'll go RTFM. It's in my queue, anyhow.)
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.
In your example, if I'm a bad guy snooping the wire, I can capture the
entire KDC reply and then the entire s/key response. Then I can
decrypt the whole thing, right?
I can think of other ways to make the integration work but they all
require keeping secrets on disk instead of deriving them from
(non-secret) s/key responses.
Am I missing something?
--John Scudder
