Chapter 10: Network Security

1

• Chapter 10 Network Security
• Topics
• Overview
• Specific Protocols/Products
• 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) (also called IP
  tunneling).
• Data Link Layer Security (hardware/link
  encryption)

2
Placement of the Security Function There are two
prominent approaches to network security Data
Link Layer (DLL) security End-to-End
security DLL security protects messages
independently on each link of a
network. End-to-end security protects messages
all the way from the source to the
destination. There are some variations for
example, end-to-end may mean from a remote
computer to a gateway (e.g., a firewall) or
firewall-to-firewall). In the later case,
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
Application
Application
Protected
Transport
Transport
Network
Network
Data Link
Data Link
Application
Application
End-to-End Protected in routers and
other intermediate systems
Transport
Transport
Network
Network
Data Link
Data Link
Protected
4
Data Link Layer Encryption
Source
Destination
Connection points (telephone office)
Links
Links might be telephone lines, fiber cable,
microwave, satellite, etc. Each 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 message and protocol headers are
typically encrypted. Used in connection-oriented
traffic where there is no intermediate
processing (e.g., no routing). Examples Secure
telephones, wireless network radio link
(802.11), satellite pay television.
5
Data Link Layer Encryption Since entire message
and headers are protected no traffic
analysis. Keys are imbedded in devices -
requires key change method. Intermediate nodes
must be secure since messages are decrypted
and encrypted at each node. An adversary
controlling a node can read all the traffic. In
nodes subjected to high volumes of traffic,
cryptographic operation reduce maximum
throughput. In a complex network, 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 routed
public networks.
6
End-to-End Encryption The intent of end-to-end
security is to protect messages over the
entire path from source to destination. In
addition, to ensure that any compromise of an
intermediate node does not compromise the
message. End-to-end may mean different end
points such as Source to destination host or
process-to-process on end hosts. Firewall-to-fire
wall leaving firewall to end-host path
unprotected. Better suited for use in routed
networks with a mix of protected and unprotected
traffic than DLL protection. Wider range of
protection methods at different protocol layers.
7
Security The Layered Model Security can be
applied at any layer in the network layered
model Type Layer
Typical
Application Application proxies
Application PGP, PEM (mail) n/a
Presentation
n/a Session proxies Session
SSL, SOCKS Session proxies
Transport TLS,
Kerberos Packet filters Network
IPSec Packet filters
Data Link PPTP,
L2TP Packet filters Physical
Hardware Encryption Lower
layers are more generalized, protect all layers
above. Higher layers are more specialized, dont
protect lower layers.
8
Security - Placement of the Function All
placements can use the same (conceptually)
underlying mechanisms of authentication,
integrity, and confidentiality The scope of
coverage is significantly different depending on
the layer the security functionality is placed
in - by scope we mean what is protected. For
example, if we encrypt at the physical layer by
adding a crypto box between the computer and
transmission line, 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.
9
Major Placements of the Security Function
Scope
PGP
Application
Application
TLS
Scope
Transport
Transport
Network
Network
Application
Application
SSL
Scope
Session Layer
Transport
Scope
IPSec
Transport
Network
Network
Application - Unique to each application, PGP,
S/MIME, SSL - Multiple applications, but is
shimmed between application TCP (API per
application) TLS - Same as SSL, except integrated
into TCP stack IPSec, most generic, protects
everything encapsulated by IP
10
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
11
Secure Sockets Layer (SSL) Open systems
protocol, developed by Netscape Communications
and offered to the Internet Engineering Task
Force (IETFI. In IETF terms, it is known as
Transport Layer Security (TLS). Uses TCP as the
transport protocol. Primary purpose is to
conduct secure internet transaction
(e-commerce). Uses public key cryptography to
provide 4 basic services 1. Secret key Exchange
------ Public key encryption Diffie-Hellman 2.
Message privacy ------------ Secret key
encryption 3. Message integrity ----------- RSA
digital signature 4. Mutual 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.
12
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
13
Secure Sockets Layer (SSL) - Web Commerce
14
Secure Sockets Layer (SSL) 1. Browser access web
site, users 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 certificate as un-expired and valid for the
merchant. 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, except
that the user's credit card has been validated
for the purchase. There is no identity assurance
between the user and the card.
15
Secure Sockets Layer (SSL) SSL is capable of
supporting 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. SSL uses the
private key and message digest to ensure message
and authentication of source. Confidentiality
is provided by secret key exchange with the
secret key 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.
16
Secure Sockets Layer - Why Diffie-Hellman is
Supported 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.
17
SSL Applications Example given was web access to
support, for example, electronic commerce. SSL
can be used for many applications. The generic
architecture of SSL 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.
18
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.
19
SSL Handshake Protocol A. Agree on 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).
20
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.
21
SSL Record Protocol The workhorse - doing the
message encryption and MAC
Message
Fragment
Compress
Add MAC
Encrypt
Add SSL Header
Handed off to TCP for transmission
22
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
(when one side decides to close, then an
attacker attempts to continue with the other
side).
23
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 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. In each case, 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.
24

