Secure Network Protocols and Communications

Introduction

Network security is not achieved by a single encryption algorithm or perimeter device. It is achieved by the coordinated design, configuration, operation, and monitoring of protocols that carry information across networks. Secure protocols must address confidentiality, integrity, authentication, authorization, freshness, availability, and accountability. They must also remain secure when endpoints are misconfigured, certificates expire, routing information is falsified, or users are deceived.

This chapter examines the principal protocols used to secure contemporary enterprise and Internet communications: TLS and HTTPS, IPsec and VPNs, SSH, DNSSEC, secure email, authentication protocols, Wi-Fi security, and routing security. It also develops a practical method for examining packets and configurations. The emphasis is not merely on what a protocol claims to provide, but on how its security properties depend on negotiation, trust anchors, algorithms, implementation, deployment, and operational governance.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain the security objectives and trust assumptions of major secure network protocols.
2. Analyze TLS, HTTPS, IPsec, VPN, SSH, DNSSEC, email, Wi-Fi, and routing-security configurations.
3. Interpret important fields and exchanges in packet captures.
4. Identify common protocol weaknesses, downgrade opportunities, certificate failures, and authentication risks.
5. Select appropriate controls for confidentiality, integrity, identity, and key management.
6. Evaluate the operational, ethical, and governance implications of secure communications.

1. A Model for Secure Communication

A communication protocol is a set of messages, state transitions, data formats, and processing rules. Security analysis begins by asking five questions:

• Who are the communicating parties?
• What is being protected, and from whom?
• How are keys or credentials established?
• How is the peer authenticated?
• What happens when negotiation, verification, or delivery fails?

A useful threat model includes passive eavesdroppers, active network attackers, compromised endpoints, malicious insiders, rogue access points, and compromised infrastructure. Encryption protects data in transit, but it does not automatically protect data before encryption or after decryption. Nor does it establish that an authenticated server is trustworthy for every business purpose.

The principal security properties are:

Modern secure protocols generally prefer authenticated encryption with associated data (AEAD). It protects plaintext and authenticates both plaintext and selected unencrypted metadata. The protocol must still enforce nonce uniqueness. Reusing a nonce with many AEAD constructions can reveal information or enable forgery; therefore nonce generation is a protocol and implementation responsibility, not an optional optimization.

2. TLS and HTTPS

2.1 TLS security model

Transport Layer Security (TLS) secures a connection between a client and server, commonly over TCP. It provides encryption, integrity, server authentication, and optionally client authentication. HTTPS is HTTP carried over TLS; HTTP itself is not made secure by its syntax, but by the protected TLS channel beneath it.

TLS 1.3 substantially simplified the handshake and removed obsolete cryptographic options. A simplified exchange is:

1. The client sends a ClientHello containing supported versions, cipher-suite options, extensions, and a key share.
2. The server selects parameters and sends a ServerHello with its key share.
3. The server sends its certificate chain, a CertificateVerify signature, and Finished message.
4. The client verifies the certificate and signature, then sends its Finished message.
5. Application data is exchanged under negotiated traffic keys.

The key share normally uses an ephemeral Diffie–Hellman group. If a fresh ephemeral private key is used for each session, compromise of a long-term certificate key does not ordinarily reveal previously recorded session content. This property is called forward secrecy.

The basic Diffie–Hellman idea uses a public group and private exponents. In a simplified multiplicative group, Alice sends g^a and Bob sends g^b. Both derive g^ab, while an observer sees the public values but should not feasibly compute the shared secret. Real TLS deployments commonly use elliptic-curve Diffie–Hellman over carefully selected groups rather than the simplified notation.

TLS 1.3 derives multiple traffic secrets from a transcript and shared secret using a key-derivation function. Exact labels and construction details are standardized; implementations should use a vetted library rather than reproduce the derivation manually.

2.2 Certificate validation

A certificate binds an identity, such as a DNS name, to a public key. Validation normally includes:

• building a chain to a trusted root;
• checking the certificate’s validity period;
• matching the requested hostname against the Subject Alternative Name extension;
• checking key-usage and extended-key-usage constraints;
• validating signatures in the chain;
• considering revocation status where required by policy;
• rejecting weak algorithms and unacceptable key sizes.

A certificate does not prove that a website is honest, free of malware, or authorized to access a particular database. It establishes a cryptographic identity under a certificate authority (CA) trust model. Trust stores are therefore security-critical assets.

