content/apacheds/kerberos-ug/1.1.6-as.mdtext

Title: 1.1.6 - AS (Authentication Server)
NavPrev: 1.1.5-database.html
NavPrevText: 1.1.5 - Database
NavUp: 1.1-introduction.html
NavUpText: 1.1 - Introduction
NavNext: 1.1.7-tgs.html
NavNextText: 1.1.7 - TGS (Ticket Granting Server)
Notice: Licensed to the Apache Software Foundation (ASF) under one
    or more contributor license agreements.  See the NOTICE file
    distributed with this work for additional information
    regarding copyright ownership.  The ASF licenses this file
    to you under the Apache License, Version 2.0 (the
    "License"); you may not use this file except in compliance
    with the License.  You may obtain a copy of the License at
    .
    http://www.apache.org/licenses/LICENSE-2.0
    .
    Unless required by applicable law or agreed to in writing,
    software distributed under the License is distributed on an
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, either express or implied.  See the License for the
    specific language governing permissions and limitations
    under the License.

# 1.1.6 - AS (Authentication Server)

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 <B>TGT</B>, 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 <B>TGS</B> 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 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

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 :

<DIV align="center">
  <img alt="Kerberos Authentication with no pre-auth" src="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 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 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 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 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  :

<DIV align="center">
  <img alt="Kerberos Authentication with pre-auth" src="images/kerberos-as-padata.png">
</DIV>