Where Each Protocol Lives
Network security protocols don't all operate at the same layer of the OSI model. Knowing which layer a protocol works at tells you exactly what it can and can't protect.
Application Layer
- RADIUS
- TACACS+
- Kerberos
- PGP
- S/MIME
- Secure HTTP (S-HTTP)
- HTTPS
Transport Layer
- Transport Layer Security (TLS)
- Secure Sockets Layer (SSL)
Network Layer
- Internet Protocol Security (IPsec)
Mnemonic — "AAA Trio, Two T's for Transport, one I for IP"
Remember the layer split as "App does the most, Transport does two, Network does one." Application layer is crowded (RADIUS, TACACS+, Kerberos, PGP, S/MIME, S-HTTP, HTTPS — 7 protocols!), Transport has just TLS and SSL, and Network layer has only IPsec.
RADIUS — Remote Authentication Dial-In User Service
RADIUS is an authentication protocol providing centralized AAA — Authentication, Authorization, and Accounting — so remote access servers can talk to a central server. It uses a client-server model at the application layer, riding on UDP or TCP as the transport protocol. Defined in RFC 2865 and RFC 2866.
RADIUS Authentication Steps
Access-Request
The client initiates a connection by sending an access-request packet (username, password) to the server.
Access-Accept / Access-Reject / Access-Challenge
The server compares the credentials against its database. Match → sends access-accept (plus an optional access-challenge for additional authentication). No match → sends access-reject.
Accounting-Request
The client sends an accounting-request to record accounting information for the connection that was just accepted.
RADIUS Accounting Flow
[start]
[interim update]
[stop]
RADIUS uses PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), or EAP (Extensible Authentication Protocol) to authenticate users talking to servers. Core components: access clients, access server, RADIUS proxies, RADIUS servers, and user account databases. RADIUS messages ride as UDP payloads — one RADIUS message per UDP packet, made of a RADIUS header plus attributes.
TACACS+ — Terminal Access Controller Access Control System Plus
TACACS+ is a network security protocol used for AAA of network devices — switches, routers, firewalls — through one or more centralized servers. Critically, TACACS+ encrypts the entire communication between client and server, including the user's password, protecting it from sniffing attacks. It's a client-server model: the client (user or device) requests a connection, and the server authenticates by examining credentials.
TACACS+ AAA Client Flow
Resource request received
The AAA client receives a resource request from a user (assumes authentication already happened).
REQUEST sent to AAA server
A request is sent to the AAA server for the "service shell."
RESPONSE returned
A pass/fail response is returned to the AAA client.
Grant or deny
The AAA client grants or denies access to the service shell based on the response.
RADIUS vs TACACS+
- Combines authentication + authorization into one step
- Encrypts only the password in the packet, not the whole payload
- Uses UDP
- Mainly for network access (dial-up/remote access)
- Separates authentication, authorization, and accounting as distinct steps
- Encrypts the entire packet body
- Uses TCP
- Mainly for device administration (routers, switches, firewalls)
Mnemonic — "RADIUS = Roaming UDP User; TACACS+ = Total Admin Cover"
RADIUS: think "Roaming" dial-in User over UDP, only the password is masked. TACACS+: think "Total" encryption for Admin device access over TCP, and the + sign reminds you it separates the three AAA steps ("+1 step of separation" vs RADIUS bundling auth together).
Kerberos
Kerberos is a network authentication protocol for authenticating requests in computer networks, built around a trusted third party called the Key Distribution Center (KDC) and a ticket-based system — no passwords ever cross the network in the clear.
Kerberos Authentication Protocol (KAP) — Step by Step
Credentials to AS
The user sends their credentials to the Authentication Server (AS).
TGT issued
The AS hashes the password and checks it against the active directory database. If it matches, the AS (which includes the Ticket Granting Service, TGS) sends back a TGS session key and a Ticket Granting Ticket (TGT) to start a session.
Service ticket requested
Once authenticated, the user sends the TGT to the TGS to request a service ticket for accessing a specific service.
Service ticket granted
The TGS authenticates the TGT and grants a service ticket, which itself contains a ticket plus a session key.
Client authenticated to server
The client sends the service ticket to the target server. The server decrypts it using its own key, and the client is authenticated.
Mnemonic — "Kerberos = Concert with 3 Tickets"
Picture a music festival: 1) you show your ID at the gate (AS) and get a wristband (TGT). 2) You take the wristband to the merch booth (TGS) to get a ticket stub for a specific stage (service ticket). 3) You hand the stub to the stage bouncer (target server) who lets you in without ever asking for your original ID again. That's the whole "don't retype your password for every service" magic of Kerberos.
PGP and S/MIME — Securing Email
Pretty Good Privacy (PGP)
PGP is an application-layer protocol providing cryptographic privacy and authentication for network communication. It encrypts/decrypts email, authenticates messages with digital signatures, and can encrypt stored files too.
A random session key encrypts the file. The session key is itself encrypted with the recipient's public key and attached in the file header, alongside the encrypted file.
The recipient uses their private key to decrypt the embedded session key, then uses that session key to decrypt the actual file.
Secure/Multipurpose Internet Mail Extensions (S/MIME)
S/MIME is an application-layer protocol for sending digitally signed and encrypted email messages. It uses RSA for email encryption. It provides confidentiality, integrity, and non-repudiation for messages, and delivers cryptographic security services: authentication, message integrity, non-repudiation, privacy, and data security. An S/MIME implementation needs a certificate from a (public) CA, and uses different private keys for signing vs. encryption.
Alice signs her message with her private key (digital signature), then encrypts the message with a secret key (DES), and encrypts that secret key with Bob's public key (RSA). Bob checks Alice's certificate, verifies the signature with Alice's public key, then decrypts the secret key with his private key (RSA) and finally decrypts the message (DES).
PGP vs. S/MIME v3
| Feature | S/MIME v3 | OpenPGP |
|---|---|---|
| Message Format | Binary, based on CMS | Application/Pkcs7-mime, binary based on previous PGP |
| Certificate Format | Binary, based on X.509v3 | Binary, based on previous PGP |
| Symmetric Encryption | Triple DES (DES, EDE3, CBC) | Triple DES (DES, EDE3, Eccentric CFB) |
| Signature Algorithm | Diffie-Hellman (X9.42) with DSS, or RSA | ElGamal with DSS |
| Hash Algorithm | SHA-1 | SHA-1 |
| MIME Encapsulation (Signed) | Multipart/signed or CMS format | Multipart/signed ASCII armor |
| MIME Encapsulation (Encrypted) | Application/Pkcs7-mime | Multipart/Encrypted |
Mnemonic — "S/MIME needs a Suit (CA cert), PGP is more Personal"
S/MIME = formal, needs a Suit — an X.509 certificate from a CA (like wearing corporate ID badge). PGP = more casual "web of trust," you generate and share your own keys directly without necessarily going through a formal CA hierarchy.
S-HTTP, HTTPS, TLS, SSL
Secure HTTP (S-HTTP)
S-HTTP is an application-layer protocol used to encrypt web communications carried over HTTP — an alternative to HTTPS/SSL. Key difference: S-HTTP secures individual messages, while SSL establishes a secure connection between two entities, protecting the entire communication. Not all browsers/servers support S-HTTP.
HTTPS — Hypertext Transfer Protocol Secure
HTTPS secures communication between two computers over HTTP by encrypting the connection using TLS or SSL. Commonly used for confidential online transactions, and it protects against man-in-the-middle attacks since data travels over an encrypted channel.
Without encryption, sending the password "Mypass" over the wire could be intercepted as literal plaintext by an attacker. With HTTPS, "Mypass" gets encrypted into something like "Xz54p6kd" in transit — even if intercepted, the raw password isn't exposed.
Transport Layer Security (TLS)
TLS ensures secure communication between client-server applications over the internet, guaranteeing confidentiality and reliability via symmetric cryptography, and authenticating both parties using public-key cryptography. It prevents eavesdropping or tampering.
Layers of the TLS Protocol
Ensures server and client authentication — negotiates the session parameters and keys before data flows.
Ensures connection security with encryption — carries the actual application data once the handshake completes.
Secure Sockets Layer (SSL)
SSL was developed by Netscape to manage the security of message transmission over the internet. It uses RSA asymmetric encryption to protect data transferred over SSL connections.
SSL Handshake — Step by Step
Client Hello
Includes SSL version, random data, supported encryption/key-exchange/compression/MAC algorithms, and session ID.
Server Hello + Certificate
Server determines the SSL version/algorithms to use, sends Server Hello (session ID) and its Certificate message.
Server Hello Done
Server signals it's finished with its part of the negotiation.
Client Key Exchange
Client verifies the certificate, generates a random premaster secret (encrypted with the server's public key), and sends it.
Change Cipher Spec + Finished (client)
Client sends a Change Cipher Spec message plus a Finished message (hash of the handshake so far).
Verification + Finished (server)
Server calculates its own hash of the handshake and compares it to what the client sent. If they match, the negotiation succeeds; server sends its own Change Cipher Spec and Finished messages.
TLS is the modern successor to SSL
You'll often see "SSL/TLS" used together in the industry — TLS is technically the newer, more secure descendant of SSL, but the slides describe them as related sibling protocols with the same overall handshake philosophy.
Internet Protocol Security (IPsec)
IPsec is a network layer protocol that secures IP-level communication, providing end-to-end security at the internet layer of the TCP/IP stack. It encrypts and authenticates each IP packet in a communication, and supports network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and replay protection.
Two LANs (each with internal IPs) sit behind their own firewalls. An IPsec tunnel is established between the two firewalls' external IPs across the internet, so traffic between the internal networks is encrypted and authenticated end-to-end even though it crosses a public, untrusted network.
IPsec vs. TLS — different layers, different scope
TLS/SSL secure a specific application's connection (e.g. one browser session). IPsec operates lower, at the IP layer, so it can transparently secure all traffic between two networks or hosts, regardless of the application generating it.
Exam Tips & Tricks
RADIUS = UDP, TACACS+ = TCP
RADIUS uses UDP and only encrypts the password field. TACACS+ uses TCP and encrypts the full packet body.
Kerberos ticket order
AS issues TGT → TGS issues service ticket (using the TGT) → server grants access (using the service ticket). Three steps, three "tickets."
RFC numbers for RADIUS
RADIUS is defined in RFC 2865 (protocol) and RFC 2866 (accounting) — a common exam detail.
PGP vs S/MIME hash algorithm
Both use SHA-1 for hashing, but differ in certificate format (X.509 for S/MIME vs. PGP's own format) and signature algorithm.
S-HTTP secures messages, SSL secures connections
A subtle but testable distinction: S-HTTP works message-by-message; SSL/TLS secures the whole connection/session.
TLS has 2 sub-protocols
TLS Handshake Protocol (authentication/negotiation) + TLS Record Protocol (actual data encryption).
IPsec operates at the network layer
Unlike TLS/SSL (transport) or the AAA/email protocols (application), IPsec secures at the IP/network layer — protecting all traffic, not just one app's session.
SSL was developed by Netscape
A frequently tested trivia fact — SSL's origin is Netscape, using RSA asymmetric encryption.
Quick Reference — Everything at a Glance
| Topic | Key Point |
|---|---|
| RADIUS | Centralized AAA for remote access; client-server; UDP/TCP; RFC 2865/2866; only password encrypted. |
| RADIUS Steps | Access-Request → Access-Accept/Reject (+optional Challenge) → Accounting-Request. |
| TACACS+ | AAA for network device admin; client-server; encrypts entire packet; separates the 3 AAA steps. |
| Kerberos | Ticket-based network authentication via a KDC (AS + TGS); tickets prevent re-sending passwords. |
| Kerberos Flow | Credentials → TGT (from AS) → Service Ticket (from TGS) → Server grants access. |
| PGP | Application-layer email/file encryption; hybrid: session key encrypts data, public key encrypts session key. |
| S/MIME | Application-layer signed+encrypted email; uses RSA; needs X.509 CA certificate; SHA-1 hash. |
| PGP vs S/MIME | S/MIME = X.509 certs via formal CA; PGP = own key format, more decentralized trust. |
| S-HTTP | Encrypts individual HTTP messages; alternative to HTTPS; not universally supported. |
| HTTPS | Secures the whole HTTP connection using TLS/SSL; defends against MITM. |
| TLS | Transport-layer security; Handshake Protocol (auth) + Record Protocol (encryption). |
| SSL | Netscape-developed; RSA asymmetric encryption; multi-step handshake (Hello → Cert → Key Exchange → Finished). |
| IPsec | Network-layer, end-to-end IP security; encrypts/authenticates every packet; used for VPN tunnels. |
| Layer mapping | Application: RADIUS/TACACS+/Kerberos/PGP/S-MIME/S-HTTP/HTTPS. Transport: TLS/SSL. Network: IPsec. |