[99] in 6.033 discussion
Re: SIS
littlitt@ATHENA.MIT.EDU (littlitt@ATHENA.MIT.EDU)
Thu Apr 18 00:13:13 1996
> Design Project 2 mentioned about the 2nd password for
> SIS. Is there any further information on how the protocol
> is like for SIS? I have tried the web but didn't have much
> luck
This is a very good question. I don't know much about the SIS protocol
specifically. However, I know that it uses kerberos for authentication
(and presumably key distribution as well), so I think I can
sufficiently answer your question.
The key to understanding the second password is understanding the full
naming scheme behind kerberos principals. The kerberos paper says:
"A principal identifier consists of three components:
* A principal name
* an instance name
* a realm name
[...]
The instance name is a label that permits the possibility that the
same client or service may exist in several forms that require
distinct authentication. ... The usual case is that users operate
using a name with the null instance" (pg. 6)
Principal identifiers are typically printed as
"principal.instance@realm". So what this means is that by default you
recieve all your tickets for username@ATHENA.MIT.EDU (because the
instance is null). For example, here is the output of "klist" on my
machine:
% klist
Ticket file: /tmp/tkt4671
Principal: littlitt@ATHENA.MIT.EDU
Issued Expires Principal
Apr 17 11:47:04 Apr 18 09:02:04 krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
Remember that once you have the ticket-granting-ticket for a
principal/instance/realm identifier, you can get any other ticket for
that identifier without having to type in your password. So if I walk
up to your machine while you have stepped away, I can incorporate your
mail, etc..
This presented a problem for the designers of SIS, because they did
not want to leave the system vulnerable to people who walk away from
their workstations without logging out. So they decided to use an
extra kerberos instance to achieve this. When you type in your "second
password" for SIS, what SIS really does is get kerberos tickets for
username.extra@ATHENA.MIT.EDU. Likewise, the SIS server requires that
all tickets it recieves must have an identifier with instance name
"extra". SIS then destroys all the "extra" tickets as soon as you
quit. As an exercise, you can actually get such tickets directly
(without going through SIS) by typing:
% kinit -i
Kerberos Initialization
Kerberos name: littlitt
Kerberos instance: extra
Password: <SIS password here>
% klist
Ticket file: /tmp/tkt4671
Principal: littlitt.extra@ATHENA.MIT.EDU
Issued Expires Principal
Apr 17 23:38:18 Apr 18 09:38:18 krbtgt.ATHENA.MIT.EDU@ATHENA.MIT.EDU
(Note that this overwrote all my old tickets.) You can change your SIS
password by doing:
% passwd -i extra
The key here is that even if the two passwords are the same, then
someone who walks up to your screen still has to know the password to
use SIS. Of course, it is better to keep the passwords different. This
way even if your first password is compromised (e.g., you type it in
over unencrypted telnet), then an eavesdropper still can not look at
your grades.
One last note: for design project #2, you might want to think about
whether kerberos itself is even secure enough at all. The kerberos
paper clearly says that it was not designed for "sensitive data or
high risk operations." (pg. 4) Why did the authors say this?
Hope that helps!
-jon