2.3 HTTPS deployment and analysis

HTTPS should be enforced with secure redirects, HSTS where appropriate, secure cookies, appropriate SameSite settings, and elimination of mixed content. TLS termination at a load balancer creates a new trust boundary: traffic between the balancer and the application must also be protected or strongly isolated.

In a packet capture, an analyst can inspect the TLS version, ClientHello extensions, supported groups, cipher-suite negotiation, certificate chain, alert messages, session resumption indicators, and timing. Encrypted application data cannot normally be read without endpoint keys or an authorized inspection mechanism. A capture that shows an apparently successful handshake does not prove that the application is secure; authorization, input validation, and endpoint compromise remain separate concerns.

2.4 Common TLS weaknesses

Frequent failures include accepting TLS 1.0 or 1.1, enabling export or obsolete cipher suites, disabling certificate validation in clients, trusting all certificates, ignoring hostname mismatches, failing to rotate private keys, and using outdated libraries. Downgrade attacks exploit inconsistent version negotiation or fallback behavior. TLS 1.3 includes downgrade protections, but a vulnerable endpoint or intermediary can still create risk.

Encrypted traffic analysis may reveal destinations, packet sizes, timing, and traffic volume even when content is protected. Traffic analysis is therefore a residual privacy risk.

3. IPsec and Virtual Private Networks

3.1 Architecture

IPsec secures traffic at the network layer. Its principal components are:

• Authentication Header (AH): provides integrity and origin authentication for selected IP packet fields, but not confidentiality. It is rarely used in modern deployments.
• Encapsulating Security Payload (ESP): provides confidentiality, integrity, authentication, and anti-replay protection according to the selected algorithms.
• Internet Key Exchange version 2 (IKEv2): negotiates security associations, authenticates peers, and establishes keys.

A Security Association (SA) is a one-way logical agreement containing algorithms, keys, lifetimes, and selectors. Bidirectional communication normally requires a pair of SAs. In tunnel mode, the original IP packet is encapsulated inside a new IP packet; in transport mode, only the payload and selected fields are protected.

3.2 VPN types and trust boundaries

A site-to-site VPN connects networks, while a remote-access VPN connects an individual device to an organization. A full-tunnel configuration sends all client traffic through the VPN; split tunneling sends only selected destinations through it. Full tunneling improves centralized inspection but consumes bandwidth and may increase latency. Split tunneling can improve performance but allows simultaneous exposure to untrusted networks.

A VPN does not make an endpoint trustworthy. Malware on a remote device can use the VPN as a route into internal systems. Strong identity, device posture assessment, least privilege, segmentation, and monitoring are therefore essential.

3.3 Configuration assessment

An assessment should verify that IKEv2 is preferred, peer identities are authenticated, strong and interoperable cryptographic suites are selected, perfect forward secrecy is enabled where required, lifetimes are appropriate, and anti-replay checks are active. Pre-shared keys should be long, unique, protected in a secrets manager, and replaced by certificate- or identity-based authentication where scale and governance require it.

Packet analysis can identify IKE negotiation, NAT traversal, ESP traffic, retransmissions, and rekey events. Payload confidentiality means that a capture alone may not reveal whether an internal application is secure. Analysts should correlate packets with gateway logs and endpoint telemetry.

4. SSH and Secure Administration

Secure Shell (SSH) provides encrypted remote login, command execution, tunneling, and file transfer. Its security depends on host-key verification and user authentication. On first connection, a client may record a server host key. Subsequent changes should trigger a warning rather than being silently accepted.

A robust SSH posture normally includes:

• current protocol versions and maintained implementations;
• public-key or centrally managed certificate authentication;
• disabled direct root login where operationally feasible;
• restricted administrative groups and commands;
• multi-factor authentication for privileged access;
• controlled agent forwarding;
• limited port forwarding;
• centralized logging and session accountability;
• removal of stale authorized keys.

Host-key verification prevents a man-in-the-middle attacker from impersonating a known server. User authentication solves a different problem: proving the identity of the person or workload requesting access. Confusing these two functions is a common design error.

SSH tunnels can bypass network segmentation. Port forwarding should therefore be governed as carefully as firewall rules. Administrators should not copy private keys to shared systems, and passphrases should protect keys stored on disk.

5. DNSSEC and Secure Name Resolution

