Chapter 13. Security Protocols Project 13A: Public Key Infrastructure

advertisement
Chapter 13. Security Protocols
Project 13A: Public Key Infrastructure
Public Key Cryptography is often referred to as Public Key Infrastructure or PKI.
PKI requires that the network run a certificate server that is able to issue
certificates to entities requesting the certificates or store a set of certificates
purchased from a third-party vendor. With PKI, there are two types of keys that
are produced using the certificates: the public key and the private key. The public
key is freely distributed to any entity that requests it. The private key never leaves
the owner of the key. When a secure transmission is requested, the owner of the
key will send the public key to the requestor. The requestor uses that key to
encrypt the message. The message is sent and then received by the owner of the
key pair. At the destination, the key pair owner uses the private key along with the
public key to decrypt the transmission. Because both the public key and the
private key are needed to decrypt a transmission, a hacker cannot sniff packets
and read the contents, thus making this form of security very valuable to network
administrators.
Project 13B: Virtual Private Networks
Project 13C: Layer 2 Tunneling Protocol
1. The PPP payload is encapsulated with the PPP header and L2TP header.
2. The packet is then encapsulated with a UDP header containing the source
and destination ports set to 1701.
3. Usually the UDP message is encrypted and encapsulated with an IPSec
Encapsulation Security Payload (ESP) header and trailer. It will also
usually include an AH trailer.
4. The IPSec-encapsulated packet is again encapsulated, this time with an IP
header holding the source and destination IP addresses of the VPN client
and server.
5. The IP datagram is encapsulated with a header and trailer for the data-link
physical interface (this is dependent on the kind of transmission – Ethernet
dial-up, etc.).
Project 13D: Kerberos
1. Obtain a ticket from a Kerberos server. This is accomplished by requesting
authentication from the third-party, trusted Kerberos server. This Authentication
Server (AS) will create a session key. The session key is composed of your
password and a randomly generated value based on the service you are
requesting. This session key is commonly referred to as a “ticket-granting ticket”
(TGT).
2. Once you have the TGT, it must be sent to a ticket-granting server (TGS). The
TGS service and the AS service may both be running on the same server, or may
be on separate servers. (Note: Collectively, the authentication server and ticketgranting servers are often referred to as the Key Distribution Center (KDC)). The
TGS verifies the ticket, time stamps it, and returns it to the principal that
submitted it. Once the ticket has been returned by the TGS, it can be submitted to
the FTP server.
3. The FTP server can accept the ticket, allowing you to access the server, or it can
reject it, denying you access.
4. Since the ticket was time stamped by the TGS, it is valid for more than one
session. Typically, a ticket will be valid for up to eight hours. During that eighthour period, you may use and reuse the ticket for access to the FTP server. After
that time, the principal must repeat the process.
Drawing:
Download