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 Approaches Da
ta Link Layer (DLL) security End-to-End
security DLL security protects messages
independently on each link of a
network. End-to-end is from source to the
destination. Variations end-to-end from a
computer to a gateway (e.g., a
firewall)/firewall-to-firewall). Traffic is
protected between the firewalls, not protected
between the firewall and the host (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, microwave,
satellite. Link is encrypted. Different keys are
used on each link so loss of one link does not
affect all. Stream ciphers are typical 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 - means
key change. Middle 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 End-to-end security
protects messages over the entire path from
source to destination. Ensures that any
compromise of an intermediate node does not
compromise the message. However, remember that
the clear text exists at the two ends points. A
compromise gives clear text access to the
adversary (think sniffer). Can be implemented
with a wide range of protection methods at
different protocol layers.
8
Gateway to Gateway Encryption Variation on
end-to-end. End point may be Firewall-to-firewal
l 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 Appl
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 mechanisms for
authentication, integrity, and confidentiality. W
hat is protected is different depending on the
layer the security is placed in. For
example Encrypting at the physical layer means
everything is encrypted - also means we
must Use dedicated lines with no intermediate
routing. Have 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 Application unique PGP, S/MIME.
SSL - Multiple applications, shimmed between
appl. and TCP (API per application). TLS - Same
as SSL, except integrated into TCP stack. IPSec -
Generic, protects everything encapsulated by IP.
12
Security - Generalized Model
Establishes connections, negotiates
algorithms. Manages keys, exchanges. Authentica
tes users, systems, and/or messages. Encrypts
authenticators and/or payloads.
Information Exchange
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) as an
Internet standard. IETF made minor changes,
called it Transport Layer Security (TLS) and
adopted it. Now is 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 for 4 services Secret key
Exchange - Public key encryption
Diffie-Hellman exchange Message privacy ---
Secret key encryption Message integrity --
RSA digital signature Authentication ----
X.509 certificates and
digital signature Provides security
at the session layer and is used for many
applications, including 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
SSL - Web Commerce
17

• Secure Sockets Layer (SSL)
• User browses web, 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.

