1. Keberos http://en.wikipedia.org/wiki/Kerberos_%28protocol%29

2. Kerberos A computer network authentication protocol  Allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner  A suite of free software published by Massachusetts Institute of Technology (MIT) that implements this protocol  Aimed primarily at a client-server model Provides mutual authentication  Both the user and the server verify each other's identity Kerberos protocol messages are protected against eavesdropping and replay attacks

3. Kerberos Builds on symmetric key cryptography  Requires a trusted third party Extensions to Kerberos can provide for the use of public key cryptography during certain phases of authentication

4. History and development

5. MIT developed Kerberos to protect network services provided by Project Athena  Named after the Greek mythological character Kerberos (Cerberus) Monstrous three-headed guard dog of Hades in Greek mythology  Several versions of the protocol exist Versions 1–3 internal only at MIT

6. History and development Version 4 published in the late 1980s  Steve Miller and Clifford Neuman The primary designers of Kerberos  Targeted primarily for Project Athena Version 5 (1993)  Addressed the limitations and security problems of version 4  Designed by John Kohl and Clifford Neuman  RFC 1510  Made obsolete by RFC 4120 in 2005

7. History and development MIT has a free version of Kerberos available  Copyright permissions similar to those used for BSD Authorities in the United States classified Kerberos as a munition  Banned its export  Used the DES encryption algorithm (with 56-bit keys)  Non-US Kerberos 4 implementation, KTH-KRB Developed at the Royal Institute of Technology in Sweden System available outside the US before the US changed its cryptography export regulations (circa 2000).  Swedish implementation was based on a version called eBones. eBones was based on the exported MIT Bones release based on version Kerberos 4 patch-level 9 Stripped of both the encryption functions and the calls to them This somewhat limited Kerberos was called the eBones release  A Kerberos version 5 implementation, Heimdal, was released by basically the same group of people releasing KTH-KRB

8. History and development Windows 2000, XP, Server 2003 and Vista  Use Kerberos as their default authentication method  Microsoft additions to the Kerberos suite of protocols Documented in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols"  RFC 4757 documents Microsoft's use of the RC4 cipherRC4 Microsoft uses the Kerberos protocol  Does not use the MIT software Apple's Mac OS X uses Kerberos  client and server versions

9. History and development The IETF Kerberos working group is updating the specifications Recent updates include:  “Encryption and Checksum Specifications” RFC 3961  “Advanced Encryption Standard (AES) Encryption for Kerberos 5” RFC 3962  New edition of the Kerberos V5 specification “The Kerberos Network Authentication Service (V5)” RFC 4120 Obsoletes RFC 1510  Clarifies aspects of the protocol and intended use in a more detailed and clearer explanation  New edition of the GSS-API specificationGSS-API “The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2.“ RFC 4121

10. Description

11. Kerberos uses as its basis the Needham-Schroeder protocolNeedham-Schroeder  It makes use of a trusted third party Key Distribution Center (KDC), Consists of two logically separate parts:  An Authentication Server (AS)  A Ticket Granting Server (TGS)  Kerberos works on the basis of "tickets“ Serves to prove the identity of users The KDC maintains a database of secret keys  Each entity on the network — whether a client or a server — shares a secret key known only to itself and to the KDC  Knowledge of this key serves to prove an entity's identity  For communication between two entities KDC generates a session key Used to secure their interactions

12. Uses

