Alexander Clouter wrote: > Arran Cudbard-Bell <[email protected]> wrote: > >> Alexander Clouter wrote: >> >>> [email protected] wrote: >>> >>>>> No one in London wants to go to Sussex though and from my logs it does >>>>> not look like anyway from Sussex wants to go to London either ;) >>>>> >>>>> If someone gives me something better to use in my RADIUS packets then >>>>> I'm game. Meanwhile I keep meaning to glue 'exec' and 'fortune' >>>>> together and see if anyone notices. >>>>> >>>> I've been having a lok at such packets on the national proxy and wonder >>>> if its because people are just blamming a reply-message in at an wrong >>>> stage...eg during Auth? would a default entry in use users file or >>>> SQL group reply table cause such wrongness? most likely. >>>> >>>> >>> I have an entry in my 'users' file for if people insist on sending their >>> username without a realm >>> >> ... hmm that's pretty standard behaviour. We don't require FQUNs >> either. Though I have no idea why you still insist on using user files >> for policies. There's this new fangled policy language you know :P >> >> > We *demand* it as otherwise the helpdesk get lazy and users start > complaining that 'eduroam' does not work. > Hmm that's a good point. I guess the difference is that we were doing 802.1X before eduroam and didn't want to effect legacy behaviour. Looks like were going down the everything under one SSID route now, so 'It just works' when users roam. Maybe we'll have to look at getting rid of none qualified usernames. > As for using the user file for policies, why would I care? It works, > does what I need. It doesn't scale (for very complex policies) , it doesn't promote code reuse, it's limited in terms of it's applications. But if it works for you... > For me, I don't particularly find the unlang stuff > particularly compact/natural and it's a bit verbose for my liking; I > have not lost anything not using it. > > For some things I do use it, things that cannot be expressed in the > users file. Whatever looks the cleanest and more natural way, is what > I use. > > Much like why I use LaTeX for presentations rather than some new > 'fangled' tool for giving presentations :P > > Yeah, you're just weird :) >>> or mix inner/outer domains, <insert other >>> braindead-ness>. It's more for me whilst looking through my SQL logs, >>> however I also slip into my Reply-Message a comment if the >>> authentication attempt was against a test (non-production use) account. >>> >> Yeah that's fine... Just strip out the Reply-Message before you send the >> packet. >> >> > Do you know of an *alternative* way to send human readable messages to > sysadmin's at other sites? > > Eduroam VSAs.
The EAP/Reply message combination is disallowed for a good reason, and i've seen it break things in real world scenarios. ProCurve Switch + Linux Laptop (any version of WPA Supplicant) + Reply-Message + EAP-Message = Rapid Re-Authentication. This has been discussed before on list. Jouni Malinen acknowledged the issue, but quite rightly did nothing to correct it. In the end it's the RADIUS server breaking the RFC, it's not the supplicants job to deal with Sys Admins screwups. > Scenario: > > The user's we block for AUP violations or whatever might be roaming. > Users *lie*, always, and cannot be trusted. If I just straightly block > the user and the user grumbles to the remote sysadmin they are going to > pester me. If they look in their logs there is a possibility that they > are logging Reply-Message and can see "this user is actually blocked and > nothing on a technical level is wrong". > > They're mandated to record all packets sent and received to/from the NRPS. > It might be upsetting the RFC's, but I challenge you (for example) to > pick a selection of IPv6 related RFC's that do not clash with one > another. RFC 3579: 2.6.5. Displayable Messages The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the peer. This is similar in concept to EAP Notification, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet. I don't give a damn whether they conflict (though I don't believe this particular section conflicts with any other RFCs) ; that's not the point. The case documented above will undoubtedly have been seen at sites other than ours. It puts load on the NRPS it puts loads on the ORPS and it fills our RADIUS server logs with spurious entries. > I'm guessing Alan could probably point out where the RFC's > conflict against one another in the RADIUS world too. > > If my Reply-Message's break something, I'll stop sending them. I think > you need to stop worrying about the Reply-Message's and maybe look out > for those borken folk who keep insisting telling me to put their users > in a particular VLAN, maybe we could just get JANET to refuse those IAS > users. :) > Erg... this is why you filter the attributes in the proxy-reply. But yes I know... it's horrible. I wish we could mandate use of FreeRADIUS/ RADIATOR but it's not going to happen. >> Wait are you talking about something really quite evil here? Like using >> EAP as a VPN tunnel ?!?! >> >> > Again, why *bother*. If someone is sending a malicious RADIUS server an > Access-Request message, all it has to do is send back an Access-Accept. > Hell you can then tunnel over something that probably has less latency > and is just as stealthy like DNS. Hell or just use a real VPN, or > forget the lot and just use a 3G modem. > For when the visited site screws up and puts you in a non routeable VLAN. Or just for fun... Arran
signature.asc
Description: OpenPGP digital signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
