headers
Jouni Malinen | 1 Dec 2006 03:52
Picon
Picon

Re: WinXP+PEAP+Cert Behavior

On Thu, Nov 30, 2006 at 06:11:52AM +0100, Benn wrote:

> Thanks for the well crafted answer, that was basically what I expected to hear, but was hoping otherwise :) 
The interesting thing is, the client is definitely sending out some kind of packet which gets turned into a
request to the radius server:
> 
> <<HOSTAPD
>    IEEE 802.1X: 9 bytes from 00:13:d3:6f:b1:4e
>       IEEE 802.1X: version=1 type=0 length=5
>       EAP: code=2 identifier=1 length=5 (response)
>    ath0: STA 00:13:d3:6f:b1:4e IEEE 802.1X: received EAP packet (code=2 id=1 len=5) from STA: EAP
Response-Identity (1)
>    ath0: STA 00:13:d3:6f:b1:4e IEEE 802.1X: STA identity ''

If the client is using Microsoft's WZC, this frame is likely the probe
it uses for autodetecting the network security parameters. If you are
more interested in that, take a look at Wireless Provisioning Services
(WPS). Microsoft has some documention available for it.

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 0 comments |
headers
Pavel Roskin | 1 Dec 2006 07:53
Picon

Re: Madwifi + wpa_supplicant (cannot get IP)

Hello!

On Wed, 2006-11-29 at 20:40 -0500, Carlos Moffat wrote:
> You're right, is not. I'm trying to get wpa_supplicant to work 'cause
> Network-Manager uses it for all connection, independent of whether you
> need WPA or not. This seems like a good idea, except that now I have
> moving part to worry about. I don't know where to file a bug, 'cause I
> don't know if the problem is with Madwifi or wpa_supplicant (NM seems to
> be innocent)

wpa_supplicant is supposed to work even without WPA and WEP.  I can make
it work with HostAP driver on the client side, even using the wext
driver in wpa_supplicant.

With the current madwifi, things are different.  Sometimes it works,
sometimes it doesn't.

That's what I'm seeing if the connection would work:

# wpa_supplicant -D wext -i ath0 -c hostap.conf 
Trying to associate with 00:0b:6b:56:01:bb (SSID='WDS1' freq=2437 MHz)
ioctl[SIOCSIWAUTH]: Invalid argument
WEXT auth param 1 value 0x1 - Association request to the driver failed
Associated with 00:0b:6b:56:01:bb
CTRL-EVENT-CONNECTED - Connection to 00:0b:6b:56:01:bb completed (auth)
[id=0 id_str=]

And that's what I'm seeing when no traffic can pass:

# wpa_supplicant -D wext -i ath0 -c hostap.conf
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benn | 1 Dec 2006 07:59

Re: WinXP+PEAP+Cert Behavior

On Thu, Nov 30, 2006 at 12:46:03PM -0500, Bryan Kadzban wrote:
> On Thu, Nov 30, 2006 at 05:29:03PM +0100, Benn wrote:
> > and even having the initial
> > handshake in plaintext would be acceptable if the rest of the
> > connection is within a pipe.
> 
> Hmm...  I'm thinking that your requirements here are contradictory.
> ;-)

Yes.  I know.  I said the same thing, actually :)

> If anyone can associate and get a key, then I don't think the encryption
> that's in place for the other clients is really worth anything anymore
> either.  I think it may be possible to start basically "stealing"
> traffic (see e.g. Ettercap) using ARP poisoning.  If you're able to get
> the server to send you data that was meant for another machine, then
> your machine will be able to decrypt it.

