IP-Address

[Nick Lowe]

I have been having fun implementing a SSO framework for Microsoft's
NPS (when used as the EAP terminating RADIUS server)... but the
project is on hold while I pester Microsoft for hotfixes:

http://www.nicklowe.org/2013/08/nps-class-attribute-bug/

The generic requirements for your NASes are pretty high to do this
properly. A few common pain points are:

1) The NAS MUST support RADIUS accounting for 802.1X authenticated
sessions and sending interim updates.

This should be obvious, but not all NASes that support 802.1X
authentication via RADIUS support RADIUS accounting.

2) Where IPv4 is to be used, the NAS MUST support DHCPv4 snooping and
use this information, and only from this source, to populate and
include the Framed-IP-Address attribute with a client's IPv4 address
in Interim-Update RADIUS accounting packets.

A NAS must, of course, make a client's IPv4 address available for
Single-Sign-On (SSO) to work in an environment where IPv4 has been
deployed.
For security reasons, it is imperative that only the information from
the DHCPv4 snooping process be used as a source of address
information.

3) Where IPv6 is to be used, the NAS MUST support DHCPv6 snooping and
use this information, and only from this source, to populate and
include Framed-IPv6-Address attributes with a client's IPv6 addresses
in Interim-Update RADIUS accounting packets.

A NAS must make a client's IPv6 addresses available for Single-Sign-On
(SSO) to work in an environment where IPv6 has been deployed.
For security reasons, it is imperative that only the information from
the DHCPv6 snooping process be used as a source of address
information.

4) Either the NAS MUST immediately send an RADIUS accounting
Interim-Update packet when a client's IP address becomes known or
changes after its DHCP process concludes.
Or the NAS MUST send an Interim-Update RADIUS accounting packets at an
interval that is sufficiently short that it ensures there is a minimal
and acceptable delay before an Interim-Update packet is sent that
contains the client's IP address.

It is important that the client's IP address be made available in a
timely manner. It is best where this is imperceptible to an end user
and the load on a RADIUS server is kept to a minimum. It is best where
the first approach is adopted. Conceptually, this is like polling vs.
event based notification, the latter is nearly always better design
where achievable.

5) The NAS SHOULD support sending Accounting-On and Accounting-Off
RADIUS accounting packets.

This allows expedient handling of stale sessions when a NAS is
shutdown or restarted without requiring a timeout to kick in.

8) A NAS that supports handoff to another NAS MUST include an
Acct-Multi-Session-Id attribute in the RADIUS accounting packets that
are sent. The Acct-Multi-Session-Id attribute MAY be introduced within
a session via an Interim-Update RADIUS accounting packet, but it MUST
be sent before a handoff event occurs.

Where roaming occurs, it is imperative that the connection can be
tracked across the multiple RADIUS sessions that result. Otherwise,
the previous session will be considered stale after a timeout and
expunged. (The replacement session will usually be accounted without a
corresponding authentication and authorisation exchange.)

8) A NAS SHOULD include the Event-Timestamp attribute and the
Acct-Delay-Time attribute in all its RADIUS accounting packets.

This allows determination to be made on the correct way to handle the
event in context to the state of a session.

9) A NAS SHOULD support processing the User-Name attribute in RADIUS
Access-Accept packets, overwriting the value used from the EAP outer
identity if one is present.

In Single-Sign-On systems, where the Authentication/Authorization
process is opaque because there is no direct integration with it, it
is necessary that the RADIUS server return the User-Name attribute
with the client's real identity AND that the NAS support processing
this in order to not end up with a deployment vulnerable to identity
spoofing.

Nick

On Mon, Mar 24, 2014 at 11:12 PM, Bruce Richardson
<bruce_m_richardson at unitedbiscuits.com> wrote:
> Hi,
>
> I have been using freeradius for many years now to authenticate WiFi users
> against active directory, and it all works perfectly.
>
> I am now trying to integrate it with the identity awareness built into our
> Checkpoint firewall system, this is able to take radius authentication
> packets and build a list of users against IP addresses.
>
> I understand that you can replicate the accounting data on from freeradius
> but for this to work obviously the WiFi client's IP address needs to be in
> the radius accounting data. At the moment it isn't because at the point when
> the accounting data is sent the client has not yet sent its DHCP request.
>
> Am I correct that to get the IP address into the radius accounting the
> freeradius server needs to be configured to send out the IP addresses rather
> than different DHCP server.
>
> If this is correct, could I create different IP pools to be used for each
> site, and have the correct IP data sent out for for different sets of wifi
> access points (NAS).
>
> Many thanks for reading this, I just want know I am going in the correct
> direction.
>
>
> Regards,
>
> Bruce Richardson
>
>
> This e-mail and any attachments are confidential and solely for the use of
> the intended recipient.  They may contain material protected by legal
> professional or other privilege. If you receive it in error, please delete
> it from your system, make no copies of it, do not disclose its contents to
> any third party or use it for your own or any other person's benefit.
> Please advise the sender of its receipt as soon as possible. Although this
> email and its attachments are believed to be free of any virus or other
> defect, it is the responsibility of the recipient to ensure that they are
> virus free and no responsibility is accepted by the company for any loss or
> damage arising from receipt or use thereof. Any opinions expressed that do
> not relate to the official business of the company are those of the author,
> not the United Biscuits group of companies.
>
> United Biscuits (UK) Limited Registered in England number 2506007
> Registered Office: Hayes Park, Hayes End Road, Hayes, Middlesex, UB4 8EE
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html