Stefan Winter wrote:
> I just consider the necessity to apply vendor-specific (or
> bash/iptables-script) "hacks" a conceptual shortcoming. If we'd ever get the
> chance to get a *proper*, standardised way of doing it, the job of 802.1X
> administration would get a lot easier.
I think people won't like this solution, but it makes a certain amount
of sense on a *technical* level: move IP address assignment into
802.1x. Many EAP methods that are TLS-based provide for transporting
information inside of the TLS tunnel. So... transport IP's.
There are large benefits to doing this. The client gets assigned an
IP from a known and trusted source (the AAA server he's authenticating
to). The NAS gets an IP from a known and trusted source (the local AAA
server). Everyone is happy.
e.g.
supplicant NAS AAA server
---------------> Can I gain access?
----------> Permit user on the net?
<----EAP---> Lots of packets...
<------------ AAA: "IP 192.0.2.10"
<---------------------------- TLS tunnel: "IP 192.0.2.10"
<--------------> Surfs the net...
In a roaming environment, it's just as easy. The local AAA server
sends the home AAA server the IP it wants to allocate to the user, and
the home AAA server puts that into the TLS tunnel:
supplicant NAS Local home AAA
---------------> Can I gain access?
----------> Permit user on the net?
-----------> Please assign IP 192.0.2.10
<----------- ACK's the IP 192.0.2.10
<----EAP---> Lots of packets...
<--------- AAA "IP 192.0.2.10"
<----------------------------------- TLS tunnel: "IP 192.0.2.10"
<--------------> Surfs the net...
All IP's are assigned via authenticated and secured transports. If
TTLS is used, much of this could be done as vendor extensions to a
supplicant. Maybe some extra effort would be needed on a NAS to permit
IP address assignment for LAN's via DHCP, but not much else.
This doesn't solve the problem of a user changing their IP later, but
enforcing MAC to IP address mapping is really a job for the NAS.
Comments? Sticks and stones?
Alan DeKok.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
