Agenda • 802.11 retrospective - B. Aboba • Lunch

advertisement
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
NAS
NAS
Access
Provider
Access
Provider
End
Station
NAS
Access
Provider
Service
Provider
Service
Provider
Enterprise Usage Cases
Enterprise
Bridge
Bridge
Enterprise
Enterprise
End
Station
Bridge
Enterprise
Enterprise
Enterprise
Provider Bridge Usage Cases
Provider
Bridge
Ethernet
Service
Provider
Enterprise
Enterprise
Bridge
Provider
Bridge
Bridge
Bridge
ESP
ESP
Ethernet
Service
Provider
Bridge
Provider
Bridge
Bridge
Enterprise
ESP
Ethernet
Service
Provider
Bridge
Provider
Bridge
ESP
Enterprise
Provider
Bridge
Provider
Bridge
Enterprise
Enterprise
Enterprise
Enterprise
Remote Access Network Usage Cases
End
Station
NAS
End
Station
NAS
Service Provider
NAP
End
Station
Service Provider 1
NAS
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 Phases
NAS
Key Mgmt
Authorize Authenticate Annouce
STA/NAS
Multicast announce
Multicast announce request
unicast announce
Announcement Phases
NAS
Annouce
STA/NAS
Multicast announce
Multicast announce request
unicast announce
pitm
Allocation
Selection
pitms
port
Environment
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
TSK = PTK
.1ae Terminology
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 Model
1) 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 Implications
a) 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 2
e)
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.
Download