13. The following software can use Kerberos for authentication:  VMware ESX Server VMware ESX Server  AFS AFS  Apache 1 (with the mod_auth_kerb module) Apachemod_auth_kerb  Apache 2 (using libapache-mod-auth-kerb) Apache  Cisco routers and switches running IOS CiscoIOS  Coda File System Coda File System  Eudora Eudora  Mac OS X Mac OS X  Microsoft Windows (2000 and later) uses as default authentication protocol Microsoft Windows  Mulberry, an e-mail client developed by Cyrusoft, Inc. Mulberry  NFS (since NFSv3) NFS  OpenSSH (with Kerberos v5 or higher) OpenSSH  Oracle RDBMS Oracle RDBMS  PAM (with the pam_krb5 module) PAM  rcp Remote copy command in linux and unix rcp  Samba since v3.x Samba  SOCKS (since SOCKS5) SOCKS  Netatalk Netatalk  GSS-API GSS-API  X Window System implementations X Window System  Indirectly, any software that allows the use of SASL for authentication, such as OpenLDAP, Dovecot IMAP4 and POP3 server, Postfix mail serverSASLOpenLDAP DovecotIMAP4POP3Postfix  Kerberos software suite also comes with kerberos-enabled clients and servers for rsh, FTP, and TelnetrshFTPTelnet  Any Java based software (since 1.4.2) using JAAS/JGSS can use Kerberos for security

14. Protocol

15. Security of the protocol relies heavily on participants maintaining loosely synchronized time and on short lived assertions of authenticity called Kerberos tickets Simplified description of the protocol  Abbreviations: AS = Authentication Server TGS = Ticket Granting Server SS = Service Server TGT = Ticket Granting Ticket  Briefly: Client authenticates to AS using a long-term shared secret  Receives a ticket from the TGS Client can use this ticket to get additional tickets for SS  Doesn’t need to resorting to using the shared secret These tickets can be used to prove authentication to SS

16. Protocol In more detail: User Client-based Logon Steps:  User enters a username and password on the client  Client performs a one-way function on the entered password Becomes the secret key of the client

17. Protocol Client Authentication Steps:  Client sends a clear-text message to the AS requesting services on behalf of the user Sample Message: "User XYZ would like to request services" Note: Neither the secret key nor the password is sent to the AS  The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client: Message A: Client/TGS session key encrypted using the secret key of the user. Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.  Once the client receives messages A and B, it decrypts message A to obtain the client/TGS session key This session key is used for further communications with TGS (Note: The client cannot decrypt the Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.

18. Protocol Client Service Authorization Steps:  When requesting services, the client sends the following two messages to the TGS: Message C: Composed of the Ticket-Granting Ticket from message B and the ID of the requested service. Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the client/TGS session key.  Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client: Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/server session key) encrypted using the service's secret key. Message F: Client/server session key encrypted with the client/TGS session key.

19. Protocol Client Service Request Steps:  Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages: Message E from the previous step (the client-to-server ticket, encrypted using service's secret key). Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.  The SS decrypts the ticket using its own secret key and sends the following message to the client to confirm its true identity and willingness to serve the client: Message H: the timestamp found in client's recent Authenticator plus 1, encrypted using the client/server session key.  The client decrypts the confirmation using the client/server session key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server.  The server provides the requested services to the client.

20. Kerberos drawbacks

21. Single point of failure: requires continuous availability of a central server  When the Kerberos server is down, no one can log in  Can be mitigated by using multiple Kerberos servers Requires the clocks of the involved hosts to be synchronized  Tickets have time availability period If the host clock is not synchronized with the clock of Kerberos server, the authentication will fail.  Default configuration requires that clock times are no more than 10 minutes apart  NTP daemons are usually employed to keep the host clocks synchronized Administration protocol is not standardized  Differs between server implementations  Password changes described in RFC 3244

22. Single sign-on

23. A method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems  Term enterprise reduced sign-on is preferred by some authors They believe single sign-on to be a misnomer:  "no one can achieve it without a homogeneous IT infrastructure" In a homogeneous IT infrastructure or at least where a single user entity authentication scheme exists or where user database is centralized, single sign-on is a visible benefit  All users in this infrastructure would have one or single authentication credentials e.g. say in an organization stores its user database in a LDAP database.  All Information processing systems can use such a LDAP database for user authentication and authorization In turn means single sign-on has been achieved organization wide