directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r851695 - in /websites/staging/directory/trunk/content: ./ apacheds/kerberos-ug/1.1.6-as.html
Date Sat, 23 Feb 2013 17:04:07 GMT
Author: buildbot
Date: Sat Feb 23 17:04:07 2013
New Revision: 851695

Log:
Staging update by buildbot for directory

Modified:
    websites/staging/directory/trunk/content/   (props changed)
    websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.6-as.html

Propchange: websites/staging/directory/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Feb 23 17:04:07 2013
@@ -1 +1 @@
-1447724
+1449371

Modified: 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 (original)
+++ websites/staging/directory/trunk/content/apacheds/kerberos-ug/1.1.6-as.html Sat Feb 23
17:04:07 2013
@@ -138,23 +138,23 @@
 
 
 <h1 id="116-as-authentication-server">1.1.6 - AS (Authentication Server)</h1>
-<p>One of the two services offered by a <strong>Kerberos</strong> server
is the Authentication Server, which is in charge to authenticate the clients, and issues a
ticket (<strong>TGT</strong>, or <em>Ticket Granting Ticket</em>)that
the user can send to the <strong>TGS</strong> to get back a service ticket.</p>
+<p>One of the two server components of a <strong>Kerberos</strong> server
is the Authentication Server, which authenticates clients, and issues tickets (<strong>TGT</strong>,
or <em>Ticket Granting Ticket</em>) that the user can send to the <strong>TGS</strong>
to get a service ticket.</p>
 <p><DIV class="info" markdown="1">
-The <strong>TGT</strong>, or <em>Ticket Granting Ticket</em>, is
a ticket that a client can use to get a service ticket. In fact, the <strong>AS</strong>
just consider the <strong>TGS</strong> as a standard service, and generates a
ticket for the user to access this service.
+The <strong>TGT</strong>, or <em>Ticket Granting Ticket</em>, is
a ticket that a client can use to get a service ticket. In fact, the authentication server
considers the <strong>TGS</strong> as just another service, and generates a ticket
for the user to access this service.
 </DIV></p>
-<p>The beauty of the <strong>AS</strong> 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.</p>
+<p>The beauty of the <strong>AS</strong> is that it does not verify that
the client issuing a request is a valid client : it just returns a tickat that an attacker
won't be able to process if he does not have the client's password.</p>
 <h2 id="exhanges-between-the-client-and-the-as">Exhanges between the client and the
AS</h2>
 <p>As we can see, for the client to get a <strong>TGT</strong>, 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 ;-).</p>
 <p>Here is the standard exchange :</p>
 <p><DIV align="center">
 <img alt="Kerberos Authentication with no pre-auth" src="images/kerberos-as-no-padata.png"
/>
 </DIV></p>
-<p>There is still a potential security breach in this scenario : as the server issues
a <strong>TGT</strong> 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...)</p>
-<p>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.</p>
-<p><strong>Kerberos 5</strong> 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 <strong>Kerberos</strong> still want to check
the users...</p>
+<p>There is still a potential security breach in this scenario : as the server issues
a <strong>TGT</strong> to the client, containing the secret key built using the
user's password, it is possible to decrypt the ticket using a brute force attack (and this
is more likely to happen if the password is weak...)</p>
+<p>Of course, as each ticket has a limited life time, the ticket won't be valid when
the attaker 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.</p>
+<p><strong>Kerberos 5</strong> introduced a mechanism to 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 <strong>Kerberos</strong> still wants to check
the users...</p>
 <p>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.</p>
 <h3 id="pre-authentication">Pre-Authentication</h3>
-<p>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 <strong>TGT</strong> This exchanged is called PreAuthentication.</p>
+<p>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 means 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's secret key, then that proves the client's identity, and now 
the server can send the <strong>TGT</strong>. This exchange is called PreAuthentication.</p>
 <p>Here is the exchange, when  :</p>
 <p><DIV align="center">
 <img alt="Kerberos Authentication with pre-auth" src="images/kerberos-as-padata.png" />



Mime
View raw message