IP-Address

[Arran Cudbard-Bell]

On 26 Mar 2014, at 07:48, Nick Lowe <nick.lowe at gmail.com> wrote:

> 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:

Ok, but the requirements you list below appear to be specific to NPS.
It's feature set is very limited.

I'm sure you have a good reason for using NPS, but it's really not
a good platform to do any sort of complex policy work. 
FreeRADIUS is significantly easier to integrate with arbitrary data
sources.

> 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:

As you've not explicitly stated these are requirements for NPS, i'm
going to respond as if they were general requirements for
implementing SSO based on IP address.

> 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.

You can always trigger the 'check whether session is active' 
process when you detect a duplicate login. In which case there's
no need for accounting.

You can periodically poll most NAS to see whether a session is
still active. Most implement the standard 802.1X MIB even if they
don't do 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.

Again not completely true, if you have an integrated DHCP and RADIUS
server, or any DHCP server which makes the IP address of the client
easily available, you can resolve the client's Mac-Address to a 
currently valid lease.

The NAS does need to send the Calling-Station-ID, but almost all do.

> 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.

Why?

I can see it being imperative that the NAS must enforce the L2/L3 
association, but it's not at all imperative that DHCP-Snooping is
the source of address information.

A NAS may support DHCP-Snooping/IP-Lockdown, but not include that
info in Accounting-Requests.

> 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.

Again not true, this can come from the DHCP server itself. You just
need the NAS to enforce the association between MAC and IP address
to prevent someone ignoring the assigned IP/Prefix (more likely for V6).

> 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.

Nope.

> 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.

You do want an accounting-request to propagate through the system
to interested parties, and yes it should be after the lease has been
acquired, but it doesn't necessarily have to come from the NAS.

> 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.

DHCP server knows :)

> 
> 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.

Though in reality this isn't a huge issue. If your entire edge
has DHCP-Snooping/IP-lockdown enabled there's no way someone can
jump on a stale session.

> 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.)

This is only a limitation because of NPS's limited policy capabilities.
> 
> 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.

Sure.

> 
> 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.

Or CUI, or you can use Class, or the Framed-IP-Address :)

> 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.

Nah.

There are so many ways to skin this particular cat, listing a bunch
of requirements doesn't make that much sense.

If you want to guarantee you'll get the system working then sure, but
even some of the musts above, I can't see being a huge problem with 
NPS, if you really think how all the components interact.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140326/a6c9a29e/attachment.pgp>