• 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.

25
Secure Electronic Transactions (SET) SET is a
protocol develop for Mastercard Visa to provide
very secure e-commerce transactions. Joint
specification development with participants
including IBM, Microsoft, Netscape, RSA Data
Security, Terisa, and VeriSign, circa 1996 (a
900 page document). SET is a set of protocols
and data formats intended to operate over
the Internet, interface with the existing
payment network while providing all the
encryption functionality of SSL plus several
important additional features. 1. Users and
merchants both hold certificates. 2. User
register with with the cardholder service
(bank) 3. One certificate per card is
required. 4. Merchants also register with a
cardholder service (bank).
26
Secure Electronic Transactions (SET)
27
Secure Electronic Transactions (SET) - The
Players 1. Two networks - The public Internet, a
private payment network. 2. Cardholder -
individual authorized by a financial institution
(the card issuer) to make transactions using the
card. 3. Merchant - willing to accept the card as
payment and is authorized by the acquirer and/or
financial institution to accept credit card
transactions. 4. Issuer - the financial
institution that issues the card. 5. Acquirer -
usually a financial institution or subsidiary
that establishes merchant accounts (i.e., the
merchants bank) and processes transaction
authorizations and payments. 6. Payment gateway
- System operated for/by acquirer to process
merchant payment notices and pass them to the
appropriate issuer. 7. Certificate Authority -
issues X.509 certificates for merchants, card
holders, payment gateways, and issuers
systems. This is a complex infrastructure!
28
Secure Electronic Transactions (SET) -
Requirements Card Issuer/Acquirer Proof that
the transaction was authorized by the card
holder Proof that the transaction was authorized
by the merchant Merchant Proof the the
transaction was authorized by the acquirer Proof
that the transaction was authorized by the card
holder Card Holder Proof the transaction was
authorized by the acquirer Proof the merchant is
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) Everyone is interested in ensuring
unauthorized payments are impossible
29
SET Transactions - Five Major Elements 1. Setup
- install software and enroll. Card issuers sets
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.
30
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 the dual signature.
31
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 provides for 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.
32
Dual Signature - Functional Generation
33
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 (continuing from our earlier step
3) Initiate Purchase Initiate Response Purchase
Request Purchase Response
34
Completing the Purchase Customer sends an
Initiate Request message to the merchant.
Requests the merchants certificate and the
certificate of the payment gateway used by the
merchant. It also contains the brand of the
credit card, a message identifier, and a time
stamp nonce. Merchant prepares an Initiate
Response message to the customer. A clear text
part contains the merchants X.509 certificate and
certificate of the merchants payment gateway.
The merchant signs a response containing the
customers nonce, another nonce generated by the
merchant, and a transaction identifier (a unique
order number). The customer verifies the
certificates with the CA and is now confident in
the identity of the merchant and the payment
server.
35
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
(, expiration date). 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). And is now ready to
complete the transaction. This is done by
creating a Purchase Request.
36
Purchase Request Message
37
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 shown as the
envelope). This denies the merchant access to the
customers payment information (credit card
information). This information and PIMD, OI, the
dual signature, and the customers X.509
certificate are sent back to the merchant.
38
Merchant Information - From the Customer
Encrypted PI
Payment Information encrypted with a DES
key, unreadable b the merchant
Envelope
DES Key encrypted with Payment servers public key
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
39
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 with the unique order
number, signed by the merchant that cannot
be repudiated by the merchant. The customer can
validate this message.
40
Merchant Information - From Customer -
Graphically
Encrypted PI
Merchant cant use - encrypted with DES key
Envelope
PIMD
POMD
OI
Hash
OIMD
COMPARE
Decrypt
Dual Sig.
POMD
X.509
Customers Public Key
41
Payment Information - From the Merchant to
Payment Gateway
Encrypted PI
When decrypted includes the PI, dual signature,
and OIMD
Contains 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 1
DES session key encrypted with payment
gateways public key
Customers Certificate
Used to verify the dual signature
Merchants Certificate
Used to verify the merchants signature
42
Payment Gateway Actions 1. Verifies customer
Merchant certificates. 2. Decrypts the digital
envelope for the transaction identifier to get
the symmetric key and decrypts the transaction
identifier. 3. Verifies the merchants digital
signature on the transaction identifier. 4.
Decrypts the symmetric key on the purchase
information to get the symmetric key and decrypts
the purchase information. 5. Verifies the dual
signature contained with the purchase
information. 6. Verifies that the transaction
identifier supplied by the merchant (2 above)
matches the transaction identifier supplied by
the customer (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.
43
Authorization Response - Information to the
Merchant 1. Authorization Information - an
authorization block, signed with the payment
gateways private key and encrypted with a
symmetric 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
symmetric 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.
44
Authorization Response - Graphically
Symmetric Key
Authorization Information
Authorization Information
This information is sent to the merchant.
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
45
Payment Capture - Capture Request ( to the
Merchant) 1. 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.
46
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 witheld from
financial institutions. 4. Integrity through the
use of Digital Signatures. 5. Authentication of
card holder with Digital Signatures
certificates. 6. Authentication of merchants
identity and authority to accept credit card
purchases from the card holder. 7. Can operate
over or on top of other security protocol at
lower layers in the IP stack.
47
SET Status SET is not being widely embraced or
implemented SET is technically elegant, but
practically difficult Big problem is speed -
30-60 seconds for transaction processing Protocol
is 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
48
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 Padding is
different Differences are not in concepts, but
in 1. Not shimmed, but a part of the TCP
layer. 2. The fact it is an open standard with
the forces of the IETF.
49
Transport Layer Security Defines standard ports
assigned by IANA for specific services. All use
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 port, a pair of systems
can negotiate any port pair for these services -
these are the assigned default ports.
50
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
51
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
52

• 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.)

