On Thu, 2013-04-18 at 16:54 +0100, Nick Lowe wrote:
Agreed, the main concern for me would be leakage via wireless.
I see the main purpose of identity privacy with PKI EAPs being to
protect the identity from being trivially snooped by an outsider.
With federations, I think it would be
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.
Nick Lowe wrote:
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?
Yes. You can do pretty much anything you want.
RFC 2865 states in Section 5.1:
[The User-Name AVP] MAY be sent in an Access-Accept
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
On 18/04/13 16:06, Nick Lowe wrote:
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
Nick Lowe wrote:
It would be great if, rather than manually having to create mappings
and rewrite the identity, having successfully performed authentication
FreeRADIUS were able to inherently spit out the identity in a
normalised form knowing the username and the realm. (Perhaps I am not
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
Nick Lowe wrote:
So, a compliant NAS that is able to treat the User-Name AVP as being
authoritative would get to see the real, inner identity and in a
normalised form.
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
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
Nick Lowe wrote:
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.
I'd have to
What 'I'm doing at the moment. For our outward facing radius servers, with any
inbound auth requests from york users elsewhere, I normalise the username in
the Access-Accept packet to have the york.ac.uk realm appended if its not there
A
On 18 Apr 2013, at 16:43, Nick Lowe nick.l...@gmail.com
On 18/04/13 16:29, Nick Lowe wrote:
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.
Maybe, maybe not.
If the home site were in a jurisdiction with data protection
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...
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 any
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
Agreed, the main concern for me would be leakage via wireless.
I see the main purpose of identity privacy with PKI EAPs being to
protect the identity from being trivially snooped by an outsider.
With federations, I think it would be perfectly reasonable to expect
and require the real
On 18/04/13 16:59, Nick Lowe wrote:
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
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
Hi,
in latest 2.x and 3.x code check out the canonicalisation policy - this
sorts out the MAC format. you could do the same for the User-Name. note that
there are data protection issues in play - for example, if a user has chosen
(and is allowed) to use anonymous outerid, then why are you
21 matches
Mail list logo
