Reply-message and supplicant

[Arran Cudbard-Bell]

Alexander Clouter wrote:
> Arran Cudbard-Bell <a.cudbard-bell at sussex.ac.uk> wrote:
>   
>> Alexander Clouter wrote:
>>     
>>> A.L.M.Buxey at lboro.ac.uk 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090607/bd79e5bc/attachment.pgp>