Part of training program for datacom freshers.

1. WLAN and IP security
By
Chaitanya T K
E-mail: tkchaitanya@tataelxsi.co.in

2. Objectives:






Why Security is very important in
WLAN?
802.1x frame work
RADIUS server
Different security methods in WLAN
Why IPsec?
Understanding IPsec.

3. T here is nobody so ir ritating a
Don Herold

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

5. 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 WiFi access point. The Authenticator
encapsulates the EAP frames within
RADIUS.
Authentication server – a RADIUS server
with EAP capability EAPOL Frame Format



6. Port Based Access:

7. 802.1x handshakes:

8. 802.1x Over WLAN:

9. EAPOL Frame Format:

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

11. 
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

12. RADIUS datagram:

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

14. 802.1X and EAP message flow

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

16. Comparison of frames using
MIC with not using MIC:

17. Per-packet keying:

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

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

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

21. 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)



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

23. 



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 .

24. TLS Authentication process

25. EAP-TLS Authentication
process:

26. 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 serverside 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

27. PEAP handshakes:

28. PEAP Authentication
process:

29. 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."

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

31. Mathematics involved in
EAP-SPEKE








B = p2b
A = p2a
(MD)
K = Ba
ProofAK
mod m (AS)
mod m (m-large prime no)
mod m (MD)(K-master key)
= 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)

32. EAP-SPEKE Handshakes:

33. IP security:

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

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

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

37. 



The ability for devices to
negotiate the security algorithms
and keys required to meet their
security needs.
Two security modes,
Tunnel
Transport

38. IP-SEC Standards:

39. Framework For IPSEC:
1.
2.
3.
4.
They must agree on a set of security
protocols to use, so that each one
sends data in a format the other can
understand.
They must decide on a specific
encryption algorithm to use in
encoding data.
They must exchange keys that are used
to “unlock” data that has been
cryptographically encoded.
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.

40. Architecture of IP SEC:


AH: Origin,Data Integrity and
Replay attacks
ESP: Encrypts data

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

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

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

44. BITS architecture:

45. (BITW) Architecture:

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

47. Transport Mode:

48. Tunnel Mode:

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

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

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

52. 

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

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

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

55. IPV4 and IPv6:

56. IPV6 extension headers and
Order in packet:

57. AH Datagram Placement and
Linking (IPV6):

58. AH Datagram Placement and
Linking (IPV4):

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

60. AH Fields:

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

62. 


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.

63. Header Calculation and
Placement(IPV6):

64. Header Calculation and
Placement(IPV4):

65. Trailer Calculation:




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

66. ESP Format:

67. ESP fields:

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

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

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

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

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

73. The things that one most
wants to do are the things
that are probably most worth
doing.
Winifred Holtby , O Magazine,
September 2002