Difference between pages "Kerberos With Funtoo" and "File:Kerberos operations.png"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(Deployment scenatio #2: Your Funtoo box as a slave Kerberos KDC)
(Maintenance script uploaded "File:Kerberos operations.png": Importing image file)
Line 1: Line 1:
= Concepts =
== The big picture ==
Kerberos is an authentication protocol originally developed at the Massachusetts Institute of Technology (part of [http://en.wikipedia.org/wiki/Project_Athena Project Athena]) and named after the three-headed guard dog who guarded the gates of Hades in the Greek mythology. ''Kerberos'' is also an historical wink to as it was first used at the MIT to guard access to the services provided the Project Athena. Kerberos was design is based on the [http://en.wikipedia.org/wiki/Needham-Schroeder_protocol Needham and Schroeder's protocol] (Xerox Research Center - 1978) and went through several revisions:
* '''1983(?)-1987''': Kerberos v1 to Kerberos v3 (never released outside the MIT)
* '''1987''': Design of Kerberos v4 and deployment at the MIT
* '''1989''': First public release of a the Kerberos v4 reference implementation
* '''1990''': Design of Kerberos v5
* '''1991''': Kerberos v5 is adopted by the [http://en.wikipedia.org/wiki/Distributed_Computing_Environment OSF/DCE]
* '''1992''': First large-scale deployments of Kerberos v4 outside the MIT (universities)
* '''1993''': Publication of the first Request For Comment that documents Kerberos v5 ([http://tools.ietf.org/html/rfc1510 RFC1510] superseded in 2005 by  http://tools.ietf.org/html/rfc4120 RFC4120]). Kerberos v4 is not documented in a RFC but had been the subject to various articles and publications.
* '''1996''': Publication by the MIT of the first version of the Kerberos v5 reference implementation
* '''2006''': Kerberos 4 reached its end of life as the DES encryption protocol it was relying on had been considered weak and insecure.
Kerberos has now a long history behind (20+ years) and is widely used worldwide as it brings an elegant, robust and reliable answer to the classic longstanding challenge of having to authenticate and check the access credentials of something in a, by nature, insecure environment:
''The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff" passwords off of the network are in common use by malicious hackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.'' -- [http://web.mit.edu/kerberos/www Massachusetts Institute of Technology].
Kerberos is a '''publicly documented''' network protocol that have the following benefits:
* '''Centralized authentication''' : In the old days, networks were composed of passive terminals which were directly connected on a central time-shared  computer through a wire (implicit trust relationship). However, with the advent of personal (and now ''mobile'') computing and packet-switched networks machines can't be as considered as being as "safe" especially because the machine as not well-locked (it is not rare that a user has administrative rights and can do whatever he wants starting by installing a service that could impersonates its real identity). Worse, having a user accessing the network from several (and unsafe) devices tends to be very common and tends to complicate the task of the system administrators especially because each machine security requires to be taken care of. Kerberos has been designed from the ground up to be a centralized architecture: a single machine (known as the ''Kerberos Key Distribution Center'' or ''KDC'') holds the responsibilities of authenticating the others machines and to emit the appropriate access credentials.
* '''Security''': Kerberos relies on electronic tickets exchanges (protected from tempering by strong cryptography mechanisms) instead of sending passwords over the network, even in strong encrypted form. As Kerberos relies on asymmetric strong cryptography/digital signing,  a KDC can, per definition, be considered as a trusted third-party when a machine of the network wants to check the access credentials given to another machine of the network.
* '''Single sign-on (SSO)''': Kerberos tickets do not need, necessarily,  to be reissued each time a client machine want to access something. Tickets have a lifetime and thus can be reused by a client machine as long as they are not expired. Moreover, the information is '''centralized''' on the Kerberos controller and not scattered on various machines of the networks.
*'''Open standard''': Kerberos relies an on a set of open and publicly well documented standards.
*'''Cross-Platforms''': Kerberos has implementation on various platforms and operating systems. Note that Microsoft Windows has been known to have authentication issues with the MIT Kerberos reference implementation (see [http://support.microsoft.com/kb/870987/en-us?fr=1 KB870987 amongst others).
Despite those advantages, having a centralized architecture has a drawback: if the heart of system (i.e. the Kerberos KDC) is compromised, the whole network security is compromised as well. Hence, it is always a good idea to:
* Dedicate a machine to the sole usage of being a KDC
* Installs on the KDC the only minimal set of software components required to run a Kerberos server
* Use SSH to open a remote administrative session (A Kerberos server can also be remotely administrated from a client machine)
* Forbids the access to the KDC to anyone but the system/network administrators.
Enough of those teasing paragraphs! It is time to give a first big picture of Kerberos. The best is to think about the following analogy and imagine yourself going to watch a film in a cinema:
# At the entrance you buy a ticket which grant the right of seeing a particular film.
# A cinema agent then checks your ticket authenticity/validity, tears it in two parts and indicates you the right place to go (in case of control it is easy to check if your ticket matches its other half kept by the agent) if your ticket is valid.
# Once you go go out of the cinema room, your ticket is considered expired preventing you to see the same film again without paying another ticket (your ticket has a a limited validity period).
Transposed to Kerberos:
A client '''(C)''' wants to access a printing service located on a printing server '''(PS)''' :
# '''C''' first contacts the Authentication Server '''(AS)'''. '''AS''' then checks the identity of '''C''' and if the authentication is successful issues a Ticket Granting Ticket '''(TGT)'''. The TGT could sent by the AS as a crypted information chuck which has to be decrypted first (via a password or a private cyphering key for example). 
# With the '''TGT''' in hands, ('''C''' then contacts the Ticket Granting Server '''(TGS)''' to request a grant to the printing service. '''TGS''' will check the presented '''TGT''', do additional checks (e.g. if the C is allowed to use the printing service) and will issue a ticket '''(T)''' to the requested service is everything is fine.
# With '''T''' in hands, '''C''' will then contact '''PS'''. If the ticket is still valid, '''PS''' will grant to '''C''' the access to its printing service.
== Concepts definitions ==
It is important to grab some addition concepts before diving further on the subject because you will manipulate them directly. Some of the definitions below directly comes from various places:
* '''Authentication Server (AS)''': A server that issues a ticket to a client for accessing a particular service on the Kerberos realm.
* '''Key Distribution Center (KDC):''' The combination of an AS and a TGS. The KDC is also known as the ''Kerberos server''. The KDC also have a database in which it stores its informations. For high availability reasons, a domain can have several KDC (one ''master'' KDC which is replicated in ''several'' slaves).
* '''Principal:''' ''something'' that can be given access credentials. In most cases a security principal designates a user or a computer but it can also denotes a service. A principal is an assembly of several components that forms  '''a unique identity''' on a given Kerberos realm. Those components are expressed under the form ''primary/instance@REALM'' where:
** '''Primary''': Identifies who the principal is (e.g. the username for a user, the service name in the case of a service)
** '''Instance''': Gives information that qualifies the primary. For example, in case of a host, the instance is the host FQDN. In the case of a user the instance is optional but can be used to denote, for example the role of a user if that later can endorse several ones within the Kerberos realm (e.g. jdoe/admin@FUNTOO.ORG or jdoe/user@FUNTOO.ORG).
** '''Realm''': See below.
* '''Kerberos Realm:''' A Kerberos realm is an logical partition of a network served by a single master KDC. A Keberos realm has its own principals Several Realms can co-exists, can be organized in a hierarchic manner and can establish trust relationships in between (Windows system administrators will talk about a ''Windows domain'', both notions are very close especially because the vast majority of Windows domains in the world now relies on Kerberos and not on NTLM). By convention a Kerberos realm:
** is expressed in capital letters
** is mapped on the Internet domain (eg. the DNS domain funtoo.org will give the Kerberos realm FUNTOO.ORG)
* '''Ticket:''' a temporary set of electronic credentials that verify the identity of a client for a particular service.
* '''Ticket-Granting Ticket (TGT):''' A special Kerberos ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm. This ticket is issued in a encrypted form by the TGS using a shared secret (like a password hash for example) between the TGS and the client.
* '''Ticket Granting Server (TGS):''' A server that handles the request coming from a client for a TGT delivery.
= Kerberize your Funtoo =
== Packages related to Kerberbos in Funtoo ==
As of writing (april 2011), Funtoo has 3 packages related to Kerberos:
* '''app-crypt/mit-krb5''': the heart of the system (Kerberos 5 servers and utilities)
* '''app-crypt/mit-krb5-appl''': ''Kerberized'' client-server applications like rcp, telnet, ftp, rsh, login
* '''sys-auth/pam_krb5''': PAM modules to integrate your machine in a Kerberos realm
== Pre-requisites ==
Kerberos requires the following to function properly:
* All of the machines on a Kerberos a realm (including those acting as KDC) '''are required to have their time synchronized''' (Kerberos tickets are timestamped) else "strange" authentication failures will appear. A simple way to ensure this requirement is satisfied would be to deploy NTP (beyond the scope of this article, it assumed here that all of your machines already have their time synchronized with NTP).
* A functional direct and reverse DNS resolution (please do not use /etc/hosts replicated on each one of your machines, this is a poor practice).
*  Kerberos connectivity installed on '''all machines who will use Kerberos or who will act as Kerberos KDCs'''. For Funtoo and Gentoo machines this lies in the package '''app-crypt/mit-krb5'''.
Once '''app-crypt/mit-krb5''' has been emerged, do in /etc and copy the sample configuration file '''krb5.conf.sample''' to be '''krb5.conf''' and use your favorite text editor to edit. By default this file has the following contents (notice it is divided in several sections whose names are in brackets):
        default_realm = ATHENA.MIT.EDU
# use "kdc = ..." if realm admins haven't put SRV records into DNS
        ATHENA.MIT.EDU = {
                admin_server = KERBEROS.MIT.EDU
                default_domain = MIT.EDU
                v4_instance_convert = {
                        mit = mit.edu
                        lithium = lithium.lcs.mit.edu
        ANDREW.CMU.EDU = {
                admin_server = vice28.fs.andrew.cmu.edu
        .mit.edu = ATHENA.MIT.EDU
        mit.edu = ATHENA.MIT.EDU
        .media.mit.edu = MEDIA-LAB.MIT.EDU
        media.mit.edu = MEDIA-LAB.MIT.EDU
        .ucsc.edu = CATS.UCSC.EDU
#      kdc = CONSOLE
* '''libdefaults''': sets the default values for various parameters (default Kerberos realm to use, ticket lifetime, if tickets are forwardable or not, etc) used by the Kerberos library on the host (client machines, note that the Kerberos KDC is also a client to itself). Most notable parameters in this section are:
** '''default_realm''':  default Kerberos realm for the client.
** '''clockskew''': maximum allowable amount of clockskew in seconds that the library will tolerate before assuming that a Kerberos message is invalid
** '''forwardable''': if set,  initial tickets by default will be forwardable (initial tickets are NOT forwardable by default)
** '''proxiable''': if set,  initial tickets by default will be proxiable (initial tickets are NOT proxiable by default)
* '''realms''': tells where to find the Kerberos servers for a particular realm plus some other realm related information (e.g. which hosts endorses the role of being KDC for the realm) and information related to deal with Kerberos v4 databases. Parameters are set by Kerberos realms and most notable one  are:
*** '''kdc''':
*** '''admin_server''':
* '''domain_realm''': maps subdomains and domain names to Kerberos realm names.
* '''logging''': tells how to perform the logging
{{fancynote|Various other sections and option are detailed in the krb5.conf(5) manual page.}}
{{fancynote|* Kerberos realms are '''case sensitive''' (hence '''BLAHBLAH.ORG''' is not the same realm as '''BlahBlah.org''').
* By convention a Kerberos realm is mapped on a DNS domain }}
= Deployment scenatio #1: Your Funtoo box as a client of a Kerberos KDC =
= Deployment scenatio #2: Your Funtoo box as a Kerberos KDC =
= Deployment scenatio #3: Your Funtoo box as a slave Kerberos KDC =

Revision as of 04:08, 28 August 2012