Author: buildbot Date: Mon Feb 11 00:42:20 2013 New Revision: 850171 Log: Staging update by buildbot for directory Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.6-as.html websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.7-tgs.html websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-no-padata.graphml (with props) websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-no-padata.png (with props) websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-padata.graphml (with props) websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-padata.png (with props) Modified: websites/staging/directory/trunk/content/ (props changed) websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html Propchange: websites/staging/directory/trunk/content/ ------------------------------------------------------------------------------ --- cms:source-revision (original) +++ cms:source-revision Mon Feb 11 00:42:20 2013 @@ -1 +1 @@ -1444569 +1444642 Modified: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html ============================================================================== --- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html (original) +++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.5-database.html Mon Feb 11 00:42:20 2013 @@ -145,6 +145,13 @@ The Kerberos protocol The Authentication Server The Ticket Granting Server

+

We will focus on the database in this section.

+

Storage

+

We store everthing related to users, hosts and services in the LDAP base, as entries. In order to be able to retrieve them, we have to store them in a known place in the hierarchy. This position is fknown by the kerberos server using the +Search Base DN parameter.

+

Everytime the Kerberos server received a request for a ticket from a principal, it will do a LDAP search starting from the Search Base DN, looking for any entry matching the filter '(krb5PrincipalName=)'. This entry should contain the Kerberos keys that will be used to generate the ticket.

+

One more requirement : the key as a version which allows a user to keep going with a previous key when he just changed its password (an operation that will change the Kerberos keys).

+

So for an LDAP entry to be seen as a valid Kerberos entry, it has to contain a Krb5PrincipalName, a Krb5Key and one more attribute, the Krb5KeyVersionNumber.

Structure

There is an existing LDAP schema to manage the keys and other information, named krb5kdc. It contains 3 ObjectClasses and 15 AttributeTypes.

All the ObjectClasses are auxilliary.

Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.6-as.html ============================================================================== --- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.6-as.html (added) +++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.6-as.html Mon Feb 11 00:42:20 2013 @@ -0,0 +1,192 @@ + + + + + 1.1.6 - AS (Authentication Server) — Apache Directory + + + + + + + + + + + + +
+ +
+
+ + + +
+
+ + + + + +

1.1.6 - AS (Authentication Server)

+

One of the two services offered by a Kerberos server is the Authentication Server, which is in charge to authenticate the clients, and issues a ticket (TGT, or Ticket Granting Ticket)that the user can send to the TGS to get back a service ticket.

+

+The TGT, or Ticket Granting Ticket, is a ticket that a client can use to get a service ticket. In fact, the AS just consider the TGS as a standard service, and generates a ticket for the user to access this service. +

+

The beauty of the AS is that it does not verify that the client issuing a request is a valid client : it just return a tickat that an attacker won't be able to process if it does not have the client's password.

+

Exhanges between the client and the AS

+

As we can see, for the client to get a TGT, it's just a matter of sending a simple request, which is sent without any encryption whatsoever (some might consider that a BER encoded message is already cryptic enough, though ;-).

+

Here is the standard exchange :

+

+Kerberos Authentication with no pre-auth +

+

There is still a potential security breach in this scenario : as the server issues a TGT to the client, containing the secret key built using the user's password, it's potentially possible to decrypt the ticket using a brute force attack (and this is more likely to happen as the passwords are generally weak...)

+

Of course, as each ticket as a limited time to live, the ticket won't be valid when the attaker will have successfully cracked the ticket, but that doesn't matter : the user's password is now known, and a new ticket can be requested safely, giving access to the services.

+

Kerberos 5 introduced a mechanism to somehow workaround this issue : the user has to provide a proof that he is who he pretends to be. As we can see, it defeats the premise we made : the Kerberos still want to check the users...

+

Note that it's an option, so if you trust your users' password strength, then you don't need to send the server this proof.

+

Pre-Authentication

+

Now, let's see how does a client 'proves' that he is who he pretends to be. The protocol allows the server to ask for some proof, by the mean of asking the client to send the server a timestamp encrypted with the user's secret key : if the server can decrypt the timestamp using the client secret key, then that prove the client's identity, and the server can now send the TGT This exchanged is called PreAuthentication.

+

Here is the exchange, when :

+

+Kerberos Authentication with pre-auth +

+ + + + + +
+
+
+ +
+ + \ No newline at end of file Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.7-tgs.html ============================================================================== --- websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.7-tgs.html (added) +++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.7-tgs.html Mon Feb 11 00:42:20 2013 @@ -0,0 +1,180 @@ + + + + + 1.1.7 - TGS (Ticket Granting Server) — Apache Directory + + + + + + + + + + + + +
+ +
+
+ + + +
+
+ + + + + +

1.1.7 - TGS (Ticket Granting Server)

+

The second major service is the Ticket Granting Server, which is the service that delivers tickets for all the managed services to the users.

+

A client can access to this service fater having been authenticated - ie, after having received a ticket allowing it to access the TGS from the AS -.

+

At this point, all the exchanges are encrypted using the user session key.

+

Ther is not too much to tell about this service, except that ach request sent by the client contains the targeted service principal name, and the ticket issued by the AS.

+

How it works ?

+

When the TGS receives a request, it will read the ticket contained in the request, and will validate it. If the ticket has been issued by the AS, then the TGS has the AS secret key and can decrypt the ticket, otherwise it's potentially a forged ticket, and it will be discarded.

+

The TGS then generate a ticket for the targted service, and enncryt it using the service's secret key, then encapsulate this encypted ticket into a response which will be itself encrypted using the client's secret key.

+

The client will receive this response, will decrypt it and extract the encypted ticket, and will send this encrypted ticket to the targeted service, which will be able to decrypt it and validate it.

+

Of course, in the mean time, many checks will be done relative to the ticket validity, so one can be assured that the service is only accessible by those with the credential to do so.

+ + + + + +
+
+
+ +
+ + \ No newline at end of file Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-no-padata.graphml ============================================================================== Binary file - no diff available. Propchange: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-no-padata.graphml ------------------------------------------------------------------------------ svn:mime-type = application/xml Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-no-padata.png ============================================================================== Binary file - no diff available. Propchange: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-no-padata.png ------------------------------------------------------------------------------ svn:mime-type = image/png Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-padata.graphml ============================================================================== Binary file - no diff available. Propchange: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-padata.graphml ------------------------------------------------------------------------------ svn:mime-type = application/xml Added: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-padata.png ============================================================================== Binary file - no diff available. Propchange: websites/staging/directory/trunk/content/apacheds/kerberos-ug/images/kerberos-as-padata.png ------------------------------------------------------------------------------ svn:mime-type = image/png