Re: Reply-message and supplicant
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
# # Make Reply-Message RFC3748 2.6.5 compliant # * # # Make Reply-Message RFC3579 2.6.5 compliant # Odd that the mime encoded GPG sig validates ok, but the in-line one doesn't... I wonder what's going on there. signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
Arran Cudbard-Bell wrote: This isn't actually mandated anywhere though is it? This is just random vendor specific behaviour ? IIRC, there's a suggestion to do this, but the actual cut-off number is vendor-specific. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
On 8/6/09 11:27, a.l.m.bu...@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-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
a.l.m.bu...@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re: Reply-message and supplicant
A couple comments on this thread... The problem with including Reply message text in EAP is that the Reply attribute comes in the Accept or Reject message, which will be carrying the EAP Success or Fail. EAP Success/Faillike a Reject doesn't carry attributes, so a Reply would have to be turned into a Notification message by a smart AP and sent as an exchange prior to the Success/Fail. That doesn't look likely. An EAP method can send it's own Notification message including any text it wants. This will get wrapped in RADIUS with an EAP message attribute in an Access-Challenge, and go the normal path. The next problem is getting the supplicant to do anything with it, like show the user. This can be a problem if your supplicant is Windows. The Windows wireless EAP system silently discards EAP Notification messages on XP. On Vista, an EAPHost API method can get them if they ask. A RasEap API method is SOL, because they are discarded and not responded to, breaking the protocol. (Ask me how I know ;^} ) Look for a forthcoming patch for Vista. Dave.Jun 8, 2009 06:38:05 AM, freeradius-users@lists.freeradius.org wrote: a.l.m.bu...@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 lookfor a message, and do *something* with it.Alan DeKok.-List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re: Reply-message and supplicant
hi, ome useful information...however, people will be far more likely to read your email if you send it as plain text rather than HTML. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
On 8/6/09 13:26, David Mitton wrote: A couple comments on this thread... The problem with including Reply message text in EAP is that the Reply attribute comes in the Accept or Reject message, which will be carrying the EAP Success or Fail. EAP Success/Fail like a Reject doesn't carry attributes, so a Reply would have to be turned into a Notification message by a smart AP and sent as an exchange prior to the Success/Fail. That doesn't look likely. ProCurve wired switches do this in the earlier software versions H.10.74. They actually send the EAP-Notification *after* the EAP-Success or EAP-Failure which is what breaks WPA-Supplicant. As far as its state machines are concerned the EAP-Success/EAP-Failure messages signifies the end of authentication... so if it receives an EAP-Notification message *after* the EAP-Success/EAP-Failure, it sees it as the NAS requesting to restart authentication. An EAP method can send it's own Notification message including any text it wants. This will get wrapped in RADIUS with an EAP message attribute in an Access-Challenge, and go the normal path. The next problem is getting the supplicant to do anything with it, like show the user. WPA_Supplicant shows the contents of EAP-Notifications, the Mac OSX supplicant logs the message to /var/system.log, windows supplicant largely ignores them. This can be a problem if your supplicant is Windows. The Windows wireless EAP system silently discards EAP Notification messages on XP. On Vista, an EAPHost API method can get them if they ask. A RasEap API method is SOL, because they are discarded and not responded to, breaking the protocol. (Ask me how I know ;^} ) Look for a forthcoming patch for Vista. Arran -- Arran Cudbard-Bell (a.cudbard-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
Arran Cudbard-Bell a.cudbard-b...@sussex.ac.uk wrote: On 8/6/09 13:26, David Mitton wrote: A couple comments on this thread... The problem with including Reply message text in EAP is that the Reply attribute comes in the Accept or Reject message, which will be carrying the EAP Success or Fail. EAP Success/Fail like a Reject doesn't carry attributes, so a Reply would have to be turned into a Notification message by a smart AP and sent as an exchange prior to the Success/Fail. That doesn't look likely. ProCurve wired switches do this in the earlier software versions H.10.74. They actually send the EAP-Notification *after* the EAP-Success or EAP-Failure which is what breaks WPA-Supplicant. As far as its state machines are concerned the EAP-Success/EAP-Failure messages signifies the end of authentication... so if it receives an EAP-Notification message *after* the EAP-Success/EAP-Failure, it sees it as the NAS requesting to restart authentication. http://tools.ietf.org/html/rfc3748#section-5.2 Implies that if you send EAP-Notification with an EAP-Success/Failure you are being a bad bad boy. However that is me reading 'prior to completion' meaning any packet before EAP-Success/Failure which does not include that final packet. Cheers -- Alexander Clouter .sigmonster says: MOKE DAT YIGARETTE -- The Last Coin, James P. Blaylock - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
Arran Cudbard-Bell a.cudbard-b...@sussex.ac.uk wrote: Alexander Clouter wrote: a.l.m.bu...@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
Alexander Clouter wrote: Arran Cudbard-Bell a.cudbard-b...@sussex.ac.uk wrote: Alexander Clouter wrote: a.l.m.bu...@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
Re: Reply-message and supplicant
Arran Cudbard-Bell a.cudbard-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
a.l.m.bu...@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
a.l.m.bu...@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-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Clouter wrote: a.l.m.bu...@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- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
2009/6/5 a.l.m.bu...@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 - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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
Re: Reply-message and supplicant
On 5/6/09 15:21, a.l.m.bu...@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-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
2009/6/5 a.l.m.bu...@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 - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
On 5/6/09 16:18, Sergio Belkin wrote: 2009/6/5a.l.m.bu...@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-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
On 5/6/09 19:10, a.l.m.bu...@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... http://technet.microsoft.com/en-us/library/cc785145.aspx That is indeed interesting. Sent you an email off-list. Arran -- Arran Cudbard-Bell (a.cudbard-b...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Reply-message and supplicant
Arran Cudbard-Bell a.cudbard-b...@sussex.ac.uk wrote: On 5/6/09 19:10, a.l.m.bu...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
