Reply-message and supplicant
Hi, Is possible that Reply-message can be seen from laptops running the supplicant? Thanks in advance! -- -- Open Kairos http://www.openkairos.com Watch More TV http://sebelk.blogspot.com Sergio Belkin -
Hi Sergio,
Is possible that Reply-message can be seen from laptops running the supplicant?
Not with EAP no. You can use EAP-Notification packets, but very few supplicants display the contents to the user, and the server doesn't support their generation. Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Hi,
Hi Sergio,
Is possible that Reply-message can be seen from laptops running the supplicant?
Not with EAP no. You can use EAP-Notification packets, but very few supplicants display the contents to the user, and the server doesn't support their generation.
which is why rather useful messages can be sent from RADIUS server to RADIUS server so that admins can see what is going on but the users dont get to see such information alan
2009/6/5 <A.L.M.Buxey@lboro.ac.uk>:
Hi,
Hi Sergio,
Is possible that Reply-message can be seen from laptops running the supplicant?
Not with EAP no. You can use EAP-Notification packets, but very few supplicants display the contents to the user, and the server doesn't support their generation.
which is why rather useful messages can be sent from RADIUS server to RADIUS server so that admins can see what is going on but the users dont get to see such information
alan
Does file attrs.access_reject has to with you are talking about? -- -- Open Kairos http://www.openkairos.com Watch More TV http://sebelk.blogspot.com Sergio Belkin -
2009/6/5 <A.L.M.Buxey@lboro.ac.uk>:
Hi,
Does file attrs.access_reject has to with you are talking about?
in a way - that file lists the attributes that are allowed to pass after an access reject - you still have to set eg the Reply-Message *or some other VSA* to let the remote site know
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry for the stupid question, what does "EAP-Message =* ANY" mean? -- -- Open Kairos http://www.openkairos.com Watch More TV http://sebelk.blogspot.com Sergio Belkin -
On 5/6/09 16:18, Sergio Belkin wrote:
2009/6/5<A.L.M.Buxey@lboro.ac.uk>:
Hi,
Does file attrs.access_reject has to with you are talking about? in a way - that file lists the attributes that are allowed to pass after an access reject - you still have to set eg the Reply-Message *or some other VSA* to let the remote site know
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry for the stupid question, what does "EAP-Message =* ANY" mean?
Allow any value for EAP-Message. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
On 5/6/09 15:21, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Hi Sergio,
Is possible that Reply-message can be seen from laptops running the supplicant? Not with EAP no. You can use EAP-Notification packets, but very few supplicants display the contents to the user, and the server doesn't support their generation.
which is why rather useful messages can be sent from RADIUS server to RADIUS server so that admins can see what is going on but the users dont get to see such information
No they can't. Reply-Messages are prohibited in packets containing EAP-Message attributes. Which is why I specified an alternate VSA :P Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Hi,
No they can't. Reply-Messages are prohibited in packets containing EAP-Message attributes.
really? well...I guess if you believe in RFC 3579 and hope that everyone read section 2.2 of that - invalid packet discussion then you'd hope so... however, I see tonnes of packets proxied through the NRPS that have EAP-Message and Reply-Message in the same packet.
Which is why I specified an alternate VSA :P
aye. Microsoft actually have a 'Reason-Code' that is interesting... http://technet.microsoft.com/en-us/library/cc785145.aspx alan
On 5/6/09 19:10, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
No they can't. Reply-Messages are prohibited in packets containing EAP-Message attributes.
really? well...I guess if you believe in RFC 3579 and hope that everyone read section 2.2 of that - invalid packet discussion then you'd hope so... however, I see tonnes of packets proxied through the NRPS that have EAP-Message and Reply-Message in the same packet.
None of them are coming from Sussex though :)
Which is why I specified an alternate VSA :P
aye. Microsoft actually have a 'Reason-Code' that is interesting...
That is indeed interesting. Sent you an email off-list. Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk> wrote:
On 5/6/09 19:10, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
No they can't. Reply-Messages are prohibited in packets containing EAP-Message attributes.
really? well...I guess if you believe in RFC 3579 and hope that everyone read section 2.2 of that - invalid packet discussion then you'd hope so... however, I see tonnes of packets proxied through the NRPS that have EAP-Message and Reply-Message in the same packet.
None of them are coming from Sussex though :)
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. Cheers -- Alexander Clouter .sigmonster says: "But this one goes to eleven." -- Nigel Tufnel
Hi,
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. crack-pipe question of the day: could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube? hmmm.... alan
A.L.M.Buxey@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, 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.
crack-pipe question of the day:
could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
Alternatively the 'smart server-end' could just send an Access-Accept :) Cheers -- Alexander Clouter .sigmonster says: Available while quantities last.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Clouter wrote:
A.L.M.Buxey@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 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.
crack-pipe question of the day:
could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
Wait are you talking about something really quite evil here? Like using EAP as a VPN tunnel ?!?!
Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkorEF8ACgkQcaklux5oVKICSwCcCga36CjkrqGqbrr3YCyQGFfk LRkAoIIMlDiuHXHBPfamcwSCkpKf5KYs =w7Az -----END PGP SIGNATURE-----
Hi,
on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
Wait are you talking about something really quite evil here? Like using EAP as a VPN tunnel ?!?!
yes. if the supplicant is code I have written and the server is running a nice bit of PHP or PERL code that i have written then.....hmmm.... PoC ? alan
Hi,
on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
Wait are you talking about something really quite evil here? Like using EAP as a VPN tunnel ?!?!
yes. if the supplicant is code I have written and the server is running a nice bit of PHP or PERL code that i have written then.....hmmm.... PoC
You just have to make it appear to the NAS that you're doing EAP. You don't actually have to *do* EAP. There's no reason why you couldn't tunnel IPv4 so long as the packets had a valid EAP header prepended to them. Send your EAP start, send the identity response... then you can pretty much do whatever you like, so long as it has a valid EAP header and the end server is in on the trick. Had you got any special plans for this other than annoying administrators by filling up their logs with very large EAP messages ? Arran
Arran Cudbard-Bell wrote:
There's no reason why you couldn't tunnel IPv4 so long as the packets had a valid EAP header prepended to them. Send your EAP start, send the identity response... then you can pretty much do whatever you like, so long as it has a valid EAP header and the end server is in on the trick.
Most AP's will hang up on the EAP session after 40-50 packets. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
There's no reason why you couldn't tunnel IPv4 so long as the packets had a valid EAP header prepended to them. Send your EAP start, send the identity response... then you can pretty much do whatever you like, so long as it has a valid EAP header and the end server is in on the trick.
Most AP's will hang up on the EAP session after 40-50 packets.
Aww; and it seemed like such a nice concept. Most include a 'quiet-period' before they'll allow the supplicant to reattempt authentication. This isn't actually mandated anywhere though is it? This is just random vendor specific behaviour ? Arran
On 8/6/09 11:27, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
IIRC, there's a suggestion to do this, but the actual cut-off number is vendor-specific.
..and i guess this cutoff is reported as an EAP failure and therefore kit configured to block/deny access will mean the eg the 3rd tunnel creation will be the last for some time....
Yes. Some kit has a configurable 'quiet-period'. So that after the EAP-Success or EAP-Failure message, it'll wait for a specified period before allowing another authentication attempt on that port. At least this is true of ProCurve products, and it seems like a sensible feature so I'm sure Cisco et al will have implemented it too. Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote:
Alexander Clouter wrote:
A.L.M.Buxey@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. As for using the user file for policies, why would I care? It works, does what I need. 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
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? 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". 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. 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. :)
crack-pipe question of the day:
could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
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. Cheers -- Alexander Clouter .sigmonster says: Try `stty 0' -- it works much better.
Alexander Clouter wrote:
Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote:
Alexander Clouter wrote:
A.L.M.Buxey@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
Arran Cudbard-Bell <a.cudbard-bell@sussex.ac.uk> wrote:
... 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 us folks down here in London get (probably) more roaming than non-high university density areas it's a problem that's regular seen. It's a simple and effective way to avoid this problem and it seems to be behind about 80% of the reasons when users cannot roam.
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.
[snipped RFC grumblings]
Okay, okay, during my summer RADIUS refresh work I'll fix this. Cheers -- Alexander Clouter .sigmonster says: Life is a series of rude awakenings. -- R. V. Winkle
Hi,
Alternatively the 'smart server-end' could just send an Access-Accept :)
ah..but then things get logged and you have a session...and most likely then a local address at the visited site and you'll then have to use a VPN etc. with the nefarious way, all traffic is transmitted via the home RADIUS server...unfiltered, unlogged. nasty. alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
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.
# # Make Reply-Message RFC3748 2.6.5 compliant # rem_reply_message_if_eap { if("%{reply:EAP-Message}"){ update reply { Reply-Message -= "%{reply:Reply-Message}" } } else { noop } } It's not exactly hard...
crack-pipe question of the day:
could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network? in fact, is the inner EAP traffic limited at all? once the authentication outer layer is started i should be able to just keep throwing data back/forward through that tube?
Completely dependent on the EAP method. Though I suspect some NAS / Supplicants will set a maximum time limit on how long authentication can take to complete. Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkorDw8ACgkQcaklux5oVKJWoACfXpBXQf9cbKhZ08GCv74wIc9D nKwAnjOjHQTBuixKthuFT5mhJirfMab1 =bttU -----END PGP SIGNATURE-----
A.L.M.Buxey@lboro.ac.uk wrote:
could reply messages be used with some smart server-end code to provide a data communication channel? ie user A has code that attempts to use EAP with special username coding...the remote server is designed to throw responses in EAP messages...which the modified supplicant on the client can then extract? this could tunnel traffic through an 802.1X restricted network?
For TTLS, just use vendor-specific attributes inside of the TTLS tunnel. It shouldn't be too hard to modify the open source supplicants to look for a message, and do *something* with it. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alexander Clouter -
Arran Cudbard-Bell -
Sergio Belkin