The Domain Name System translates names into records. Ordinary DNS offers little protection against forged responses. DNS Security Extensions (DNSSEC) add origin authentication and integrity through digital signatures and a chain of trust from a trust anchor at the root through delegated zones.

Important DNSSEC records include DNSKEY, which publishes zone-signing keys; DS, which links a child zone to its parent; RRSIG, which signs resource records; and NSEC or NSEC3, which supports authenticated denial of existence. A validating resolver checks signatures, key relationships, time validity, and the authenticated denial response.

DNSSEC does not encrypt DNS queries. It helps a resolver determine whether an answer is authentic, but observers may still see the query. DNS over TLS (DoT) and DNS over HTTPS (DoH) protect the channel to a designated resolver, but they do not replace DNSSEC’s data-origin validation. These technologies address different threats and can be combined.

Operational failures include expired signatures, incorrect DS records, broken delegation, clock errors, and excessive dependence on one resolver. A validating resolver should fail safely according to service requirements: silently accepting an invalid answer defeats the purpose of validation, while indiscriminate failure can create availability problems.

6. Secure Email

Email has several distinct security goals. TLS between mail servers protects a connection in transit, but it does not necessarily protect stored messages or the entire delivery path. STARTTLS can be vulnerable to downgrade if not combined with appropriate policy. MTA-STS and DANE can strengthen expectations about encrypted mail transport, although their deployment models differ.

End-to-end mechanisms such as S/MIME and OpenPGP protect message content and support digital signatures. They require reliable key discovery, validation, storage, revocation, and recovery. A signed message can provide evidence of origin under a key-management policy; it does not automatically prove that the sender is acting lawfully or that attachments are safe.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM. SPF authorizes sending infrastructure for a domain. DKIM applies a domain-associated signature to selected message headers and body content. DMARC evaluates alignment between the visible From domain and authenticated identities, then publishes a policy and reporting preference. Forwarding, mailing lists, subdomain policy, and third-party senders complicate deployment.

Mail security must therefore combine protocol controls with filtering, user training, attachment isolation, phishing-resistant authentication, and incident response. Encryption cannot compensate for a user who approves a fraudulent payment instruction.

7. Authentication and Access Protocols

Authentication protocols prove possession of a secret, private key, or authenticator without unnecessarily disclosing that secret. Authorization then determines what the authenticated identity may do.

7.1 Passwords and challenge–response

Passwords should be transmitted only through a protected channel or used in a protocol that prevents disclosure. Servers should store salted, slow password hashes rather than plaintext or reversible encryption. Challenge–response protocols can prevent direct password transmission, but poor designs may remain vulnerable to offline guessing, replay, or phishing.

7.2 Kerberos

Kerberos uses a trusted Key Distribution Center (KDC), typically consisting of an Authentication Server and Ticket Granting Server. A client obtains a ticket-granting ticket, then requests service tickets for particular services. The service verifies a ticket and an authenticator without receiving the user’s password.

Kerberos provides mutual authentication and supports centralized policy, but it depends heavily on KDC availability, clock synchronization, protected service keys, and correct realm configuration. Compromise of a high-privilege service account can have broad consequences.

7.3 RADIUS, TACACS+, and federated identity

RADIUS is widely used for network access control, including Wi-Fi and remote access. TACACS+ separates authentication, authorization, and accounting and is common for device administration. Neither should be treated as a complete security architecture; transport protection, server validation, and administrator governance remain necessary.

OAuth 2.0 is primarily an authorization framework, not an authentication protocol. OpenID Connect adds an identity layer on top of OAuth 2.0. SAML is widely used for browser-based enterprise federation. Implementations must validate issuer, audience, redirect URI, state, nonce, signature, and token lifetime as appropriate. Accepting a validly signed token issued for another application is still a security failure.

Phishing-resistant methods such as WebAuthn/FIDO2 use public-key credentials bound to an origin. They substantially reduce credential replay and phishing risk, although account recovery and device enrollment remain important attack surfaces.

8. Wi-Fi Security

Wi-Fi security operates across radio, link, and authentication layers. WEP is obsolete because of serious design weaknesses. WPA2 with AES-CCMP remains widely deployed, while WPA3 improves password-based authentication through SAE and supports stronger enterprise options.

Enterprise Wi-Fi commonly uses 802.1X with EAP. The client authenticates through an authentication server, often RADIUS, while the access point enforces controlled network access. EAP method selection matters: clients must validate the authentication server certificate and should not silently fall back to an unauthenticated method.

