This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
AS_REP
AS_REP

Version management

Difference between version and

At line 1 added 42 lines
!!! Overview
[{$pagename}] represent the [response] from the [Ticket Granting Service] to the [Client] in the [AS Exchange]
When the previous [AS_REQ] arrives, the [Kerberos Authentication Service] checks whether [PrincipalClient|UserPrincipalName] and [PrincipalService|ServicePrincipalName] exist in the [KDC] [database].
If at least one of the two does __NOT__ exist an [error] message is sent to the [Client]
Otherwise the Authentication Server processes the reply as follows:
* [Kerberos Authentication Service] randomly creates a session key which will be the secret shared between the client and the TGS.
* [Kerberos Authentication Service] creates the [Ticket Granting Ticket] putting inside it the requesting
** [UserPrincipalName]
** [ServicePrincipalName] which is generally [KRBTGT]/REALM@REALM
** [IP Address] list (these first three pieces of information are copied as they arrive by the AS_REQ packet)
** [DateTime] (of the [KDC]) in timestamp format
** lifetime
** [Session Key]
The [Ticket Granting Ticket] thus appears as follows:\\
\\
TGT = ( [PrincipalClient|UserPrincipalName] , krbtgt/REALM@REALM , IP_list , Timestamp , Lifetime , SKTGS )
\\
\\
[Kerberos Authentication Service] generates and sends the reply containing:
* the ticket created previously, encrypted using the secret key for the service
* the service principal, timestamp, lifetime and session key all encrypted using the [Secret-key] for the user requesting the service (let’s call it KUser).
In summary:
\\
AS_REP = { PrincipalService , Timestamp , Lifetime , SKTGS }KUser { TGT }KTGS
\\
Though it may seem that this message contains redundant information (PrincipalService, timestamp, lifetime and session key). But this is not the case: since the information present in the TGT is encrypted using the secret key for the server, it cannot be read by the client and needs to be repeated.
At this point, when the client receives the reply message, it will ask the user to enter the [password]. The [salt] is concatenated with the [password] and then the string2key function is applied: with the resulting key an attempt is made to decrypt the part of the message encrypted by the KDC using the secret key of the user stored in the database. If the user is really who he/she says, and has thus entered the correct [password], the decrypting operation will be successful and thus the [Session Key] can be extracted and with the TGT (which remains encrypted) stored in the user’s [credential] [cache].
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Kerberos Operation|https://zeroshell.org/kerberos/kerberos-operation/|target='_blank'] - based on information obtained 2018-05-16
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop