Chapter 10: Network Security

1

• Chapter 10 Network Security
• Topics
• Placement of the security function.
• Security the layered model.
• Secure Sockets Layer (SSL).
• Secure Electronic Transactions (SET).
• Transport Layer Security (TLS).
• Internet Protocol (IP) security (IPSec).
• Virtual Private Networks (VPN) (IP tunneling).
• Data Link Layer Security (hardware/link
• encryption)

2
Placement of the Security Function Prominent
approaches Data Link Layer (DLL)
security End-to-End security DLL security
protects messages independently on each link of
a network. End-to-end is from the source to the
destination. Variations end-to-end may mean
from a computer to a gateway (e.g., a firewall)
or from firewall-to-firewall). Traffic is
protected between the firewall, but is not
protected between the firewall and the end
computer (e.g., on the LAN behind each
firewall).
3
Placement of the Encryption Function
Data Link not Protected in routers or
other intermediate systems
Protected
Application
Application
Transport
Transport
Network
Network
Data Link
Data Link
End-to-End Protected in routers and
other intermediate systems
Application
Application
Transport
Transport
Network
Network
Data Link
Data Link
Protected
4
Data Link Layer Encryption
Source
Destination
Connection points (e.g., telephone office)
Links
Links phone lines, fiber cable, microwave,
satellite, etc. The link is encrypted. Often,
different keys are used on each link so
subversion of one link does not affect all
links. Stream ciphers are typically used and
entire messages and headers are encrypted. Used
in connection-oriented traffic (no intermediate
processing, like routing).
5
Data Link Layer Encryption Examples Secure
telephones, wireless network radio link
(802.11), satellite pay television. Message and
headers are protected no traffic
analysis. Keys are imbedded in devices -
requires key change. Intermediate nodes must be
secure since messages are decrypted and
encrypted at each node. An adversary
controlling a node can read unencrypted traffic.
.
6
Data Link Layer Encryption In nodes subjected
to high volumes of traffic, cryptographic
operations reduce maximum throughput. In a
complex networks, the end user does not have
control of the nodes and must trust an
intermediary. Used in connection-oriented
networks (telephone system), private networks,
on single links (e.g., wireless). Not used in
routed public networks.
7
End-to-End Encryption The intent of end-to-end
security is to protect messages over the entire
path from source to destination. Ensures that
any compromise of an intermediate node does not
compromise the message. However, always remember
that the clear text exists at the two ends
points. A compromise their give clear text access
to the adversary Can be implemented with a wide
range of protection methods at different
protocol layers.
8
Gateway to Gateway Encryption A variation on
end-to-end where end point may be Firewall-to-fi
rewall leaving firewall to end-host path
Unprotected at both ends (clear text is
available on the Internal network). Well suited
for use in routed networks with a mix of
protected and unprotected traffic. Protocols
exist that can be applied at any layer in the
Layered network model.
9
Security The Layered Model Type
Layer Typical
Application Application proxies Application
PGP, PEM (mail) Session proxies
Transport SSL, TLS, Kerberos Packet filters
Network IPSec Packet
filters Data Link PPTP,
L2TP Packet filters Physical
hardware Lower layers are more generalized,
encrypt data at all layers above. Higher layers
protect above, but do not protect data added by
lower layers (header data).
10
Security - Placement of the Function All
placements can use the same underlying mechanisms
for authentication, integrity, and
confidentiality. What is protected is different
depending on the layer the security
functionality is placed in. For
example Encrypting at the physical layer means
everything is encrypted - also means we
must 1. Have a dedicated line with no
intermediate routing 2. Have exactly the same
equipment at the far end.
11
Major Placements of the Security Function
PGP
Scope
Application
Application
TLS
Scope
Transport
Transport
Network
Network
Application
Application
SSL
Scope
Scope
IPSec
Session Layer
Transport
Transport
Network
Network
Application - Unique to each application, PGP,
S/MIME. SSL - Multiple applications, but is
shimmed between application and TCP (API per
application). TLS - Same as SSL, except
integrated into TCP stack. IPSec, most generic,
protects everything encapsulated by IP.
12
Security - Generalized Model
Information Exchange
Establishes connections, negotiates
Algorithms. Manages keys, key
exchanges. Authenticates users, systems,
and/or Messages. Encrypts authenticators and/or
Payloads.
Key Management
Authentication
Encryption
13
Secure Sockets Layer (SSL) Open system protocol,
developed by Netscape Communications and
embedded in the Netscape browser. Offered to the
Internet Engineering Task Force (IETF) for
consideration as an Internet standard. IETF
made minor changes, called is Transport Layer
Security (TLS) and adopted it. Now appears in
all Browsers. Uses TCP for transport. Main use
is to conduct secure Internet transactions
(e-commerce).
14

• Secure Sockets Layer (SSL)
• Uses public key cryptography to provide 4 basic
  services
• Secret key Exchange ------ Public key encryption
  
• Diffie-Hellman exchange
• 2. Message privacy ------------ Secret key
  encryption
• 3. Message integrity ----------- RSA digital
  signature
• 4. Authentication -------------- X.509
  certificates and
• 
  digital signature
• Provides security at the session/application
  layer and
• is used for many applications, including for web
• commerce transactions.

15
SSL - Fit in Layered Architecture Normal
Communications SSL Communications
Application
Application
SSL I/O Calls
I/O Calls
SSL
WinSock
I/O Calls
TCP Calls
WinSock
TCP
TCP Calls
TCP
To Network
To Network
16
Secure Sockets Layer (SSL) - Web Commerce
17
Secure Sockets Layer (SSL) 1. User accesses web
site, fills shopping cart, goes to checkout. 2.
The server sends a copy of the server's X.509
certificate. The certificate identifies the CA
certifying the certificate. 3. The user's browser
contacts the specified CA and requests
certification. The CA sends a CA signed copy of
the certificate to the user certifying the
merchant certificate as un-expired and valid. 4.
The browser encrypts a session key with the
server's public key. 5. The server prompts the
browser for a transaction. The browser sends its
ID and credit card number encrypted with the
session key. 6. The server decrypts the credit
card number, validates it from the issuing bank,
and completes the transaction. Notice that only
the server has been authenticated. The user has
not. However, the user's credit card has been
validated for the purchase. There is no identity
assurance between the user and the card.
18
Secure Sockets Layer (SSL) SSL can support all
the services available using Public
Key Infrastructure (PKI). All transmissions
between an SSL-enabled client and server can be
encrypted using algorithms negotiated during SSL
set-up. The private key and message digest
ensures message and authentication of source.
Confidentiality is provided by secret key
exchange the secret key is encrypted with the
public key of the user and authenticated by
private key encryption of the encrypted secret
key digest. Mutual authentication is supported,
but that requires the client (user) to hold a CA
registered certificate. This is not common, but
is supported by the basic technology of SSL.
19
Secure Sockets Layer - Why Diffie-Hellman? Diffie
-Hellman is a method of secret key exchange that
does not require the use of certificates. Instead
, a shared secret is developed using public keys
and nonces. Diffie-Hellman can also be used with
signing only keys. Finally, the patents on
Diffie-Hellman expired in 1997 so it is now a
public domain algorithm freely usable by anyone.
20
SSL Applications Previous example was web access
to support electronic commerce. SSL can be used
for many applications. SSL architecture is
Handshake
Change Cipher
Alert
SSL Record Protocol
TCP
IP
Top part of SSL at the application layer provides
3 different functions, all using a common
underlying record structure. SSL uses standard
TCP for reliable transport.
21
SSL Protocols Handshake - Establishes
connection, initial authentication, negotiates
cipher suite keys. Change cipher - Used to
re-negotiate ciphers and/or keys at any time
during a session. Alert - Sends warning messages
regarding any potential problems (e.g., no
certificate, out-dated certificate, etc.) used
to terminate a session. Record - Main protocol
used during actual exchange of information
between the client and server.
22
SSL Handshake Protocol A. Agree on SSL protocol
version (version 3 is current) B. Agree on crypto
algorithms (encryption, MAC, compression) C.
Optionally authenticate each other (exchange
certificates) D. Use public keys to generate a
shared secret key. 1. Establish security
capabilities (id SSL version, nonces, session
id, algorithms, compression method). Is a
negotiated agreement. 2. Server authentication
and key exchange. 3. Client authentication and
key exchange. If no certificate is available for
client authentication, an ALERT message is
sent. 4. Finish - completes the secure
connection At end, two shared secret keys have
been negotiated, one for encryption and one for
a encrypting the message authentication code
(MAC).
23
SSL - Cipher Suites Supported The following
suites are supported IDEA, 128 bit key, block
cipher RC2, 40 bit key, block cipher DES, 40 bit
key, block cipher DES, 56 bit key, block
cipher 3DES, 168 bit key, block cipher Fortezza,
80 bit key, block cipher RC4, 40 bit key, stream
cipher RC4, 128 bit key, stream cipher Weak
(e.g., 40 bit) keys appear in SSL because of
federal encryption export control limitations
that have now been lifted.
24
SSL Record Protocol The workhorse - doing the
message encryption and MAC
Message
Fragment
Compress
Add MAC
Encrypt
Handed off to TCP for transmission
Add SSL Header
25
SSL Change Cipher Spec Alert Protocols Change
Cipher Spec allows for notification that a
different cipher suite needs to be negotiated
(this is a 1 Byte notification message) Alert
Protocol is used to notify the peer of any alert
such as Decompression or handshake
failure. Illegal parameters. Certificate
problem no certificate, bad certificate,
expired, revoked, unknown, unsupported. Close
notification (this is the last message). Close
notification is an alert message requiring action
to confirm the close to avoid truncation attacks
(one side decides to close, and an attacker
attempts to continue with the other side).
26
SSL - Summary SSL is robust, and widely used,
but it can be hacked heres how dsniff 2.3,
is a man-in-the-middle SSL hack. To work The
intruder must be in the path between a client
server, or fool theuser into connecting to the
intruder instead of the intended server, or Do
arp spoofing to re-direct the connection between
the user and server. In each case, the result is
that the intruder is inserted between the user
and the real server then and proxies all traffic
while reading everything that goes by including
passwords, credit card numbers, etc.
27

• SSL Hack
• Minimal risk from outsiders due to the path
  requirements. If arp
• spoofing is used the hacker leaves tracks and
  must be in the path.
• That leaves fooling the user. This can be avoided
  as follows
• Insure the site in the browser bar is the site
  you wanted.
• Check the SSL certificate to ensure its the
  right site and that
• it is from a known CA, like Verisign.
• 3. Like any other security method, if the machine
  you are on is
• root compromised, the every I/O character can be
  captured,
• stored, and analyzed looking for usernames,
  passwords,
• passphrases to access keys, etc.

28
Secure Electronic Transactions (SET) SET is a
protocol develop for Mastercard Visa to provide
very secure e-commerce transactions. Joint
development with IBM, Microsoft, Netscape, RSA
Data Security, Terisa, and VeriSign, circa 1996
(a 900 page specification document). SET is a
group of protocols and data formats intended to
operate over the Internet, interface with the
existing payment network while providing the
encryption functionality of SSL plus several
important additional features. 1. Users and
merchants both hold certificates. 2. Users
register with with the cardholder service
(bank). 3. One certificate per card is
required. 4. Merchants also register with a
cardholder service (bank).
29
Secure Electronic Transactions (SET)
30
SET - The Players Two networks The public
Internet, a private payment network. Cardholders
Individuals authorized by a financial institution
(the card issuer) to make transactions using the
issuers card. Merchant Company willing to
accept the card as payment and is authorized by
the acquirer and/or financial institution to
accept credit card transactions. Issuer The
financial institution that issues the
card. Acquirer Usually a financial institution
or subsidiary that establishes merchant accounts
(i.e., the merchants bank) and processes
transaction authorizations and payments.
Payment gateway A system operated for/by
acquirer to process merchant payment notices and
pass them to the appropriate issuer. Certificate
Authority Issuer of X.509 certificates for
merchants, card holders, payment gateways, and
issuers systems.
31
SET - Requirements Card Issuer/Acquirer Proof
transactions were authorized by the card
holder. Proof transactions were authorized by
the merchant. Merchant Proof transactions were
authorized by the acquirer. Proof transactions
were authorized by the card holder. Card
Holder Proof transactions were authorized by
the acquirer. Proof merchants are authorized
with the acquirer. Proof of the purchase from
the merchant (a receipt). Privacy of card number
(dont disclose to merchant). Privacy of
transaction (dont disclose to bank). All
Ensuring that unauthorized payments are
impossible!
32
SET Transactions - Five Major Elements 1. Setup
- install software and enroll. Card issuers set
up a Certificate Authority. Merchants enroll to
use the CA payment system. Customers enroll to
use the CA payment system. On acceptance, the
CA issues X.509 certificates and the public key
of the CA. The merchant also needs the public key
of the payment server. Both the merchant and
customer require software. 2. Browsing -
shopping for purchases. Customer browses the
merchants site and puts items in a shopping
cart - completing the merchants order form.
33
SET Transactions - Five Major Elements (contd)
3. Purchase request - ordering goods When the
customer selects purchase, the merchant completes
an order form and sends it to the customer for
final confirmation. All of these actions are
similar to those followed by SSL (except the one
associated with enrolling the customer). From
here on, the actions are different. 4. Payment
authorization - confirming payment is
authorized 5. Payment capture - finalizing the
order payment Before discussing them, we need
to look at a capability called the dual signature.
34
SET - Dual Signature Similar to Digital
Signature for authentication/non-repudiation. But
, with a significant difference Uses a dual
signature Binds (links) the two
signatures Function The dual signature
establishes a way to separate a customers Order
Information (OI) from the customers Payment
Information (PI). This allows the merchant to
view the OI to fulfill the order, but blocks the
merchant from viewing the PI - no need, keeps the
credit card information out of the hands of the
merchant. Also, the banks only need to see PI,
not OI. The link between signatures is necessary
to settle disputes.
35
Dual Signature - Functional Generation
36
Dual Signature - What it Does Provides the
customers digital signature over the entire PI
and OI package of information - non-repudiation
of source. Because the PI and OI are hashed - in
fact hashed twice, they can be individually and
collectively tested for integrity such that they
cannot be tampered with after being signed -
integrity of contents. This is still not enough
to be able to separate the information, so we
need to look at the additional processing
required to complete a purchase which consists
of 4 parts Initiate Purchase Initiate
Response Purchase Request Purchase Response
37
Completing the Purchase Customer sends an
Initiate Request message to the merchant.
This message requests two certificates The
merchants certificate, and the certificate of
the merchants payment gateway It also contains
the brand of the credit card, a message
identifier, and a time stamp nonce. Merchant
responds by sending an Initiate Response
message back to the customer. A clear text part
contains the both the merchants X.509 certificate
and the certificate of the merchants payment
gateway.
38
Completing the Purchase (contd) The message
contains the customers nonce, another nonce
generated by the merchant, and a transaction
identifier (a unique order number) and is signed
by the merchant. The customer verifies both
certificates with the CA and is now confident of
the identity of the merchant and the payment
server. The customer now creates the Order
Information (OI) and Payment Information (PI)
documents. The OI only needs to include the
transaction identifier supplied by the merchant.
The PI only needs to contain the customers
credit card information (the number and
expiration date).
39
Completing the Purchase (contd) So far, the
customer has 1. Verified the identity of the
merchant and the payment gateway. 2. Has prepared
an order form (OI). 3. Has prepared a separate
payment information document (PI). These are the
two documents that are input to the dual
signature process depicted on an earlier slide
and can create The PIMD, and OIMD (payment and
order digests). A concatenated PIMDOIMD and its
hash POMD. A signed version of the POMD by
encrypting the POMD with the users private
key. Now the customer can create a Purchase
Request.
40
Purchase Request Message
41
Purchase Request Message The PI, dual signature,
and OI Message Digest (OIMD) are combined into a
single message (block) and DES encrypted using a
one-time symmetric key producing an encrypted PI.
The DES key is encrypted using the payment
gateways public key (this is contained in the
envelope). This denies the merchant access to
the customers payment information (credit card
information) since only the gateways private
key will open the envelope. This information and
PIMD, OI, the dual signature, and the customers
X.509 certificate are sent back to the
merchant.
42
Merchant Information - From the Customer
Encrypted PI
Payment Information encrypted with a DES
key, unreadable by the merchant.
DES key encrypted with Payment servers public
key.
Envelope
PIMD
PI Message digest to ensure integrity of PI.
OI
Clear text Order Information.
Dual Signature for non-repudiation and integrity.
Dual Sig.
X.509
Customers X.509 Certificate.
43
Merchant Actions 1. Verify the customers
certificate with the CA. 2. Using OI, create
OIMD, concatenate with PIMD, hash, and verify
the result against the dual signature using the
customers public key. 3. Forward the Payment
information (encrypted PI envelope) to the
payment server (and get a response back
authorizing). 4. Process the order for
fulfillment and notify the customer to
acknowledge the order, delivery date, etc.
Customer notification is called Purchase
Response and is a message containing the unique
order number, signed by the merchant that cannot
be repudiated by the merchant. The customer can
validate this message with the merchants public
key.
44
Merchant Information - Customer to Merchant
Encrypted PI
Merchant cant use - encrypted with DES key.
Envelope
PIMD
POMD
Merchant can and does do these computations to
validate the POMD (Order Information).
OI
Hash
OIMD
COMPARE
Decrypt
Dual Sig.
POMD
X.509
Customers Public Key
45
Payment Info - Merchant to Payment Gateway
Encrypted PI
When decrypted includes the PI, dual signature,
and OIMD.
DES key to decrypt PI block above, encrypted with
the payment gateways public key - no merchant!
Envelope 1
Customer order number, signed with
Merchants private key, and encrypted with a DES
session key (notice - no order details)
Transaction Identifier
Envelope 2
DES session key to open the transaction ID,
encrypted with payment gateways public key.
Customers Certificate
Used to verify the dual signature.
Merchants Certificate
Used to verify the merchants signature.
46
Payment Gateway Actions 1. Verifies customer
Merchant certificates. 2. Decrypts the digital
envelope for the transaction identifier to get
the symmetric DES key and decrypt the
transaction identifier. 3. Verifies the
merchants digital signature on the transaction
id. 4. Decrypts the symmetric key on the purchase
information to get the symmetric DES key and
decrypt the purchase information (card ). 5.
Verifies the dual signature. 6. Verifies that the
transaction identifier supplied by the merchant
in 2 above matches the transaction identifier
supplied by the customer and contained in the
purchase information. 7. Requests and receives an
authorization from the customer card
issuer. Passing these tests, the payment
gateway issues an Authorization Response
message to the merchant.
47
Authorization Response - Gateway to Merchant 1.
Authorization Information - an authorization
block, signed with the payment gateways private
key and encrypted with a symmetric DES key
generated by the gateway. 2. An envelope
containing the symmetric key, encrypted with the
merchants public key-exchange key (not his
signing key). 3. Capture token - Same form as 1
2 above, a token signed with the payment
gateways private key and encrypted with a DES
key. 4. An envelope containing the symmetric key,
encrypted with the merchants public key (this
notifies the merchant that payment is authorized
and is a token used by the merchant to actually
request payment. 5. The payment gateways
signature key certificate.
48
Authorization Response - Graphically
Symmetric Key
Authorization Information
Authorization Information
This information is sent to the merchant from
the payment gateway.
Signature
Hash
Gateways Private Signing Key
Envelope 1
Merchants Public Exchange Key
Capture Token Information
Capture Token
Symmetric Key
Gateways Private Signing Key
Signature
Hash
Merchants Public Exchange Key
Gateways Certificate
Envelope 2
49

• Payment Capture - to the Merchant
• The merchant generates, signs, and encrypts a
  capture request
• block containing payment amount and transaction
  identifier, the
• capture token issued by the payment gateway, plus
  the merchants
• signature and key exchange certificates.
• 2. The payment gateways verifies the information
  and creates a
• clearing request that goes to the customers card
  issuer (bank).
• This cause funds to be transferred to the
  merchants bank. All of
• this goes over the payment network.
• 3. The gateway then notifies the merchant via a
  Capture Response,
• encrypted and signed, that the payment has been
  authorized. The
• merchant uses this information to reconcile
  payment when it
• arrives.

50
Summary - SET Characteristics 1. Application
layer protocol 2. Does not support choice in
cryptographic algorithms DES for
confidentiality RSA Digital Signature (signing
key exchange) SHA-1 Hash X.509, V 3
Certificates 3. Confidentiality privacy of
payment ordering information from third
parties, payment information is withheld from
merchants, order information is withheld from
financial institutions. 4. Integrity through the
use of Digital Signatures. 5. Authentication of
card holder and merchants with Digital
Signatures, certificates, and a registration
process. 6. Can operate over or on top of
other security protocols at lower layers in the
IP stack (e.g., IPSec).
51
SET Status SET is not being widely embraced or
implemented. SET is technically elegant, but
practically difficult. One problem is speed -
30-60 seconds for transaction processing. Protoco
l was code heavy in first release. Resistance on
the part of merchants - SSL is simpler,
easier. Some early supporters have abandoned SET
in favor of SSL.
52
Transport Layer Security Essentially an IETF
standards version of SSL. Current SSL version is
3.0, TLS 1.0 is effectively SSL version 3.1 Few
differences compared to SSL, but are enough that
TLS 1.0 SSL 3.0 are not interoperable Version
numbers are different, MAC algorithm is
different, TLS has more alert codes, does not
support Fortezza token encryption, and padding
is different. Other differences are not in
concepts, but in 1. TLS is not shimmed like
SSL, but is a part of the TCP layer. 2. It is an
open standard with the force of the IETF.
53
Transport Layer Security Defines standard ports
assigned by IANA for specific services. Uses TCP
as the transport protocol. Some of the ports
are Keyword Port Description https 433 http
protocol over TLS/SSL sshell 614 secure shell
over SSL ldaps 636 ldap protocol over
TLS/SSL ftps - data 989 ftp protocol - data over
TLS/SSL ftps 990 ftp protocol - control over
TLS/SSL telnets 992 telenet protocol over
TLS/SSL pop3s 995 pop3 protocol over
TLS/SSL NOTE Like all ports, a pair of systems
can negotiate any port pair for these services -
these are the assigned default ports.
54
Internet Protocol Security - IPSec A suite of
protocols documents providing security services
at the network layer.
RFC 2401
Architecture
RFC 2406
RFC 2402
Encapsulating Security Payload Protocol
Authentication Header
Encryption Algorithm(s)
Authentication Algorithm(s)
RFC 2405
RFC 2407
RFC 2104
Domain of Interpretation
Key Management
RFC 2409
55
IPSec - Documents Architecture - General
concepts, what it does, how it works,
requirements, definitions, processing
mechanisms. Domain of Interpretation - Naming
schemes, policy, syntax, relationships with other
documents. ESP/AH Protocols - Packet format,
padding, default values, any mandatory
algorithms. ESP/AH Algorithms - Specific
algorithms that can be implemented, multiple
documents, one per algorithm. Key Management -
How keys are created and exchanged.
56

• IPSec The Big Picture
• Internet Engineering Task Force (IETF) Standard
  for IPv4, IPv6
• Services Supported
• User/system authentication,
• Integrity,
• Confidentiality
• Access control
• Some protection against traffic analysis
• How?
• Establishes security associations (one at each
  end)
• Performs secure key exchange
• Negotiates services
• Performs data transfers (with integrity,
  confidentiality, etc.)

57
Security Associations Big Picture A database
on each end machine that holds policies that
apply to the device when using IPSec. For
example For IP address 130.54.230.0 use IDEA
encryption and SHA-1 for message
authentication. It is based on the policies of
the system (what encryption and/or hash
algorithms are used can be more than 1 for what
purpose). Requires that the rules between two
systems must be compatible or IPSec cant be
used. Database is called the Security Policy
Database.
58
Security Associations - Detail A security
association (SA) is a simplex connection that
defines security services for the flow over the
path. Thus, there are at least two (2)
associations per connection (i.e., A to B path
B to A path). An SA pair applies only to one
IPSec service (e.g., authentication) If only one
service is used (e.g., authentication) there are
2 SAs. If both authentication and encryption
services are being used, there are 4 SAs in use
(2 at each end). SAs are defined by a three
things A Security Parameter Index (SPI), a
pointer to the SA database entry for the SA
The IP destination address at the other end of
the association, and a security protocol
(authentication or encryption) identifier. Needed
to identify the keys, algorithms, etc. for a
particular flow.
59
Internet Protocol Security Standard
(IPSec) IPSec provides two primary
services IP Authentication IP Encapsulating
Security Payload (ESP) IP Authentication
provides authentication and integrity for an IP
payload, but not the entire datagram That is,
payload integrity and authentication is
protected, but the header fields that change are
not protected. IP encapsulation (ESP) protects
the confidentiality of the datagram in one of
two modes Transport mode Tunnel mode
60
Transport Tunnel Modes Transport Mode IP
Headers are sent in clear text, the payload is
encrypted (recall, the payload for IP is the TCP
protocol data unit which encapsulates the
application data) Tunnel Mode Both the IP
header and payload are encrypted. This means
another header must be pre-pended to the
encrypted header. Otherwise, routers in the
transmission path could not read the destination
address and make routing decisions. This header
is usually added at the network domain egress
point (e.g., at the network perimeter firewall
or gateway computer). This hides the identity of
the source computer (provides partial traffic
analysis protection).
61
IP Authentication Adds an authentication header
to the datagram in the options field.
IP Header
Authentication Header
Payload (TCP PDU)
Authentication is applied to the entire IP
datagram except for information that changes
during routing Hop count/Time-to-Live Identifi
cation Fragment Offset Since these change, they
would change authentication, so they are not
part of the authenticating calculation.
62
Authenticating Header - Format
Next Header
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable number of 32 bit
words)
Next header defines the type of header following
this header (this is typically a TCP
header). Length is the length of the
authentication header (used to calculate the
next header location). Reserved - is set to all
0s.
63
Authenticating Header - Format - Continued
Next Header
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable number of 32 bit
words)
SPI Pseudo-random number identifying the
security association to use (0 none, 1-255
reserved for IANA, others are available to be
used by anyone). Identifies the security
association for a flow set by the sender.
The association is one-way (e.g., flow from a
to b). The reverse flow, b to a, will have a
separately identified association. This
decouples key management methods from the
security protocols so multiple key management
methods could be used.
64
Authenticating Header - Format - Continued
Next Header
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable number of 32 bit
words)
Sequence Number Used to thwart re-play attacks.
Initialized to zero and incremented by 1 for
every packet sent, so 1st one sent 1. Never
allowed to exceed 231-1 (this would return the
value to 0 and allow for duplicates to appear -
receiver would not know if this was a legal
packet or a re-play duplicate. If 231 -1 packets
are sent, then a new security association (SPI)
must be negotiated using a new key.
65
Authenticating Header - Format - Continued
Next Header
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable number of 32 bit
words)
Authentication Data Data that authenticates this
packet. Holds a Value called the Integrity Check
Value (ICV). Is essentially a Message
Authenticating Code (MAC) calculated over the
packet including 1. IP header fields that do
not change in transit. 2. Authenticating header
except the Authentication data field. 3. The
entire IP payload (the higher level protocol
data, typically a TCP segment).
66
Authenticating Algorithms IPSec supports
multiple authenticating algorithms In all cases
uses an HMAC implementation. HMAC works like
any conventional signing system except is uses a
secret key to encrypt the hashed data. The HMAC
for IPSec is described in rfc 2104. IPSec
compliant systems require the following
algorithms/digests HMAC - MD5 - 96 (MD5 digest,
truncated to 96 bits) HMAC - SHA-1 - 96 (SHA-1
digest, truncated to 96 bits) 96 bits is the
default length of the Authentication Data
field Longer lengths can be used, but with
performance penalties.
67
Authenticating Modes - Transport
Tunnel Transport mode doesnt encrypt headers,
tunnel mode does. Transport Mode
Original IP Header
AH
TCP Header
Application Data
Authenticated, except for fields that change in
transit
Tunnel Mode
Application Data
TCP
Original IP Header
New IP Header
AH
Authenticated, except for fields that change in
the new IP header
Result In both cases, the entire packet (except
fields that change) are authenticated.
68
Encapsulating Security Payload (ESP) Provides
confidentiality of payload (message contents) and
limited traffic flow confidentiality, depending
on mode (transport/tunnel). Also can provide
same authentication service as Authenticating
Header That is Authentication can be over a
clear text datagram (no confidentiality
requirement), OR Over an encrypted datagram
(confidentiality requirement). If over
encrypted, then authentication is handled as a
part of ESP.
69
Encapsulating Security Payload - Datagram
Format SPI, Sequence , Authentication data are
AH related. Payload Pad, Pad Length, Next header
are encrypted. Padding accommodates different
encryption block lengths.
Security Parameters index (SPI)
Sequence Number
Payload Data
Pad
Next Header
Pad Length
Authentication Data
70
Encapsulating Security Payload -
Format Transport Mode
IP Hdr
ESP Hdr
TCP Hdr
Payload
ESP Trlr
ESP Auth
Encrypted
Authenticated
Tunnel Mode
New IP Hdr
ESP Hdr
Old IP Hdr
Payload
TCP Hdr
ESP Trlr
ESP Auth
Encrypted
Authenticated
71
Encapsulating Security Payload Transport mode is
end-to-end between two hosts that both
support ESP protected communications. The
security association is negotiated between these
two machines. Since IP header contains routing
information, it must be sent in clear text.
Therefore, traffic analysis is possible Tunnel
mode is used to avoid traffic analysis, but
requires a host external to the end-node (e.g.,
gateway, firewall, router), that can encrypt the
original datagram, header and all and attach a
new header with clear text network to network
routing information. So tunnel mode is between
two intermediaries operating in front of the end
hosts and the SA is between them.
72
ESP Security Associations The initial release
required DES in cipher block chaining (CBC)
mode. Other associations identified
include 3DES RC5 IDEA 3IDEA CAST Blowfish
Authentication uses the same algorithms as AH
(HMAC-MD5-96, HMAC-SHA-1-96)
73
IP Key Management IPSec disassociates key
determination and distribution from IPSec
itself. This can be done manually (e.g.,
face-to-face, courier) or automatically. If
automated, the framework for authentication key
exchange is Internet Security Association and
Key Management Protocol (ISAKMP). Protocol
support for key management, including formats
and negotiation of security attributes. Does not
define specific key exchanges, making many
possible. A couple of key exchange protocols are
Oakley (RFC 2412), and IKE (RFC 2409).
74
ISAKMP Protocol used to negotiate, modify, and
delete security associations. Uses well-defined
message formats that contain payloads for
exchanging key generation and authentication
data. Complex, because it supports most major
authentication and encryption methods in a very
generic framework. Not clear how successful it
will be given the complexity. Makes most other
security protocols look simple by comparison.
75
ISAKMP Messages
Initiator Cookie
Responder Cookie
Next Payload
MjVer
MnVer
Exchange Type
Flags
Message ID
Length
Cookies are as described in Oakley, Next payload
defines type of payload (how parsed). MjVer os
Major version , MnVer is minor version
. Exchange Type (Base, Identity, Authentication,
Aggressive, Informational) -how to use. Flags -
Options - encryption bit if all payloads are
encrypted, commit bit. Message ID - unique ID for
this message. Length - Of entire message
including all payloads (payloads follow unless
next payload is 0 ).
76
ISAKMP Message Types Security Association Used
to negotiate security attributes. Proposal
Indicates proposed protocol, of transforms
(e.g., ESP or AH, of encryption or
authentication methods). Transforms Indicates
transform to be used (e.g., 3DES). Key Exchange
Selects key exchange method (e.g., Oakley,
D-H). Identification Used to exchange ID
information (e.g., IP address). Certificate Used
to transport certificates (e.g., PGP,
X.509). Certificate Request Used to request
certificates (by type). Hash - Contains hashed
data to verify integrity or authenticate. Signatur
e - Contains signature data. Nonce - Contains
nonce data. Notification Used for notification,
like an alert, error, status, etc. Delete -
Indicates the security association in use is no
longer valid.
77
Oakley Key Determination Protocol Key
determination and exchange using modified
Diffie-Hellman Has same strengths as
Diffie-Hellman. Adds 1. Cookies to resist
clogging attacks. 2. Concept of groups (so
different algorithms can be used). 3. Nonces to
avoid re-play attacks. 4. Supports several key
exchange methods. 5. Authenticates to avoid
man-in-the-middle attacks.
78
Oakley Cookies An attacker forges a source
address and sends multiple public keys to a
victim - enough of these could clog the victims
system In Oakley, the first message is a cookie
exchange - each side sends a pseudo - random
number, the cookie, that is acknowledged and
repeated back to the source. If the source
address was forged, the forger would see no
message. Thus, a forger can force a victim to
acknowledge messages, but cannot force a victim
to start a Diffie-Hellman key computation. Requir
ement is that cookies cant be guessed done by
hashing the source/destination IP address and
port , and a secret value.
79
Oakley Groups Following Groups are
supported 1. Modular exponentiation with 728
bit modulus, fixed parameters. 2. Modular
exponentiation with 1024 bit modulus, fixed
parameters. 3. Modular exponentiation with 1024
bit modulus, parameters TBD. 4. Elliptic Curve
group over 2155, fixed parameters. 5. Elliptic
Curve group over 2185, fixed parameters.
80
Oakley Nonces Authentication Nonces - 3-way
exchange Source nonce1, Destinations
nonce1 reply, and nonce2, Source nonce 2
reply. Authentication 1. Digital Signature. 2.
Public Key Encryption. 3. Symmetric Key
Encryption (out-of-band key distribution).