53
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.
54
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). One 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). The SA is uniquely defined by a
triple A Security Parameter Index (SPI), a
pointer to the SA database entry 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.
55
Internet Protocol Security Standard
(IPSec) IPSec Primary Services are 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. Encapsulati
on (ESP) protects the confidentiality of the
datagram in one of two modes Transport
mode Tunnel mode
56
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).
57
IP Authentication Adds an authentication header
to the IP datagram in the options field
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
58
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.
59
Authenticating Header - Format - Continued
Next Header
Length
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data (Variable number of 32 bit
words)
Security Parameters Index (SPI). Pseudo-random
number identifying the security association being
used (0 none, 1-255 reserved for IANA use,
others are available to be used by anyone).
Identifies the security association for a flow
set by the sender. The association is
unidirectional (e.g., flow from a to b). The
reverse flow, b to a, will have a separately
identified association. Main reason for this is
to decouple key management mechanism from the
security protocols such that multiple key
management methods could be used.
60
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.
61
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 Authenticati
ng 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)
62
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
potential performance penalties.
63
Authenticating Modes - Transport Tunnel Recall
- 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
64
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 requiremen
t), OR Over an encrypted datagram
(confidentiality requirement). If over
encrypted, then authentication is handled as a
part of ESP.
65
Encapsulating Security Payload - Datagram
Format SPI, Sequence , Authentication data are
AH related Payload Data, Pad Length, Next header
are encrypted Padding accommodates different
encryption block lengths
Security Parameters index (SPI)
Sequence Number
Payload Data
Next Header
Pad Length
Authentication Data
66
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
67
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 some host external to the end-node
(e.g., gateway, firewall, router), that can
encrypt the original datagram, header and all
and then 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.
68
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)
69
IP Key Management IPSec disassociates key
determination and distribution from IPSec
itself. This can be done manually (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)
70
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.
71
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 )
72
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 used to verify integrity or
authenticate Signature - Contains signature
data Nonce - Contains nonce data Notification -
used to send notification, like an alert, error,
status, etc. Delete - Indicates the security
association in use is no longer valid
73
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.
74
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 local secret value.
75
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.
76
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)