Re: Multiple Password Prompts
[EMAIL PROTECTED] wrote: > I agree. In their argument, they even pointed me to a security web site > that supposedly listed 42 freeradius vulnerabilities, most of which had > still not been addressed (according to them). Liars. This isn't just incompetence, it's pretty close to libel. > I visited the site, read the material, followed the links, and > apparently they just typed "freeradius" and clicked "search", and > didn't actually read the results, because half of the results were > totally unrelated and the rest were describing things that were > fixed in version 0.4 or something. Do that on CERT, for example, and you'll get stacks of hits for FreeRADIUS, most of which say things like "FreeRADIUS: no response from vendor for vulnerability FOO in Mozilla." Personally, I interpret their attitude as indicating that FreeRADIUS is significantly cutting into their sales. If they have to lie about it to make their sales, it shows that FreeRADIUS is so much better than their product that they just can't compete on a technical level. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple Password Prompts
- Original Message - From: Alan DeKok <[EMAIL PROTECTED]> Date: Friday, August 5, 2005 5:30 pm Subject: Re: Multiple Password Prompts > [EMAIL PROTECTED] wrote: > > If the server get's an incomplete reply to it's challenge, or no > reply,> will it resend it's challenge? > > No. RADIUS is entirely driven by the clients. > Gotcha > > Or, will the client sense that the server didn't respond to it's > > challenge response and start a new session. > > The client *does* see the Access-Challenge, but it decides for some > reason to stop talking to the server. > Yep...that's sort of weird. > > Of course, because each vendor has their own radius server and > > 802.1x client solution, they want to blame freeradius so that I'll > > buy their product. > > FreeRADIUs is interoperable with pretty much everything out there. > Novell is dumping their proprietary server for FreeRADIUS. Zyxel is > selling a $500 FreeRADIUS box (with some question of possible GPL > violations), and I know of 2 other companies using FreeRADIUs as part > of their RADIUS server solutions. > I agree. In their argument, they even pointed me to a security web site that supposedly listed 42 freeradius vulnerabilities, most of which had still not been addressed (according to them). I visited the site, read the material, followed the links, and apparently they just typed "freeradius" and clicked "search", and didn't actually read the results, because half of the results were totally unrelated and the rest were describing things that were fixed in version 0.4 or something. > > I'm trying my hardest to fight this, because I'm a big freeradius > > fan. > > Thanks. > No prob. Just keep it up. > > The debug on the Odyssey Client shows that it believes it sent the > > response to the challenge. The debug on the WLAN switch shows > that it > > forwards both the challenge from freeradius and the challenge > response> from the client. Freeradius debug appears to get the > response from the > > client, sees the outer credentials (anonymous, etc.), but doesn't > > process the tunneled information for some reason. > > Hmm... I do know that the odyssey client does some very weird > things. In some cases, it's interoperable *only* with Funk's server, > which is a nice way for them to say "other servers are broken", rather > than "our client is broken". > Yep, I'm beginning to suspect as much. > > So, does this mean that I should interpret the above enum to have > > elements 0-13, or 1-14, and match the numbers 7 and 13 with it's > > position in the enum? > > 0-13 > thanks > > I'm curious why we can see the TLS stuff during the first try > (13), but > > not the second try (7). What is the difference? > > The client is behaving differently the second time around. > > FreeRADIUS treats the two TLS sessions as being 100% unique. It > responds in the same way to the same input every time. So if one > session fails and the other succeeds, it's because the client is doing > something different. > Gotcha. > > I performed a packet capture using ethereal, listening on the > interface> that freeradius is running on. Did this on the box, not > inline. I > > would rather not post it to the list, but I'd be glad to send it > to you > > if you'd be willing to look at it. Let me know. > > Put it on a web page and mail me the link. > Will do. I'll shoot for tomorrow (08/06). > On a plus, the latest version of Ethereal appears to have stolen the > FreeRADIUS dictionary files, so the radius packets it decodes should > make a lot more sense. > Yeh...I noticed that. Very nice. > 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: Multiple Password Prompts
Josh Howlett <[EMAIL PROTECTED]> wrote: > > Zyxel is selling a $500 FreeRADIUS box (with some question of possible GPL > > violations) > > *sigh* > > If this is the case I hope you will inform the list. It was discussed on freeradius-devel a little. I've exchanged email with one of their sales reps, and was told: - zyxel complies with the GPL - there is no mention of GPL or "download" offer in the product - we offer source only to paying customers This is despite that fact that the GPL says: a) you must OFFER source b) anyone who gets binaries can request source The binaries are on their web site, for anyone to download. Running "strings" on it yeilds many references to FreeRADIUS-specific terms. Maybe I'll send their legal department a nice letter, asking for a CD of source, and saying that if they refuse to send me a CD, they should stop infringing on my (and others) copyright. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple Password Prompts
Alan DeKok wrote: Zyxel is selling a $500 FreeRADIUS box (with some question of possible GPL violations) *sigh* If this is the case I hope you will inform the list. josh. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple Password Prompts
[EMAIL PROTECTED] wrote: > If the server get's an incomplete reply to it's challenge, or no reply, > will it resend it's challenge? No. RADIUS is entirely driven by the clients. > Or, will the client sense that the server didn't respond to it's > challenge response and start a new session. The client *does* see the Access-Challenge, but it decides for some reason to stop talking to the server. > Of course, because each vendor has their own radius server and > 802.1x client solution, they want to blame freeradius so that I'll > buy their product. FreeRADIUs is interoperable with pretty much everything out there. Novell is dumping their proprietary server for FreeRADIUS. Zyxel is selling a $500 FreeRADIUS box (with some question of possible GPL violations), and I know of 2 other companies using FreeRADIUs as part of their RADIUS server solutions. > I'm trying my hardest to fight this, because I'm a big freeradius > fan. Thanks. > The debug on the Odyssey Client shows that it believes it sent the > response to the challenge. The debug on the WLAN switch shows that it > forwards both the challenge from freeradius and the challenge response > from the client. Freeradius debug appears to get the response from the > client, sees the outer credentials (anonymous, etc.), but doesn't > process the tunneled information for some reason. Hmm... I do know that the odyssey client does some very weird things. In some cases, it's interoperable *only* with Funk's server, which is a nice way for them to say "other servers are broken", rather than "our client is broken". > So, does this mean that I should interpret the above enum to have > elements 0-13, or 1-14, and match the numbers 7 and 13 with it's > position in the enum? 0-13 > I'm curious why we can see the TLS stuff during the first try (13), but > not the second try (7). What is the difference? The client is behaving differently the second time around. FreeRADIUS treats the two TLS sessions as being 100% unique. It responds in the same way to the same input every time. So if one session fails and the other succeeds, it's because the client is doing something different. > I performed a packet capture using ethereal, listening on the interface > that freeradius is running on. Did this on the box, not inline. I > would rather not post it to the list, but I'd be glad to send it to you > if you'd be willing to look at it. Let me know. Put it on a web page and mail me the link. On a plus, the latest version of Ethereal appears to have stolen the FreeRADIUS dictionary files, so the radius packets it decodes should make a lot more sense. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple Password Prompts
Thanks for the response. See below:
- Original Message -
From: Alan DeKok <[EMAIL PROTECTED]>
Date: Friday, August 5, 2005 11:03 am
Subject: Re: Multiple Password Prompts
> [EMAIL PROTECTED] wrote:
> > As I'm troubleshooting this, I generated another question in my
> head.
> > This time I'll give some freeradius debug (see blocks
> > between "*"):
> >
> > Here's an exerpt from first try (failure):
> ...
> > Sending Access-Challenge of id 186 to 192.168.3.2:1024
>
> That doesn't look like a failure to me. The supplicant may stop
> talking to the server, and start a new session, but the server thinks
> everything's OK.
>
Sorry...maybe I used the wrong word. By "failure", I meant that from
the end user's perspective, the first attempt was a failure.
If the server get's an incomplete reply to it's challenge, or no reply,
will it resend it's challenge? Or, will the client sense that the
server didn't respond to it's challenge response and start a new
session. I ask because, in talking to the vendors, there is a question
of which side is giving up, or which side isn't sending complete
requests/responses. Of course, because each vendor has their own radius
server and 802.1x client solution, they want to blame freeradius so that
I'll buy their product. I'm trying my hardest to fight this, because
I'm a big freeradius fan.
The debug on the Odyssey Client shows that it believes it sent the
response to the challenge. The debug on the WLAN switch shows that it
forwards both the challenge from freeradius and the challenge response
from the client. Freeradius debug appears to get the response from the
client, sees the outer credentials (anonymous, etc.), but doesn't
process the tunneled information for some reason.
> > I looked back through some of the output, and it seems that each
> time
> > it fails I get "eaptls_process returned 13", but when it is
> succeeds I
> > get "eaptls_process returned 7". Anyone know what 7 and 13
> represent
> > (please don't say 'sucess' or 'failure'...i'm hoping it more
> > meaningful than that).
>
> From src/modules/rlm_eap/types/rlm_eap_tls.h:
>
> typedef enum {
>EAPTLS_INVALID = 0,/* invalid, don't reply */
>EAPTLS_REQUEST,/* request, ok to send,
> invalid to receive */
>EAPTLS_RESPONSE, /* response, ok to receive,
> invalid to send */
>EAPTLS_SUCCESS,/* success, send success */
>EAPTLS_FAIL, /* fail, send fail */
>EAPTLS_NOOP, /* noop, continue */
>EAPTLS_START, /* start, ok to send, invalid
> to receive */
>EAPTLS_OK, /* ok, continue */
>EAPTLS_ACK,/* acknowledge, continue */
>EAPTLS_FIRST_FRAGMENT, /* first fragment */
>EAPTLS_MORE_FRAGMENTS, /* more fragments, to
> send/receive */
>EAPTLS_LENGTH_INCLUDED,/* length included */
>EAPTLS_MORE_FRAGMENTS_WITH_LENGTH, /* more fragments with
> length */
>EAPTLS_HANDLED /* tls code has handled it */
> } eaptls_status_t;
>
> So I don't see any particular reason why one session would succeed
> and the other would fail.
>
So, does this mean that I should interpret the above enum to have
elements 0-13, or 1-14, and match the numbers 7 and 13 with it's
position in the enum?
> > Also, anyone know what the rlm_eap_tls messages mean that accompany
> > the 'returned 13' block?
>
> Information about internal TLS stuff. There are a *lot* of TLS
> packets that go back and forth.
>
I'm curious why we can see the TLS stuff during the first try (13), but
not the second try (7). What is the difference? I agree...it seems
like there should nothing different between what the client sends in the
first try and the second.
> At this point, the only thing I can suggest is to put a packet
> capture on the net somewhere. That might give more information.
>
I performed a packet capture using ethereal, listening on the interface
that freeradius is running on. Did this on the box, not inline. I
would rather not post it to the list, but I'd be glad to send it to you
if you'd be willing to look at it. Let me know.
> 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: Multiple Password Prompts
[EMAIL PROTECTED] wrote:
> As I'm troubleshooting this, I generated another question in my head.
> This time I'll give some freeradius debug (see blocks
> between "*"):
>
> Here's an exerpt from first try (failure):
...
> Sending Access-Challenge of id 186 to 192.168.3.2:1024
That doesn't look like a failure to me. The supplicant may stop
talking to the server, and start a new session, but the server thinks
everything's OK.
> I looked back through some of the output, and it seems that each time
> it fails I get "eaptls_process returned 13", but when it is succeeds I
> get "eaptls_process returned 7". Anyone know what 7 and 13 represent
> (please don't say 'sucess' or 'failure'...i'm hoping it more
> meaningful than that).
From src/modules/rlm_eap/types/rlm_eap_tls.h:
typedef enum {
EAPTLS_INVALID = 0, /* invalid, don't reply */
EAPTLS_REQUEST, /* request, ok to send, invalid to
receive */
EAPTLS_RESPONSE,/* response, ok to receive, invalid to
send */
EAPTLS_SUCCESS, /* success, send success */
EAPTLS_FAIL,/* fail, send fail */
EAPTLS_NOOP,/* noop, continue */
EAPTLS_START, /* start, ok to send, invalid to
receive */
EAPTLS_OK, /* ok, continue */
EAPTLS_ACK, /* acknowledge, continue */
EAPTLS_FIRST_FRAGMENT, /* first fragment */
EAPTLS_MORE_FRAGMENTS, /* more fragments, to send/receive */
EAPTLS_LENGTH_INCLUDED, /* length included */
EAPTLS_MORE_FRAGMENTS_WITH_LENGTH, /* more fragments with length */
EAPTLS_HANDLED /* tls code has handled it */
} eaptls_status_t;
So I don't see any particular reason why one session would succeed
and the other would fail.
> Also, anyone know what the rlm_eap_tls messages mean that accompany
> the 'returned 13' block?
Information about internal TLS stuff. There are a *lot* of TLS
packets that go back and forth.
At this point, the only thing I can suggest is to put a packet
capture on the net somewhere. That might give more information.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple Password Prompts
As I'm troubleshooting this, I generated another question in my head. This time I'll give some freeradius debug (see blocks between "*"): Here's an exerpt from first try (failure): rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(cn=anonymous)' radius_xlat: 'o=sometree' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=sometree, with filter (cn=anonymous) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user anonymous authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 4 modcall: group authorize returns updated for request 4 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included * eaptls_verify returned 11 rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established eaptls_process returned 13 ** modcall[authenticate]: module "eap" returns handled for request 4 modcall: group authenticate returns handled for request 4 Sending Access-Challenge of id 186 to 192.168.3.2:1024 Here's an exerpt from the second attempt (success): rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(cn=anonymous)' radius_xlat: 'o=sometree' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=sometree, with filter (cn=anonymous) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user anonymous authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 5 modcall: group authorize returns updated for request 5 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 5 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included *** eaptls_verify returned 11 eaptls_process returned 7 *** rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 modcall[authorize]: module "preprocess" returns ok for request 5 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 5 rlm_ldap: - authorize rlm_ldap: performing user authorization for doe_john I looked back through some of the output, and it seems that each time it fails I get "eaptls_process returned 13", but when it is succeeds I get "eaptls_process returned 7". Anyone know what 7 and 13 represent (please don't say 'sucess' or 'failure'...i'm hoping it more meaningful than that). Also, anyone know what the rlm_eap_tls messages mean that accompany the 'returned 13' block? Thanks for any help! - Original Message - From: [EMAIL PROTECTED] Date: Thursday, August 4, 2005 6:40 pm Subject: Multiple Password Prompts > Hi, > > The Odyssey Client prompts at least twice for the password. Once > connected, clients can roam across different AP's within the same > WLAN > with no problems. Has anyone else experienced this problem with a > similar configuration? > > Running Environment: > > -- Freeradius Server = Gentoo Linux running FreeRADIUS v1.0.2 > -- User DB = Novell NetWare 6.5 SP3 w/ eDirectory 8.7.3.5 (LDAP) > -- Wireless Switch = Cisco Airespace 4100 WLAN Switch with WLAN > configured for WPA-TKIP using dynamic key exchange > -- Wireless AP = Cisco 1000 Series AP's (was Airespace) > -- Wireless Client = Funk Odyssey
Multiple Password Prompts
Hi, The Odyssey Client prompts at least twice for the password. Once connected, clients can roam across different AP's within the same WLAN with no problems. Has anyone else experienced this problem with a similar configuration? Running Environment: -- Freeradius Server = Gentoo Linux running FreeRADIUS v1.0.2 -- User DB = Novell NetWare 6.5 SP3 w/ eDirectory 8.7.3.5 (LDAP) -- Wireless Switch = Cisco Airespace 4100 WLAN Switch with WLAN configured for WPA-TKIP using dynamic key exchange -- Wireless AP = Cisco 1000 Series AP's (was Airespace) -- Wireless Client = Funk Odyssey Client v4.0.1 on Windows XP configured for WPA-TKIP and EAP-TTLS We have captured debug output on the Odyssey Client, on the Airespace WLAN switch, and on FreeRADIUS, as well as an ethereal sniff on the freeradius interface on the radius server. I can provide these as well as freeradius configs if needed. Thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
