Transcript 04198E-TGe Security Baseline

7/17/2015
doc.:
Pros and Cons of Upper Layer
Network Access
Bernard Aboba
Microsoft
[email protected]
http://www.drizzle.com/~aboba/IEEE/
Slide 1
BURP BOF
7/17/2015
doc.:
Agenda
•
•
•
•
•
•
How do we measure success?
What do we do today?
Who standardizes what?
What have we learned from the past?
Pros and Cons of Upper Layer Auth
Summary
Slide 2
BURP BOF
7/17/2015
doc.:
How Do We Measure Success?
• A network access architecture is successful if:
– Users get access quickly. Need to minimize round-trips!
– High speed operation is supported
• We will have 1,000 Gbps wired networks by 2008!
• That’s 5 clock cycles @ 10 Ghz to process a 64 octet packet!
– It’s simple to develop, understand, operate and manage
• We don’t get paid by the word for specifications.
• On the Internet, we need to scale to handle everyone on (multiple?)
planets – and their dog, watch, car, light bulb, etc.
– Equipment can be manufactured inexpensively
• Cost matters if you’re trying to connect everything!
• More state, complexity means more hardware, higher cost, slower
speed – so new features need to add real value.
• Summary: You need to pass the laugh test!
Slide 3
BURP BOF
Gilder’s Law vs. Moore’s Law: The Next 20 Years
1000000
doc.:
Storage
Ethernet
Microprocessor performance
10000
1000
100
10
Storage in GB
100000
Speed in Gbps
Performance in Gflop/s
7/17/2015
1
Slide 4
BURP BOF
7/17/2015
doc.:
What Do We Do Today?
• Today, network access authentication is typically done at the link layer
– Authentication takes place at the beginning of the session, with periodic
re-auth if desired
– Implies that the NAS is one-hop from the client, since link layer isn’t
routable
• Network access is granted on a per-port basis
– NAS can do ingress filtering if desired, but usually doesn’t
– Virtual ports (VPNs) can provide access control by user or machine
• The client and Network Access Server speak the link layer protocol
over a point-to-point link
– 802.11: shared media converted to point-to-point for authentication via the
concept of an Association (see 802.11 Tge)
• The NAS and AAA server talk AAA protocol, which runs over IP
– NAS tells AAA server what kind of access is desired (VPN, xDSL,
802.11, etc.); AAA server responds with appropriate attributes
– The AAA protocol can tunnel the auth conversation (EAP)
– AAA server can be many hops from client
• Does this still make sense? Or has the world changed?
Slide 5
BURP BOF
7/17/2015
doc.:
Who Standardizes What?
• IETF: PPP, AAA, MobileIP, etc.
• IEEE
– Open standards body (http://www.ieee.org/)
•
•
•
•
Much of the discussion is held on the mail reflectors
Attendance at plenary, interim meetings not required
Documents in process available free for download
Standards CD-ROM available free to attendees at meetings
– Responsible for standardization of IEEE 802 physical and link layers
• Not just Ethernet or hardware or wired networks!
– Current activities of interest
• Ethernet in the First Mile Study Group
– Ethernet over passive optical and xDSL
• 802.3ae: 10 Gigabit Ethernet
• 802.1X: network port authentication
• 802.11: PHY & MAC for wireless LANs
– TgE: security & QoS, TgF: inter-access point protocol
• 802.16: Personal Area Networks (PANs)
Slide 6
BURP BOF
7/17/2015
•
•
What We’ve Learned
Network access authentication has already been implemented at every layer.
PHY
–
–
–
•
–
Examples: PPP , 802.1X
Pros: no firmware changes required for new auth methods, easier to fix bugs, easy to integrate into
AAA, no network access needed prior to authentication, extensible (RFC 2284)
Cons: requires MAC layer changes unless implemented in driver
IP
–
–
–
•
Example: 802.11b
Pros: no MAC or TCP/IP changes required (all support in firmware)
Cons: requires firmware changes in NICs and NASes to support new auth methods, requires NAS to
understand new auth types, slows delivery of bug fixes (e.g. WEP v1.0), hard to integrate into AAA
MAC
–
–
•
doc.:
Examples: hotel access (based on ICMP re-direct to access web server)
Pros: no client MAC or TCP/IP changes required (for ICMP re-direct method)
Cons: Doesn’t work for all apps, no mutual authentication, partial network access required prior to
auth, need to find access control server if not at first hop, typically not extensible, may not derive
encryption keys, no accounting (no logoff)
UDP/TCP
–
–
–
Examples: Proprietary token card protocols
Pros: No client MAC or TCP/IP changes required – can be implemented purely at the application
layer
Cons: requires client software, partial network access required prior to auth, need to find access
control server if not at first hop, typically not extensible, no accounting (no logoff)
Slide 7
BURP BOF
7/17/2015
doc.:
Static vs. Extensible Authentication
• Lesson: New authentication methods are constantly being
developed
– Passwords, public key smartcards, token cards, OTP, biometrics,
etc.
• If new NAS code is required for each new authentication
method, new methods will never be widely deployed.
• Solution:
– Build extensibility into the authentication framework: support for
method negotiation, multiple round trips, etc.
– Only require support for new auth methods on client and AAA
server
– NAS acts as a “pass through” to enable a conversation between the
client and AAA server.
– New access methods should support EAP, RFC 2284
Slide 8
BURP BOF
7/17/2015
doc.:
Why Do Auth at the Link Layer?
• It’s fast, simple, and inexpensive
– Most popular link layers support it: PPP, IEEE 802
– Cost matters if you’re planning on deploying 1 million ports!
• Client doesn’t need network access to authenticate
– No need to resolve names, obtain an IP address prior to auth
• NAS devices need minimal layer 3 functionality
– 802.11 access points, 1 Gbps switch ports go for $300, support 802.1D,
802.1X, SNMP & RADIUS, may have no layer 3 filtering support
– Authentication, AAA support typically a firmware upgrade
• In a multi-protocol world, doing auth at link layer enables
authorizing all protocols at the same time
– Doing it at the network layer would mean adding authentication within
IPv4, IPv6, AppleTalk, IPX, SNA, NetBEUI
– Would also mean authorizing within multiple layers
– Result: more delay
Slide 9
BURP BOF
7/17/2015
doc.:
Implications of Link Layer Auth
• Authentication not routable, must occur at edge
– NAS acts as Link-Layer/AAA gateway
– Edge auth more scalable than core auth
• No intrinsic support for fragmentation
– To handle certs you need fragmentation support
– RFC 2284 should have built this in
– Workarounds available (RFC 2716)
• No windowing support (ACK/NAK only)
– Not a big issue unless you have a long exchange
• Need to implement auth for each new link layers
– Question: how many new link layers do we need?
Which ones?
Slide 10
BURP BOF
7/17/2015
doc.:
Trends
•
•
•
•
More of everything (people, addresses, routes, hosts, names…)
Faster, faster, faster!
Mobile Internet Access the Next Big Thing
IP everywhere!
– Non-IP protocols going away (AppleTalk, IPX, NetBEUI, SNA)
– Though multi-protocol still alive (IPv4 & IPv6)
• Ethernet everywhere!
– Non-Ethernet LAN protocols going away (FDDI, Token Ring, ARCNET)
• Though PPP is alive and well (L2TP & PPPOE)
–
–
–
–
–
–
Support for point to point topologies as well as shared media
Speed increases by an order of magnitude every 3 years
Distance limitations removed via fiber optic PHYs
Ethernet now a LAN, MAN, WAN and even SAN medium
Some say Ethernet will also replace ATM, Frame Relay & SONET
Support for wired as well as wireless (802.11)
Slide 11
BURP BOF
7/17/2015
doc.:
When Might Layer 3+ Auth Make Sense?
• If speed is not a concern: filtering consumes precious cycles
• If you can’t re-use PPP or 802 link layers
– This rules out xDSL, dialup, wired LAN/MAN/WAN/SAN, wireless LAN
– What’s left and why?
• If you need to do complex authentication quickly
– Combined auth methods, long cert chains, etc.
• Some thoughts…
– Need for new PHY doesn’t imply new frame format
– Frame size not a factor at higher speeds
– 802 hard invariants and soft invariants…
• Hard: non-duplication, sequential delivery
• Soft: low error rate, high bandwidth, low delay
• Other: need to support multicast/broadcast service
– Can be satisfied in a wireless LAN
• Hard: ARQ
• Software: ARQ/FEC, 100+ Kbps bandwidth, 300 ms delay
Slide 12
BURP BOF
7/17/2015
doc.:
Pitfalls of Upper Layer Auth
•
•
Difficult to do accounting: if you don’t support logoff
Increased cost, decreased performance
– Need to implement layer 3 filtering adds cost
– Sweet spot for NASen implemented purely at layer 2 (low cost 802.11 APs, 1+
Gbps ports, etc.)
– Result: is this a high-priced niche solution?
•
Finding the access control server, if not at first hop
– Do you need to resolve the name? Use Service Discovery?
•
Service dependencies
– Do you need DHCP? DNS? SLP? Anycast?
– How porous does the filter need to be? What attacks do you enable in the process?
•
Inflexible and incompatible authentication
– No support for multiple round trips, requiring MICs thereby increasing AAA
complexity, etc.
– Solution: support EAP
•
Enforcement in the core
– Beware of state explosion, route changes, etc.
•
Security issues
– Increased vulnerability to DoS attacks results from partial access
Slide 13
BURP BOF
7/17/2015
doc.:
Five Questions…
• Why do port authentication? Why not machine or
user authentication?
– Port authentication requires minimal state: the port is
either open or closed.
– Machine auth requires keeping state on which machines
are authorized (substantial if the port connects to a
shared medium), as well as filtering non-authorized
traffic (more CPU cycles).
– User auth (distinguishing between users on the same
machine) is even harder: need to track flow state, filter
non-authorized flows.
Slide 14
BURP BOF
7/17/2015
doc.:
Five Questions (cont’d)
• Why do we need a AAA protocol? Why not just tunnel the
link layer?
– You can tunnel link layer auth: EAP
– You can tunnel the entire link layer: L2TP
– But AAA isn’t just about authentication – it’s also about
authorization and accounting
• NASes need to authorize services beyond network access – telnet to a
port (substitute for X.25), compulsory tunneling, etc.
• Don’t necessarily trust client to do its own accounting
Slide 15
BURP BOF
7/17/2015
doc.:
Five Questions (cont’d)
• Why authenticate and authorize at the edge? Wouldn’t it be
more flexible to do this in the core?
– Core auth implies that unauthorized users can reach authorized
users – security risk
– Can’t do port authentication in the core – one port corresponds to
many machines. So core auth requires more state.
– Routing and MPLS tagging can interact in core auth
– Summary: Core authentication is more complex, costly, insecure
Slide 16
BURP BOF
7/17/2015
doc.:
Five Questions (cont’d)
• Why can’t we do AAA directly between client and server?
– You can authenticate directly, and receive a ticket authorizing network
access: Kerberos
– Requires clients to have (limited) network access prior to authenticating
• Need to do name resolution, ICMP, address assignment, etc. prior to auth
• Use “uncontrolled port” with appropriate filters
– However, you may not want to put authentication, internal DNS servers on
the Internet, open to all clients
• May be concerned about DoS implications
– Instead, client and server can talk through a gateway
• EAP: uses NAS as a gateway
• IAKERB: uses IAKERB proxy as a gateway
• Gateways tunnel packets, no need for name resolution
Slide 17
BURP BOF
7/17/2015
doc.:
Five Questions (cont’d)
• Why is link layer auth easy to integrate with AAA? Why
has integrating IP layer (or higher) auth been so hard?
– Link layer auth has typically kept within the existing AAA auth
model: PAP, CHAP, EAP
• Result: no code changes needed to extend AAA to VPNs, xDSL, 802,
etc., only additional attributes or values
– IP-layer auth methods have included per-packet integrity and
authentication via Message Integrity Check (MIC)
• Link layers often assume physical security, but IP layer can’t do this
– Need to prevent rogue DHCP server from sending bad configuration info
(could determine boot load of diskless clients!)
– Need to prevent rogue MN from registering with the HA
• Result: AAA server needs to be intimately integrated with IP-layer
auth method; you need an extension, not just new attributes or values
• Example: AAA for DHCP requires AAA to parse DHCP packets,
validate and prepare MICs, possibly distribute keys
– Can’t just support CHAP, or you’d be vulnerable to attack by rogue
servers!
Slide 18
BURP BOF
7/17/2015
doc.:
Summary
• Network port authentication more scalable than machine or
user auth
• Edge more scalable than core authentication
• New network access methods should support existing AAA
auth model: (CHAP, EAP)
– DHCP for AAA proposals difficult to integrate
• Link layer authentication likely to remain mainstream
technique
– Dialup, xDSL, 802, VPN already supported
– Inexpensive, fast NAS devices available
– AAA “just works”
• Need for Layer 3+ auth rests on need for multiple new link
layers
– If there’s a need, it is in wireless WAN
– No need for layer 3+ auth in dialup, LAN, xDSL, wireless LANs
Slide 19
BURP BOF