[3661] in Kerberos
S/KEY integrated with Kerberos?
daemon@ATHENA.MIT.EDU (James R. Hendrick)
Mon Aug 8 10:30:28 1994
Date: Mon, 8 Aug 1994 10:16:27 -0400
From: "James R. Hendrick" <hendrick@ctron.com>
To: tls@panix.com
Cc: tytso@MIT.EDU, kerberos@MIT.EDU
In-Reply-To: Thor Lancelot Simon's message of Sat, 6 Aug 94 21:01:00 EDT <CMM.0.90.0.776221260.tls@panix3.panix.com>
Date: Sat, 6 Aug 94 21:01:00 EDT
From: Thor Lancelot Simon <tls@panix.com>
> :-) What makes you think that simply because the login program on
> net-dist supports S/Key has any relationship to Kerberos?
>
> There have been some thoughts about how you might do it; it would
> involve the use of public-key technology, though, and require that you
> run a separate S/Key->TGT server on your Kerberos server. We haven't
> sat down and seriously designed it though, and it's most probably won't
> be appearing in the next beta. :-)
Your idea about how to do it sounds more or less like my idea about how to do
it. I spent about ten minutes looking at the crimelab s/key distribution's
"skey server" (don't bother; it's horrbily insecure) shuddered in fear,
thought about how to do it right, and then thought, "oh, hey, why not make the
`skey server` hand out a Kerberos TGT", shuddered in fear again (because I
don't understand Kerberos internals well enough to believe I could do that
correctly) and just figured that someone, somewhere would get around to it.
But it's an idea whose time is clearly at hand. Unless something's changed
since I last used them, even Athena's own terminal servers don't have Kerberos
support, and I seriously doubt that any substantial percentage of the people
who use the athena.dialup machines from outside kinit to get there. The
Kerberos installation at Usenix was a disaster because there weren't any
secure machines to run kinit on. (Having spent four hours trying to find
someone from NCR who could build a kinit binary for their X terminals and
solve the problem, I know this from painful experience.)
An S/KEY TGT server would eliminate the "dumb terminals can't speak Kerberos"
problem (or rather do an end-run on it), wouldn't it? It seems to me that
there must be an enormous demand for that, both at MIT and outside.
I have also spent a few minutes thinking about the issues of having the KDC
hand out TGTs using an S/Key password. Here are a few of the thoughts
that have fallen out of my head on the subject:
+ Making the KDC recognize skeys is not very difficult. It simply
needs to keep track of the initial skey password and a sequence number
and return a TGT encrypted with the proper sequence key. This is
basically what it does now for normal passwords.
+ Making login know to send a request to the KDC for a TGT based on
skeys is also not real tough. Again, see the normal login&get-a-TGT sequence.
- The *first* problem I see is that of a single point of failure vs.
keeping sequence numbers sync'd across all the slave KDCs. If only one
KDC could provide this skey=>TGT service, there is not any real issue
here. If you would like any KDC to provide this service, you get into
the problems of:
- what if one is unavailable when an skey gets used?
If this server doesn't sync, it will allow the same
skey to work again, defeating the purpose.
+ this *could* be solved by making the propogation
part of teh skey-login process, but then if a server
is unavailable, should the process continue? Possible
denial of service in this case.
- The *second* problem I thought of is that of when the skey-KDC
should increment the sequence number. This has to wait for successful
authentication or you get a nasty denial of service problem here. So
the KDC should not send a *real* TGT first. If it sent a TGTGT (arrgh :-)
that would give the client machine (doing the login) enough info. to
inform the KDC that authentication is successful, then the KDC can
increment the skey sequence and send the real TGT.
All throughout this exchange, the same precepts that guide Kerberos
need to be adhered to. No long-term critical information ever goes
over the net. No tickets etc. ever go over the net unencrypted.
I think the second part of this can be done (not sure about the single
KDC problem) if something like this happens:
User Client KDC
====================================================
types username
sends username
in an S/Key-TGT
request to the KDC
generates a session key,
and a ticket that will
obtain a TGT later. Encrypts
this w/ the skey and
sends this to the Client
<< NOTE that in here, the Client doen't know the >>
<< sequence number. It may be that the login.Clinet >>
<< may need to be a registered principal so the KDC >>
<< can send the sequence number encrypted with the >>
<< login.Client principal's key to be correct >>
receives the packet
and prompts the
user for a password.
types the skey
If the TGTGT decrypts
corerectly, the
Client takes it and
sends it back to the
KDC (encrypted with
the session key)
Now the KDC can
increment the sequence number
and generate and
return a TGT to the client.
allows login and
has a TGT.
Is this a reasonable approach? Have I left any doors open? And what about
the single S/Key-KDC vs. the problem of keeping sequences in-sync?
Later,
Jim
###########################################################################
### Jim Hendrick (hendrick@ctron.com) ### ###
### Cabletron Systems Inc. ### " My opinions, etc are ###
### P. O. Box 5005 ### exclusively the property ###
### Rochester, NH 03867-5005 ### of nobody in particular." ###
### (603) 337-7572 ### ###
### fax:(603)337-7370 ### ###
###########################################################################
