[转载]The Unofficial 802.11 Security Web Page
信息来源：[url]http://www.drizzle.com/~aboba/IEEE/[/url]<p><H1>The Unofficial 802.11 Security Web Page</H1>
<P align=right>Last update: May 29, 2005</P>
<P>Lots of people are interested in wireless LAN security nowadays. Given that
level of interest, there's a need for accurate information on how the current
standards work, what's wrong with them, and the current thinking on how to fix
the problems. This page tries to gather relevant papers and standards in a
single place. </P>
<H2>Trends and overview</H2>
<H3>Ethernet Everywhere</H3>
Ethernet is on the verge of becoming the preferred
technology for LAN (wired and wireless), SAN, MAN and WAN. Increasing in
speed by an order of magnitude every 3 years, "Ethernet Everywhere" could be to
the next decade what "IP everywhere" was to the 1990s.
<P>IEEE 802.1X "network Port Authentication" was designed to scale with
Ethernet, adding no per-packet overhead, and bringing the management technology
of dialup networks to the wired and wireless LAN worlds. Here are presentations
on the current trends in Ethernet network access, both wired and wireless, and
an introduction to IEEE 802.1X and its applications.
<P><A href="http://www.drizzle.com/~aboba/IEEE/Ethernet_MAN.zip">Ethernet
Everywhere!</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/BAWUG.ppt">Wireless World 2001 and
BAWUG Presentations on IEEE 802.1X</A>
<H3>Thinking about network access authentication</H3>
<P>Here's a presentation on how we do authentication for network access and why
this is most often handled at layer 2 (PPP, IEEE 802.1X) rather than at layer 1
(802.11) or at layer 3 (Mobile IP) or higher.</P>
<P><A href="http://www.drizzle.com/~aboba/IEEE/BURP-BOF.zip">BURP BOF
presentation at IETF 50</A>
<P>
<H2>IEEE 802.11</H2>
<P>Here is where you can download 802.11 standards:
<A href="http://standards.ieee.org/getieee802/802.11.html">IEEE 802.11
specifications</A>
<H3>WEP security issues</H3>
<P>You've read all about the security problems with WEP. Here are the
papers and presentations that lay out the problem.
<P><A href="http://www.wardrive.net/wardriving/tools/">War Driving Tools</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-01-253r0-I-WEP2SecurityAnalysis.ppt">A
summary presentation on WEP security issues (from 802.11 Tgi)</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/wep-draft.zip">Berkeley WEP Security
Analysis Presentation (PDF)</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/wireless.pdf">Bill Arbaugh's paper on
cracking WEP (PDF)</A> <BR><A
href="http://www.crypto.com/papers/others/rc4_ksaproc.pdf">Fluhrer, Mantin and
Shamir's paper on cracking WEP</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/0-362.zip">Jesse Walker's "Unsafe at
any key length" paper</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/wepimprovF.ppt">Possible ways of
improving WEP (near impossible)</A>
<H3>Wireless LAN performance</H3>
<P>Recently, there has been interest in wireless LAN performance. This includes
work on MAC performance and capacity analysis, as well as interactions with TCP.
Here are some presentations and papers on the subject:</P>
<P><i><b>PHY performance</b></i></P>
<p><a href="http://www.pdos.lcs.mit.edu/~rtm/papers/p442-aguayo.pdf">Link-level
Measurements from an 802.11b Mesh Network</a>
<a href="http://www.pdos.lcs.mit.edu/roofnet/sigcomm-talk.pdf">(Slides)</a><BR>
<a href="http://mwnl.snu.ac.kr/~schoi/publication/Conferences/03-ICC-LA.pdf">
Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength
Measurement</a><BR>
<A href="http://www.tkn.tu-berlin.de/publications/papers/toie01_webout.pdf">
Measurements of a Wireless Link in an Industrial Environment</A><BR>
<A href="http://www.tkn.tu-berlin.de/publications/papers/powersaveletter.fm.pdf">
A Short Look at Power Save in 802.11</A><BR>
<a href="http://uluru.ee.unsw.edu.au/~tim/projects/measure.11/2003/thesis.pdf">
Characterizing Errors in Wireless LAN</a><BR>
<a href="http://uluru.ee.unsw.edu.au/~tim/measure.11/">802.11 Measurements
Project</a>
<P><i><b>MAC performance</b></i></P>
<P><A href="http://nms.lcs.mit.edu/~mbalazin/wireless/">802.11 Traffic
Characterization</A><BR>
<A href="http://www.csee.umbc.edu/~sweet/papers/80211adhoc.pdf">Performance in an Ad-hoc Environment</A><BR>
<A href="http://www.atheros.com/pt/atheros_range_whitepaper.pdf">Atheros White Paper on 802.11 performance</A><BR>
<A href="http://www.eurecom.fr/~nikaeinn/madnet2003/perf-802_11-madne-proct.ppt">Performance
Anomaly of 802.11b (Powerpoint)</A><BR><A
href="http://www.ieee-infocom.org/2003/papers/21_01.PDF">Performance Anomaly of
802.11b (PDF)</A><BR>
<A href="http://widen.korea.ac.kr/n-ano.pdf">Resolving 802.11 Performance Anomaly</A><BR>
<A href="http://citeseer.ist.psu.edu/cache/papers/cs/14005/http:zSzzSzwww.math.nus.edu.sgzSz~mattyczSz802.pdf/a-capacity-analysis-for.pdf">Capacity
analysis of 802.11</A><BR>
<A href="http://www.cs.virginia.edu/~cl4v/PRES_SLI/Multihop802-11.ppt">802.11
performance in a multi-hop network</A><BR>
<P><b><i>Transport </i></b><i><b>layer performance</b></i></P>
<P><A
href="http://www.drizzle.com/~aboba/IEEE/trigtran.pdf">Presentation on Transport
use of Layer 2 triggers by Sally Floyd (For IETF 55 TRIGTRAN BOF)</A><BR>
<A href="http://www.ensc.sfu.ca/people/faculty/ljilja/papers/opnetwork02_chiho_jack.pdf">Performance
evaluation of TCP over 802.11</A><BR>
<A href="http://www.ieee-infocom.org/2002/papers/230.pdf">Performance of Reliable
Transport Protocols over 802.11</A>
<H3>IEEE 802.11 handoff</H3>
<P>A number of elements contribute to 802.11 handoff delay including:</P>
<UL>
<LI>Probe/Beacon delay
<LI>Authentication delay (can be reduced by pre-authentication)
<LI>Association/Re-association delay </LI></UL>
<P>As shown by a recent University of Maryland paper, in an "open" network,
Probe/Beacon delay is responsible for the majority of the measured delay.
However, where Layer 2 authentication is used, authentication delay can also be
substantial. </P><P>
<H4>Experimental Studies</H4>
<A href="http://www.medialab.co.nz/assets/downloads/IEEE%20802.11%20Wireless%20LAN%20Security%20Performance.pdf">802.11
security performance</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-04-0377-01-frfh-analysis-roaming-techniques.ppt">Analysis
of Roaming Techinques (Submission to IEEE 802.11r, work in progress)</A><BR>
<a href="http://www.drizzle.com/~aboba/IEEE/11-04-0378-00-roaming-intervals-measurements.ppt">
Roaming intervals measurement (Submission to IEEE 802.11r, work in progress)</a><BR>
<A href="http://www.cs.umd.edu/~waa/pubs/handoff-lat-acm.pdf">An Empirical Analysis
of the IEEE 802.11 MAC Layer Handoff Process</A> <BR>
<A href="http://www.ieee802.org/11/Documents/DocumentHolder/3-417.zip">Improving
the Latency of the Probe Phase during IEEE 802.11 Handoff</A><BR>
<A href="http://www.it.kth.se/~hvelayos/papers/TRITA-IMIT-LCN%20R%2003-02%20Handover%20in%20IEEE%20802.pdf">Techniques
to Reduce IEEE 802.11b MAC Layer Handover Time</A><BR>
<A href="http://www.it.kth.se/~vatn/research/handover-perf.pdf">An Experimental
Study of IEEE 802.11b handover performance and its effect on voice
traffic</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-03-0563-00-000i-tgi-4-way-handshake-timings.ppt">
Measurements of 802.11i 4-way handshake latency (Submission to IEEE 802.11i, work in progress)</A><BR>
<H4>Proposals for Improvement</H4>
<A href="http://www.cs.cmu.edu/~glennj/scp/FixingAPSelection.html">Fixing AP
Selection</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/692.zip">Roaming
Candidates</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-04-0412-00-000k-thinking-about-site-report.ppt">Thinking
about the Neighbor Report (Submission to IEEE 802.11k, work in progress)</A><BR>
<A href="http://www.drizzle.com/~aboba/SITE/11-04-0735-04-000k-site-report-enhancements.doc">The
Neighbor Report (Submission to IEEE 802.11k, work in progress)</A><BR>
<A href="http://www.fahd.albinali.name/papers/ICWN/ICWN03-PaperID34-CameraReady.pdf">An Inter-Access Point Handoff Mechanism for Wireless Network Management: The Sabino System</A><BR>
<A href="http://www.ieee802.org/11/Documents/DocumentHolder/3-416.zip">Fast Active
Scan for Measurement and Handoff</A><BR>
<A href="http://www.cs.ucsd.edu/%7Eiramani/sync_scan.pdf">SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks</A><BR>
<A href="http://ramp.ucsd.edu/%7Eiramani/sync_scan.ppt">SyncScan slides</A><BR>
<H3><IMG height=18 src="new.gif" width=30 border=0>Lightweight Access Points</H3>
<P>Protocols for communication between lightweight Access Points and WLAN switches are
being standardized in the IETF CAPWAP WG. Here are some pointers:<P>
<A href="http://mail.frascone.com/pipermail/capwap/">CAPWAP WG mailing list archives</A><BR>
<A href="http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-06.txt">CAPWAP Architecture Taxonomy</A><BR>
<A href="http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-01.txt">CAPWAP Objectives</A><BR>
<A href="http://www.watersprings.org/pub/id/draft-ohara-capwap-lwapp-00.txt">LWAPP Protocol (IETF Draft, Work in Progress)</A><BR>
<A href="http://www.cs.mdx.ac.uk/staffpages/m_cheng/link/lwapp_g.pdf">
Security Analysis of LWAPP</A><BR>
<H3>Inter-Access Point Protocol (IAPP)</H3>
<P>Inter-Access Point Protocol (IAPP) is being standardized by IEEE 802.11F as
well as the IETF SEAMOBY WG. IAPP enables seamless, authenticated
fast handoff between 802.11 Access Points. Here are some pointers:
<P><A href="http://standards.ieee.org/getieee802/802.11.html">IEEE
802.11F</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-aboba-802-context-02.txt">IEEE
802.11 context transfer</A><BR><A
href="http://mmlab.snu.ac.kr/~webmaster/publications/docs/Networks2002_shpack.pdf">Fast
Inter-AP Handoff Using Predictive Authentication Scheme in a Public Wireless
LAN</A><BR><A href="http://www.drizzle.com/~aboba/IEEE/iapp.ppt">Proposal for
pre-emptive handoff support in IAPP (from University of Maryland)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-08.txt">SEAMOBY
Candidate Access Router Discovery protocol (IETF Draft, work in
progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-seamoby-ctp-11.txt">SEAMOBY
Context Transfer Protocol (IETF Draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/80211fmib.txt">Some suggested additions
to the IEEE 802.11F MIB</A>
<H2>Wi-fi Protected Access (WPA)</H2>
<P>The WiFi Alliance (WFA) is now certifying an interim draft of the 802.11
security specification, known as Wi-fi Protected Access (WPA). There are
also pre-WPA implementations in the market, some of which have known
vulnerabilities. Here are the details of the WPA specification and the
known security vulnerabilities:
<H3>WPA</H3>
<P>Details on WPA can be found here:
<P><A href="http://www.wifialliance.com/OpenSection/protected_access.asp">WPA
Web Site (includes links to the specification)</A><BR><A
href="http://www.microsoft.com/downloads/details.aspx?FamilyId=009D8425-CE2B-47A4-ABEC-274845DC9E91&displaylang=en">Microsoft
WPA Support</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-172.zip">NDIS WLAN
Objects</A>
<H3>WPA Security
Vulnerabilities</H3>
<P>Details of WPA security vulnerabilities can be found here:</P>
<A href="http://www.drizzle.com/~aboba/IEEE/prestand.html">Issues with
Pre-WPA implementations</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-211.zip">Michael
Attacks and Countermeasures</A><BR><A
href="http://wifinetnews.com/archives/002452.html">PSK-mode dictionary attack
vulnerability</A><BR>
<A href="http://www.nowires.org/Papers-PDF/WPA_attack.pdf">Weaknesses in the WPA
Temporal Key Hash</A><BR>
<H2><IMG height=75 src="IMG_1344.jpg" width=100
border=0> IEEE 802.11i <IMG height=75
src="IMG_1345.jpg" width=100 border=0></H2>
<P>The IEEE 802.11i standard was approved in July, 2004. Here are pointers to the
specification and its vulnerabilities:
<P><A
href="http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/">IEEE
802.11i specification (Approved as an IEEE 802.11 Standard) </A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-05-0123-01-0jtc-802-11i-overview.ppt">
IEEE 802.11i Overview</A><BR>
<A href="http://csrc.nist.gov/wireless/">NIST Security Workshop</A><BR>
<H3>IEEE 802.11i Security Vulnerabilities</H3>
<P>Details of IEEE 802.11i security vulnerabilities can be found here:
</P><A
href="http://www.drizzle.com/~aboba/IEEE/11-04-0497-00-000i-1-message-attack-4-way-handshake.doc">One
Message Attack on the 4-way Handshake</A><BR>
<A href="http://byte.csc.lsu.edu/~durresi/7502/reading/p43-he.pdf">Analysis of the 4-way Handshake (Paper)</A><BR>
<A href="http://www.ep.liu.se/exjobb/ida/2004/dd-d/116/exjobb.pdf">Summary of Security Issues </A><BR>
<H2>Extensible Authentication Protocol (EAP)</H2>
<P>EAP is the IETF standard for extensible authentication in network access. It
is standardized for use within PPP (RFC 2284), wired IEEE 802 networks (IEEE
802.1X), and VPNs (L2TP/IPsec and PIC). Here are pointers to information on the
EAP protocol:</P>
<P><A href="http://www.ietf.org/rfc/rfc3748.txt">EAP (Proposed Standard,
RFC 3748)</A><BR><A href="http://www.drizzle.com/~aboba/EAP/eapissues.html">EAP
Issues List</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-06.pdf">EAP
state machine (IETF draft, work in progress)</A><BR><A
href="http://mail.frascone.com/pipermail/public/eap/">EAP WG mailing list
archives</A><BR><A
href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/eap/eap/about_extensible_authentication_protocol.asp">How
to develop an EAP method for Windows</A>
<H3>EAP Key Management</H3>
<P>EAP methods provide keying material. Here are the documents describing
EAP key management. </P>
<P><A
href="http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-06.txt">EAP
Key Management Framework (IETF draft, work in progress)</A> <BR>
<A href="http://www.drizzle.com/~aboba/EAP/draft-aboba-eap-keying-extns-00.txt">
EAP Key Management Extensions (IETF draft, work in progress)</A><BR>
<A href="http://www.ietf.org/rfc/rfc3079.txt">MPPE Key Derivation (Informational,
RFC3079)</A> </P>
<H3>EAP methods</H3>
<H4>Security requirements</H4>
<P>Since EAP is extensible there are lots of proposals for authentication
methods that work with it. Only some of these methods meet the requirements for
use in wireless authentication; others have known security
vulnerabilities. Here are the security requirements for EAP methods as laid out
by IEEE 802.11i:</P><A
href="http://www.ietf.org/rfc/rfc4017.txt">EAP
method requirements (Informational, RFC 4017)</A>
<P>Here are some of the proposed EAP methods:</P>
<H4>Certificate authentication</H4>
<P><A href="http://www.ietf.org/rfc/rfc2716.txt">EAP-TLS (Experimental, RFC
2716)</A> </P>
<H4>Token card/smartcard authentication</H4>
<P><A
href="http://www.drizzle.com/~aboba/IEEE/draft-josefsson-eap-securid-01.txt">RSA
SecurID Token Card (IETF draft, work in progress)</A> <BR><A
href="http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-07.txt">Smartcard
EAP Method (IETF draft, work in progress)</A> </P>
<H4>Password authentication</H4>
<P><A
href="http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-10.txt">PEAPv2
(IETF draft, work in progress) </A>; used with: <A
href="http://www.drizzle.com/~aboba/EAP/draft-kamath-pppext-eap-mschapv2-01.txt">EAP
MS-CHAP-v2 (IETF draft, work in progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-01.txt">EAP-FAST
(IETF draft, work in progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-02.txt">TLS Session Resumption for EAP-FAST (IETF draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-ietf-pppext-eap-srp-03.txt">EAP-SRP
(IETF draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-01-497r0-I-EAP-SRP.ppt">Presentation
on EAP SRP</A><BR>
<H4>Pre-shared keys</H4>
<P><A
href="http://www.watersprings.org/pub/id/draft-jwalker-eap-archie-01.txt">EAP
Archie (IETF draft, work in progress)</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-204.zip">Presentation
on EAP Archie </A><BR><A
href="http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-07.txt">EAP-PSK
(IETF draft, work in progress)</A><BR>
<a href="http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-02.txt">
EAP-PAX (IETF draft, work in progress)</a><H2>Security vulnerabilities in EAP methods</H2>
<P>Here is a summary of the known security vulnerabilities of implemented or
proposed EAP methods.</P>
<H3>Kerberos vulnerability</H3>
<P>Kerberos is vulnerable to dictionary attacks. Here are the details on
the vulnerability: </P><A
href="http://www.drizzle.com/~aboba/IEEE/draft-aboba-pppext-eapgss-12.txt">EAP-GSS
(IETF draft, work in progress)</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-ietf-cat-iakerb-09.txt">IAKERB
(used with EAP GSS, IETF draft, work in progress)</A><BR><A
href="http://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/wu.pdf">Thomas
Wu's security analysis of Kerberos (why using Kerberos for wireless
authentication isn't a good idea)</A>
<H3>LEAP vulnerability</H3>
<P>Cisco's LEAP protocol is also vulnerable to dictionary attacks, and several
LEAP cracking tools are now available. Here are the details on the vulnerability
and cracking tools: </P><A href="http://asleap.sourceforge.net/">ASLEAP cracking
tool</A><BR><A href="http://www.thc.org/releases.php/">THC LEAP cracking
tool</A><BR><A href="http://www.securiteam.com/tools/6O00P2060I.html">ANWRAP
LEAP cracking tool</A><BR><A
href="http://www.cisco.com/warp/public/707/cisco-sa-20040407-username.shtml">Cisco
Security Advisory on default username/password vulnerability</A><BR><A
href="http://www.missl.cs.umd.edu/wireless/ethereal/leap.txt">Cisco LEAP
specification</A><BR><A
href="http://www.cisco.com/warp/public/707/cisco-sn-20030802-leap.shtml">Cisco
Tech Note on LEAP Dictionary Attack Vulnerabilities</A><BR><A
href="http://www.computerworld.com/securitytopics/security/story/0,10801,85637,00.html">Computerworld
story</A><BR><A
href="http://home.jwu.edu/jwright/presentations/asleap-defcon.pdf">Defcon 11
Presentation on LEAP cracking</A><BR><A
href="http://home.jwu.edu/jwright/presentations/attacking-80211-lightreading-live-2003.pdf">Light-Reading
Presentation on LEAP cracking</A><BR><A
href="http://www.schneier.com/paper-pptp.html">Security analysis of
MS-CHAPv1</A> <BR><A href="http://www.schneier.com/paper-pptpv2.html">Security
analysis of MS-CHAPv2</A> <BR>
<H3>EAP-SIM vulnerability</H3>
<P>The security weaknesses in GSM/GPRS are well known. Recently there have been
proposals for reuse of GSM (SIM) and 3G (AKA) security mechanisms in WLAN. Here
are pointers to the specifications and papers describing how GSM/GPRS security
can be cracked in real time. The attacks can be used against EAP-SIM where a
single SIM is used for both WLAN and WWAN authentication: </P>
<P><A
href="http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-16.txt">EAP-SIM
Specification (IETF draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf">Security Analysis of
EAP SIM</A><BR><A href="http://cryptome.org/gsm-crack-bbk.pdf">Instant
Ciphertext-only Cryptanalysis of GSM Encrypted Communication</A><BR><A
href="http://www.isaac.cs.berkeley.edu/isaac/gsm.html">Other GSM security
analyses</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-15.txt">EAP
AKA (IETF draft, work in progress)</A> <BR><A
href="http://www.3gpp.org/TB/SA/SA3/SA3.htm">3GPP security (AKA)</A>
<H3>PAP vulnerability</H3>
<P>Authentication protocols supporting cleartext authentication using RADIUS
(even within a protected tunnel) are vulnerable to known plaintext
attacks. IETF protocols vulnerable to this attack include:</P>
<P><A
href="http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-17.txt">IKEv2</A><BR><A
href="http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-eap-ttls-05.txt">EAP
TTLS (IETF draft, work in progress)</A>
<P>Here are the details of the vulnerability: </P>
<P><A
href="http://www.drizzle.com/~aboba/IEEE/11-01-TBD-I-RADIUS-Security.ppt">PAP
security vulnerability</A>
<H3>Man-in-the-Middle Attacks on Tunneled Authentication Protocols</H3>It has
recently been discovered that a number of protocols proposed within the IETF are
vulnerable to man-in-the-middle attacks. IETF protocols vulnerable to the
attack include:
<P><A href="http://www.ietf.org/rfc/rfc3230.txt">HTTP digest over TLS</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-beaulieu-ike-xauth-02.txt">XAUTH
within IKE</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-ietf-ipsra-pic-06.txt">PIC</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-ohba-pana-potls-01.txt">PANA over
TLS</A><BR><A
href="http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-eap-ttls-05.txt">EAP
TTLS (IETF draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/mspeap.zip">Microsoft Windows XP SP1
PEAPv0 Implemention </A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-josefsson-pppext-eap-tls-eap-02.txt">Cisco
PEAPv1 Implementation (IETF draft, work in progress)</A>.
<P>Details of the attacks are described in these papers:</P>
<P><A
href="http://www.watersprings.org/pub/id/draft-puthenkulam-eap-binding-04.txt">The
Compound Authentication Binding Problem (IETF draft, work in progress)</A><BR><A
href="http://www.saunalahti.fi/~asokan/research/mitm.html">Man-in-the-Middle
Attacks in Tunneled Authentication Protocols (Nokia Research Center)</A><BR><A
href="http://www.drizzle.com/~aboba/CPW/PICy.ppt">What's Wrong with PIC?
(Presentation to IETF 55 Credentials Workshop)</A></P>
<P></P>
<H2>IEEE 802.1X "Network Port Authentication"</H2>
<P>IEEE 802.1X is an IEEE standard (approved, June 2001) that enables
authentication and key management for IEEE 802 Local Area Networks, including
Ethernet, Token Ring, and FDDI. Since the IEEE 802.11 Task Group I
security work had only just gotten underway at the time that the IEEE 802.1X
standard was approved, 802.1X does not describe how the 802.1X and 802.11 state
machines are to be coupled. That task was left to IEEE 802.11 Task Group I. </P>
<P>Since IEEE 802.1X is not a cipher, it is not an alternative to WEP, 3DES,
AES, or any other cipher. Since IEEE 802.1X is only focused on
authentication and key management, it does not specify how or when security
services are to be delivered using the derived keys. However, it can be used to
derive authentication and encryption keys for use with any cipher, and can also
be used to periodically refresh keys and re-authenticate so as to make sure that
the keying material is "fresh".
<P>IEEE 802.1X is not a single authentication method; rather it utilizes
Extensible Authentication Protocol (EAP) as its authentication framework. This
means that 802.1X-enabled switches and access points can support a wide variety
of authentication methods, including certificate-based authentication,
smartcards, token cards, one-time passwords, etc. However, the 802.1X
specification itself does not specify or mandate any authentication methods.
Since switches and access points act as a "pass through" for EAP, new
authentication methods can be added without the need to upgrade the switch or
access point, by adding software on the host and backend authentication server.
<P>Since IEEE 802.1X doesn't involve encapsulation (unlike PPPOE or VPN) it adds
no per-packet overhead and can be implemented on existing switches and access
points with no performance impact. This means that IEEE 802.1X can scale from
speeds of 11 Mbps (802.11) to 10+ Gbps, and can be enabled on existing
switches with a firmware upgrade, without the need to buy new hardware. On
hosts, since IEEE 802.1X can be implemented in the NIC driver, support can be
enabled by obtaining updating drivers from the NIC vendor; there is no need to
install a new operating system.
<P>IEEE 802.1X integrates well with open standards for authentication,
authorization and accounting (including RADIUS and LDAP) and so it fits in well
with existing infrastructure for managing dialup networks and VPNs. RADIUS
servers (including Windows 2000 IAS) that support EAP can be used to manage IEEE
802.1X-based network access.
<P>These specifications describe how IEEE 802.1X works, and how it can be
managed via RADIUS and SNMP. Through RADIUS, IEEE 802.1X permits
management of authorization on a per-user basis. Per-user services include
filtering (layer 2 or layer 3), tunneling, dynamic VLANs, rate limits, etc.
<P><BR><A
href="http://www.ieee802.org/1/files/private/x-REV-drafts/d11/802-1X-REV-d11.pdf">IEEE
802.1X-2004 (Approved as an IEEE 802.1 Standard)</A><BR><A
href="http://www.ieee802.org/1/files/public/MIBs/802-1x-2004-mib.txt">IEEE
802.1X-2004 MIB</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/8021xmib.txt">IEEE 802.1X-2001 MIB
(IEEE 802 Standard)</A><BR>
<A href="http://standards.ieee.org/getieee802/download/802.1X-2001.pdf">IEEE
802.1X-2001 (IEEE 802 Standard) </A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/diag.txt">Some thoughts on diagnosing
problems via the 802.1X MIB</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/918.zip">IEEE 802/802.1X Architecture
Issues (Draft, work in progress) </A>
<H3><B>802.1X Implementations</B></H3>
<P><A href="http://www.open1x.org/">Open 802.1X</A><BR><A
href="http://wire.cs.nthu.edu.tw/wire1x/">WIRE1X</A>
<H3><B><A name=liaison></A>IETF/IEEE 802 Liaison</B></H3>
<P>IEEE 802 and IETF communicate regularly relating to IETF dependencies of IEEE
802 working groups. Here is some information relating to the liaison
relationship:
<P><A
href="http://www.ietf.org/internet-drafts/draft-aboba-ieee802-rel-04.txt">IEEE
802/IETF Relationship History</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/IETF_802_coord_2004.pdf">IEEE 802
Archive Access for IETF WGs</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/NIST-Status.ppt">Status of IEEE
802.11i/IETF Liaison (for the NIST 802.11 Security Workshop)</A><BR><A
href="http://www.ietf.org/IESG/LIAISON/ieee802.11.txt">IEEE 802.11 Liaison
letter No. 1</A><BR><A
href="http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt">IEEE 802.11 Liaison
letter No. 2</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/ietf56-eap.pdf">Erik Nordmark's
response to Liaison letter No. 2</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-361.zip">IEEE 802.11
Draft Liaison letter No. 3 (not sent)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-03-264r0-W-IETF_Liaison_Report_March_2003.ppt">IEEE
802.11/IETF Liason Status Report (March 2003)</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-378.zip">IEEE
802.11/IETF Liaison Status Report (May 2003)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/763.zip">IEEE 802.11/IETF Liaison
Status Report (September 2003)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/paul.txt">IEEE 802 request for feedback
on IEEE 802.21 PAR (October 2003)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-04-0117-00-0000-ietf-liaison-report-january-2004.ppt">IEEE
802.11/IETF Liaison Status Report (January 2004)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/coord.ppt">IEEE 802/IETF Liaison
Meeting Summary (January 2004)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/8021coord.ppt">IEEE 802.1/IETF Liaison
Meeting Summary (January 2004)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-04-0166-00-0000-ieft-ieee-802-11-meeting-summary.ppt">IEEE
802.11/IETF Liaison Meeting Summary (January 2004)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-04-0610-00-0000-may-ieee-80211-ietf-liaison-report.ppt">IEEE
802.11/IETF Liaison Status Report (May 2004)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-04-0776-00-0000-july-ieee-80211-ietf-liaison-report.ppt">IEEE
802.11/IETF Liaison Status Report (July 2004)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-04-1463-00-0000-november-ieee-802-11-ietf-liaison-report.ppt">
IEEE 802.11/IETF Liaison Status Report (November 2004)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-05-0024-00-0000-january-05-ieee802-11-ietf-liaison-report.ppt">IEEE 802.11/IETF Liaison Status Report (January 2005)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-05-0189-00-0000-march-05-ieee-802-11-ietf-liaison-report.ppt">IEEE
802.11/IETF Liaison Status Report (March 2005)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-05-0449-00-0000-may-05-ieee-802-11-ietf-liaison-report.ppt">IEEE
802.11/IETF Liaison Status Report (May 2005)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/755.zip">3GPP liaison request to IEEE
802.11 on RADIUS/Diameter Coexistence (September 2003)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/794.zip">IEEE 802.11 Response to 3GPP
liaison request on RADIUS/Diameter Coexistence (September 2003)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/kerry.txt">IEEE 802.11 Liaison letter
No. 4 (February 2004)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/gsma.pdf">GSMA Request to IETF relating
to RADIUS WLAN Support</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/wfa.zip">WFA Request to IETF relating
to RADIUS WLAN Support</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/stuart1.txt">IEEE 802.11 Liaison Letter
relating to Network Discovery</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-04-1109-01-0000-input-to-ietf-from-wien-ad-hoc-september-2004.doc">
Input to IETF from IEEE 802.11 WIEN (September 2004)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-04-xxxx-00-0000-input-to-ietf-from-WIEN-Ad-Hoc-November-2004.doc">Input to IETF from IEEE 802.11 WIEN (November 2004)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/11-05-0283-03-000u-liaison-to-ietf-from-ieee802-11-and-ieee802-21.doc">
Liaison to IETF from IEEE 802.11 and IEEE 802.21 (May 2005)</A><BR>
<A href="http://ieee802.org/16/liaison/docs/L80216-05_025.pdf">Liaison to IETF from
IEEE 802.16 (April 2005)</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/liaison0405.txt">April 2005 Liaison Report</A><BR>
<A href="http://www.drizzle.com/~aboba/IEEE/minutes0408.txt">Minutes of the April 8, 2005 Liaison Conference Call</A><BR>
<A href="http://ieee802.org/16/liaison/docs/L80216-05_039.pdf">Liaison to IETF from IEEE 802.16 (May 2005)</A><BR>
<H2>Remote Access Dialin User Service (RADIUS)</H2>
<P>RADIUS is a widely deployed protocol for network access authentication,
authorization and accounting (AAA). There are many problems with it, including
issues with security and transport, yet it is likely that RADIUS will continue
to be widely used for many years to come. Why? RADIUS is simple, efficient
and easy to implement -- making it possible for RADIUS to fit into the most
inexpensive embedded devices. </P>
<P>The issues with transport are most relevant for accounting, in situations
where services are billed according to usage. In these situations packet
loss = revenue loss! RADIUS runs on UDP, with no defined retransmission or
accounting record retension policy, and does not support application-layer
acknowledgments or error messages (like "I'm busy, come back later" or "No disk
space left"). This makes RADIUS accounting unreliable for usage-based billing
services, particularly in inter-domain usage (such as roaming) where there can
be substantial packet loss.
<P>As a result, usage-based billing is often done with SNMP today.
Although SNMP runs over UDP (a TCP transport mapping has been developed but is
not deployed yet), the retry policy and polling interval can be configured on
the management station, so that you are not at the mercy of the RADIUS
retransmission and retension policy of a particular NAS vendor. To enable
SNMP-based accounting for 802.11, as well as RADIUS accounting, we designed the
IEEE 802.1X MIB to provide all the information available in RADIUS accounting
within the MIB tables. The situation is better for RADIUS authentication
and authorization, because if packet loss prevents users from being
authenticated, they will typically try to get on again soon afterwards.
<P>In terms of security, RADIUS includes its own application-layer integrity
protection and authentication, as well as confidentiality for "hidden
attributes". In RFC 2865, RADIUS Access Requests need not be authenticated
and integrity protected; the situation was improved somewhat in RFC 2869, which
requires that all messages involved in an EAP conversation include
authentication and integrity protection via the Message-Authenticator attribute.
As noted in the RADIUS security analysis, RADIUS security is particularly poor
when dealing with cleartext passsword authentication (PAP). RFC 2865 requires
that the RADIUS Response Authenticator be globally and temporally unique, since
the stream cipher that RADIUS uses to encrypt User-Password is based on the
Response Authenticator, and thus if it were to repeat, the keystream would be
compromised. Unfortunately, not all implementations do a good job of ensuring
that the Response Authenticator is not repeated.
<P>Since the RADIUS Response Authenticator and Message-Authenticator attributes
are both vulnerable to dictionary attack, it's a good idea to make sure your
RADIUS shared secret has sufficient entropy and is not the same for multiple
NASen. However, in real-life simple shared secrets shared with many NASen (or
even all of them!) are common, and so this is probably the most serious RADIUS
security vulnerability.
<P>In terms of solutions, the best thing to do is to turn off PAP support on the
NAS; that way the User-Password attribute will never be sent. Fortunately, EAP
does not support PAP, and so RADIUS usage with IEEE 802.1X is not vulnerable to
this particular class of attack. If possible, it is a good idea to use
authentication methods that offer protection against an offline dictionary
attack. These include EAP TLS (RFC 2716), EAP SRP and PEAP (both still under
development), but not EAP GSS with Kerberos V, EAP MD5 or Cisco LEAP.
<P>If the NAS can support IPsec, then the best thing to do is foresake RADIUS
application-layer security entirely and just run RADIUS over IPsec ESP with a
non-null transform. This is described in RFC 3162. Unfortunately, many
embedded systems do not have the horsepower or headroom to run IPsec, so
RADIUS/IPsec is not widely used today.
<P><A href="http://www.ietf.org/rfc/rfc2548.txt">Microsoft RADIUS Attributes
(Informational, RFC 2548)</A> <BR><A
href="http://www.ietf.org/rfc/rfc2865.txt">RADIUS authentication (Proposed
Standard, RFC 2865)</A> <BR><A
href="http://ftp.cerias.purdue.edu/pub/doc/network/radius/archive/">IETF RADIUS
WG Archives</A><BR><A href="http://www.ietf.org/rfc/rfc2866.txt">RADIUS
accounting (Informational, RFC 2866)</A> <BR><A
href="http://www.ietf.org/rfc/rfc2867.txt">RADIUS tunneling accounting
attributes (Informational, RFC 2867)</A><BR><A
href="http://www.ietf.org/rfc/rfc2868.txt">RADIUS tunneling authentication
attributes (Informational, RFC 2868)</A><BR><A
href="http://www.ietf.org/rfc/rfc2869.txt">RADIUS Extensions (Informational, RFC
2869)</A><BR><A href="http://www.ietf.org/rfc/rfc3162.txt">RADIUS for IPv6
(Proposed Standard, RFC 3162)</A> <BR><A
href="http://www.ietf.org/rfc/rfc3575.txt">RADIUS IANA Considerations (Proposed
Standard, RFC 3575)</A><BR><A href="http://www.ietf.org/rfc/rfc3576.txt">RADIUS
Dynamic Authorization (Informational, RFC 3576)</A><BR><A
href="http://www.ietf.org/rfc/rfc3579.txt">RADIUS/EAP (Informational, RFC
3579)</A><BR><A href="http://www.ietf.org/rfc/rfc3580.txt">Using RADIUS with
IEEE 802.1X (Informational, RFC 3580)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.txt">Additional
RADIUS attributes for IEEE 802.1X (IETF draft, work in progress)</A><BR><A
href="http://www.untruth.org/~josh/security/radius/radius-auth.html">RADIUS
security analysis</A><BR><A
href="http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt">Dictionary Attack
Vulnerability</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-01-TBD-I-RADIUS-Security.ppt">A
presentation on RADIUS security (IEEE 802.11i submission, discusses potential
solutions)</A> <BR><A href="http://www.ietf.org/rfc/rfc2975.txt">Introduction to
Accounting Management (Informational, RFC 2975, discusses issues with RADIUS
accounting)</A> <BR><A href="http://www.ietf.org/rfc/rfc2989.txt">Network access
requirements (Informational, RFC 2989, What a AAA protocol really needs to
do)</A> <BR><A href="http://www.ietf.org/rfc/rfc3127.txt">AAA protocol
evaluation (Informational, RFC 3127, How RADIUS fares against the
requirements)</A> <BR><A href="http://www.ietf.org/rfc/rfc3539.txt">AAA
Transport Specification (Proposed Standard, RFC 3539)</A>
<H2>Handoff and Roaming</H2>
<P>According to usage within GSM and IETF, "handoff" is movement of a mobile
node between Access Points. "Roaming" is the movement of a mobile node
between networks. This section provides references to documents on handoff
and roaming. </P>
<H3>Handoff and IEEE 802.1X</H3>
<P>Here are some papers relating to handoff in IEEE 802.1X-enabled networks:
</P>
<P><A
href="http://www.cs.umd.edu/~mhshin/paper/Proactive_Key_Dist_NG.pdf">Proactive
Key Distribution using Neighbor Graphs</A><BR><A
href="http://www.cs.umd.edu/~mhshin/paper/ContextCachingNG.pdf">Context Caching
using Neighor Graphs</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip">Proactive
Key Distribution to Support Secure Roaming (submission to IEEE 802.11 Tgi)</A>
<BR>
<a href="http://www.drizzle.com/~aboba/IEEE/draft-irtf-aaaarch-handoff-04.txt">RADIUS
handoff extension (IRTF draft, work in progress)</a><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-02-TBDr0-I-Pre-Authentication.doc">802.1X
pre-authentication and 802.11 (submission to IEEE 802.11 Tgi, Word
document)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-02-389ar0-I-802.1X-Pre-Authentication.ppt">802.1X
pre-authentication and 802.11 (submission to IEEE 802.11 Tgi,
Powerpoint)</A><BR><A
href="http://mmlab.snu.ac.kr/~webmaster/publications/docs/pwc2002_shpack.pdf">Pre-Authenticated
Fast Handoff in a Wireless LAN Based on IEEE 802.1X Model</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-01-TBD-I-Authenticated-FastHandoff.ppt">A
presentation on authenticating 802.11 management frames</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-03-155r0-I-Fast-Handoff-Issues.ppt">Fast
Handoff Issues (IEEE 802.11i draft, work in progress)</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-411.zip">PMK Plumbing
for fast roaming</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-421.zip">PMK
Caching</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/3-419.zip">PMK
Naming</A>
<H3>Routing Metrics</H3>
<p>Here are some papers relating to link-aware routing metrics: </p>
<p><a href="http://research.microsoft.com/mesh/papers/metrics.pdf">Comparison of
Routing Metrics for Static Multi-Hop Wireless Networks</a><br>
<a href="http://pdos.csail.mit.edu/~rtm/srcrr-draft.pdf">SrcRR: A High
Throughput Routing Protocol for 802.11 Mesh Networks</a><br>
<a href="http://pdos.csail.mit.edu/~rtm/roofnet-b.pdf">Architecture and
Evaluation of the MIT Roofnet Mesh Network</a><BR>
<a href="http://pdos.csail.mit.edu/papers/grid:losstr02/paper.pdf">Effects of
Loss Rate on Adhc Wireless Routing</a><BR>
<a href="http://www.ee.ucla.edu/~kulkarni/papers/Routing.pdf">A Radio Aware
Routing Protocol for Wireless Mesh Networks</a><BR>
<a href="http://pdos.csail.mit.edu/~rtm/papers/etx.pdf">A High Throughput Path
Metric for Multi-Hop Wireless Routing</a> </p>
<H3>Inter-media Handoff</H3>
<P>Here are some papers relating to handoff between media: </P>
<P><A
href="http://www.ieee802.org/handoff/march04_meeting_docs/Generalized_triggers-02.pdf">A
Generalized Model for Link Layer Triggers (Submission to IEEE 802.21, work in
progress)</A><BR><A
href="http://www.ieee802.org/handoff/march04_meeting_docs/802.21_L2_upper_layer_interaction_r1.ppt">Interactions
of IEEE 802.21 and Upper Layers (Submission to IEEE 802.21, work in
progress)</A><BR><A href="http://www.drizzle.com/~aboba/IEEE/alias.ppt">Trouble
with Triggers (Presentation at IETF 56 ALIAS BOF, work in progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-iab-link-indications-01.txt">Architectural
Implications of Link Indications (IETF draft, work in progress) </A>
<H3>Detection of Network Attachment</H3>
<P>At layer 3, support for either handoff or roaming requires that mobile nodes
efficiently detect network attachment. IEEE 802.11 does not support network
attachment detection very well, and so this is trickier than it might seem at
first glance. Here are some links describing the problem:
<P><A href="http://webcamserver.eng.monash.edu.au/~warchive/dna/">Detection of
Network Attachment (DNA) Mailing List </A><BR><A
href="http://www.drizzle.com/~aboba/DNA/dnaissues.html">DNAv4 Issues Website
</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt">Optimistic
DAD (IETF draft, work in progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-dna-hosts-00.txt">Detection
of Network Attachment for IPv6 (IETF draft BCP, work in progress)</A><BR><A
href="http://www.thinkonweb.com/sait/MD.pdf">Review of current movement
detection schemes for IPv6</A><BR><A
href="http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-12.txt">Detection
of Network Attachment for IPv4 (IETF draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/DNA-and-handoff-scope.ppt">Detection of
Network Attachment and IEEE 802.11 (IEEE 802 Handoff ECSG Presentation, work in
progress)</A>
<H3><IMG height=18 src="new.gif" width=30 border=0>Inter-Provider
Roaming</H3>
<P>You've probably heard a lot about the "WHISPR" specification, which is being
developed within WECA. Here are the references to open standards which describe
how to do roaming and fast handoff within 802.11. </P>
<P>Roaming, defined as the ability to connect to multiple ISPs while maintaining
an account with only one, was tackled by the IETF ROAMOPS WG starting in 1996
and solutions based on this architecture are now widely deployed. Since
IEEE 802.1X is based on EAP, it is compatible with the ROAMOPS architecture as
well as with existing RADIUS servers supporting RFC 2869 encapsulation of EAP in
RADIUS.
<P>One of the keys to roaming economics within 802.11 is enabling "shared use"
APs. Shared use infrastructure has been widely deployed in dialup network
access, allowing multiple ISPs to share the same points of presence. Enabling
APs to be shared by multiple wireless ISPs offers to improve efficiency and
improve the utilization of deployed APs. Shared use APs are particularly
important for wireless because not only does it cost more to deploy multiple APs
in the same location, but the limited radio channels in 802.11 makes radio
interference a potential problem.
<P>In order to keep the same IP address while roaming, there are approaches at
layer 2 as well as layer 3. Mobile IP is the layer 3 approach. Of the layer 2
approaches, one is dynamic VLANs. Another is tunneling. Both are enabled by
RADIUS tunneling attributes.
<P><A href="http://www.ietf.org/rfc/rfc2194.txt">Roaming implementations survey
(Informational, RFC 2194)</A> <BR><A
href="http://www.ietf.org/rfc/rfc2477.txt">Roaming architecture and requirements
(Informational, RFC 2477)</A> <BR><A
href="http://www.ietf.org/rfc/rfc2486.txt">The Network Access Identifier
(Proposed Standard, RFC 2486)</A> <BR><A
href="http://www.ietf.org/rfc/rfc2607.txt">RADIUS Proxies, Policy and Roaming
(Informational, RFC 2607)</A> <BR><A
href="http://www.ietf.org/rfc/rfc2924.txt">Accounting record formats
(Informational, RFC 2924)</A><BR><A
href="http://www.ietf.org/rfc/rfc2975.txt">Introduction to Accounting Management
(Informational, RFC 2975)</A> <BR><A
href="http://www.weca.net/OpenSection/downloads/WISPr_V1.0.pdf">Best Practices
for WISP Roaming (WFA)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-05.txt">RFC
2486bis (IETF Draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-netsel-problem-02.txt">Network
Selection Problem Statement (IETF Draft, work in progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-13.txt">Network
Discovery Proposal (IETF Draft, work in progress) </A><BR>
<H3>Virtual Access Points</H3>
<P>Supporting roaming on a wide scale requires an AP to support more than one
SSID. Here are some papers describing how this can be done:<BR><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-03-154r1-I-Virtual-Access-Points.doc">Virtual
APs (IEEE 802.11i draft, work in progress)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/virtual-APs.ppt">Virtual APs
(Presentation to WFA) </A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/11-04-0238-00-0wng-definition-virtual-access-point.doc">Virtual
AP Definition </A><BR>
<P>
<H2>Miscellaneous Topics</H2>
<H3>VPN Standards and Security Analyses</H3>
<P>You've probably heard "experts" say that "VPN is the answer to WEP
security problems." Well, it isn't that simple -- because the next question is
"whose VPN?" Almost all IPsec tunnel mode products shipping today are
proprietary, interoperability is poor and many of the proprietary
extensions have security flaws. Here are the references to the security analyses
of VPN protocols as well as to the IETF standards for VPN. Ask your
vendors when they plan to implement the IETF standards! </P>
<P><A href="http://www.schneier.com/paper-pptpv2.html">Security analysis of
PPTPv2</A> <BR><A href="http://www.schneier.com/paper-pptp.html">Security
analysis of PPTP</A> <BR><A
href="http://www.microsoft.com/NTServer/Support/faqs/VPNSec_FAQ.asp">Microsoft
point of view on PPTP</A> <BR><A
href="http://www.ima.umn.edu/~pliam/xauth/">Security analysis of XAUTH (shipping
in most IPsec tunnel mode implementations)</A> <BR><A
href="http://www.blackhat.com/presentations/bh-usa-03/bh-us-03-ornaghi-valleri.pdf">Man-in-the-middle
attacks against IPsec VPNs (also SSH, HTTPS, etc.)</A><BR><A
href="http://www.ietf.org/rfc/rfc3456.txt">Configuration of IPsec tunnel mode
with DHCPv4 (Proposed Standard, RFC 3456)</A> <BR><A
href="http://www.ietf.org/rfc/rfc3193.txt">Securing L2TP with IPsec ( Proposed
Standard, RFC 3193)</A> <BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-ietf-ipsra-pic-06.txt">Legacy
authentication within IPsec tunnel mode (PIC) (IETF draft, work in
progress)</A><BR><A href="http://www.ietf.org/rfc/rfc3715.txt">IPsec-NAT
compatibility requirements (Informational, RFC 3715) </A>
<H3>Credential provisioning</H3>
<P>Recently, there has been a lot of interest in the application of certificates
to WLAN authentication. Here are some presentations and papers on the
subject:</P>
<P><A href="http://www.drizzle.com/~aboba/CPW/">IETF 55 Enrollment Workshop</A>
<BR><A
href="http://www.drizzle.com/~aboba/IEEE/draft-ietf-roamops-cert-02.txt">Certificate-based
roaming (IETF draft, now expired)</A><BR><A
href="http://www.ieee802.org/11/Documents/DocumentHolder/2-401.zip">Certificate
hierarchy for the WLAN industry (presentation to IEEE 802.11 Tgi)</A><BR><A
href="http://www.ietf.org/rfc/rfc3770.txt">WLAN certificate extensions (Proposed
Standard, RFC 3770)</A><BR><A
href="http://www.drizzle.com/~aboba/IEEE/731.zip">Why Certificate OIDs are
needed</A><BR><A href="http://www.drizzle.com/~aboba/IEEE/peapod.txt">PEAPOD
proposal for EAP-based enrollment</A>
<H3>Multihoming Issues </H3>
<P>The IETF is now looking at a number of new solutions to the problems of
mobility, multi-homing and security. Here are some pointers: </P>
<P><A
href="http://www.watersprings.org/pub/id/draft-crocker-mast-analysis-01.txt">Choices
for multi-addressing (IETF Draft, work in progress)</A><BR><A
href="http://www.watersprings.org/pub/id/draft-crocker-mast-proposal-01.txt">Multiple
Address Service for Transport (MAST) (IETF Draft, work in progress)</A><BR><A
href="http://www.watersprings.org/pub/id/draft-nordmark-multi6-cb64-00.txt">Multihoming
using 64-bit crypto-based IDs (IETF Draft, work in progress)</A><BR><A
href="http://www.watersprings.org/pub/id/draft-nordmark-multi6-noid-01.txt">Multihoming
without IP identifiers (IETF Draft, work in progress)</A><BR><A
href="http://www.watersprings.org/pub/id/draft-nikander-hip-mm-02.txt">End-host
Mobility and Multi-Homing with HIP (IETF Draft, work in progress)</A><BR><A
href="http://www.watersprings.org/pub/id/draft-moskowitz-hip-arch-06.txt">HIP
architecture (IETF Draft, work in progress)</A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-hip-base-02.txt">HIP
Specification (IETF Draft, work in progress)</A><BR>
<A href="http://www.watersprings.org/pub/id/draft-nikander-mobileip-homelessv6-01.txt">Homeless
Mobile IPv6 (IETF Draft, work in progress)</A><BR>
<P>
<H3>Adhoc networking</H3>802.11 enables "adhoc" networking, which is
communication between stations without an Access Point. This mode has enormous
potential, most of which is not being realized. Recent IETF work in progress
enables hosts to automatically assign IPv4 addresses without a DHCP server, and
resolve names without a DNS server (IPv4 or IPv6). There is also IEEE work in
progress that addresses the "hidden node problem" -- not all 802.11 stations in
an adhoc network can communicate with each other, because they might be out of
range!
<P>To knit the stations together into a coherent network, they can either act as
bridges (layer 2 approach) or routers (layer 3 approach, MANET). The issue with
bridging has been convergence times -- 802.11D spanning tree doesn't converge
fast enough to be viable in an adhoc network where hosts are constantly moving,
associating and disassociating with each other. IEEE work in progress on
"rapid spanning tree convergence" promises to change that. This could
enable adhoc networks with dozens or even hundreds of users that could stretch
over a substantial geographic distance. Here are some pointers:
<P><A href="http://guinness.cs.stevens.edu/~swetzel/papers/stealth.pdf">Stealth
Attacks on Adhoc Networks </A><BR><A
href="http://www.ietf.org/rfc/rfc3927.txt">IPv4
linklocal addressing (Proposed Standard, RFC 3927) </A><BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2462bis-08.txt">IPv6
linklocal addressing (Proposed Standard, RFC 2462)</A> <BR><A
href="http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-40.txt">Link
Local Multicast Name Resolution (LLMNR), (IETF draft, work in progress)
</A><BR><A href="http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html">LLMNR
Issues List </A><BR><A href="http://www.ietf.org/rfc/rfc3397.txt">DHCP Domain
Search option (Proposed Standard, RFC 3397)</A>
<P>
<H3>Bridging and Routing protocols</H3><A
href="http://standards.ieee.org/getieee802/802.1.html">IEEE 802.1 standards </A>
页:
[1]