Embed Size (px)
DESCRIPTION
Part of training program for datacom freshers.
Citation preview
Objectives:
Why Security is very important in WLAN?
802.1x frame work RADIUS server Different security methods in WLAN Why IPsec? Understanding IPsec.
There is nobody so irritating as somebody with less intelligence and more sense than we have.
Don Herold
Wireless security:
There are 3 major elements in a wireless security
Authentication framework
E.g.:802.1x Authentication algorithm
E.g.:EAP Data encryption algorithm
E.g.:TKIP
802.1X:
Port-Based Network Access Control Supplicant – sits on a client device such as a laptop or PDA, the Supplicant is software that handles authentication from the client's point of view, it is also known as the Port Access Entity (PAE)
Authenticator – edge network device such as an access switch, router or Wi-Fi access point. The Authenticator encapsulates the EAP frames within RADIUS.
Authentication server – a RADIUS server with EAP capability EAPOL Frame Format
Port Based Access:
802.1x handshakes:
802.1x Over WLAN:
EAPOL Frame Format:
Remote Authentication Dial In User Service (RADIUS):
AAA management Authentication - A client sends a access request
to the network at link layer. This request contains user credentials or a user certificate. The authenticator packages this in RADIUS format as an Access Request message and forwards it on to a RADIUS server. The RADIUS server checks its user database for a match and then consequently decides whether or not to authenticate the user. The messages used are either Access Reject, Access Challenge (ask more information) or Access Accept.
Authorization - The RADIUS server stipulates the terms of access for the user i.e. what the user is permitted to do on the network.
Accounting - If user access statistics and information are required then RADIUS accounting is enabled by the Authenticator issuing an Accounting Start Request to the RADIUS server. Subsequent Interim Accounting Records may also be sent to indicate information such as the duration of the user session. Accounting is halted when an Accounting Stop Record is sent to the server.
The RADIUS protocol uses UDP ports 1812 for Authorization and 1813 for Accounting as standard. Originally these ports were 1645 for Authorization and 1646 for Accounting and are still used today, therefore RADIUS servers look
out for both sets of ports
RADIUS datagram:
EAP Cisco Authentication Algorithm:
It is very robust with these features
Mutual Authentication User based Authentication Dynamic WEP keys
(1key/client,re-authentication with timeouts)
802.1X and EAP message flow
Data privacy with TKIP
It is a modified form of WEP with all its weaknesses addressed,it has 3 important features
Message integrity check Per-packet keying Broadcast key rotation (No there is standard)
Comparison of frames using
MIC with not using MIC:
Per-packet keying:
Broadcast key rotation:
Employ a static broadcast key configured on the access point
Enable broadcast key rotation for dynamic broadcast key generation
a static broadcast key will go through the per-packet keying process. This reduces the opportunity for statistical key derivation attacks, but because the base broadcast key remains static, Statistical attacks may take much longer to execute, but they are still possible.
LEAP Authentication process It is secure enough to implement in a hostile wireless environment,it is a modified version of MS-CHAP.
It is a password based algorithm(MD4 hash of an MD4 hash of password (windows NT key)
This key is sent over the medium not the password /hash of password so security is enhanced
Windows logon is used as LEAP logon using a special software code in windows .
Re authentication and WEP key derivation follow a similar process.
Precautions in LEAP:
Usage of strong passwords Using MAC and LEAP authentication on different RADIUS servers
Use RADIUS session timeouts to rotate WEP keys
Deploy LEAP on a separate VLAN so that it wont effect the other users who require less security
EAP Authentication types:
EAP-TLS(DC) PEAP(password)
EAP-SPEKE(Random no.s) EAP-TTLS(only server side
authentication) EAP-SIM(thru GSM no need of NAI
and password)
TLS Overview:
TLS is designed to provide secure TCP/IP connection previously known as SSL.
It has three kinds of protocols Handshake protocol(Negotiation) Record protocol(secure tunnel) Alert protocol(error/session termination)
TLS has of 2 types authentication schemes
Server side authentication Client side authentication both make use PKI certificates for authentication and EAP-TLS uses client side certificates .
TLS Authentication process
EAP-TLS Authentication process:
PEAP:
PEAP employs server-side PKI authentication. For client-side authentication, PEAP can use any other EAP authentication type,Because PEAP establishes a secure tunnel via server-side authentication.
It is based on server side EAP-TLS it addresses the manageability and scalability problems of the EAP-TLS
No need for digital certificates in PEAP on the clients side (only authentication of server to client) so that protected method needs only to authenticate client
PEAP handshakes:
PEAP Authentication process:
EAP-TTLS Vs PEAP TTLS and PEAP are similar in concept, but there are important differences: TTLS supports other EAP authentication methods and also PAP, CHAP, MS-CHAP and MS-CHAPv2, whereas PEAP can tunnel only EAP-type protocol.
TTLS requires installation of client software, whereas PEAP comes ready to run in XP Service Pack 1 on the client device. TTLS is widely available and implemented, while PEAP is still new. But given PEAP's backing from Cisco, Microsoft and RSA, it's likely to emerge as the de facto authentication mechanism for 802.1x."
EAP-SPEKE: It uses a random looking messages exchanged between devices
To a third party observer SPEKE messages look like random numbers and they cant guess the password
There is no need for any other public private keys other than the password
It uses Zero knowledge Password Proof(ZKPP) and mutual authentication
Mathematics involved in EAP-SPEKE
B = p2b mod m (AS) A = p2a mod m (m-large prime no)(MD) K = Ba mod m (MD)(K-master key) ProofAK = h (“A” | A | K) (MD) K = Ab mod m (AS) TestAK = h (“A” | A | K) (AS)(MD Authentication)
ProofBK = h (“B” | B | K) (AS) TestBK = h (“B” | B | K) (MD)(AS Authentication)
EAP-SPEKE Handshakes:
IP security:
Why IP SEC?
Need for IP sec Initially to compensate for IP sec they used application layer security such as SSL for HTTP and FTP, but it cannot be generalized.
The technology that brings secure communications to the Internet Protocol is called IP Security, commonly abbreviated IPSec (The capitalization of this abbreviation is variable, so IPsec and IPSEC are also seen. Though not IpSeC or IPseC, fortunately. J)
Basically targeted at IPV6, but works for both IPV4 and IPV6
IP SEC and Application SEC:
Where to put security? Application security: – “really” secure (end-to-end) – applications must be modified ssh,sftp,https
Network (IP)-layer security (IPSec): – “general” security – applications remain unchanged – applications must rely on “lower” security
Functionality:
IPSec is not a single protocol, but rather a set of services and protocols that provide a complete security solution for an IP network
Functionality: Encryption of user data for privacy. Authentication of the integrity of a message to ensure that it is not changed en route.
Protection against certain types of security attacks, such as replay attacks.
The ability for devices to negotiate the security algorithms and keys required to meet their security needs.
Two security modes, Tunnel Transport
IP-SEC Standards:
Framework For IPSEC:
1. They must agree on a set of security protocols to use, so that each one sends data in a format the other can understand.
2. They must decide on a specific encryption algorithm to use in encoding data.
3. They must exchange keys that are used to “unlock” data that has been cryptographically encoded.
4. Once this background work is completed, each device must use the protocols, methods and keys previously agreed upon to encode data and send it across the network.
Architecture of IP SEC:
AH: Origin,Data Integrity and Replay attacks
ESP: Encrypts data
Supported Encryption/Hashing Algorithms: Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1).
Security Policies and Associations, and Management Methods: security policies and security associations, and by providing ways to exchange security association information
Key Exchange Framework and Mechanism: To exchange security association information. Internet Key Exchange (IKE) provides these capabilities.
IPSec Implementation Methods:
IPSec Implementation Methods defined in RFC 2401, depends of Version(4/6),application….
End Host Implementation - End to End security - Deployment issues Router Implementation - Secure only outside network - Ease of Installment
IPSec Architectures:
Integrated Architecture -Integrate directly into IP -Preferable for IPV6 but not for IPV4 “Bump In The Stack” (BITS) Architecture -Extra layer after IP -Suitable for IPV4 “Bump In The Wire” (BITW) Architecture -Adding a separate IP sec device for all the traffic
-complexity and cost.
BITS architecture:
(BITW) Architecture:
IP Sec Modes:
Transport and Tunnel Modes The choice of mode does not affect the method by which each generates its header, but rather, changes what specific parts of the IP datagram are protected and how the headers are arranged to accomplish this.
In essence, the mode really describes, not prescribes how AH or ESP do their thing.
It is used as the basis for defining other constructs, such as security associations (SAs).
Transport Mode:
Tunnel Mode:
Simple Overview: Parameters for encryption and AH field are agreed upon in the SA
ESP field indicates the identity of the SA and carried additional
information for decoding the payload AH field is created using the payload (and ESP, if present)
Terminology in IP sec: Security Policies - How to treat a incoming packet - Security Policy Database (SPD). Security Associations -secure connection between one device and another
-Security Association Database (SAD). - Unidirectional Selectors - Helps to choose a SA based on certain rules
Selector fields: Five basic types: Destination IP address (Different from destination
IP address of SA identifier tuple) - Single (unicast, anycast, broadcast, multicast),
range, address+mask, wildcard - Obtained from inner IP header for tunnel mode SA Source IP address (separate for inbound & outbound) - Single (unicast, anycast, broadcast, multicast),
range, address+mask, wildcard Name - User id (fully qualified user name, X.500
distinguished name) - System name (fully qualified DNS name, X.500
distinguished/or general name)
Transport layer protocol
- IPv4: ‘Protocol’ field, IPv6: ‘Next Header’ field
- These fields may not contain TP due to the presence of routing header,
- AH, ESP, fragmentation header, destination option etc.
Source and Destination ports
- If the packet is fragmented, discard it
Security associations: Security associations don't actually have names, however. They are instead defined by a set of three parameters, called a triple:
Security Parameter Index (SPI): -32-bit number that is chosen to uniquely identify a particular SA for any connected device
IP Destination Address: -The address of the device for whom the SA is established.
Security Protocol Identifier: -Specifies whether this association is for AH or ESP. If both are in use with this device they have separate SAs.
IPSec Authentication Header
(AH):
Similar to CRC but uses Hashing (using key) algorithm
On the source device, AH performs the computation and puts the result (called the Integrity Check Value or ICV) into a special header with other fields for transmission
the ICV calculation does not change the original data
AH provides authentication but not privacy (that's what ESP is for
IPV4 and IPv6:
IPV6 extension headers and Order in packet:
AH Datagram Placement and
Linking (IPV6):
AH Datagram Placement and Linking (IPV4):
AH Format:
The size of the Authentication Data field is variable to support different datagram lengths and hashing algorithms.
Its total length must be a multiple of 32 bits. Also, the entire header must be a multiple of either 32 bits (for IPv4) or 64 bits (for IPv6).
Padding and No IP addresses appear
AH Fields:
IPSec Encapsulating Security Payload (ESP)
Encapsulating Security Payload Fields: ESP Header: This contains two fields, the SPI and Sequence Number, and comes before the encrypted data
ESP Trailer: - Placed after the encrypted data. - Padding that is used to align the encrypted data, through a Padding and Pad Length field.
- Interestingly, it also contains the Next Header field for ESP.
ESP Authentication Data: This field contains an Integrity Check Value (ICV), computed in a manner similar to how the AH protocol works, for when ESP's optional authentication feature is used.
Some encryption algorithms require the data to be encrypted to have a certain block size, and so padding must appear after the data hence appears in the ESP Trailer.
ESP Authentication Data it is used to authenticate the rest of the encrypted datagram after encryption. This means it cannot appear in the ESP Header or ESP Trailer.
Header Calculation and Placement(IPV6):
Header Calculation and Placement(IPV4):
ESP trailer is added, then encryption is carried from ESP header(excluding) to ESP trailer (including).
ESP Authentication Field Calculation and Placement: If the optional ESP authentication feature is used, the authentication field is computed over the entire ESP datagram (except the Authentication Data field itself, of course). This includes the ESP header, payload and trailer.
Padding is also used to make sure that the ESP Trailer ends on a 32-bit boundary. That is, the size of the ESP Header plus Payload plus ESP Trailer must be a multiple of 32 bits.
The ESP Authentication Data must also be a multiple of 32 bits
Trailer Calculation:
ESP Format:
ESP fields:
IPSec Key Exchange (IKE) “shared secret”. Anyone who isn't “in” on the secret is able to intercept the information but is prevented either from reading it (if ESP is used to encrypt the payload) or from tampering with it undetected (if AH is used).
The primary support protocol used for this purpose in IPSec is called Internet Key Exchange (IKE) (RFC 2049)
IKE works by allowing IPSec-capable devices to exchange security associations (SAs), to populate their security association databases (SADs). These are then used for the actual exchange of secured datagrams with the AH and ESP protocols.
ISAKMP: Internet Security Association and Key
Management Protocol Frame work for IKE In IKE, the ISAKMP framework is used as the
basis for a specific key exchange method that combines features from two key exchange protocols:
OAKLEY: Describes a specific mechanism for exchanging keys through the definition of various key exchange “modes”. Most of the IKE key exchange process is based on OAKLEY.
SKEME: Describes a different key exchange mechanism than OAKLEY. IKE uses some features from SKEME, including its method of public key encryption and its fast re-keying feature.
ISAKMP Phase negotiations: ISAKMP Phase 1: The first phase is a “setup”
stage where two devices agree on how to exchange further information securely. This negotiation between the two units creates a security association for ISAKMP itself; an ISAKMP SA. This security association is then used for securely exchanging more detailed information in Phase 2.
ISAKMP Phase 2: In this phase the ISAKMP SA established in Phase 1 is used to create SAs for other security protocols. Normally, this is where the parameters for the “real” SAs for the AH and ESP protocols would be negotiated.
Phase-1 Negotiations:
An encryption algorithm to be used, such as the Data Encryption Standard (DES).
A hash algorithm (MD5 or SHA, as used by AH or ESP). An authentication method, such as authentication
using previously shared keys. A Diffie-Hellman group: In this method, instead of
encrypting and decrypting with the same key, data is encrypted using a public key knowable to anyone, and decrypted using a private key that is kept secret.
Note that even though security associations in general are unidirectional, the ISAKMP SA is established bi-directionally. Once Phase 1 is complete, then, either device can set up a subsequent SA for AH or ESP using it.
Diffie-Hellman Algorithm: Peers P and Peer Q have been given the same
publicly viewable numbers m and n. Peer P picks a very large secret random number
x and calculates mxmod n to give P. Peer Q picks a very large secret random number
y and calculates mymod n to give Q. Peer P and Peer Q exchange P and Q publicly,
so anyone can see these numbers. The numbers x and y remain known only to the relevant peer and they are not transmitted.
Peer P then performs the calculation Qxmod n to give the value K.
Peer Q then performs the calculation Pymod n to give the value L.
K=Qxmod n = mxymod n =Pymod n =L, so K and L are equal, therefore Peers P and Q have negotiated a shared secret that has not been transmitted.
The things that one most wants to do are the things that are probably most worth doing.
Winifred Holtby, O Magazine, September 2002