Personal networks rely on a shared password. Password length and uniqueness are critical because attackers can capture exchanges and attempt offline guesses. Protected Management Frames reduce certain deauthentication and spoofing attacks, but compatibility and deployment settings must be assessed.

A wireless assessment should inspect encryption mode, authentication method, certificate validation, roaming behavior, guest isolation, management-frame protection, rogue access points, and segmentation between wireless clients and sensitive services. A hidden SSID is not a security control; it merely suppresses ordinary beacon advertising.

9. Routing Security

Routing protocols were historically designed for reachability and rapid convergence rather than hostile environments. Attacks may inject false routes, alter path attributes, create black holes, or redirect traffic for interception.

At the inter-domain level, Resource Public Key Infrastructure (RPKI) allows route-origin authorization: a resource holder publishes which autonomous systems may originate a prefix. Route Origin Validation can classify an announcement as valid, invalid, or unknown. RPKI does not prove the entire path is correct. BGP security extensions such as BGPsec address stronger path validation but have more complex deployment and interoperability requirements.

Within an organization, routing protocol authentication, infrastructure access control lists, passive-interface settings, route filtering, prefix limits, and management-plane protection reduce risk. Operators should monitor unexpected path changes and compare control-plane events with traffic observations.

10. Packet Analysis and Configuration Assessment

A disciplined assessment follows a repeatable sequence:

1. Define scope and authorization. Capture only traffic and systems covered by written authority.
2. Identify assets and trust boundaries. Document clients, servers, gateways, certificate authorities, identity providers, resolvers, and management systems.
3. Capture representative traffic. Include successful, failed, resumed, and rekeyed sessions where possible.
4. Inspect protocol negotiation. Record versions, algorithms, extensions, certificate chains, authentication methods, and error alerts.
5. Compare with configuration. A packet shows what happened; configuration files show what is intended. Neither alone is sufficient.
6. Test failure behavior. Examine expired certificates, invalid signatures, revoked identities, unsupported versions, and unavailable authentication servers in a controlled environment.
7. Assess residual risk. Consider metadata leakage, endpoint compromise, availability, logging, and recovery.
8. Report evidence and remediation. Include timestamps, packet identifiers, configuration excerpts, impact, and a verification plan.

Useful tools include protocol analyzers, TLS scanners, certificate inspection utilities, VPN and firewall logs, DNS validation tools, wireless survey tools, and routing-monitoring systems. Tools must be used ethically and with care: decryption keys, personal data, and authentication logs are sensitive evidence.

11. Applied Case: A Multi-Site University Network

Background

This illustrative case concerns a university with a central data center, remote campuses, cloud applications, student Wi-Fi, staff Wi-Fi, and a research network. An audit found intermittent VPN failures, warnings about certificates, and reports that users were redirected to counterfeit login pages.

Problem

The initial review revealed four conditions: some web services accepted outdated TLS versions; a remote-access VPN used a shared pre-shared key for multiple contractors; staff laptops connected to a wireless network without validating the RADIUS server certificate; and several DNS zones had inconsistent DNSSEC delegation.

Analysis

Packet captures showed clients offering modern TLS but occasionally falling back after handshake errors. Certificate inspection identified a missing intermediate certificate on one load balancer. VPN logs showed that the same identifier was used by several people, preventing reliable attribution. Wireless configuration profiles accepted any certificate issued by a broadly trusted authority, making rogue authentication infrastructure more plausible. DNS validation failures were correlated with expired signatures and stale DS records.

Approach and solution

The university adopted TLS 1.2 and 1.3 only, removed weak suites, corrected certificate-chain deployment, and enabled automated certificate inventory and renewal. The VPN was migrated to individual federated identities with phishing-resistant multi-factor authentication and device posture checks. Staff wireless profiles were configured to validate the expected RADIUS identity and certificate chain; guest traffic was isolated. DNSSEC signing and delegation were placed under monitored change control, with alerts for signature expiration and validation failures. Route filters and RPKI validation were added at Internet edges.

Outcome

The changes improved attribution, reduced downgrade exposure, and made failures visible before users experienced widespread outages. The project also showed that encryption alone was insufficient: identity lifecycle, certificate operations, segmentation, monitoring, and recovery procedures were equally important.

Learning points

