Top Banner
Agenda • 802.11 retrospective - B. Aboba • Lunch • Goals/Requirements - J Burns
23

Agenda

Jan 13, 2016

Download

Documents

Bliss_

Agenda. 802.11 retrospective - B. Aboba Lunch Goals/Requirements - J Burns. 802.1af Goals/Requirements Agenda. Usage cases Goals & overall requirements. General Usage Cases. Service Provider. Service Provider. NAS. NAS. Access Provider. Access Provider. Service Provider. End - PowerPoint PPT Presentation
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.
Transcript
Page 1: Agenda

Agenda

• 802.11 retrospective - B. Aboba

• Lunch

• Goals/Requirements - J Burns

Page 2: Agenda

802.1af Goals/Requirements Agenda

• Usage cases

• Goals & overall requirements

Page 3: Agenda

General Usage Cases

NASEnd

StationServiceProvider

Access Provider

NASNASServiceProvider

Access Provider

ServiceProvider

Access Provider

Page 4: Agenda

Enterprise Usage Cases

Bridge EnterpriseBridgeEnterprise

Enterprise Enterprise

EndStation

EnterpriseBridge

Enterprise

Page 5: Agenda

Provider Bridge Usage Cases

BridgeProviderBridge Bridge

ProviderBridge

BridgeEnterpriseProviderBridge Bridge

ProviderBridge

Ethernet ServiceProvider

Enterprise

EnterpriseProviderBridge

ProviderBridge Enterprise

Bridge Bridge

Ethernet ServiceProvider

Ethernet ServiceProvider

ESP ESP

Enterprise ESP ESP Enterprise

Enterprise Enterprise

Page 6: Agenda

Remote Access Network Usage Cases

NASEnd

StationService Provider

NAP

NASEnd

Station

NASEnd

Station

Service Provider 1

NAP

Service Provider 2

Service Provider 3

Page 7: Agenda

802.1af Goals

• Provide and manage a cryptographic key framework in order to provide keys to the SecY so that it may provide a protected channel.

Page 8: Agenda

802.1af Requirements

• Announcement (formerly discovery)

• Authentication

• Authorization

• Key Management

• Threat model

• Performance model

Page 9: Agenda

Typical PhasesSTA/NAS

Multicast announce request

An

no

uce

NAS

Multicast announce

unicast announce

Au

then

tica

teA

uth

ori

zeK

ey M

gm

t

Page 10: Agenda

Environment

Announcement PhasesSTA/NAS

Multicast announce requestA

nn

ou

ce

NAS

Multicast announce

unicast announce

Sel

ecti

on

Allo

cati

on

pitms

pitm

port

Page 11: Agenda

Announcement Goals(formerly Discovery)

• Provide sufficient information for a .1af entity to decide on a NAS to attempt a connection with.

• End result shall be a port on which the remaining .1af processes shall operate.

Page 12: Agenda

Announcement Requirements(formerly Discovery)

• Assume Announcement is unprotected, but do not preclude use of separate Discovery protection

• Announce AE capabilities (MAC): cipher suites, name of device

• Announce distinguished name(s) for NAP(s)• For each NAP: announce distinguished name(s) for

service providers• Fast delivery of announcements when asked• In ‘virtual port’ systems: operate through an ‘all ports’

port• Creation of a port (Port/ISS MILSAP)• Minimal processing: to limit DoS impact

Page 13: Agenda

Announcement Information

• Identifier for the domain of the network access provider

• Identifiers for the service providers

• Supported authentication methods

• Supported cipher suites

• Optional - Announcement Key

Page 14: Agenda

Authentication Goals

• Enable identity verification via higher layer– Potentially between end station and network

access provider, end station and service provider, end station and home network

• Generate the root key for a key framework (EAP document)

Page 15: Agenda

Authentication Requirements

• Provide facility for various authentication methods• Define a set of required authentication method(s)• Generate a master key that shall be the root of a

key framework (EAP document). This allows future processes to be cryptographically bound to the authentication result.

• Authentication success begins the key framework but does not imply network access.

• Verification of distinguished names of the .1af entities (NAS).

Page 16: Agenda

Authorization Goals

• Enable service restrictions (negotiations?)

• Enforce pre-connection service restrictions

Page 17: Agenda

Authorization Requirements

• Enable communication between higher layer authorization entities

• Determine when authorization has completed (success/fail)

• Protected communications

Page 18: Agenda

.1ae TerminologyTSK = PTK

Page 19: Agenda

Key Management Goals(Formerly ‘Enable Session’)

• Maintain secure connection association (CA) state

• Generate new TSKs for the SecY from the maintained CA. (The ‘bottom’ of the key framework)

Page 20: Agenda

Key Management Requirements(Formerly ‘Enable Session’)

• Maintain overlapped SAs

• Generate new TSKs

• Allow deletion of CA (?)

• Time out CA (?)

Page 21: Agenda

Threat Model1)    The network may be completely controlled by an attacker, and

the attacker may have significant computational resources.  How significant is dependant on the application. 

2)    One or more of the end-points may ultimately be fully compromised as well.

3)    There may be third parties involved in an authentication (e.g., a Radius server).  This third party, as well as the trust relationships between parties may be the source of attack.

4)      Discovery messages are likely to be unprotected during the discovery phase, but important decisions may be made based on them.

Page 22: Agenda

Threat Model Implicationsa)    The attacker can passively eavesdrop.

b)    The attacker can prevent traffic from reaching its intended destination.

c)    The attacker can send spurious messages and arbitrarily modify otherwise valid messages.

d)    The attacker can capture messages and replay them.

Page 23: Agenda

Threat Model Implications 2e)    For those worried about possible end-point compromise,

forward secrecy should be obtainable. f)    There may be possible timing attacks.g)    Unless one party really does not care with whom it is

communicating, mutual authentication is an absolute requirement.

h)      It is unrealistic to stop DoS in an absolute sense.  However, we can assume that attackers will perform "cheap" DoS attacks, such as trying to disturb a connection by tampering with individual messages or trying to overwhelm a machine's computational ability by launching a very few (expensive) authentications.