1
Q
Wired Equivalent Privacy (WEP)
A
- found to be weak and easily breakable
2
Q
Wi-Fi Protected Access 2 (WPA2)
A
- current 802.11i security standard
- provides support for IEEE 802.11n/ac, which WPA did not
3
Q
WPA2 Personal Mode
A
1) uses WPA2-PSK (pre-shared key) authentication, a common key is statically configured on the client and the AP
2) Designed for environments where there is no RADIUS authentication server
3) Provides inadequate security for an enterprise wireless network; if attackers break the WPA2 PSK, then they can access all device data
4) Often authenticates devices, not users
4
Q
WPA2 Enterprise Mode
A
1) Uses IEEE 802.1X and EAP authentication; each user or device is individually authenticated
2) Incorporates RADIUS authentication server for authentication and key management
3) Used by enterprise-class networks
5
Q
WPA3
A
- improves upon its predecessor, WPA2, including stronger encryption, robust authentication methods, and protection against common security vulnerabilities.
- One of the significant enhancements in WPA3 is the introduction of a new authentication method called Simultaneous Authentication of Equals (SAE), also known as Dragonfly. SAE replaces the pre-shared key (PSK) authentication used in WPA2
6
Q
WebAuth
A
- authenticates a guest in a way that provides for security, but does not create undue support overhead
- Can be used for devices that cannot perform or pass 802.1X credentials
- Can be used as a backup means of authenticating employee devices that fail 802.1X authentication, but to which you still want to provide some level of access
7
Q
PSK Authentication
A
- uses symmetric encryption, meaning the same algorithm and key that are used to encrypt the creds are used in reverse to decrypt the msg
8
Q
SKA Process
A
- client uses open authentication, which operates at L1 & L2 only to show it’s 802.11 capable
1) Client sends an authentication request to the AP
2) AP sends a cleartext challenge phrase to to the client
3) Client encrypts the phrase with the shared key and sends it to the AP
4) If the AP can decrypt the phrase with the key, then the AP sends an authentication to the client.
5) Once authenticated, the client makes an association request
6) AP sends an association response
7) A virtual port is opened, and client data is now allowed
8) Data is encrypted using the same key
9
Q
Public Key Infrastructure (PKI)
A
- service framework that is needed to support large-scale, public key-based technologies
- uses digital certificates
- Certificate Authorities (CAs) generate certificates for users (clients) and servers, which are used to validate user and server identities
- Clients request a user certificate from a CA and use the certificate to authenticate the server, using 802.1X authentication (e.g. EAP-TLS)
- Servers request a server certificate from the CA, which is used by the client to validate the authenticity of the server. A server can also use a self-signed certificate with which it acts as its own CA
- Cisco WLCs that are used as the authentication server use pre-installed server certificates or can request a server certificate from a CA
10
Q
Asymmetric Encryption
A
1) User generates a public and private key, that work together - e.g. key1 will encrypt something that can be decrypted by key2 and vice versa
2) Server generates another pair of keys
3) Server sends its public key3 to user
4) User uses key3 to encrypt response to server and sends key1
5) Server will use key1 to encrypt when responding to user
11
Q
Digital Signing
A
- With asymmetric encryption only, there’s no guarantee the src is who they say they are
- when user sends traffic to server, it’ll encrypt with its private key, and then again with the server’s public key. when the server receives it, it’ll be able to double decrypt it
12
Q
Certificate Authority (CA)
A
- takes the public key that belongs to User1, adds text that contains their name, the validity duration, and a hash that contains a signed message that is encrypted with a private key that belongs to the authority
- a public key to which a trusted 3rd party has signed in this manner is called a certificate
- when receiving the public key that belongs to User1, the server tries to read the hash by using a public key of an installed well-known CA. if this is successful, then the public key truly belongs to User1
13
Q
CA Certificate Retrieval
A
1) User1 and User2 request the CA certificate that contains the CA public key
2) Upon receipt of the CA cert, their systems verify the validity of the cert by using the public key cryptography
3) User1 & User2 contact the CA admin and verify the public key and serial number of the certificate
14
Q
Certificate Enrollment
A
1) User1 & 2’s systems forward a certificate request, which includes their public key along with some identifying information. All this information is encrypted by using the public key of the CA
2) Upon receipt of the cert requests, the CA admin contacts User1 and User2 to confirm their submittal and the public key.
3) The CA admin issues the certificate by adding more data to the cert request, and digitally signing all of it
4) Either the end user manually retrieves the certificate, or Simple Certificate Enrollment Protocol (SCEP) automatically retrieves the cert, and the cert is installed onto the system
15
Q
Authentication Using Certs
A
1) User1 and the server exchange certificates. The CA is no longer involved.
2) Each party verifies the digital signature on the cert by hashing the plaintext portion of the cert, decrypting the digital signature using the CA public key, and comparing the result. If matched, then the cert is verified confirming that User1 is User1 and the server is the server.
16
Q
Extensible Authentication Procotol (EAP)
A
- general protocol for authentication that supports multiple methods such as token cards, Kerberos, one-time passwrods, certificates, public key authentication, and smart cards
- EAP with 802.1 address authentication, but not encryption
- EAP msgs are relayed btwn client and server; AP and controller don’t care
17
Q
EAP Message Types
A
1) Request
2) Response
3) Success
4) Failure
18
Q
EAP Types
A
- there are ~40 types of EAP, but some of the most common are:
1) EAP-TLS
2) Protected EAP (PEAP)
3) EAP-Flexible Authentication via Secure Tunneling (EAP-FAST)
4) EAP-Subscriber Identity Module (SIM), for Global System for Mobile Communications (GSM)
5) EAP-Authentication and Key Agreement (AKA), for Universal Mobile Telecommunications Service (UMTS)
19
Q
WPA2 Enterprise EAP Types
A
1) EAP-TLS
2) PEAP
3) EAP-FAST
4) EAP-generic token card (GTC)
5) EAP-SIM
6) EAP-AKA
- others might be allowed, but aren’t supported
20
Q
EAP Authentication Server
A
1) Locally by a Cisco WLC (local EAP) can use either the local creds, or LDAP to authenticate users. Can be used as a backup to RADIUS, so clients can auth even when the controller disconnects from RADIUS
2) Globally by a RADIUS server such as ISE, Microsoft server configured for RADIUS, or any RADIUS-compliant server
21
Q
EAP Frame Format
A
1) RFC 3748
2) EAPOL is the method used to transport EAP packets btwn a supplicant and an authenticator directly by a LAN MAC service over 802.1X
22
Q
EAP Request
A
- The authenticator sends the request packet to the supplicant
- Each request has a Type field that indicates what is being requested.
- Sequence number allows the authenticator and peer to match an EAP response to each EAP request
23
Q
EAP Response
A
- Supplicant sends the response to the authenticator and uses a sequence number to match the initiating EAP request
- The type of EAP response generally matches the EAP request, unless the response is a negative acknowledgement
24
Q
EAP Success
A
- the authenticator sends the success packet to the supplicant when successful authentication has occurred
25
EAP Failure
- Authenticator sends the failure packet to the supplicant when authentication fails
26
EAP-TLS
- while very secure, EAP-TLS requires client certs to be installed on each Wi-Fi workstation. This approach requires a PKI infrastructure with extra administrative expertise and time, and also maintaining the WLAN itself
27
PEAP
- requires only server-side certs. therefore, you can use a more manageable PKI or no PKI.
- Cisco and Microsoft support PEAP and it's available at no additional cost from Microsoft
- most prominently used EAP bc it's used with Microsoft servers
28
EAP-FAST
- solution for enterprises that cannot enforce a strong password policy and do not want to deploy certificates for authentication
29
EAP-Tunneled Transport Layer Security (TTLS)
- addresses the certificate issue by tunneling TLS, and thus eliminating the need for a certificate on the client side
- EAP-TTLS is a proprietary standard, owned by Juniper, and there's a charge for supplicant and authentication server software
30
Lightweight Extensible Authentication Protocol (LEAP)
- longest history, and previously Cisco proprietary, but now licensed to other vendors
- a strong password policy should be enforced when LEAP is used for authentication to prevent dictionary attacks, so it's not recommended for enterprise
31
EAP-TLS Process
1) EAP-TLS uses 802.1X auth framework, so WLAN uses open auth up to the association phase
2) Client sends a start frame to show that it uses 802.1X and EAP
3) Authenticator returns a request identity message to the client
4) Client sends its identity, user, or machine name.
5) Auth server sends its certificate, which proves its identity and provides the client with a means of sending back encrypted frames
6) Client answers with its own certificate
7) The client & server use public and private keys to create an encrypted tunnel to generate a session key to encrypt the data
8) Auth server sends the primary key to the AP or controller, to which is also has a secure connection.
9) Encryption then occurs between the client and AP
32
Reasons Public & Private Certs Are Not Used To Directly Encrypt Data Over The Air
1) Public & private keys are too CPU-intensive for fast data encryption and decryption
2) In a wireless environment, encryption must occur in the wireless space, which means it must stop at the AP level. The public and private keys used are between the client and the auth server, so it would be transparent to the AP
33
PEAP Implementations
1) PEAP-GTC - allows generic authentication to several databases by using token cards, such as LDAP, one-time password (OTP) and so on
2) PEAP-MS-CHAPv2 - allows authentication to databases that support MS-CHAPv2 including Microsoft AD
34
PEAP Process
1) PEAP uses 802.1X auth framework, so WLAN uses open auth up to the association phase
2) Client sends start frame to AP to show that it uses 802.1X and EAP
3) AP returns a request for identity to the client
4) Client sends bogus identifier to hide info that may be used in the CHAP user/pass auth
5) Server sends certificate
6) Client authenticates the server by using a CA to verify digital certificate
7) Client generates a primary encryption key, encrypts this key with teh server public key, and sends the encrypted key to the authentication server. This phase, which could be the client cert phase from the perspective of an attacker, is known as Phase1.
8) Phase2 begins with an EAP server sending an (optional) EAP-Request/Identity frame to the client, which is protected by the TLS tunnel.
9) Client responds with EAP-Response/Identity msg containing its user ID.
10) Client sends its creds using GTC, or MS-CHAPv2 to prove it is the user it claims to be
11) Auth server and client user their exchanged values and random numbers sent to each other to generate a common value, called the session key, or Pairwise Master Key (PMK)
12) RADIUS server sends the session key to the AP in success packet. The client and AP use the keys during the session.
35
Pairwise Master Key (PMK)
- authentication server and client use their exchanged values and random numbers that are sent to each other to generate a common value, which is called the session key or Pairwise Master Key (PMK)
- used to directly generate a WEP key or as an initial value for further negotiation between the client and AP
36
EAP-Flexible Authentication via Secure Tunneling
1) Phase0 - a unique shared cred is generated by the server. It will be used by the client and server to authenticate each other during Phase1. The cred is specific to a user ID and Server Authority ID (A-ID). The PAC needs to be installed on the client either manually or via a trusted connection, where the client is authenticated using another method (cert-based [TLS] or password-based [MS-CHAPv2])
2) Phase1 - The AAA server and end user use PAC to authenticate each other and establish a secure tunnel. A process similar to EAP-TLS is used but PAC replaces the cert. A tunnel key will be established, which will be used in Phase2 for confidentiality and integrity.
3) Phase2 - The RADIUS server authenticates the user creds with another EAP, which is protected by the tunnel that is created in Phase1. The common means of authentication are passwords and GTCs.
37
Protected Access Credential (PAC)
- achieve adequate security in EAP-FAST, the same authentication server on which authentication occurs also generates a unique shared credential that is used to mutually authenticate client and server
- PAC is associated with a specific client username and a server A-ID
- when the PAC has been created, it's sent to the client. - can be sent during the autoprovisioning in Phase0 or a PAC refresh in Phase2
- a PAC can be manually created and installed on the client.
- One PAC is required for each client
- After the PAC has been created, the server forgets the PAC and relies on the primary key and the PAC-Opaque field
- limiting factors is the necessity to have a server that can generate and manage PACs and a client that can support EAP-FAST
38
PAC Parts
1) PAC Key - the client uses this 32-octet key to establish the Phase1 EAP-FAST tunnel. This key maps as the TLS preprimary secret. The AAA server randomly generates the PAC key.
2) PAC-Opaque - this variable-length field is sent to the AAA server during the establishment of the Phase1 EAP-FAST tunnel. The PAC-Opaque field can be interpreted only by the AAA server to recover the required info for the server to validate the client identity and authentication.
3) PAC-Info - variable-length field used to provide, at a minimum, the A-ID or PAC issuer. Other useful, but non-mandatory information, such as PAC-key lifetime, can also be conveyed by the AAA server to the client during PAC provisioning or refreshment. The server maintains a local key (primary key) that only the server knows.
39
PAC Steps
1) A server A-ID maintains a local key (primary key), which only the server knows.
2) When a client identity, sometimes referred to as the I-ID, requests a PAC from the server, the server generates a randomly unique PAC key and PAC-Opaque field for this client
3) The PAC-Opaque field contains the randomly generated PAC key, along with other infromation such as the I-ID and key lifetime
4) The PAC-Opaque field is encrypted with the primary key
5) A PAC-Info field, which contains the A-ID, is also created
40
PAC Exchange
1) When an EAP-FAST session is initiated, the server sends its A-ID in an EAP-FAST start packet to the client.
2) The client uses the A-ID to choose the PAC to use for this session
3) The client sends the PAC-Opaque field from the appropriate PAC to the server
4) The server uses the primary key to decrypt the PAC-Opaque field and retrieve the PAC key, I-ID, and PAC lifetime
5) Now the server and the client have the PAC key, which is used as a shared secret to establish a TLS tunnel
41
EAP-FAST Process
1) EAP-FAST uses 802.1X auth framework, so WLAN uses open auth up to the association phase
2) Client sends start frame to AP to show that it uses 802.1X and EAP
3) AP returns a request for identity to the client
4) Client sends a network access identifier (NAI) address, in email format, to the AP, which passes it onto the RADIUS server
5) Server and client mutually authenticate each other, using Phases1 & 2 of the EAP-FAST process
6) Auth server and client user their exchanged values and random numbers sent to each other to generate a common value, called the session key, or Pairwise Master Key (PMK)
12) RADIUS server sends the session key to the AP in success packet. The client and AP use the keys during the session.
42
WebAuth Basic Areas
1) From where guest path isolation is defined in the network.
- Local WLC
- Auto-Anchor
2) From where web portal pages are provisioned
- Local pages on a WLC
- Remote pages on an external web server
3) From where users are defined
- Local guest user account on a WLC
- Centralized guest user account on a RADIUS authentication server
43
WLC Functions in Local WebAuth
1) maps an SSID to a dedicated VLAN to provide path isolation (typically open authentication)
2) Provisions basic web authentication splash pages for the web portal
3) Maintains local user guest accounts
- Username and password
- An SSID that is allowed for the account (asociated to a VLAN)
- Lifetime for the account (how long it can be used)
44
Local WebAuth with Auto-Anchor
- Auto-Anchor mobility (aka guest tunneling) is a feature that restricts WLAN to a single subnet, regardless of a client entry point into the network
1) The guest associates to the local controller, and a local session is created
2) A session (via a tunnel) is created to the Auto-Anchor WLC (session is per SSID, not client)
3) Packets from the client are encapsulated and sent through the tunnel to the Auto-Anchor WLC
4) Auto-Anchor WLC de-encapusulates the client packets and delivers them to the wired network
5) Traffic from the wired network to the client goes through the same tunnel
45
Auto-Anchor Duties
1) The local WLC:
- Tunnels client traffic to the Auto-Anchor (while the anchor WLC provides path isolation)
2) The anchor WLC:
- Provisions basic web auth splash pages for the web portal
- Maintains local user guest accounts
46
Local WebAuth with External Authentication Traits
1) A guest associates to a local controller and a local session is created
2) The guest receives web login pages from the local WLC
3) The guest enters creds that are forwarded to the auth server (ISE) for authentication
4) The authentication server returns confirmation (assuming creds are valid)
5) Guest traffic is routed to the internet, and the WLC provides path isolation.
47
Centralized WebAuth Traits
1) A guest associates to a local controller and a local session is created
2) The guest is redirected to Cisco ISE
3) Cisco ISE provides web portal pages and guest authentication
4) Guest traffic is routed to the internet
48
EAPOL
- network authentication protocol used in 802.1X that provides encapsulation between supplicant and authenticator
49
Pairwise Master Key (PMK) 4-Ways Handshake
1) The authenticator sends an EAPOL key frame that contains an authenticator nonce (ANonce). The ANonce is a random number that the authenticator generates.
- The supplicant generates a supplicant nonce (SNonce), which is a random number that the supplicant generates
- The supplicant derives a Pairwise Transient Key (PTK) from the ANonce, SNonce, PMK, authenticator MAC address, and supplicant MAC address
2) Supplicant sends an EAPOL key frame that contains an SNonce and a Message Integrity Check (MIC), generated from the PTK
- The authenticator derives the PTK from the ANonce, SNonce, PMK, authenticator MAC address, and supplicant MAC address, and validates the MIC in the EAPOL key frame
3) If the validation is successful, the authenticator sends an EAPOL key frame that contains the Group Temporal Key (GTK), the multicast or broadcast encryption key.
- When validating the MIC from this frame, the supplicant installs its PTK and the GTK
4) The supplicant sends an EAPOL key frame to confirm that the temporal keys are installed.
- When validating the MIC from this frame, the authenticator installs the PTK for this client
50
Group Temporal Key (GTK)
- a temporal key that is used to secure the broadcast and multicast traffic from the AP to all supplicants (stations).
51
Pairwise Temporal Key (PTK)
- used to secure the unicast data traffic between the AP and the individual stations
Personal Cisco
flashcards
Decks in class (25)
# Cards
-
EIGRP39
-
OSPF51
-
BGP24
-
Multicast28
-
NAT5
-
Infrastructure Security23
-
Enterprise Network Security Architecture72
-
Secure Access Control32
-
Wireless Principles65
-
Wireless Deployments16
-
Wireless Roaming & Location Services26
-
Wireless AP Services26
-
Wireless Client Authentication51
-
Troubleshooting Wireless22
-
Introducing Virtualization Protocols & Techniques14
-
Virtual Private Networks & Interfaces30
-
Network Services36
-
Network Analysis Tools22
-
Python Basics6
-
Network Programmability Protocols0
-
Cisco Digital Network Architecture (DNA) Center39
-
Cisco SD-Access Solution4
-
Cisco SD-WAN15
-
DNA Center APIs and vManage8
-
Implementing Site-to-Site VPN Solutions6