1. A protocol’s security depends on its complete trust chain, not only its cipher.
2. Shared credentials weaken accountability and incident response.
3. Client-side certificate validation is as important as server-side certificate deployment.
4. Availability testing must accompany security hardening.
5. Automated inventory and expiry monitoring are essential for cryptographic infrastructure.

12. Limitations, Governance, and Contemporary Developments

Secure protocols cannot eliminate endpoint malware, social engineering, denial of service, insider abuse, or lawful-access conflicts. Inspection systems may improve malware detection but create privacy risks and new decryption key stores. Organizations should define purpose limitation, retention periods, access controls, audit trails, and transparent acceptable-use policies.

Cryptographic agility is increasingly important. Organizations should inventory protocol versions, algorithms, certificates, keys, and dependencies so that they can respond to newly discovered weaknesses. Post-quantum migration planning is also emerging: public-key systems used for long-lived confidentiality may require hybrid or post-quantum replacements, but organizations should avoid adopting unverified algorithms outside standards and tested implementations.

Artificial intelligence can assist with anomaly detection, certificate-risk prioritization, and packet classification. It should not be treated as an authority for identity or incident conclusions. Models can produce false positives, learn from biased data, expose sensitive captures, or be manipulated by adversarial traffic. Human review, reproducible evidence, and conventional controls remain necessary.

Best-Practice Checklist

• Prefer current, standards-based protocol versions and maintained libraries.
• Authenticate both endpoints whenever the threat model requires it.
• Validate names, certificate chains, issuers, audiences, and lifetimes.
• Use unique identities rather than shared administrative credentials.
• Protect private keys and secrets with controlled storage and rotation.
• Segment VPN, wireless, management, guest, and research networks.
• Monitor expiry, negotiation failures, route changes, and validation errors.
• Test fail-closed and recovery behavior in controlled environments.
• Document trust anchors, ownership, dependencies, and emergency procedures.
• Treat packet captures and decrypted traffic as sensitive personal or institutional data.

Chapter Summary

Secure network communication is a system property created by protocol design, cryptographic mechanisms, identity management, endpoint configuration, monitoring, and governance. TLS protects transport sessions when versions, certificates, keys, and hostname validation are correctly managed. IPsec and VPNs protect network paths but do not make remote endpoints trustworthy. SSH depends on both host-key verification and user authentication. DNSSEC authenticates DNS data but does not encrypt queries, while DoT and DoH protect selected resolver channels. Secure email requires transport security, domain authentication, and, where necessary, end-to-end protection. Kerberos, RADIUS, federated identity, and phishing-resistant credentials solve different authentication and authorization problems. WPA3, correctly configured enterprise Wi-Fi, routing filters, and RPKI reduce wireless and routing risks.

Packet analysis reveals actual negotiation and failure behavior; configuration assessment reveals intended policy. Both are required. The most serious weaknesses commonly arise from trust-anchor errors, downgrade paths, shared credentials, missing validation, stale keys, poor segmentation, and inadequate operational monitoring. Effective security therefore combines cryptography with sound identity, lifecycle, availability, privacy, and accountability practices.

Key Terms

TLS: Protocol that protects transport connections with encryption, integrity, and authentication.

HTTPS: HTTP carried over a TLS-protected connection.

Certificate authority: Entity that issues and signs digital certificates.

Forward secrecy: Property that protects past sessions if a long-term private key is later compromised.

AEAD: Authenticated encryption with associated data.

IPsec: Network-layer security architecture using protocols such as ESP and IKEv2.

Security Association: One-way IPsec agreement containing keys, algorithms, and selectors.

VPN: Encrypted or authenticated logical connection across an untrusted network.

SSH: Protocol for secure remote administration, tunneling, and file transfer.

DNSSEC: Extensions that provide origin authentication and integrity for DNS data.

RRSIG: DNSSEC record containing a digital signature over DNS resource records.

SPF: Policy identifying permitted mail-sending hosts for a domain.

DKIM: Domain-associated digital signature for selected email content.

DMARC: Policy framework evaluating email authentication and domain alignment.

Kerberos: Ticket-based authentication system using a trusted key distribution center.

RADIUS: Authentication, authorization, and accounting protocol widely used for network access.

WPA3: Wi-Fi security generation using stronger personal and enterprise mechanisms.

RPKI: Public-key infrastructure supporting authorization of route origins.

