When you are using a traditional EAP type, the identity seen in the
EAPOL exchange is authoritative and can be trusted.
(Returning a User-Name AVP in an Access-Accept is unnecessary in this
case unless it needs to be normalised or customised, and is optional
as part of the RADIUS RFCs.)
When you
*You can of course mandate something like the outer identity must
equal the inner identity, or require anonymous@..., which would make
the identity spoofing issue one of anonymisation alone.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Dear All,
I am curious if it is possible today with FreeRADIUS to normalise the
identity that is returned in the User-Name AVP in an Access-Accept?
Hypothetically, lets say that a client uses the PEAP EAP type and logs
in successfully using an inner-identity of its choosing in a valid
format.
Thanks, Alan!
I have got a feature request with Aerohive, our wireless vendor, to
support treating the User-Name AVP as being authoritative which they
are being pretty receptive and responsive to.
(I think RADIUS clients need to stop treating the outer identity as
being authoritative if and
I would have thought that it is perfectly reasonable to return the
identity back in the case you have roaming federations as long as it
was an agreed requirement beforehand.
I am of the opinion that this -should- be mandated as part of Eduroam,
for example.
-
List info/subscribe/unsubscribe? See
I would default the behaviour to not send the User-Name attribute in
the Access-Accept but give the ability to have it trivially enabled
with a toggle.
And where it is enabled, by default, send it in the normalised
user@realm format unless configured otherwise. (That would be the
general case as
As an aside to the mechanics of this, if you do this, test your NAS under
simulated user load. We found that our Cisco WLC equipment didn't like
that and leaked internal resources, which eventually ran out. We were
adding some additional information to the username, so we had many more
That's a very fair point. A problem with anonymous identities though
also comes where you have features at the edge that 'do things' based
on the identity. Often you will just want an anonymised unique
identity for each discrete user, but not necessarily their real
identity.
Food for thought...
I honestly don't see what the problem is with writing it yourself - it's not
rocket science - but OTOH a set of examples in the default config would be a
good thing too.
No problem at all, rather, I would have simply thought that it lowers
the barrier to entry, requiring less concious thought
So which id are you talking about?
if its the outer and the user has configured the machine correctly, all
you're going to see is @realm - not much use other than it's that
institution
if its the inner then o.k. you've got a realm from the outer user-name and a
userid from the inner but
Eduroam visited ORPS and home server ORPS should support CUI. Where the NAS
at the visited site lacks support for CUI, and the NAS supports setting
values for attributes associated with a session, a globally and temporarily
unique identifier should be set (via Access-Accept/COA/SNMP) and
Dear All,
If anybody still uses any Comware v3 switches anywhere with 802.1X,
they had a bug until recently where they would drop and not respond to
all EAPOL v2 and v3 in flagrant violation to the 802.1X-2001
specification.
These are switches such as:
3Com 4500, 5500 or 5500G series
H3C S3600,
In response to a private email I had asking for clarification, sorry,
I meant the 10/100 4210s which run Comware v3, not 4210Gs which run
Comware v5...
The actual error you will see on such switched with terminal
debugging enabled along with debugging dot1x all you'll see on
afflicted devices is:
Great, hit send by accident with a sentence half constructed.
Hopefully you'll get the gist!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
14 matches
Mail list logo
