Top Banner

Click here to load reader

Network Security Network Security Protocol 1 Network Security Chapter 3. Security and Layered Architecture

Jan 11, 2016

ReportDownload

Documents

Network Requirements*
Objectives
Provide certain amount of security.
Direct Sequence Spread Spectrum(DSSS)
Frequency Hopping Spread Spectrum(FHSS)
Security provided by these protocols stems from keeping the codes(chip sequence or frequency hopping sequence) secret.
The codes are not cryptographically protected
are usually well known or easy to figure out.
Keep out of the most casual of eavesdroppers.
Security at Layer 1
Point-to-Point Protocol(PPP)
used for connecting to the internet over phone line using modem.
< Authentication Model for Dial-In Internet Access>
Three entities :
Supplicant (user)
Security at layer 2
(2) Authentication Procedure
Authentication Server
DHCP Server
Network Security
PAP(password Authentication Protocol)
CHAP : challenge-response-based mechanism
Cheating CHAP (refer to handout )
When new protocol is developed, it should be registered to IANA(Internet Assigned Numbers Authority).
Also NAS should update software module to identity the new authentication protocol.
Idea :
EAP header : identify various authentication method
NAS do not process Authentication, instead relay EAP message to authentication server.
Authentication is processed between user and Authentication server
EAP-MD5, EAP-TSL is well known.
EAP(Extensible Authentication Protocol)
Network Security
just act as pass through agent for back-end authentication server.
Separation of authenticator and authentication server allows for higher flexibility and simple, low-cost authenticators.
Disadvantage
No mechanism to tie the two authentications together as part of a session.
Do not provide protection against a forged “EAP-success”
does not provide any mechanism to link the authentication procedure to the following session.
The EAP Architecture
*
802.1X : definition - “mechanism for port-based network access control that make use of the physical access characteristics of IEEE 802 LAN ….”
EAPoL : EAP over LAN
Authentication category :
establish security context such as session key : TLS and so on.
dose not establish security context : MD5, SHA and so on.
EAP-TLS
a premaster key.
see the documents.
Network Security
IPSec (Internet Protocol Security)
general IP Security mechanisms
key management
applicable to use over LANs, across public & private WANs, & for the Internet
Security at Layer 3 (IP network Layer)
Network Security
IPSec Services
Traffic flow confidentiality is the service that addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality.
Network Security
RFC 2401 - 2412 (1998)
RFC 4301 – 4309 (2005)
have two security header extensions:
Authentication Header (AH)
responsible for authentication and session key establishment between the two communicating parties.
AH(Authentication Header), ESP(Encapsulation Security Payload)
IP Header extensions are used for confidentiality, integrity, and authentication.
AH standard - 2402(1998), 4302(2005)
ESP standard – 2406(1998), 4303(2005)
Specifies completely all the cryptographic information required in one direction of communication
defined by 3 parameters:
Security Parameters Index (SPI)
other parameters
AH info : algorithm, Key, key lifetime
ESP info: encryption : algorithm, key, key lifetime
authentication : algorithm, key, key lifetime
Security Associations
Network Security
Sequence number starts at 1 and cannot go past 232-1
receiver keeps a window of min size 32 (64 preferred, larger is ok)
packets to left of window are discarded
repeated packets within window are discarded
authentic packets to right of window cause window to move right
Anti-Reply Mechanism
Network Security
can optionally provide the same authentication services as AH
supports range of ciphers, modes, padding
incl. DES, Triple-DES, RC5, IDEA, CAST etc
CBC & other modes
flow confidentiality
• Security Parameters Index (32 bits): Identifies a security association
• Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function ,as discussed for AH
• Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption
• Padding (0–255 bytes): for various reasons
• Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field
• Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload
• Authentication Data (variable): A variable-length field that contains the Integrity Check Value computed over the ESP packet minus
the Authentication Data field
Network Security
*
Authentication is applied to the entire packet, with the mutable fields(change hop-by-hop) in the IP header zeroed out
Data origin authentication, data integrity, reply prevention
If both ESP and AH are applied to a packet, AH follows ESP
Authentication Header (AH)
Combining Security Associations
The IPSec Architecture document lists four examples of combinations of SAs that must be supported by compliant IPSec hosts or security gateways.
Note the *’d devices in the figure implement IPSec.
The cases are:
Case 1 : security is provided between end systems that implement IPSec.
Case 2 : security is provided only between gateways (routers, firewalls ,etc.) and no hosts implement IPSec.
Case 3 : builds on Case 2 by adding end-to-end security. The same combinations discussed for cases 1 and 2 are allowed here.
Case 4 : provides support for a remote host that uses the Internet to reach an organization’s firewall and then to gain access to some server or workstation behind the firewall. Only tunnel mode is required between the remote host and the firewall.
Network Security
*
A mature, complex protocol for securely setting up keyed sessions, in particular IP-Sec SA.
Evolved over several years from multiple proposals; IKEv2 is now ‘draft standard` ( http://tools.ietf.org/html/rfc4306 )
Runs over UDP (port 500; detect NAT: 4500)
One IKE message per UDP datagram
Uses (only) exchanges (request/response)
Initiator (only) retransmits/aborts for reliability
Not necessarily client/server! But usually Alice is client.
Introduction to IKE
NAT/NAPT-friendly
What’s this?
*
Protect traffic of period i from exposure of all keys of all periods j≠i, as long as exposure happens after (refresh phase of) period i+1
Active adversary - can always inject/eavesdrop etc.
Motivation: attacker may eventually expose some old keys, by cryptanalysis, reading erased data,…
Strong (Perfect) Forward Security(PFS)
ISAKMP(Internet Security Association and Key Management Protocol) SA.
Authenticate computer identity
Algorithms, keys, etc. – to be used by IKE (not AH/ESP!)
Perfect forward secrecy (PFS)
Phase II : Generate IP-Sec SA
Establishes a secure channel between computers intended for the transmission of data.
Protected using the ISAKMP SA
Many 2nd phases may share ISAKMP SA (1st phase)
PFS optional
Network Security
Ensure reliable, secure separation of sessions
In particular prevent IP spoofing in ESP/Transport
Restrict use of a single key
Make cryptoanalysis harder
Less available ciphertext
(chosen/known plaintext)
Restrict damage of known key attack: session key exposure does not expose past or future messages, session keys, or master key
Strong (Perfect) Forward Secrecy (PFS)
Why derive many session keys?
Network Security
*
To fulfill the PFS requirement, every phase I exchange, performs a DH exchange
In phase II, DH execution is optional – phase II and the IPsec keys can be derived from phase I exchange
Phase II is more efficient
Many phase II exchanges can use the same set of phase I keys
Why derive different keys and not?
Why Two IKE Phases?
*
IKE DOS Attack: flood victim with IKE requests (fake source IP addr) victim performs expensive computations in vain
Solution : before performing expensive computations (e.g. DH), verify that the other party is indeed located in the IP address that appears in the header
How ? Cookies mechanism… (next)
exchange in IKEv2.
Network Security
*
The recipient sends a pseudo random string (Cookie) to the other party
The other party return the cookie, proving it can receive from its IP address
Compute cookie
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
<secret> : a randomly generated secret known only to the responder and periodically changed
<VersionIDofSecret> : should be changed whenever <secret> is regenerated.
Efficient generation, memory less verification
Expensive calculations will be performed, and state kept, only if valid cookie is received
The Cookies Mechanism
Exchange nonces
IKEv2 : IKE_SA_Init exchange
Exchange identities and certificates (encrypted for privacy – but client identity has weaker protection)
Exchange traffic selectors
Encrypted and authenticated (MAC) using SK { }
Like in ESP: encrypt then MAC; use keys SK_[a/e][i/r].
IKEv2: IKE_Auth exchange
*
IKE generates keying material using an ephemeral Diffie-Hellman exchange in order to gain the property of "perfect forward secrecy". This means that once a connection is closed and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the two endpoints cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space.
Achieving perfect forward secrecy requires that when a connection is closed, each endpoint
MUST forget not only the keys used by the connection but also any information that could be
used to recompute those keys. In particular, it MUST forget the secrets used in the Diffie-Hellman calculation and any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets. Since the computing of Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups. There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state.
Decisions as to whether and when to reuse Diffie-Hellman exponentials is a private decision in
the sense that it will not affect interoperability. An implementation that reuses exponentials MAY
choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation.
Reuse of Diffie-Hellman Exponentials
Secure Socket Layer(SSL)/Transport layer Security(TLS): incompatible but similar.
A protocol developed by Netscape for transmitting private documents via the Internet.
Sits between application layer and transport layer, so applications use SSL sockets.
Authenticate the communicating party and establish a session key.
By convention, URLs that require an SSL connection start with https: instead of http:
Security at Layer 4 : SSL/TLS
Network Security
Network Security
Session-Id used in TLS:
Become valid only when shaking is completed and persists until it is removed due to aging or session error.
The whole session messages are protected(signed hash) by the Finished message.
Can not be spoofed by a malicious Eve.
SSL/TLS Security
Network Security
TCP checks transmission error; not protected cryptographically.
SSL does not have API to tell vague packet to TCP
Scenario
Insert malicious data packet into a packet stream which is protected by SSL.
SSL drops the packet;
When real packet arrive, TCP will drop the packet since duplicate packet.
SSL is missing a packet it is expecting.
SSL close the connection after timeout. DoS attack!
SSL – DoS attack loop hole
Network Security
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.