Home page logo

basics logo Security Basics mailing list archives

RE: 802.1x and PEAP
From: Camillo Bucciarelli <camillobucciarelli () yahoo it>
Date: Thu, 4 Mar 2004 16:43:04 +0100 (CET)

Can I  use these features(Enhanced MIC verification
for WEP, Temporal Key Integrity Protocol, Broadcast
WEP Key rotation) with a non-cisco wireless adatpter?
Such as a 3com wireless PCMCIA? 
Actually I've tried a cisco aironet 340 wireless card.

Camillo Bucciarelli

 --- shankarnarayan.d () netsol co in ha scritto: > This
can be done best on the wireless networks
having AP's from Cisco. The
others are still in the process of accomplishing the
same on their Access
Points (most have done it, some are yet to
accomplish the same). The
broadcast key is negotiated for the first time and
then the same is changed
at periodic intervals (configurable by an
administrator). The old broadcast
key is used to encrypt the new key and the same is
broadcast out to all the
clients on the access point at the expiry of the
administrator defined time
limit. On a Cisco you would use the following
commands on the Aironet 1100/
1200 (with IOS) in order
BM_1036542configure terminal
interface dot11radio { 0 | 1 }
broadcast-key change seconds
copy running-config startup-config
-----Original Message-----
From: Camillo Bucciarelli
[mailto:camillobucciarelli () yahoo it] 
Sent: Wednesday, March 03, 2004 3:03 PM
To: shankarnarayan.d () netsol co in
Subject: RE: 802.1x and PEAP
this is what I need to know.
I have another question: I need to use 802.1x in
order to enable the
"broadcast key rotation"?

shankarnarayan.d () netsol co in wrote:
The Lines below have been pulled straight from the
PEAP working draft. This
clearly defines that the initial negotiation of the
PEAP is as in the TLS -
thus providing the necessary security.
Hope this answers your question OR have I got it
wrong - If you believe this
is not the information that you were looking for
request you to please
rephrase your question


Protected EAP (PEAP) Version 2 is comprised of a

[1] In Part 1, a TLS session is negotiated, with
server authenticating
to the client and optionally the client to the
server. The
negotiated key is then used to encrypt the rest of

[2] In Part 2, within the TLS session, zero or more
EAP methods are
carried out. Part 2 completes with a success/failure
protected by the TLS session or a protected error
(TLS alert).

The PEAP conversation typically begins with an
optional identity
exchange. The initial identity exchange is used
primarily to route the
conversation to the EAP server. Since the initial
identity exchange
is in the clear, the peer MAY decide to place a
routing realm instead
of its real name in the EAP-Response/Identity.

In short, the first exchange is based on TLS where
certificates are used
much in the same way as that used in the EAP-TLS.
The remaining information
of identity etc is then pumped through the TLS
tunnel. Hence, EAP-TLS may be
one of the methods (actually the most common method)
used to establish the
tunnel (using certificates)


-----Original Message-----
From: Camillo Bucciarelli
[mailto:camillobucciarelli () yahoo it] 
Sent: Tuesday, March 02, 2004 3:46 PM
To: security-basics () securityfocus com
Subject: 802.1x and PEAP

Good morning,
I'm looking for detailed information about the
Protected EAP. I can't understand what the
and Access Server use to establish the TLS tunnel.
Here's an example:

Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=PEAP, V=0
(PEAP Start, S bit set)

EAP-Type=PEAP, V=0
(TLS client_hello)->
<- EAP-Request/
EAP-Type=PEAP, V=0
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Type=PEAP, V=0
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=PEAP, V=0
(TLS change_cipher_spec,
TLS finished)
EAP-Type=PEAP ->

TLS channel established
(messages sent within the TLS channel)

They exchange a server_key_exchange and a
client_key_exchange used to derive the session key. 

It seems to me that the key exchange between the
client and the server is done in clear text, but
means that I can actually sniff this exchange. Now,
this seems not logical to me. Anyone here has any
idea about "where" I am wrong ? Do the two elements
hash in some way the keys ? Or, another possibility,
do we actually have the client key encrypted with
public key that belongs to the server - that is of
course available - and we have the server key *only*
that is transmitted in clear text ? In the TLS
protocol of course the two key are encrypted with
ublic key of the "other end". But in PEAP ?

Thanks in advance,

Camillo Bucciarelli

Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi
allegati, l'antivirus,
il filtro Anti-spam


Free 30-day trial: firewall with virus/spam
protection, URL filtering, VPN,
wireless security

Protect your network against hackers, viruses, spam
and other risks with
Security Linux, the comprehensive security solution
that combines six

=== message truncated === 

Camillo Bucciarelli

Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l'antivirus, il filtro Anti-spam

Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off 
any course! All of our class sizes are guaranteed to be 10 students or less 
to facilitate one-on-one interaction with one of our expert instructors. 
Attend a course taught by an expert instructor with years of in-the-field 
pen testing experience in our state of the art hacking lab. Master the skills 
of an Ethical Hacker to better assess the security of your organization. 
Visit us at: 

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]