[3673] in Kerberos
Re: S/KEY integrated with Kerberos?
daemon@ATHENA.MIT.EDU (Glenn Machin)
Mon Aug 8 17:57:47 1994
From: Glenn Machin <gmachin@sahp044.sandia.gov>
To: bf4grjc@bell-atl.com
Date: Mon, 8 Aug 94 15:45:45 MDT
Cc: kerberos@MIT.EDU
In-Reply-To: <9408081739.AA21534@einstein.bell-atl.com>; from "Ganesan" at Aug 8, 94 1:39 pm
>
> > If I am missing something here, please help me understand. Why can't the KDC
> > store the user's S/Key (keyinit) passphrase similarly to how a standalone
> > machine
>
> As discusse, you can, but dont call it S/Key!
>
> > would not get anything useful. My concern is that of the client's login program
> > not knowing the proper sequence number initially. Should the login program
> > on each client be made a registered principal so it can use it's own
> > "password" to encrypt the whole sesion with the KDC? Or wouldn't the
> > sending of a sequence number unencrypted outside the TGTGT be a problem?
>
> In your scheme, i.e. storing x0 on the Kerberos server, the login program
> need not even be altered. It decrypts TGT as usual, and hopefully,
> verifies that the encrypted TGT really came from the KDC using a locally
> stored service key. Only the KDC need keep track of sequences.
>
> > P. S. Has anyone thought about how to keep the sequence numbers in-sync across
> > multiple KDCs ??
>
> Run kprop as cron job..ha ha ha. Seriously, the updates to the sequence
> numbers in all KDCs in your scheme needs to be instantaneous, if not
> I can steal the passphrase you used in talking to KDC1 and immediately
> use it against KDC2.
>
> If this is ever implmented, I would personally not recommend altering
> the KDC functionality in any way. I would use the same external hooks
> used to integerate token authenticators (your scheme is basically a
> token authenticaion scheme without the harware) in KV5. See HW_AUTHENT
> discussion in RFC 1510. I would then make each of your multiple KDCs
> talk to your version of S/KEY (running as a separate server) and
> build some sort of secure channel between all the KDCs and S/KEY.
>
I like this approach, in fact there could even be a side channel between
the client and the S/KEY server which could be used to get the current
sequence number, plus some verifier(timestamp, client, etc), encrypted
in a key known only to the S/KEY server. Now the user can place their
S/KEY response for the passed sequence number, as well has the verifier,
into the preauthentication data field of the AS_REQ (encrypted in their
kerberos key, if need be) and send it of to the KDC who would then send
it off to the S/KEY server, to validate it. No real change to the kerberos
protocol would be necessary, except the definition of the S/KEY preauth
type.
I would suggest that an additional ticket flag be introduced which the KDC
could set in the returned TGT indicating that a 1 time password authentication
mechanism was used to further authenticate the user. This way issuance of
additional service tickets may be based on whether the user authenticated by
means of S/KEY, just as hardware authentication is currently being used.
Glenn Machin