Well, the key rotation should keep it from being interceptable simply from any point, but snarfing the
entire stream would, without a shared secret of some kind, of course compromise the whole setup.  So
naturally if WinXP boxs were set up to default permit SSL signed certificates (which has the problems
you've previously mentioned, and others) that'd be avoidable.  Otherwise, our friend Mallory will have a fieldday.

> But if that's still acceptable, and your management *really* only wants
> the appearance of security, then you could probably hack up the internal
> RADIUS server to always send Access-Accepts after the first packet.
> Actually, you could probably hack together a fairly small standalone
> RADIUS server that responds to anything on udp/1812 with an
> Access-Accept (and at that point, you might as well just not bother
> checking the RADIUS authenticator either -- although you would need to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bryan Kadzban | 1 Dec 2006 14:31

Re: WinXP+PEAP+Cert Behavior

Benn wrote:
> Well, the key rotation should keep it from being interceptable simply
>  from any point,

Not really.  The key rotation doesn't matter here -- the attacker would
be sending broadcast ARP responses using the known group key at the
moment, claiming that his machine had somebody else's IP.  So when a
server tries to send to that IP, it sends to the attacker's MAC instead
of the real MAC.  The AP will happily use the attacker's key to encrypt
this traffic, because it only looks at the target MAC.

Because the attacker already has a valid association, the new group key
will be given to him just like any other valid client.  And so at the
appropriate time, the attacker's ARP responses will start being
encrypted with the new group key.

This isn't related to getting onto the network; this is an attack that
can be carried out after associating and going through the EAP
transaction, if everyone is always allowed.  It's a half-DoS, half-MitM
attack (you can do either).

> Interesting you mention that -- I actually tweaked freeradius to do 
> exactly that, but lacking the proper response Message-Authenticator
> it was dropped.  Is that the kind of thing that I can easily
> generate?

You should only require the RADIUS shared secret.  It may be easier if
you write your own "RADIUS" server (in quotes because it isn't; it'll
just blindly generate accept messages); then you can take the shared
secret and generate the proper authenticator.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tino Keitel | 2 Dec 2006 14:03
Picon
Picon

wpa_supplicant broken when card is ejected/inserted

Hi folks,

I used to use this setup:

- wpa_supplicant always running

- Cardbus card that I insert when I need it

I noticed at some point that this doesn't work anymore. Now I tried to
repair my setup, and observed the following:

1.

- card inserted, supplicant started: can associate, dhclient gets an IP

- card ejected, supplicant goes to sleep

- card inserted again, supplicant seems to associate, but dhclient
  doesn't get an IP [1]

- supplicant restarted, dhclient gets an IP

2.

- card not inserted, supplicant started and waiting for the interface

- card inserted, supplicant can not associate [2]

- supplicant restarted, can associate, dhclient gets an IP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouke Witteveen | 2 Dec 2006 19:41
Picon

new wired driver code

Hello,

For some stupid reason my ISP uses WPA on its connection. So in order
to get my FreeBSD box on the net I need to make driver_wired.c from
the wpa_supplicant work in BSD. I downloaded the source (v0.4.8) and
tried to compile. A few days of reading a lot of c code in order to
lean c later I came up with the following changes:

BSD doesn't provide the following include, and the code that uses it
is __linux__ only anyway, so I added the following if block:
---driver_wired.c------
#ifdef __linux__
#include <netpacket/packet.h>
#endif /* __linux__ */
------

Next I searched for all non-BSD compliant code and found that ifreq
has no ifr_hwaddr in BSD (this is used in wpa_driver_wired_multi). The
following adjustment however does not work though I'm pretty positive
something alike should do the trick) because the ioctl complains about
invalid arguments during runtime:
---driver_wired.c (wpa_driver_wired_multi)------
#ifdef __linux__
        ifr.ifr_hwaddr.sa_family = AF_UNSPEC;
        memcpy(ifr.ifr_hwaddr.sa_data, addr, ETH_ALEN);
#else /* __linux__ */
        ifr.ifr_addr.sa_family = AF_UNSPEC;
        memcpy(ifr.ifr_addr.sa_data, addr, ETH_ALEN);
#endif /* __linux__ */
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jouni Malinen | 3 Dec 2006 00:59
Picon
Picon

Re: [PATCH] Avoid a segmentation fault

On Thu, Nov 30, 2006 at 02:27:19PM +0100, Nicolas DICHTEL wrote:

> please find enclosed a patch to avoid segmentation fault when some
> errors occur when loading certificats.

Thanks, applied.

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 0 comments |
headers
于爱民 | 4 Dec 2006 03:33
Picon

use case of FilterID in hostap

Hello every one !

    I am doing some experience about trusted network connection.I use hostAPd as my Access Point.As the TNC
Specification required,the AP should support FilterID to isolate the current connection to specific
location.So can someone add the function handling FilterID .
    Thank you very much!!

	Previous Mail:
>  On Fri, Oct 20, 2006 at 03:24:36PM +0800, ?????? wrote:

> 	I am using HostAPd(on a wired Ethernet Card) and a Radius server to do some experience. I want to know if the
HostAPd support the Filter-Id Attribute that is wrapped in a Accept-Accept packet.

> No, hostapd does not control any filtering that would benefit of this
> attribute and as such, it is not parsed from Access-Accept. Do you have
> some specific use cases in mind for this attribute? What would you like
> hostapd to do if the RADIUS server includes this attribute? I could
> think of adding a callback function to be called when Access-Accept is
> received. This function would likely be empty at least for the time
> being, but there would be a clear place to add some custom code if
> someone wants to add extra actions based on Access-Accept. It would also
> be possible to just send this frame to another process to allow changing
> this behavior without having to modify hostapd.
Permalink | Reply | 501 comments |
headers
Jouni Malinen | 4 Dec 2006 03:54
Picon
Picon

Re: use case of FilterID in hostap

On Mon, Dec 04, 2006 at 10:33:15AM +0800, ?????? wrote:

>     I am doing some experience about trusted network connection.I use hostAPd as my Access Point.As the TNC
Specification required,the AP should support FilterID to isolate the current connection to specific
location.So can someone add the function handling FilterID .

Can you please tell us where to get TNC specification that specifies how
FilterID needs to be supported?

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 501 comments |
headers
ramprasad.rajendran | 4 Dec 2006 07:01

Username on EAP-MSCHAPv2


Hi,
I am using wpa_supplicant version 0.5.5 and hostapd 0.4.9 as the
authenticator cum RADIUS.
I am testing with EAP-MSCHAPv2

The username in the hostapd's user and password file has the format
DOMAIN\user.

I tried setting the username at the configuration file at the supplicant
to user <at> DOMAIN, DOMAIN\user, but gets rejected.
Is there any particular format in which the user name must be used for
MSCHAPV2.

Thanks in advance
----
ram

The information contained in this electronic message and any attachments to this message are intended for
the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability for any damage caused by any
virus transmitted by this email.

www.wipro.com
Permalink | Reply | 1 comment |

Gmane