miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller) (03/30/89)
I take issue with the statement by Don Davis and Ralph Swick that "Currently, Kerberos supports only user-to-secure-host authentication." This is incorrect. Kerberos supports principal-to-principal (e.g. user-to-user) authentication. This is clearly demonstrated by observing that the protocols always specify source and destination principal, that hosts may store multiple server (destination principal) keys, and that one must re-authenticate to communicate (via Kerberos) with additional principals residing at the same host. In other words, it is not like logging in to a local system, where you are normally performing user-host authentication, and once successfully done, have been authenticated for *All* the services local to the host. The current Kerberos implementation uses the host as a secure repository of the set of server keys, however this is not a requirement. For example, a host receiving a Kerberos mediated request could present the encrypted ticket on the display (or an RS232 port), where it would then be input to a smart card which would decrypt the ticket using the *principal's* key. My issue is with their description. Based on reading a previous draft, I do believe that they are trying to address a legitimate problem, that is, avoiding storing long-lived server master keys on hosts. I do not have any comments yet on the current version. Steve.
jhs%computer-lab.cambridge.ac.uk@NSS.CS.UCL.AC.UK (Jerome H Saltzer) (04/01/89)
Steve Miller says, > I take issue with the statement by Don Davis and Ralph Swick that > > "Currently, Kerberos supports only user-to-secure-host authentication." > > This is incorrect. Kerberos supports principal-to-principal (e.g. > user-to-user) authentication. I think that, with proper interpretation, both statements are right! Or, to be more careful, both statements are slightly abbreviated versions of the same correct statement; they just have been abbreviated with different concerns in mind. I claim that the correct, fully qualified, statement is more like this: Kerberos supports principal-to-principal authentication where both principals have the ability to retain a secret key and produce it at the necessary times. The collection of implemented utilities currently supports holding and producing the necessary secret keys for exactly two cases: 1. A private user, presenting a secret password at login time, and 2. A service operating on a secure host, using a private file to hold the secret key. On that basis, one can use Kerberos to authenticate a private user to a service running on a secure host (which Don and Ralph abbreviated as "user-to-secure-host authentication". I wouldn't interpret that to mean logging in to the host, but rather to mean depending on the securedness of the host for service key presentation.) One can also use the current Kerberos to authenticate a service on a secure host to another service on (the same or) another secure host. Using it for any other application (e.g., user-to-user, user-to-nth-level-service, or to service on unsecured host) is possible within the protocol, but would require some kind of extension, if only to the procedures for presenting the secret key. And that kind of extension is the essence of the changes proposed by Don and Ralph. It is also the kind of extension Steve suggests in using a smart-card to eliminate the need for a secure host. Jerry
dla@athena.mit.edu (Don Alvarez) (04/01/89)
In article <8903292250.AA09858@decwrl.dec.com> miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller) writes: >Kerberos supports principal-to-principal (e.g. user-to-user) authentication. >This is clearly demonstrated by observing that the protocols >always specify source and destination principal [so the neccesary info >is available]. This is a potentially very dangerous beleif. Given the fundamental assumption of an insecure network of untrusted machines an the possibility of attackers with root privilegdges on a subset of machines you can not trust any communications above the host-host level. When you log in to a machine, you typically think of yourself as authenticating yourself to the machine. With kerberos, you do something additional: you make it possible for the machine to request services and send messages in your name. If you don't log in, the workstation can't do anything in your name, but if you do log in, the only way that you can trust what the machine does in your name is to trust the operating system. Your key is stored in memory, and if you can ask the machine to get it for you, then if I massage it with my root priviledges I can get it too. >The current Kerberos implementation uses the host as >a secure repository of the set of server keys, however this is not >a requirement. For example, a host receiving a Kerberos mediated >request could present the encrypted ticket on the display (or an RS232 port), >where it would then be input to a smart card which would decrypt the >ticket using the *principal's* key. This doesn't help either. Somehow, your machine has to be able to get at the ticket, either by reading it from memory or by querying the smart card for the current instance of the ticket. If it is possible for the OS to get at the ticket in your name, then it is possible for me to massage the OS into getting the ticket for me (assuming I'm root, which you have to assume based on historical observations). Asking the user to manually type in the key doesn't help either, 'cause anybody with enough smarts to know when the machine should ask for the key will be running to many processes to bother typing in the key every two seconds. Kerberos is great, but it has its limitations, and one of those is that you have to be able to trust the software on the end machines. That is a very important assumption which I have not seen explicitly addressed by any official documentation. It is particularly important in the context of public clusters of workstations. Several people have mentioned the idea of instructing all workstations to take their boot blocks from a kerberos-style-authenticated read-only file server. That would at least give you a trusted kernel, on which you could base your OS trust features, but I'm not aware of anyone actively implementing such a system. >Steve. ...Don Alvarez, boomer@space.mit.edu