Perfect forward secrecy: Another common description of forward secrecy achieved through ephemeral key exchange.

Trust anchor: Locally trusted key or certificate from which a validation chain begins.

Review Questions

Short Answer Questions

1. What security properties does TLS provide, and what does it not guarantee about an application?
2. Distinguish IPsec tunnel mode from transport mode.
3. Why is hostname validation necessary when a certificate chain is valid?
4. What problem does DNSSEC solve, and what problem does it not solve?
5. Why should an SSH client warn when a known host key changes?

Long Answer Questions

1. Explain the TLS 1.3 handshake and discuss the roles of certificate authentication, ephemeral key exchange, and Finished messages.
2. Compare site-to-site and remote-access VPNs, including their trust boundaries, operational risks, and monitoring requirements.
3. Explain how SPF, DKIM, and DMARC complement one another and identify important deployment limitations.
4. Describe an enterprise Wi-Fi security architecture using 802.1X, EAP, RADIUS, certificate validation, and network segmentation.
5. Discuss how RPKI, route filtering, and routing-protocol authentication reduce routing attacks, and explain their limitations.

Analytical / Application Questions

1. A client accepts any TLS certificate without checking the hostname. Analyze the attack this enables and propose a remediation and verification method.
2. A university uses one VPN pre-shared key for 300 contractors. Evaluate the risks and design an identity, authentication, and revocation model.
3. A DNSSEC-enabled zone intermittently fails validation after a key rollover. Identify likely causes, evidence to collect, and a safe recovery procedure.

Multiple Choice Questions with Answers

Question 1

Which TLS feature most directly supports forward secrecy?

A. A static server certificate used as the session key

B. Ephemeral Diffie–Hellman key exchange

C. Disabling certificate validation

D. Using HTTP redirects

Correct Answer: B. Ephemeral Diffie–Hellman key exchange

Question 2

What is the primary purpose of ESP in IPsec?

A. Providing DNS name resolution

B. Providing network-layer confidentiality and integrity according to selected algorithms

C. Issuing user passwords

D. Signing BGP prefixes

Correct Answer: B. Providing network-layer confidentiality and integrity according to selected algorithms

Question 3

Which statement about DNSSEC is correct?

A. It encrypts all DNS queries

B. It authenticates DNS data origin and integrity

C. It replaces TLS for web traffic

D. It prevents endpoint malware

Correct Answer: B. It authenticates DNS data origin and integrity

Question 4

What does SSH host-key verification primarily protect against?

A. A server impersonation or man-in-the-middle attack

B. Password reuse across websites

C. Wireless radio interference

D. DNS cache expiration

Correct Answer: A. A server impersonation or man-in-the-middle attack

Question 5

Which technology evaluates alignment between a visible From domain and authenticated email identities?

A. IPsec

B. DMARC

C. IKEv2

D. RPKI

Correct Answer: B. DMARC

Question 6

Why is accepting any RADIUS server certificate dangerous in enterprise Wi-Fi?

A. It prevents encryption of radio traffic

B. It can permit authentication to a rogue server

C. It disables DHCP

D. It forces use of WEP

Correct Answer: B. It can permit authentication to a rogue server

Question 7

What is a principal security risk of a shared VPN pre-shared key?

A. It guarantees individual accountability

B. Compromise cannot be contained to one user

C. It prevents all encryption

D. It automatically validates device posture

Correct Answer: B. Compromise cannot be contained to one user

Question 8

What does RPKI route-origin validation primarily assess?

A. Whether a prefix announcement is authorized by its resource holder

B. Whether an email attachment is safe

C. Whether a TLS certificate matches a hostname

D. Whether a Wi-Fi password is long enough

Correct Answer: A. Whether a prefix announcement is authorized by its resource holder

Question 9

Which statement best distinguishes authentication from authorization?

A. Authentication determines permissions; authorization proves identity

B. Authentication proves identity; authorization determines permitted actions

C. They are identical terms

D. Authorization only applies to encryption keys

Correct Answer: B. Authentication proves identity; authorization determines permitted actions

Question 10

In packet analysis, why should observed traffic be compared with configuration?

A. Packets always show intended policy perfectly

B. Configuration always shows what actually occurred

C. The two sources reveal different aspects of intended and actual behavior

D. Configuration is irrelevant after capture

Correct Answer: C. The two sources reveal different aspects of intended and actual behavior