230 likes | 363 Views
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
E N D
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 Station NAS Access Provider
Enterprise Usage Cases Enterprise Enterprise Bridge Bridge Enterprise Enterprise Enterprise End Station Bridge Enterprise
Provider Bridge Usage Cases Provider Bridge Provider Bridge Bridge Bridge Ethernet Service Provider Ethernet Service Provider Bridge Bridge ESP ESP Provider Bridge Ethernet Service Provider Provider Bridge Bridge Bridge Enterprise Enterprise Enterprise ESP ESP Enterprise Provider Bridge Provider Bridge Enterprise Enterprise Enterprise Enterprise
Remote Access Network Usage Cases End Station NAS End Station NAS Service Provider NAP Service Provider 1 End Station NAS Service Provider 2 Service Provider 3 NAP
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 STA/NAS Multicast announce Multicast announce request Annouce unicast announce Authenticate Authorize Key Mgmt
Announcement Phases NAS STA/NAS Multicast announce Multicast announce request Annouce unicast announce pitms Selection pitm Allocation 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.