18
Secure Sockets Layer (SSL) 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 is 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.
19
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.
20
Secure Sockets Layer (SSL) 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. It is not common for the user to
hold a certificate, But the capability is
supported by the basic technology of SSL.
21
Secure Sockets Layer - Why Diffie-Hellman? Diffie
-Hellman is a method of secret key exchange that
does not require the use of certificates. Instea
d, 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.
22
SSL Applications SSL supports many applications.
Architecture is
Handshake
Change Cipher
Alert
SSL Record Protocol
TCP
IP
SSL at the application layer provides 3 different
functions, all using a common underlying record
structure. SSL uses TCP for reliable transport.
23
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 exchanges between the client
and server.
24
SSL Handshake Protocol Agree on SSL version
(version 3 is current). Agree on algorithms
(encryption, MAC, compression). Optionally
authenticate each other (exchange
certificates) Use public keys to generate a
shared secret key.
25
SSL Handshake Protocol Client authentication
and key exchange. If no certificate is available
for client authentication, an ALERT message is
sent. Finish - completes the secure
connection At end, two shared secret keys have
been negotiated, one for encryption and one for
encrypting the message authentication code
(MAC).
26
SSL - Cipher Suites 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
export control limitations - now been lifted.
27
SSL Record Protocol Does the message encryption
and MAC
Message
Fragment
Compress
Add MAC
Encrypt
Handed off to TCP for transmission
Add SSL Header
28
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 notifies the peer of alerts such
as Decompression or handshake failure. Illegal
parameters. Certificate problem
no/bad/expired/revoked/ Unknown/unsupported. Close
notification (this is the last message).
29
SSL Change Cipher Spec Alert Protocols Close
notification is an alert message requiring
action to confirm the close to avoid truncation
Attacks. A truncation attack is where one side
decides to close and an attacker attempts to
continue with the other side.
30
SSL - Summary Robust, and widely used, but can
be hacked. dsniff 2.3, man-in-the-middle SSL
hack. The intruder must be in the path between
a client server, or fool the user into
connecting to the intruder instead of the
intended server, or Do arp spoofing to re-direct
the connection between the user and server.
31
SSL - dsniff For dsniff, the result is that the
intruder is inserted between the user and the
real server and proxies all traffic while reading
everything that goes by including passwords,
credit card numbers, etc. Minimal risk of being
in the path. Arp spoofing also requires being in
the path and is difficult.
32
SSL Hack That leaves fooling the user. This can
be avoided Insure the site in the browser bar
is the site you wanted. Check the SSL
certificate to ensure its the right site and is
from a known CA, like Verisign. Like any other
security method, if the machine you are on is
root compromised, every I/O character can be
captured,stored, and analyzed looking for
usernames, passwords, passphrases to access
keys, etc.
33
Secure Electronic Transactions (SET) SET is a
protocol develop for Mastercard Visa for very
secure e-commerce transactions. Joint
development with IBM, Microsoft, Netscape, RSA
Data Security, Terisa, and VeriSign, circa 1996
(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.
34
SET 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).
35
SET Architecture
36
SET - The Players Two networks Public
Internet, private payment network. Cardholders
Individuals authorized by a financial
institution (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.
37
SET - The Players 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.
38
SET Requirements/Needs Card
Issuer/Acquirer Proof transactions were
authorized by card holder. Proof transactions
were authorized by merchant. Merchant Proof
transactions were authorized by acquirer. Proof
transactions were authorized by card holder.
39
SET - Requirements Card Holder Proof
transactions were authorized by acquirer. Proof
merchants are authorized by acquirer. Proof of
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!
40
SET Transactions - Five Major Elements Setup/Init
ialization Install software and
enroll. Browsing Shopping for
purchases. Purchase Request Ordering
goods. Payment authorization Confirming payment
is authorized by card issuer. Payment capture -
finalizing the order payment information.
41
SET Transactions - Setup Setup - install
software and enroll. Card issuers set up a
Certificate Authority. Merchants enroll in the CA
payment system. Customers enroll in the CA
payment system. On acceptance, the CA issues
X.509 certificates and the public key of the
CA. Merchants also need the public key of the
payment server. Both the merchant and customer
require client software.
42
SET Transactions - Browsing Browsing - shopping
for purchases. Customer browses the merchants
site and puts items in a shopping cart -
completing the merchants order form.
43
SET Transactions Purchase Request
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.
44
SET Transactions Last Two Steps
Payment authorization - confirming payment is
authorized. Payment capture - finalizing the
order payment to the merchant. Before
discussing them, we need to look at a capability
called the dual signature.
45
SET - Dual Signature Similar to Digital
Signature for authentication/ non-repudiation. Bu
t, with a significant difference Uses a dual
Signature that 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).
46
SET - Dual Signature - Purpose Allows the
merchant to view the Order Information (OI) to
fulfill the order, but blocks the merchant from
viewing the Payment Information (PI). This
keeps the credit card information out of the
hands of the merchant and keeps the
order information away from the bank . The link
between signatures ties orders to payments if
there is any need to settle disputes.
47
Dual Signature - Functional Generation
48
Dual Signature - What it Does Fixes customers
digital signature over the entire PI and OI
package of information provides
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 provides assurance of
integrity of contents.
49
Dual Signature Further Needs Signatures are
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 Request Initiate Response Purchase
Request Purchase Response
50
Initiate Purchase Request Customer sends an
Initiate Purchase 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.
51
Initiate Response Merchant responds to
Initiate Purchase Request 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.
52
Completing the Purchase 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.
53
Completing the Purchase (contd) 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).
54
Completing the Purchase (contd) So far, the
customer has Verified the identity of the
merchant and the payment gateway. Has prepared
an order form (OI). 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.
55
Completing the Purchase (contd) The dual
signature process creates The PIMD, and OIMD
(payment/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.
56
Dual Signature - Recap
57
Purchase Request Message
58
Purchase Request Message The PI, dual signature,
and OI Message Digest 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 with the payment gateways
public key (contained in the envelope). This
denies merchant access to the customers payment
information (credit card) since only the
gateways private key will open the envelope.
59
Purchase Request Message This information and
PIMD, OI, the dual signature, and the customers
X.509 certificate are sent back to the
merchant. The next slide shows the information
sent to the merchant
60
Merchant Information - From the Customer
Encrypted PI
PI encrypted using DES key, unreadable by
merchant.
DES key encrypted with Payment servers public
key.
Envelope
PI Message digest (integrity of PI).
PIMD
OI
Clear text Order Information.
Dual Sig non-repudiation/integrity.
Dual Sig.
Customers X.509 Certificate.
X.509
61
Merchant Actions Verify the customers
certificate with the CA. Using OI, create OIMD,
concatenate with PIMD, hash, and verify the
result against the dual signature using the
customers public key. Forward the PI (encrypted
PI envelope) to the payment server (get back
response authorizing). Process the order and
notify the customer to acknowledge the order,
delivery date, etc.
62
Merchant Actions Customer notification is
called Purchase Response and is a message
containing the unique order number, signed by
the merchant . Provides non-repudiation of the
merchant. The customer can validate this
message with the merchants public key.
63
Customer to Merchant Information
Encrypted PI
Merchant cant use - encrypted with DES key.
Envelope
PIMD
POMD
Merchant does these to validate the POMD
(Order Information).
OI
Hash
OIMD
COMPARE
Decrypt
Dual Sig.
POMD
X.509
Customers Public Key
64
Merchant to Payment Gateway
Encrypted PI
When decrypted includes the PI, dual signature,
and OIMD (Can be done by PG).
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.
65
Payment Gateway Actions Verifies customer
Merchant certificates. Decrypts the digital
envelope for the transaction identifier to get
the symmetric DES key and decrypt the
transaction identifier. Verifies the merchants
digital signature on the transaction
id. Decrypts the symmetric key on the PI to get
the symmetric DES key and decrypt the purchase
information (card ).
66
Payment Gateway Actions Verifies the dual
signature. Verifies that the transaction
identifier supplied by the merchant matches the
transaction identifier supplied by the customer
and contained in the purchase information. Reque
sts and receives an authorization from the
customer card issuer. Passing these tests, the
payment gateway issues an Authorization
Response message to the merchant.
67
Authorization Response to Merchant Authorization
Information - a block, signed with the payment
gateways private key and encrypted with a
symmetric DES key generated by the gateway. An
envelope containing the symmetric key, encrypted
with the merchants public key- exchange key (not
his signing key).
68
Authorization Response to Merchant Capture token
- Same form as above, a token signed with the
payment gateways private key and encrypted with
a DES key. 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. The payment
gateways signature key certificate.
69
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
70
Payment Capture - to the Merchant 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. The
payment gateway verifies the information and
creates a clearing request that goes to the
customers card issuer (bank) causing funds to
be transferred to the merchants bank.
71
Payment Capture - to the Merchant Information
between customer and merchant uses the Internet.
Information between merchant and payment
gateway uses the payment network. The gateway
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.
72
Summary - SET Characteristics Application layer
protocol No choice in cryptographic algorithms
DES for confidentiality RSA Digital Signature
(signing key exchange) SHA-1 Hash X.509, V
3 Certificates Confidentiality privacy of
payment ordering information from third
parties, payment information is withheld from
merchants, order information is withheld from
financial institutions.
73
Summary - SET Characteristics Integrity through
the use of Digital Signatures. Authentication of
card holder and merchants with Digital
Signatures, certificates, and a registration
process. Can operate over or on top of other
security protocols at lower layers in the IP
stack (e.g., IPSec).
74
SET Status Not widely embraced or
implemented. Technically elegant, but
practically difficult. Speed - 30-60 seconds per
transaction. Protocol was code heavy in first
release. Merchants have resisted - SSL is
simpler/easier. Some early supporters have
abandoned SET in favor of SSL.
75
Transport Layer Security An IETF standards
version of SSL. Current SSL version is 3.0, TLS
1.0 is SSL version 3.1 Few differences compared
to SSL, but are enough that TLS 1.0 SSL 3.0
dont interoperate Version numbers are
different, MAC algorithm is different, TLS has
more alert codes, does not support Fortezza
token encryption, and padding is
different. TLS is not shimmed, is a part of the
TCP layer. Open standard with the force of the
IETF.
76
Transport Layer Security Ports assigned by IANA
for specific services. Uses TCP for transport.
Some of the ports are Keyword Port Description h
ttps 433 http protocol over TLS/SSL sshell 614 sec
ure shell over SSL ldaps 636 ldap protocol over
TLS/SSL ftps - data989 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
77
Internet Protocol Security - IPSec Protocols
providing security at 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
78
IPSec - Documents Architecture - Concepts, what
it does, how it works, requirements,
definitions, mechanisms. Domain of
Interpretation - Naming schemes, policy, syntax,
fit with other documents. ESP/AH Protocols -
Packet format, padding, default values,
mandatory algorithms. ESP/AH Algorithms -
Specific algorithms that can be implemented, one
document per algorithm. Key Management - Keys
creation/use.
79

• IPSec IETF Standard
• Services Supported
• User/system authentication,
• Integrity,
• Confidentiality
• Access control
• Some protection against traffic analysis
• How?
• Security associations (one at each end)
• Performs secure key exchange
• Negotiates services
• Data transfers (integrity, confidentiality)

80
Security Associations Big Picture Database on
each end machine holding policies that apply to
the device when using IPSec. Example For IP
address 130.54.230.0 use IDEA encryption and
SHA-1 for message authentication. Content is
based on system policies (what encryption and/or
hash algorithms are used can be more than 1
). Requires that the rules between two systems
must be compatible or IPSec cant be
used. Database is called the Security Policy
Database.
81
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). For one
service there are 2 SAs. If both authentication
and encryption services are being used, there
are 4 SAs in use (2 at each end).
82
Security Associations - Detail SAs are defined
by a three things A Security Parameter Index
(SPI), that is 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.
83
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
84
Transport Mode 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). Means the port (application id) is
hidden, but The source and destination addresses
are not.
85
Transport Tunnel Modes 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).
This hides the identity of the source computer
(provides partial traffic analysis protection).
86
IP Authentication Adds authentication header 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.
87
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.
88
Authenticating Header - 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 (0 none, 1-255 reserved
for IANA, others are available to 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 different association. This
decouples key management methods from security
protocols so multiple key management methods
could be used.
89
Authenticating Header - 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, 1st one 1. Not allowed to
exceed 231-1 (this would return the value to 0
and allow duplicates - 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.
90
Authenticating Header - Continued
Next Header
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable number of 32 bit
words)
Authentication Data Holds a value called the
Integrity Check Value (ICV). Is essentially a
MAC calculated over the packet including 1. IP
header fields that do not change in transit. 2.
Authenticating header, but not data field. 3. The
entire IP payload (the higher level protocol
data, typically a TCP segment).
91
Authenticating Algorithms IPSec supports
multiple authenticating algorithms All cases
use an HMAC implementation. HMAC works like a
conventional signing system except is uses a
secret key to encrypt the hashed data. HMAC for
IPSec is described in rfc 2104. IPSec compliant
systems require HMAC - MD5 - 96 (MD5 digest,
truncated to 96 bits) HMAC - SHA-1 - 96 (SHA-1
digest, truncated to 96 bits) 96 bits default
length of the Authentication Data field Longer
lengths can be used, but with performance
penalties.
92
Authenticating Modes - Transport
Tunnel Transport mode doesnt encrypt headers,
tunnel 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) is authenticated.
93
Encapsulating Security Payload (ESP) Provides
confidentiality of payload (message contents) and
limited traffic flow confidentiality, mode
dependent . 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
needed). If over encrypted, then authentication
is handled as a part of ESP.
94
ESP - Datagram Format SPI, Sequence ,
Authentication data are AH related. Payload Pad,
Pad Length, Next header are encrypted. Padding
allows different encryption block lengths.
Security Parameters index (SPI)
Sequence Number
Payload Data
Pad
Next Header
Pad Length
Authentication Data
95
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
96
Encapsulating Security Payload Transport mode is
end-to-end between two hosts that both support
ESP protected communications. The SA is
negotiated between these two machines. As IP
header contains routing information, it must be
sent in clear text. Therefore, traffic analysis
is possible Tunnel mode avoids traffic analysis,
but requires a host external to the end-node
(e.g., firewall), that can encrypt original
datagram, header and attach a new header with
clear text network to network routing
information. Tunnel mode is between two
intermediaries operating in front of the end
hosts and the SA is between them.
97
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)
98
IP Key Management IPSec disassociates key
determination and distribution from IPSec. 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 Key
Management Protocol (ISAKMP). Protocol supports
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).
99
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.
100
ISAKMP Messages
Initiator Cookie
Responder Cookie
Next Payload
MjVer
MnVer
Exchange Type
Flags
Message ID
Length
Cookies (later), Next payload defines type of
payload. MjVer is Major version , MnVer is minor
version . Exchange (Base, Id, Auth, Aggressive,
Informational) -how to use. Flags - Options -
encryption bit if payloads are encrypted, commit
bit. Message ID - unique ID for this
message. Length - Of message including all
payloads.
101
ISAKMP Message Types Security Association
Negotiate security attributes. Proposal
Proposed protocol, of transforms (e.g., ESP or
AH, of encryption or authentication
methods). Transforms Transform to be used
(e.g., 3DES). Key Exchange Key exchange used
(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).
102
ISAKMP Message Types Certificate Request
Request certificates (by type). Hash - Contains
hashed data to verify integrity or
authenticate. Signature - 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.
103
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 other
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.
104
Oakley Cookies Assume an attacker forges a
source address and sends multiple public keys to
a victim - enough of these could clog the
victims system. This is a denial of service
attack. 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.
105
Oakley Cookies 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. Requirement is that cookies
cant be guessed done by hashing the
source/destination IP address and port , and a
secret value.
106
Oakley Groups Following Groups are
supported Modular exponentiation with 728/1024
bit modulus, fixed parameters. Modular
exponentiation with 1024 bit modulus, parameters
TBD. Elliptic Curve group over 2155, fixed
parameters. Elliptic Curve group over 2185,
fixed parameters.
107
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).
108
IPsec Summary IPsec is a robust suite of
protocols, but is not widely embraced. Main
problem is processing speed and very cumbersome
code especially key management. Requires a
client on every machine. SSL does not Since the
code is in the browser. IPv6 will help since
IPsec is required it is not Required in IPv4.