IVT and Kerberos

Kerberos IVT and Kerberos

Date of last modification: Tue May 05 16:43:08 2009

Kerberos is an authentication and encryption protocol that allows you to have secure connections over a public network. It was developed as part of the Athena project of the MIT. Details can be found at the Website of the Massachusets Institute of Technology: http://web.mit.edu/kerberos/www.
SSH is perhaps in wider use, but Kerberos offers better security, IMHO.

IVT offers accurate support for Kerberos version 5 authentication and encryption:

  • Authentication means you can prove to the telnet host who you are. The user-id and password are not transmitted in clear text over the network, but the Kerberos software uses cryptographic techniques that give you single sign-on (login once to Kerberos, thereafter you can login to all sorts of (Kerberized) hosts without supplying a user-id and password again).
  • Encryption. The connections established to a Kerberized telnet server can be encrypted, providing privacy on the session.
    IVT supports encryption and auto-encryption. Also, encryption can be turned on or off under script control. Various checks are built in to protect against man-in-the-middle attacks.
  • Ticket forwarding. IVT can forward the Kerberos credentials from the Windows environment to the host you log in to. You can then use Kerberos software on that host (ftp, rsh, rcp, telnet and so on) without having to enter a user-ID and password again.
  • X-Windows port forwarding. The Unix Kerberized telnet daemon available from Stanford University implements a draft RFC from Jeffrey Altman (of the Kermit project) which allows Kerberized telnet to tunnel X-Windows sessions over the secure connection, a feature that SSH also supports. The telnet client must of course support this also. IVT 16.1 fully supports this protocol (enabled by default).

    • The commercial version of IVT containing the Kerberos/DCE functionality is available from this webshop!

    Only Kerberos and SSH functionality are licensed parts, the rest of IVT is free (as in beer), if you don't use Kerberos or SSH, IVT is entirely free.

    IVT is integrated with the DCE software from Gradient/Entegrity.
    During startup, IVT will detect such an environment and will use the DCE32.DLL to access the DCE environment and obtain the location of the DCE master.
    It will generate a KRB5.INI file with the proper settings for the (pure) Kerberos code to find and use.
    The upshot of this is that you can install IVT in a Gradient DCE environment and have instant integration: the credentials obtained during login of your workstation will be used to authenticate against Kerberized telnet servers.
    In environments without Gradient installed, you will have to supply the KRB5.INI file yourself and use the Kerberos kit from my website to do the initial login. The current release of that kit is based on release 1.6.3 of the MIT Kerberos code.

    Perhaps even more important is the integration with Microsoft Active Directory. Windows started using Kerberos as the underlying security protocol in Windows 2000. For a change, Microsoft did not violate the RFC's - the Windows implementation can work together with MIT Kerberos.
    This means that you can obtain credentials from an AD domain that are valid for MIT Kerberos servers, such as Kerberized telnet and Kerberized FTP servers.

    Some of the most important advantages:

  • Single sign-on. When the user has authenticated by logging in to the AD network, the obtained credentials are valid for use by IVT and/or FileZilla to setup Telnet and FTP sessions for the rest of the day.
  • By default, AD usernames are mapped to the same usernames on Unix, but through use of .k5login files on Unix, specific users (principals) can be given access to specific Unix accounts. This can be used to map long AD names to shorter Unix names, but also to allow access to special accounts (such as root) to specific users. This means several people can have root access without knowing the password. The telnet server can log the name of the principal that is using the root account.
  • Single point of administration setup. An account that is disabled in Active Directory prevents access to all Kerberos authenticated services, so a user cannot login to Unix anymore.
    The password is stored in only one place (AD) - no synchronisation headaches anymore.
  • Possibility to authenticate using smartcards.
    This is actually an AD feature. When the user authenticates to the AD server, a ticket is obtained. The details of the authentication are irrelevant, so anything that is acceptable to Active Directory (passwords, smartcards, fingerprints, face-scans, DNA samples, whatever) can be used to authenticate to Unix with no change whatsoever to the rest of the software!
  • No SSH key distribution problem. SSH requires that a user who wants to use keypairs for authentication store the public key in the authorized_keys file for all accounts on all machines that he wants access to. When the user leaves the organization, all these keys have to be removed.
    The private key must be kept private, but this is the responsibility of the user.
    Kerberos uses tickets created by the AD server, no specific configuration is required for a user on the Unix end (except to create an account there, and not even that if you use NIS (a.k.a. Yellow Pages)) to store account information in.
    • The Dutch Tax Office uses IVT and FileZilla in their network of 500 Unix machines (a mix of HP-UX and AIX) to do remote, secure administration. File transfer between Unix machines is based on Kerberized rcp (remote copy) and kftp (Kerberized File Transfer Protocol).
    The X-windows tunneling supported by IVT even provides secure X-windows. Credential forwarding (as supported by IVT) allows administrators to use ktelnet on Unix (Kerberized telnet) from one Unix machine to another without reauthentication.
    All this proves that the technology works in demanding environments to do real work in.

    Back to main IVT page.


    View My Stats