TABLE A – Verification of Data 

Data held in database 

Yes/No 

Correction / Completion 

Evaluation of IMS 

Evaluator:  

M. Meints 

Organisation:  

ICCP 

Date of evaluation:  

07-Jun-2005 

Identification of IMS 

Sources of information:  

http://web.mit.edu/kerberos/www/

Version:  

5-1.4.1 

Manufacturer:  

MIT Massachusetts Institute of Technology 

Nature:  

Private 

Country:  

USA 

Regions:  

Global 

Language:  

State:  

Available 

Open/Closed:  

Open IMS: the identities work with several systems or applications. 

Platform & Environment 

Requirements:  

Almost any modern hardware/software 

Number of users:  

Widely used, distributed with various Microsoft and Apple products 

Standards:  

Kerberos employs a standardized protocol of the same name. There are several partially interoperable implementations by MIT, Kungliga Tekniska Hoegskoln Stockholm, Microsoft, Apple and Transarc 

The Transarc implementation only supports version 4 of the protocol and should be considered obsolete. I do not recommend including it in this document. 

The Kerberos standard is defined by the IETF. The current controlling documents are RFC 4120 and RFC 4537 

Suggest that you change “partially” to “mostly”. 

Description of Server - Side components:  

The main component is the Key Distribution Center (KDC) which authenticates the users and supplies them with so-called tickets. These in turn allow the use of other resources. The KDC shares secrets with every service and user in the installation. 

Description of methods:  

The only data kept about a user is her username and a hash of her password. The password can be changed by the user. 

Descriptor of Client -
Side components:

The client needs Kerberos-enabled clients for the services it wants to use with Kerberos. 

Seals:  

No  

Which seal:  

Third party:  

yes 

Which third party:  

Features:  

Kerberos authentication perimeters are called Realms. Inside a realm, the Kerberos setup consists of clients, application servers and the Ticket Granting Service (TGS). A user authenticates herself by password on her local machine (which must be known to the TGS and share a secret with it). After successful authentication the user can request tickets for services from the TGS. A ticket states that the user is authenticated and is allowed to use the service. Services on the application servers check if the user sent a valid ticket with her request, and allows access if valid. Tickets are valid only for pre-defined periods of time. Newer versions of Kerberos allow cross-realm authentication. In this setup, the TGSs of the several realms have pairwise shared secrets and forward requests to remote services. The forwarded tickets are authenticated with the shared secrets. 

There are many other standards that extend the functionality of Kerberos. For example some implementations currently support PKINIT so that public keys can be used for initial authentication instead of a username / password.  

Please see http://www.ietf.org/html.charters/krb-wg-charter.html

You make no mention that many organizations use Kerberos as a key component of their single sign-on (SSO) strategy. That is probably more useful than the features that you are pointing out. 

There are also products that use Kerberos for web authentication. Using http-spnego. Examples include: IE, IIS, Apache, Firefox, Safari, … 

Screenshot picture:  

n.a.

Flowchart:  

kerberos-flow.gif

Cost 

Price:  

0 

Comment to the Cost:  

Open Source 

Type & Class of IMS 

Type of IMS:  

Type 1: IMS for account management. 

Class of IMS:  

Functionality:  

Authentication and Single Sign-On 

Suggestions: