massey@kpc.com (Todd Massey) (04/06/91)
I cannot figure out how to get the setup correct so that kerberos stops giving me Warning: No Kerberos tickets obtained. when i rlogin. I would appreciate if responses would be sent directly to me, so as not to waste net posting space. Thanks, Todd Massey massey@kpc.com
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (04/07/91)
Date: 5 Apr 91 20:04:58 GMT From: massey@kpc.com (Todd Massey) I cannot figure out how to get the setup correct so that kerberos stops giving me Warning: No Kerberos tickets obtained. when i rlogin. You always get those messages; what rlogind is warning you about is the fact that if you have Kerberos tickets on host A, and use them to rlogn to host B from host A, you will _not_ automatically get Kerberos tickets on host B. The reason behind this is of security. Kerberos tickets are only good on one host, so that if someone steals your tickets, they can only use them to compromise you on the host they originally came from. Therefore, when you login to a new host, your Kerberos credentials do not automatically follow you. In order to get tickets on host B, you will either need to kinit after you rlogin (which has the drawback that your password goes accross the network in the clear), or you need to use a client called rkinit before you use rlogin. rkinit securely obtains and transports over to host B tickets which can be used for host B. Both using kinit and rkinit require that you type your password over again, but that's the price you pay for security. In Kerberos Version 5, "forwardable" tickets can be created (although the KDC can be compiled to disallow them, depending on the site policies) which allow you to forward tickets from Host A to Host B without needing to type your password over again. Of course, this opens up a minor security hole, but some users demand convenience at any cost.... - Ted
qjb@ATHENA.MIT.EDU (04/08/91)
> not automatically follow you. In order to get tickets on host B, you > will either need to kinit after you rlogin (which has the drawback that > your password goes accross the network in the clear), or you need to use > a client called rkinit before you use rlogin. rkinit securely obtains > and transports over to host B tickets which can be used for host B. > Both using kinit and rkinit require that you type your password over > again, but that's the price you pay for security. It should also be mentioned that you can use rlogin -x and then kinit. If you use the encrypted rlogin, you still have to type your password over again, and it still goes over the network, but at least it goes over encrypted instead of in the clear. - Jay Berkenbilt
pallas@eng.sun.com (Joseph Pallas) (04/09/91)
In <9104062139.AA09007@tsx-11.MIT.EDU> tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes: >The reason behind this is of security. Kerberos tickets are only >good on one host, so that if someone steals your tickets, they can >only use them to compromise you on the host they originally came >from. Unless, of course, the thief has the skills of a typical undergraduate. >Both using kinit and rkinit require that you type your password over >again, but that's the price you pay for security. Funny, I thought the whole point of Kerberos's Ticket-Granting Ticket was so you don't have to type your password all the time. Where does the price of security go in that case? >In Kerberos Version 5, "forwardable" tickets can be created (although >the KDC can be compiled to disallow them, depending on the site >policies) which allow you to forward tickets from Host A to Host B >without needing to type your password over again. Of course, this opens >up a minor security hole, but some users demand convenience at any >cost.... It's hard to see how this "opens up" a security hole. Either Kerberos depends on host addresses or it doesn't. If it does, there's a security hole. If it doesn't, forwarding tickets won't create one. joe
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (04/09/91)
Date: 8 Apr 91 19:54:11 GMT From: pallas@eng.sun.com (Joseph Pallas) It's hard to see how this "opens up" a security hole. Either Kerberos depends on host addresses or it doesn't. If it does, there's a security hole. If it doesn't, forwarding tickets won't create one. While it is true that the TCP/IP addresses can be faked on the host, if you're on the same subnet (Ethernet LAN), both machines will complain when they see packets coming from the same TCP/IP address but different ethernet addresses. If you're coming from a different subnet, the routers won't route the packets to you, unless you play some really horrible routing games, which will probably be noticed since it will cause some lossage of network connectivity as routes get played around. So while "a typical undergraduate" might be able to change a hosts TCP/IP address, it probably would be noticed quickly. Certainly I would be suspicious if I saw duplicate IP address messages on my console window. In contrast, if someone can grab your tickets from your workstation and use them on another workstation, there would be virtually no way of detecting this use. At least with the duplicate IP address, there is some hope of noticing what's going on. Or if you have forwardable tickets, and you leave your workstation unprotected for a second, a ticket thief could quickly run a program which stashed forwarded tickets on another workstation and you would be none the wiser. The thief could copy your tickets, but if the IP address is there, it makes it that much harder to use the stolen tickets without detection. The right answer, of course, is to make sure that your tickets don't get stolen. Unfortunately, asking users to lock their workstations and secure their operating systems is a lot like asking people to choose good passwords or to wear seat belts.... - Ted
bcn@CS.WASHINGTON.EDU (Clifford Neuman) (04/09/91)
Kerberos does not depend on host addresses for security. When included in tickets, the host addresses only make it a little more difficult for an attacker that has already stolen one's credentials to use them. In particular, it puts the attacker in a position that he is more likely to be discovered. The security of Kerberos lies in the fact that the attacker can not obtain one's credentials unless he has breached the security of the system on which the credentials are stored, and if that security is breached, the credentials are only valid for a short period of time. At present, credentials are stored on disk. They might also be stored in a workstation's memory. In either case, a privileged user of the workstation can get at them. Alternatively, if you leave your workstation unattended and logged in for a short period of time, someone might be able to walk up to it, steal the credentials, and use them from somewhere else. By including host addresses, the attacker would also have to impersonate your network address which, while not difficult, is more likely to be noticed. In any case, it all boils down to trade offs in security vs. convenience. Kerberos does not provide absolute security. It just changes the relative costs and consequences. ~ Cliff
Galina Kofman@watson.ibm.com (04/17/91)
> not automatically follow you. In order to get tickets on host B, you > will either need to kinit after you rlogin (which has the drawback that > your password goes accross the network in the clear), or you need to use > a client called rkinit before you use rlogin. rkinit securely obtains > and transports over to host B tickets which can be used for host B. > Both using kinit and rkinit require that you type your password over > again, but that's the price you pay for security. > > - Ted Sorry if this is a duplicate append. How can I get my hands on rkinit? I could not find it in Version 4 distribution. Thank you. Galina.
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (04/20/91)
Sorry if this is a duplicate append. How can I get my hands on rkinit? I could not find it in Version 4 distribution. It's not available in the Version 4 distribution; I'm not sure what the status of the rkinit code is, as far as distribution goes. Jay, do you know? - Ted
qjb@ATHENA.MIT.EDU (04/20/91)
I have been asked not to distribute the sources to rkinit
because the need for this functionality is one of the main
forces that drives people to pick up version V.
Jay