On May 3, 2015, at 11:37 , mourik jan heupink <heup...@gmail.com> wrote:
> Is this all approximately correct?
Hi Mourik,
I would call it approximately fanciful.
Assuming 802.1x with PEAP — which is the most common deployment — the actual
workflow is something like this (gross handwaving and simplifications follow):
You connect a device to a switch (assume for the purpose of this post that we
are connecting to a wired switch, but the general principle is the same on
wireless).
The switch probes your device with 802.1x frames.
The supplicant on your device replies with it’s credentials
(username/password). In the case of PEAP these are not the password itself but
a response to a challenge derived from it.
The switch turns that reply into a radius request which it sends to the RADIUS
server.
The radius server checks those credentials against whatever authentication
source it is configured for (e.g. an Active-Directory server).
If authentication is successful, it proceeds with authorization (e.g. assigning
a VLAN, an ACL or role). In the case of PacketFence authorization is done
through a call from FreeRADIUS to a webservice where most of the business logic
is implemented. That webservice adds the proper attributes to the radius reply
depending on the configuration you entered in PacketFence and based on the
knowledge each switch modules has of what attributes it (the switch) expects in
reply for a given configuration.
RADIUS receives the reply from the webservice and returns it in the RADIUS
reply to the original request from the switch.
The switch allows or denies the access request and applies the authorization
specified in the radius reply, i.e. it will either switch VLANs, apply an ACL
or a role depending on what was returned.
What you need to understand is the nature of the RADIUS protocol.
RADIUS is a request/reply over UDP protocol where everything is specified as a
set of key-values pair called attributes.
These attributes contain information like the user or device credentials, the
IP of the originating switch and anything else that might be relevant.
Attributes are also used to convey information in the reply like the VLAN, ACL
or even QoS to apply to the connecting device.
While 802.1x is a layer 2 protocol, RADIUS is level 4 (UDP) and happens before
your device is allowed on the network.
Therefore things like dns or dhcp cannot be relied upon during 802.1x/RADIUS
(e.g. no name resolution from the point of view of the supplicant).
Furthermore, this authentication/authorization happens every time you connect a
device or reauthenticate.
There is no such thing as checking if authorization has changed. Everything
starts over from scratch, every time.
So the following is incorrect:
> - procurve confirms that the mac address is the same as last time, no
> further dialogue with freeradius: the client is granted the same access.
And finally, 802.1x does not rely on MAC addresses. It relies on authentication
credentials provided by the supplicant, usually a username/password.
Hope that is clearer.
Cheers,
--
Louis Munro
lmu...@inverse.ca :: www.inverse.ca
+1.514.447.4918 x125 :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
