Agenda • 802.11 retrospective - B. Aboba • Lunch • Goals/Requirements - J Burns
Jan 13, 2016
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.