Agenda

Post on 13-Jan-2016

33 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

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

Transcript

Agenda

• 802.11 retrospective - B. Aboba

• Lunch

• Goals/Requirements - J Burns

802.1af Goals/Requirements Agenda

• Usage cases

• Goals & overall requirements

General Usage Cases

NASEnd

StationServiceProvider

Access Provider

NASNASServiceProvider

Access Provider

ServiceProvider

Access Provider

Enterprise Usage Cases

Bridge EnterpriseBridgeEnterprise

Enterprise Enterprise

EndStation

EnterpriseBridge

Enterprise

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

Remote Access Network Usage Cases

NASEnd

StationService Provider

NAP

NASEnd

Station

NASEnd

Station

Service Provider 1

NAP

Service Provider 2

Service Provider 3

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.

802.1af Requirements

• Announcement (formerly discovery)

• Authentication

• Authorization

• Key Management

• Threat model

• Performance model

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

Environment

Announcement PhasesSTA/NAS

Multicast announce requestA

nn

ou

ce

NAS

Multicast announce

unicast announce

Sel

ecti

on

Allo

cati

on

pitms

pitm

port

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.

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

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

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)

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

Authorization Goals

• Enable service restrictions (negotiations?)

• Enforce pre-connection service restrictions

Authorization Requirements

• Enable communication between higher layer authorization entities

• Determine when authorization has completed (success/fail)

• Protected communications

.1ae TerminologyTSK = PTK

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)

Key Management Requirements(Formerly ‘Enable Session’)

• Maintain overlapped SAs

• Generate new TSKs

• Allow deletion of CA (?)

• Time out CA (?)

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.

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.

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.

top related