Thursday, March 3, 2011
Sunday, April 18, 2010
23.Kerberos
Kerberos is a cross-platform authentication protocol used for mutual authentication of users and services in a secure manner. Kerberos v5 is the current version of this protocol. The protocol ensures the integrity of data as it is transmitted over the network. It is widely used in all other major operating systems, such as Unix and Cisco IOS. The authentication process is the same in all operating system environments.
Kerberos protocol is build upon Symmetric Key Cryptography and requires a trusted third party. Kerberos works in a Key Distribution Center (KDC)—which is usually a network server—used to issue secure encrypted keys and tokens (tickets) to authenticate a user or a service. The tickets carry a timestamp and expire as soon as the user or the service logs off. The following steps are carried out to complete the authentication process:
1.The client presents its credentials to the KDC for authentication by means of username and password, smart card, or biometrics.
2.The KDC issues a Ticket Granting Ticket (TGT) to the client. The TGT is associated with an access token that remains active until the time client is logged on. The TGT is cached locally and is used later if the session remains active.
3.When the client needs to access the resource server, it presents the cached TGT to the KDC. The KDC grants a session ticket to the client.
4.The client presents the session ticket to the resource server, and the client is granted access to the resources on the resource server.
The TGT remains active for the entire active session. Kerberos is heavily dependent on synchronization of clocks on the clients and servers. Session tickets granted by the KDC to the client must be presented to the server within the established time limits; otherwise, they may be discarded.
Kerberos protocol is build upon Symmetric Key Cryptography and requires a trusted third party. Kerberos works in a Key Distribution Center (KDC)—which is usually a network server—used to issue secure encrypted keys and tokens (tickets) to authenticate a user or a service. The tickets carry a timestamp and expire as soon as the user or the service logs off. The following steps are carried out to complete the authentication process:
1.The client presents its credentials to the KDC for authentication by means of username and password, smart card, or biometrics.
2.The KDC issues a Ticket Granting Ticket (TGT) to the client. The TGT is associated with an access token that remains active until the time client is logged on. The TGT is cached locally and is used later if the session remains active.
3.When the client needs to access the resource server, it presents the cached TGT to the KDC. The KDC grants a session ticket to the client.
4.The client presents the session ticket to the resource server, and the client is granted access to the resources on the resource server.
The TGT remains active for the entire active session. Kerberos is heavily dependent on synchronization of clocks on the clients and servers. Session tickets granted by the KDC to the client must be presented to the server within the established time limits; otherwise, they may be discarded.
22.Remote Authentication Dial-in User Service (RADIUS)
RADIUS is used to provide centralized authentication for remote users connecting to the internal network of an organization through simple dial-up, VPN, or wireless connection. When a remote user needs access to the internal resources of an organization, he must provide his credentials to the Network Access Server (NAS). The NAS, in turn, sends the user’s credentials to the RADIUS server for authentication. If the RADIUS server authenticates the user, the connection request is accepted; otherwise, it is refused.
A RADIUS server can either work as a standalone server to authenticate all connection requests coming from outside users, or it can be a part of a distributed RADIUS setup. Larger organizations deploy multiple RADIUS servers to distribute the authentication load among multiple RADIUS servers. RADIUS servers support several popular protocols such as PAP, PPP, CHAP, and EAP. When a remote or wireless user sends a connection request, the RADIUS authentication process takes place as follows:
1.When the user attempts to connect to the RAS server, he is asked to supply his credentials, which in most cases are the username and password.
2.The RAS server encrypts the credentials of the user and forwards the request to the RADIUS server.
3.The RADIUS server makes an attempt to verify the user’s credentials against a database.
4.If the user’s credentials match those stored in the centralized database, the server responds with an access-accept message. If the user’s credentials do not match the stored credentials, the server sends an access-reject message.
5.The RAS server acts upon receipt of access-accept or access-reject messages and grants or denies a connection to the remote user appropriately.
6.If the connection is granted, the RADIUS server may also be configured to automatically assign an IP address to the remote client.
A RADIUS server can either work as a standalone server to authenticate all connection requests coming from outside users, or it can be a part of a distributed RADIUS setup. Larger organizations deploy multiple RADIUS servers to distribute the authentication load among multiple RADIUS servers. RADIUS servers support several popular protocols such as PAP, PPP, CHAP, and EAP. When a remote or wireless user sends a connection request, the RADIUS authentication process takes place as follows:
1.When the user attempts to connect to the RAS server, he is asked to supply his credentials, which in most cases are the username and password.
2.The RAS server encrypts the credentials of the user and forwards the request to the RADIUS server.
3.The RADIUS server makes an attempt to verify the user’s credentials against a database.
4.If the user’s credentials match those stored in the centralized database, the server responds with an access-accept message. If the user’s credentials do not match the stored credentials, the server sends an access-reject message.
5.The RAS server acts upon receipt of access-accept or access-reject messages and grants or denies a connection to the remote user appropriately.
6.If the connection is granted, the RADIUS server may also be configured to automatically assign an IP address to the remote client.
Subscribe to:
Posts (Atom)