Re: EAP Session resumption && reply attributes
--On Thursday, January 21, 2010 10:05:36 AM + Alexander Clouter wrote: James J J Hooper wrote: < How did you get around the "my policy rejects you now, but i've already sent a tunneled success TLV in the TLS tunnel and you're now ignoring my EAP-Failure messages" issue... or are you just happily ignoring it/ encouraging adoption of TTLS-PAP like I was? :) Our setup never changes its mind :-) Any valid credentials always get a connection. ...only whether that connection is Internet/port limited/captive redirect to web message server changes. Arran is probably referring to that with EAP TLS reauth you are actually using the authentication (and possibly authorisation) credentials from a previous session that can even be a few days prior. You might decide to do some user focused authorisation in the post-auth section[1], for example you might reject a user if their user account has been disabled, or if they are in the wrong group or maybe they have been a Bad Bad Boy(tm) :) You might then have them marked 'disabled' in your LDAP tree however the EAP-TLS reauth bit never gets that farso you end up accepting them. That's precisely what I meant, although I didn't explain it. If the credentials where initially valid, for the life of the connecting device being able to resume it's session, we always send back an Access-Accept (even if their account is now "disabled"). We then outer post-post auth to put them in a suitable network. (i.e. Naughty users get a only a WRD to say so.) -James -- James J J Hooper Network Specialist Information Services University of Bristol +44 (0)117 331 7080 (17080 internal) -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
James J J Hooper wrote: < >> How did you get around the "my policy rejects you now, but i've already >> sent a tunneled success TLV in the TLS tunnel and you're now ignoring my >> EAP-Failure messages" issue... or are you just happily ignoring it/ >> encouraging adoption of TTLS-PAP like I was? :) > > Our setup never changes its mind :-) Any valid credentials always get a > connection. ...only whether that connection is Internet/port > limited/captive redirect to web message server changes. > Arran is probably referring to that with EAP TLS reauth you are actually using the authentication (and possibly authorisation) credentials from a previous session that can even be a few days prior. You might decide to do some user focused authorisation in the post-auth section[1], for example you might reject a user if their user account has been disabled, or if they are in the wrong group or maybe they have been a Bad Bad Boy(tm) :) You might then have them marked 'disabled' in your LDAP tree however the EAP-TLS reauth bit never gets that farso you end up accepting them. Again, another reason not to do user based authorisation. :) Cheers [1] or indirectly in the authentication section via an amended LDAP filter where you only authenticate against user objects where 'accountdisabled=false' or something -- Alexander Clouter .sigmonster says: Your aim is high and to the right. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
On 20/01/2010 23:36, Arran Cudbard-Bell wrote: On 1/17/2010 8:37 AM, Alexander Clouter wrote: James J J Hooper wrote: In order to also return e.g. VLAN IDs (that could be computed from the inner User-Name in a non-session-resumption enabled config), I can move the config that sets the VLAN to the outer tunnel post-auth&& ensure the inner tunnel sets: reply:outer User-Name to request:inner User-Name and then key my VLAN computation (in outer post-auth) from reply:User-Name. We have been doing authorisation depending on the outer layer since summer. How did you get around the "my policy rejects you now, but i've already sent a tunneled success TLV in the TLS tunnel and you're now ignoring my EAP-Failure messages" issue... or are you just happily ignoring it/ encouraging adoption of TTLS-PAP like I was? :) -Arran Our setup never changes its mind :-) Any valid credentials always get a connection. ...only whether that connection is Internet/port limited/captive redirect to web message server changes. This also avoids the 'wireless doesn't accept my password' queries at the helpdesk (which end up with the user messing around and perhaps turning off certificate validation to see if that "fixes it" etc). Instead facebook.com returns "you're a virus infected monster - use a different PC to read your email. We've sent you instructions" etc. -James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
Arran Cudbard-Bell wrote: > > On 1/17/2010 8:37 AM, Alexander Clouter wrote: >> James J J Hooper wrote: >> >>> In order to also return e.g. VLAN IDs (that could be computed from the >>> inner User-Name in a non-session-resumption enabled config), I can move >>> the config that sets the VLAN to the outer tunnel post-auth&& ensure the >>> inner tunnel sets: >>>reply:outer User-Name to request:inner User-Name >>> and then key my VLAN computation (in outer post-auth) from reply:User-Name. >>> >> We have been doing authorisation depending on the outer layer since >> summer. > > How did you get around the "my policy rejects you now, but i've already > sent a tunneled success TLV in the TLS tunnel and you're now ignoring my > EAP-Failure messages" issue... or are you just happily ignoring it/ > encouraging adoption of TTLS-PAP like I was? :) > Probably as I do not use user *authorisation*... :P It's nuts to do user authorisation for network nodes, user authorisation lives further up the stack and should stay in the realm of layer 5 where it belongs. What I do though is let user authentication 'bootstrap' the host authentication, so you think of it that "I user xyz vouch that I am responsible for MAC address abc for the duration of my session"; with that in mind you can forget about user authorisation...which is just a plain nasty idea anyway. If yer interested, you can see what I'm doing more or less: http://stuff.digriz.org.uk/freeradius-public-20100101.tar.gz Been a few minor changes/cleanups since though so be gentle ;) Cheers -- Alexander Clouter .sigmonster says: Preserve Wildlife! Throw a party today! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
On 1/17/2010 8:37 AM, Alexander Clouter wrote: James J J Hooper wrote: In order to also return e.g. VLAN IDs (that could be computed from the inner User-Name in a non-session-resumption enabled config), I can move the config that sets the VLAN to the outer tunnel post-auth&& ensure the inner tunnel sets: reply:outer User-Name to request:inner User-Name and then key my VLAN computation (in outer post-auth) from reply:User-Name. We have been doing authorisation depending on the outer layer since summer. How did you get around the "my policy rejects you now, but i've already sent a tunneled success TLV in the TLS tunnel and you're now ignoring my EAP-Failure messages" issue... or are you just happily ignoring it/ encouraging adoption of TTLS-PAP like I was? :) -Arran smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
Hi, > In order to also return e.g. VLAN IDs (that could be computed from the > inner User-Name in a non-session-resumption enabled config), I can move > the config that sets the VLAN to the outer tunnel post-auth && ensure the > inner tunnel sets: >reply:outer User-Name to request:inner User-Name > and then key my VLAN computation (in outer post-auth) from reply:User-Name. > > I can see other possibilities to do this (e.g. cache > Tunnel-Private-Group-Id in the TLS session cache), but the above seems ok > to me. Can anyone on the list spot any problems, something that I've > missed / gotchas with the above? this is a fine idea - you only need to hit the handling logic post-auth (after the basic accept/reject has been done). just ensure that you dont pass this inner-id stuff back to remote proxies. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
On 17/01/2010 20:22, Alan Buxey wrote: Hi, One thing to remember, is for *your* users roaming at other universities to remember to remove the reply:User-Name attribute to protect the guilty. :) the best thing to do for this is to create a new virtual server - eg 'eduroam' - which is identical to your normal stuff EXCEPT that it doesnt return VLANs etc. just ensure that this virtual server is only called when a request comes from the national proxies (or perhaps, just not one of your own NAS - eg properly assign your own NAS to their own internal virtual server) - et voila...you cannot accidentally mess up remote connections etc yep - that's what we are already doing for eduroam ;-) -James - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
Hi, > One thing to remember, is for *your* users roaming at other universities > to remember to remove the reply:User-Name attribute to protect the > guilty. :) the best thing to do for this is to create a new virtual server - eg 'eduroam' - which is identical to your normal stuff EXCEPT that it doesnt return VLANs etc. just ensure that this virtual server is only called when a request comes from the national proxies (or perhaps, just not one of your own NAS - eg properly assign your own NAS to their own internal virtual server) - et voila...you cannot accidentally mess up remote connections etc alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP Session resumption && reply attributes
James J J Hooper wrote: > > In order to also return e.g. VLAN IDs (that could be computed from the > inner User-Name in a non-session-resumption enabled config), I can move > the config that sets the VLAN to the outer tunnel post-auth && ensure the > inner tunnel sets: > reply:outer User-Name to request:inner User-Name > and then key my VLAN computation (in outer post-auth) from reply:User-Name. > We have been doing authorisation depending on the outer layer since summer. The best part about doing this is that all you really care about from the inner layer is if it gave you Access-Accept or Access-Reject[1]; the cached username is handy to make sure your Accounting packets are then nice and helpful; One thing to remember, is for *your* users roaming at other universities to remember to remove the reply:User-Name attribute to protect the guilty. :) Cheers [1] in my opinion[2] it's a Bad Idea(tm) to do *user* authorisation...host authorisation is fine though [2] the 'why' is in how do you handle multi-user hosts where there *could* be multiple simultaneous interactive users on the host -- Alexander Clouter .sigmonster says: Memory fault - where am I? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP Session resumption && reply attributes
Hi All,
When a client does session resumption:
cache { enable = yes} in eap.conf
The session User-Name (from previous access-accept) is restored from the
cache e.g:
[ttls] Skipping Phase2 due to session resumption
[ttls] Adding cached attributes to the reply:
User-Name = "ab1234"
In order to also return e.g. VLAN IDs (that could be computed from the
inner User-Name in a non-session-resumption enabled config), I can move
the config that sets the VLAN to the outer tunnel post-auth && ensure the
inner tunnel sets:
reply:outer User-Name to request:inner User-Name
and then key my VLAN computation (in outer post-auth) from reply:User-Name.
I can see other possibilities to do this (e.g. cache
Tunnel-Private-Group-Id in the TLS session cache), but the above seems ok
to me. Can anyone on the list spot any problems, something that I've
missed / gotchas with the above?
Many thanks,
James
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
