directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kayyag...@apache.org
Subject svn commit: r1449371 - /directory/site/trunk/content/apacheds/kerberos-ug/1.1.6-as.mdtext
Date Sat, 23 Feb 2013 17:04:01 GMT
Author: kayyagari
Date: Sat Feb 23 17:04:01 2013
New Revision: 1449371

URL: http://svn.apache.org/r1449371
Log:
minor editing

Modified:
    directory/site/trunk/content/apacheds/kerberos-ug/1.1.6-as.mdtext

Modified: directory/site/trunk/content/apacheds/kerberos-ug/1.1.6-as.mdtext
URL: http://svn.apache.org/viewvc/directory/site/trunk/content/apacheds/kerberos-ug/1.1.6-as.mdtext?rev=1449371&r1=1449370&r2=1449371&view=diff
==============================================================================
--- directory/site/trunk/content/apacheds/kerberos-ug/1.1.6-as.mdtext (original)
+++ directory/site/trunk/content/apacheds/kerberos-ug/1.1.6-as.mdtext Sat Feb 23 17:04:01
2013
@@ -24,13 +24,13 @@ Notice: Licensed to the Apache Software 
 
 # 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.
+One of the two server components of a **Kerberos** server is the Authentication Server, which
authenticates clients, and issues tickets (**TGT**, or _Ticket Granting Ticket_) that the
user can send to the **TGS** to get a service ticket.
 
 <DIV class="info" markdown="1">
-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 **TGT**, or _Ticket Granting Ticket_, is a ticket that a client can use to get a service
ticket. In fact, the authentication server considers the **TGS** as just another service,
and generates a ticket for the user to access this service.
 </DIV>
 
-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.
+The beauty of the **AS** 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.
 
 ## Exhanges between the client and the AS
 
@@ -42,17 +42,17 @@ Here is the standard exchange :
 ![Kerberos Authentication with no pre-auth](images/kerberos-as-no-padata.png)
 </DIV>
 
-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...)
+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 is possible to
decrypt the ticket using a brute force attack (and this is more likely to happen if the password
is 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.
+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.
 
-**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...
+**Kerberos 5** 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 **Kerberos** still wants 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.
+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 **TGT**. This exchange is called PreAuthentication.
 
 Here is the exchange, when  :
 



Mime
View raw message