Liikkuvuuden mahdollistaminen ja tietoturvan parantaminen Aalto-yliopiston langallisessa verkossa

Transkriptio

1 Liikkuvuuden mahdollistaminen ja tietoturvan parantaminen Aalto-yliopiston langallisessa verkossa Esko Järnfors Sähkötekniikan korkeakoulu Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa Työn valvoja: Prof. Raimo Kantola Työn ohjaaja: DI Tommi Saranpää

2

3 aalto-yliopisto sähkötekniikan korkeakoulu diplomityön tiivistelmä Tekijä: Esko Järnfors Työn nimi: Liikkuvuuden mahdollistaminen ja tietoturvan parantaminen Aalto-yliopiston langallisessa verkossa Päivämäärä: Kieli: Suomi Sivumäärä: Tietoliikenne- ja tietoverkkotekniikan laitos Professuuri: Tietoverkkotekniikka Työn valvoja: Prof. Raimo Kantola Työn ohjaaja: DI Tommi Saranpää Tässä työssä suunniteltiin, toteutettiin ja arvioitiin tapa mahdollistaa Aalto yliopiston tietotekniikkapalveluiden langallisen tietoverkon käyttäjien liikkuminen kampusalueella siten, että käytettävissä olisi aina käyttäjän yksikön oma verkko. Koska verkkoon ei pitäisi päästä kytkemään sinne kuulumattomia laitteita, täytyi samalla varmistaa, että ratkaisu on tietoturvallinen ja automaattinen. Toteutus kattaa kytkimet, päätelaitteet sekä todennustavat. Ratkaisu suunniteltiin, toteutettiin ja testattiin, jonka jälkeen siihen liittyvät uhat ja riskit arvioitiin, sekä arvioitiin vaikutukset verkon käytettävyydelle. Arvioinnissa osoittautui, että toteutus ei sisällä sietämättömiä riskejä, ja että sen käytettävyys ei ole huonompi kuin nykytilanteen. Lisäksi verkon ylläpidettävyyden katsottiin paranevan automaation myötä. Avainsanat: Liikkuvuus, langallinen verkko, 802.1X, EAP, EAPOL, EAP TLS, PEAP, PKI, RADIUS, kytkin, MVRP, työasema, todennus, varmenteet, uhka, riski, riskianalyysi

4 aalto university school of electrical engineering abstract of the master s thesis Author: Esko Järnfors Title: Enabling mobility and improving security in wired network at Aalto University Date: Language: Finnish Number of pages: Department of Communications and Networking Professorship: Network Technology Supervisor: Prof. Raimo Kantola Advisor: M.Sc. Tommi Saranpää In this thesis a way was devised to enable the users of the wired network of Aalto IT services to roam the campus so that the users can access their organization s private network. Because only authorised devices should be connected to the network, it was also made sure that the solution is secure and automatic. The solution covers switches, client devices and authentication methods. The solution was designed, implemented and tested after which it was subjected to threat and risk analysis and the effects to the usability of the network were assessed. It was discovered that the solution does not pose unacceptable risks and that its usability is not worse than in the current situation. Network administration was also made easier due to increased automation. Keywords: Mobility, wired network, 802.1X, EAP, EAPOL, EAP TLS, PEAP, PKI, RADIUS, switch, MVRP, workstation, authentication, certificates, threat, risk, risk analysis

5 v Esipuhe Haluan kiittää työn valvojaa professori Raimo Kantolaa hyvistä keskusteluista ja ohjauksesta tämän tovin kestäneen työn tiimoilta. Suurkiitokset myös Aalto IT:n henkilökunnalle, erityisesti kollegoilleni työasemaryhmässä, esimiehilleni Elena Piriselle ja Siiri Sipilälle, sekä tietoliikenneryhmälle, tietoturvaryhmälle ja ohjaajalleni Tommi Saranpäälle siitä, että sain tehdä opinnäytetyötä osin työn ohessa, sekä heidän korvaamattomasta avustaan tämän työn toteuttamisessa. Haluan lisäksi kiittää vanhempiani kärsivällisyydestä ja tuesta varsin pitkään kestäneellä opintiellä sekä oikolukuavusta. Lopuksi haluan kiittää myös ystäviäni, ilman teitä ei opintoja olisi selvitetty! Espoo, Esko Järnfors

6 vi Sisällysluettelo Tiivistelmä Tiivistelmä (englanniksi) Esipuhe Sisällysluettelo Lyhenteet iii iv v vi ix 1 Johdanto Tutkimuksen tausta Tutkimusongelma Tutkimuksen rajaus Tutkimusmenetelmä Tutkimuksen rakenne Tietoturva, protokollat ja todentaminen Julkisen avaimen salaus Varmenteiden hallintajärjestelmä X.509 varmenteet Varmenteen voimassaolo Varmenteen tarkistaminen EAP Pakettityypit Todennusprosessi TLS Tietueprotokolla Kättelyprosessi EAP TLS Pakettityypit Fragmentointi Todennusprosessi PEAP Fragmentointi RADIUS Pakettityypit Todennusprosessi EAP liikenteen välittäminen RADIUS paketeissa RADIUS kirjanpitoprotokolla Tietoverkot Kerrosmallit Fyysinen kerros ja siirtoyhteyskerros

7 3.1.2 Verkkokerros Kuljetuskerros Sovelluskerros Verkon topologia Ethernetin toiminta ja alueet Kytkinten toiminta ja MAC learning Virtuaaliset lähiverkot Multiple VLAN Registration Protocol Aalto yliopiston langallinen tietoverkko Ethernet verkkojen heikkoudet ARP Spoofing DHCP-hyökkäykset Man in the Middle X porttitodennus Todentaminen EAPOL Porttien tila RADIUS 802.1X:ssä Tunnetut heikkoudet EAPOL Logoff Man in the Middle Toteutus Suunnittelu ja reunaehdot Verkot VLAN:ien levittäminen Työasemat Työasemien identiteetit, PKI ja RADIUS Verkkojen levittäminen Kytkinkonfiguraatiot Junos HPE Comware Työasemien konfigurointi Windows Mac OS X Linux Havaitut ongelmat ja vaikutukset muihin palveluihin Epäyhteensopivat laitteet Työasemien asentaminen Linux kannettavien käytettävyys Tietotekniikkapalveluiden ulkopuolisten Mac tietokoneiden käytettävyys Arviointi 52 vii

8 viii 6.1 Tietoturva ja toimintavarmuus Uhat ja uhkaskenaariot Riskit Käytettävyys Johtopäätökset 63 Viitteet 64 A Kytkinkonfiguraatiolistaukset 68 A.1 Junos A.2 Comware

9 ix Lyhenteet AAA Authentication, Authorization and Accounting (todentaminen, valtuutus, kirjanpito) AD Active Directory (Aktiivihakemisto) AES Advanced Encryption Standard ARP Address Resolution Protocol CA Certificate Authority (varmenteiden myöntäjä) CSMA/CD Carrier Sense Multiple Access / Collision Detection DHCP Dynamic Host Configuration Protocol EAP Extensible Authentication Protocol EAP TLS Extensible Authentication Protocol Transport Layer Security EAP TTLS Extensible Authentication Protocol Tunneled Transport Layer Security EAPOL Extensible Authentication Protocol Over LAN HMAC Keyed hash Message Authentication Code IANA The Internet Assigned Numbers Authority IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IP Internet Protocol KDC Key Distribution Center LAN IEEE 802 Local Area Network LDAP Lightweight Directory Access Protocol LLC Logical Link Control LTE Long Term Evolution MAC Media Access Control tai Message Authentication Code MAU Media Access Unit MD5 Message Digest algorithm v. 5 MRP Multiple Registration Protocol MTU Maximum transmission unit (suurin siirtoyksikkö) MVRP Multiple VLAN Registration Protocol OCSP Online Certificate Status Protocol OSI Open Systems Interconnection PAE Port Access Entity PDU Protocol Data Unit (protokollan tietoyksikkö) PEAP Protected Extensible Authentication Protocol PKI Public Key Infrastructure (julkisten avainten hallintajärjestelmä) PPP Point to Point Protocol PRF Pseudorandom Function (pseudosatunnaisfunktio) PXE Preboot Execution Environment RADIUS Remote Authentication Dial In User Service RFC Request for Comments TCP Transmission Control Protocol TLS Transport Level Security UDP User Datagram Protocol VPN Virtual Private Network WLAN Wireless Local Area Network (langaton lähiverkko) WoL Wake on LAN

10 x

11 1 Johdanto 1.1 Tutkimuksen tausta Aalto yliopisto on Suomen mittakaavassa suuri yliopisto, sillä on noin opiskelijaa ja noin 4600 työntekijää. Yliopistotyötä tehdään kolmella kampuksella, joita yhdistää Aalto yliopiston tietotekniikkapalveluiden ylläpitämä tietoverkko. Aalto yliopiston tietotekniikkapalvelut on Aalto yliopiston IT palveluja tuottava yksikkö, jonka tehtävänä on tarjota tietotekniset peruspalvelut opiskelijoille ja henkilökunnalle. Peruspalveluiden (mm. sähköposti, levypalvelut, työasemat, tulostus, verkkoinfrastruktuuri) lisäksi tietotekniikkapalvelut pyrkii tukemaan muita Aalto yliopiston palveluyksiköitä palveluiden tietoteknisessä toteuttamisessa. Tietotekniikkapalvelut toimii asiakaslähtöisesti ja painottaa erityisesti asiakaspalvelua ja tyytyväisyyttä. Tietotekniikkapalveluiden langallinen tietoverkko on suunniteltu Aalto yliopiston perustamisen aikoihin vuosina Sitä hallitaan edelleen pitkälti käsityönä ja sen rakenne on staattinen. Tarve verkkojen levityksen automatisoinnille ja työasemien liikkuvuuden mahdollistamiselle on selkeä, sillä vastaava toiminnallisuus on jo käytettävissä langattomissa tukiasemissa. Langattomissa verkoissa laitekanta on yhtenäinen ja toiminnallisuuden toteuttaa sitä varten suunniteltu tukiasemakontrolleri. Langallisen verkon laitekanta on hyvin kirjavaa. Olemassa olevat kytkimet toteuttavat tarvittavat teknologiat hieman eri tavoin. Tästä seuraa, että valmista yleistä toteutusta ei ole, vaan sellainen on suunniteltava jokaiseen ympäristöön erikseen. 1.2 Tutkimusongelma Nykytilassa tietotekniikkapalveluiden verkko on jaettu useisiin erillisiin virtuaalisiin lähiverkkoihin. Verkkojen palomuurisäännöt ovat erilaisia ja monia palveluita tarjotaan vain tiettyihin aliverkkoihin. Tällöin työntekijän on saatava verkkoyhteys tietyn aliverkon kautta, jotta työnteko on mahdollista. Mikäli työntekijän työpiste vaihtuu tai tämä on tilapäisesti vaikkapa toisella kampuksella, täytyy hänen verkkoyhteytensä siirtää käsityönä levittämällä käyttäjän tarvitsema virtuaalinen lähiverkko keskuskytkimiltä työpisteelle asti. Näin tehtäessä aliverkkoon voi liittyä myös sinne kuulumattomia asiakaslaitteita käyttäjän kytkinportin kautta. Tässä työssä suunnitellaan toteutus, jossa työasemaverkot voidaan levittää automaattisesti työasemia palveleville kytkimille ja asiakastyöasemat todentaa kytkinporttitasolla. Näin mahdollistetaan työntekijöiden vapaa liikkuvuus ilman käsityötä sekä saavutetaan kohtuullinen varmuus siitä, että verkossa on vain sinne kuuluvia laitteita. Lisäksi suunnitellaan asiakaspään toteutus Windows, OS X ja Linux käyttöjärjestelmille keskitetysti hallittuihin työasemiin. Tällä hetkellä vastaava toiminnallisuus on käytettävissä langattomassa, mutta ei langallisessa verkossa.

12 2 1.3 Tutkimuksen rajaus Tutkimus rajataan koskemaan siirtoyhteystason liikkuvuutta ja todennusta langallisessa Ethernet pohjaisessa verkossa. Lisäksi toiminnallisuuden käyttöönotto ja suunnittelu rajataan työasemaverkkoihin. Erilaiset palvelinverkot ovat suljettuja ja maantieteellisesti rajattuja, eikä liikkuvuudesta saavuteta niissä hyötyä. Lisäksi verkon yleinen toimintavarmuus saattaisi heikentyä, mikäli esimerkiksi todennuspalvelimen pettäminen sulkisi myös palvelimia verkosta. Kytkinverkko kuvataan nykytilassaan. Työn toteuttamiseen liittyvät protokollat, käytännöt ja verkkolaitteet kuvataan toiminnallisella tarkkuudella. Asiakaslaitteiden konfiguraatio kuvataan yksityiskohtaisesti. Toteutuksen hyötyjä verrataan nykytilaan. Näin voidaan arvioida hyötyjä ja haittoja, joita muutoksista koituu. 1.4 Tutkimusmenetelmä Tutkimusmenetelminä ovat kirjallisuustutkimus sekä työn yhteydessä suunniteltavan toteutuksen tietoturvan, käytettävyyden ja toimintavarmuuden arviointi kirjallisuuden ja testauksen perusteella. 1.5 Tutkimuksen rakenne Työ on jaettu seitsemään osaan. Ensimmäinen osa on johdanto, jossa esitellään tutkimus lyhyesti. Toisessa osassa esitellään tietoturvaan ja todennukseen liittyviä käsitteitä sekä työn kannalta olennaiset teknologiat. Kolmannessa osassa paneudutaan tietoverkkoihin sekä tietotekniikkapalveluiden langallisen verkon rakenteeseen ja toteutukseen. Neljännessä osassa paneudutaan erityisesti 802.1x teknologiaan. Viidennessä osassa kuvataan suunniteltu toteutus, ja kuudennessa osassa arvioidaan toteutusta tietoturvan ja käytettävyyden kannalta. Seitsemännessä osassa esitellään tutkimuksen johtopäätökset.

13 3 2 Tietoturva, protokollat ja todentaminen Langallisten verkkojen tietoturva perustuu pitkälti julkisen avaimen salaus ja todennustekniikoihin, palomuureihin sekä fyysisen infrastruktuurin suojaamiseen. Tässä luvussa esitellään salaus ja todennustekniikoita sekä niihin liittyvää infrastruktuuria, erityisesti julkisten avainten hallintajärjestelmä (Public key infrastructure, PKI), EAP protokolla (Extensible Authentication Protocol), muutamia sen laajennuksia, PEAP sekä RADIUS. Pintapuolisesti esitellään myös TLS protokolla, jota käytetään EAP TLS:n ja PEAP:n osana. 2.1 Julkisen avaimen salaus Julkisen avaimen salauksella tarkoitetaan epäsymmetrisiä salaustekniikoita, joissa viestin avaaminen tapahtuu eri avaimella kuin sen salakirjoittaminen. Tällöin toinen avaimista voidaan julkaista, jolloin kaksi tahoa voi esimerkiksi viestiä toisilleen siten, että lähetettävä viesti salataan julkisella salausavaimella ja vastaanottaja saa viestin auki ainoastaan, jos tällä on hallussaan purkamiseen käytettävä yksityinen avain. Symmetrisissä salausalgoritmeissa salaaminen ja purkaminen tapahtuu samalla avaimella. Tällöin ongelmaksi tulee avainten hallitseminen, sillä viestinnän molempien osapuolten tulee joko tuntea salausavain etukäteen, tai avain täytyy pystyä jakamaan jonkin tahon (KDC, key distribution center) kautta. Julkisen avaimen salaustekniikat poistavat tämän ongelman, koska toinen avaimista on täysin julkinen. [1] Julkisia avaimia käyttäviä algoritmeja suunniteltaessa on tärkeää, että purkuavaimen päätteleminen algoritmin ja tunnetun salausavaimen perusteella on laskennallisesti vaikeaa [2]. 2.2 Varmenteiden hallintajärjestelmä PKI (public key infrastructure) on yleisnimitys laitteistoille, ohjelmistoille, ihmisille, politiikoille ja prosesseille, joita tarvitaan digitaalisten varmenteiden luomiseen, hallitsemiseen, säilyttämiseen, jakeluun ja sulkemiseen [3]. Varmenne on digitaalinen asiakirja, joka yhdistää julkisen avaimen sitä käyttävään tahoon sekä yleisimmässä käyttötarkoituksessaan todistaa, että varmenteen haltijalla on hallussaan julkista avainta vastaava yksityinen avain. Usein PKI toteutuksissa käytetään X.509 standardin mukaisia varmenteita [2]. IETF:n standardi RFC 5280 kuvaa X.509 varmenteiden käyttöä Internet sovelluksissa. PKI:ssa voidaan erottaa mm. seuraavat tahot [4]: lopputaho, CA, RA, CRL julkaisija ja säilytyspaikka. Lopputaho on PKI varmenteiden käyttäjä ja/tai sellainen loppukäyttäjän järjestelmä, jolla on varmenne. CA eli certificate authority on varmenteen allekirjoittaja. RA eli registration authority on mahdollinen lisäjärjestelmä, jolle CA delegoi hallintatoimintoja. CRL julkaisija on järjestelmä, joka luo ja allekirjoittaa varmenteiden sulkulistat. Säilytyspaikka on järjestelmä tai joukko hajautettuja

14 4 järjestelmiä, joka säilyttää varmenteita ja sulkulistoja ja jakaa niitä lopputahoille. Luotettujen tahojen allekirjoittamia varmenteita käytetään verkkoliikenteessä osapuolten tunnistamiseen ja todentamiseen sekä liikenteen salaukseen. Luotetuilla tahoilla taas on hallussaan juurivarmenteita (root CA) tai niistä johdettuja välivarmenteita (Intermediate CA), joilla voidaan allekirjoittaa muita varmenteita X.509 varmenteet X.509 varmenteilla on kaksi kätevää ominaisuutta [5]. Kuka tahansa, jolla on hallussaan CA:n julkinen avain voi lukea tämän allekirjoittaman varmenteen julkisen avaimen. Lisäksi ainoastaan varmenteen allekirjoittanut CA voi muokata varmennetta ilman, että se huomataan. Näiden kahden ominaisuuden ansiosta varmenteet ovat julkisia ne voidaan jakaa julkisesti eikä niitä tarvitse erityisesti suojella. Lisäksi jälkimmäisestä ominaisuudesta seuraa se, että varmenteita ei voi väärentää. Versio Sarjanumero Allekirjoitusalgoritmi Myöntäjän nimi Voimassaoloaika Kohteen nimi Kohteen julkisen avaimen tiedot Myöntäjän uniikki tunniste Kohteen uniikki tunniste Laajennukset Allekirjoitus Versio 1 Versio 2 } Versio 3 } Kaikki versiot Kuva 1: X.509 varmenteen rakenne Varmenteen rakenne on esitetty kuvassa 1. Varmennedokumentti sisältää seuraavat kentät[5]: Versio: Varmenneformaatin versio, oletuksena 1. Mikäli varmenne sisältää myöntäjän ja/tai kohteen uniikin tunnisteen, tulee version olla 2 tai 3. Mikäli varmenne sisältää yhden tai useampia laajennuksia, tulee version olla 3. Käytännössä kaikki nykyään käytössä olevat varmenteet ovat versiota 3. Sarjanumero: CA:n asettama kokonaisluku, joka yhdessä myöntäjän nimen kanssa yksilöi käsiteltävän varmenteen.

15 Allekirjoitusalgoritmi: Allekirjoitettaessa käytetyn algoritmin ja tiivistefunktion tunnus. Myöntäjän nimi: Varmenteen myöntäneen CA:n nimi X.500 muodossa (distinguished name). Voimassaoloaika: Aikaväli, jona CA lupaa huolehtia, että varmenteeseen liittyvät tiedot ovat ajantasalla. Kohteen nimi: Taho, jolle varmenne on myönnetty. Mikäli kyseessä on lopputaho, voi tämä kenttä olla tyhjä, mikäli vastaava tieto löytyy subjectaltname laajennuksesta ja on merkitty kriittiseksi. Kohteen julkisen avaimen tiedot: Tämä kenttä kuvaa algoritmin, jota kohteen julkinen avain käyttää, sekä sisältää varmenteen julkisen avaimen. Myöntäjän uniikki tunniste: Vapaaehtoinen kenttä, jota voidaan käyttää yksilöimään varmenteen myöntäjä, mikäli X.500 muotoinen nimi on käytetty uudelleen. Tämä kenttä on poistunut käytöstä. Kohteen uniikki tunniste: Vapaaehtoinen kenttä, jota voidaan käyttää kohteen tunnistamiseen, mikäli nimi on käytetty uudelleen. Myös tämä kenttä on poistunut käytöstä. Laajennukset: Laajennuskenttä mahdollistaa kenttien liittämisen varmenteisiin ilman, että varmenteen rakennetta tarvitsee muuttaa. Jokainen laajennuskenttä sisältää laajennuksen tunnisteen, kriittisyyslipun ja laajennuksen sisältämän datan. Allekirjoitus: Allekirjoitus sisältää CA:n yksityisellä avaimella salatun tiivisteen muiden kenttien sisällöstä, sekä tiedot salausalgoritmista. Varmenteita on kahden tyyppisiä: CA sekä lopputahovarmenteita. Lopputahovarmenne on varmenne, jonka CA myöntää sellaiselle taholle, joka ei ole toinen CA. CA varmenteet sisältävät basicconstraints laajennuskentän, jossa on merkitty CA käyttötarkoitus sallituksi. Tällaista varmennetta voi käyttää muiden varmenteiden allekirjoittamiseen Varmenteen voimassaolo Normaalitilanteessa varmenne on voimassa varmenteessa määritellyn ajan (jolle tekniset reunaehdot asettaa allekirjoittamiseen käytetyn varmenteen voimassaoloaika). Varmenteita voidaan kuitenkin sulkea myös voimassaoloaikana, mikäli tiedossa on esimerkiksi, että jonkin varmenteen yksityinen avain on saattanut joutua vääriin käsiin. Tällöin varmenne lisätään CA:n sulkulistalle (CRL, certificate revocation list). Sulkulistan rakenne on kuvattu kuvassa 2, ja se sisältämät kentät ovat [5]: Versio: Vapaaehtoinen kenttä, joka sisältää sulkulistan version. Jos lista sisältää kriittiseksi merkityn laajennuskentän, tulee version olla 2. Muutoin versiota ei joko tarvita tai sen on oltava 2. Allekirjoitusalgoritmi: Sisältää tiedot sulkulistan allekirjoittamiseen käytetystä algoritmista. Sama tieto löytyy myös allekirjoituskentästä.

16 6 Versio Allekirjoitusalgoritmi Myöntäjän nimi Tämän päivityksen ajankohta Seuraavan päivityksen ajankohta Suljettu varmenne 1 Suljettu varmenne 2. Suljettu varmenne n Laajennukset Allekirjoitus Kuva 2: Sulkulistan rakenne Myöntäjän nimi: Listan varmenteiden myöntäjän nimi. Tämän päivityksen ajankohta: Aika, jolloin nykyinen sulkulistaversio on julkaistu. Seuraavan päivityksen ajankohta: Vapaaehtoinen kenttä, joka kertoo milloin seuraava versio sulkulistasta ilmestyy. Seuraava versio voi ilmestyä milloin tahansa ennenkin tätä aikaa, mutta ei jälkeen. Suljetut varmenteet: Lista suljetuista varmenteista. Varmenteet tunnistetaan niiden sarjanumeron perusteella. Mikäli listalla ei ole yhtään varmennetta, suositellaan tyhjän kentän jättämistä pois. Laajennukset: Sulkulistan laajennuskentät. Kenttä on vapaaehtoinen. Allekirjoitus: Sulkulistan myöntäjän allekirjoitus. Sulkulistalla varmenteiden järjestyksestä ei oleteta mitään, joten on varmennetta tarkastavan tahon vastuulla käydä koko lista läpi Varmenteen tarkistaminen Varmenteita käytettäessä täytyy pystyä varmistamaan varmenteen aitous, luotettavuus ja voimassaolo. Varmenteen luotettavuus määritetään listan luottamusankkureita avulla. Luottamusankkuri on sellaisen tahon juurivarmenne, jonka toimintatapoihin ja kykyyn tunnistaa varmenteen kohde luotetaan ja viime kädessä luottamusankkurit valitsee varmennetta kulloinkin tarkistava taho itse. Lopputahon varmenteen ja luottamusankkurin välillä saattaa olla useiden CA varmenteiden ketju. Jos tutkittavan varmenteen

17 allekirjoitusketju ei johda luottamusankkuriin, ei varmennetta voida katsoa luotetuksi. Luottamusketju ja suhteet on esitetty kuvassa 3. 7 Luottamusankkuri CA CA PKI CA Lopputaho Luottava taho Kuva 3: Luottamusankkuri ja varmenteen allekirjoitusketju Allekirjoituksen ansiosta varmenteen aitouden voi määrittää laskemalla tiivisteen kenttien sisällöstä ja vertaamalla sitä varmenteen myöntäjän laskemaan tiivisteeseen, joka voidaan purkaa allekirjoituskentästä myöntäjän julkisella avaimella. Mikäli tiivisteet ovat yhtenevät, voidaan varmennetta pitää aitona. Myös tämä tehdään koko varmenneketjulle. Jos tiivisteet eroavat, on varmennetta muutettu allekirjoittamisen jälkeen, eikä sitä sen vuoksi voida hyväksyä. Varmenteen voimassaolon määrittäminen tapahtuu vertaamalla varmenteen voimassaoloaikaa nykyiseen päivämäärään. Lisäksi varmenne ei saa olla suljettu eli se ei saa olla varmenteen myöntäjän sulkulistalla. Mikäli kaikki varmenneketjun varmenteet täyttävät nämä ehdot, voidaan varmennetta pitää voimassaolevana. Voimassaolo voidaan tarkistaa erillisen sulkulistan noutamisen sijaan myös esimerkiksi OCSP protokollalla (Online Certificate Status Protocol), jos myöntäjä tarjoaa siihen mahdollisuuden [6]. Tarkistusprosessia eri tarkistustapa ei kuitenkaan muuta millään tavalla. Mikäli varmenteen tilaa ei voida määrittää, esimerkiksi sulkulistan puuttuessa, varmennetta ei katsota voimassaolevaksi. Mikäli varmenne on voimassa ja se voidaan katsoa aidoksi ja luotettavaksi, voidaan yleensä olla melko varmoja siitä, että sitä käyttävä taho on se, joka väittääkin olevansa. Varmenteita käyttävät protokollat sisältävät vielä itse varmenteen tarkistuksen lisäksi myös varmistuksen sille, että varmenteen haltijalla on hallussaan myös varmenteen yksityinen avain. Tämä käsitellään TLS:n osalta luvussa 2.4.

18 8 2.3 EAP EAP (Extensible Authentication Protocol) on todennukseen käytettävä protokolla, joka tukee useita todennustapoja ja jota voidaan nimensä mukaisesti laajentaa. Se on määritelty RFC 3748:ssa ja myöhemmin määritystä on päivitetty RFC 5247:ssa. EAP ei protokollana ota kantaa siirtotiehen tai laajennuksiin, vaan määrittelee ainoastaan viestien muodon ja todennusprosessin. Erityisesti EAP ei tarvitse IP protokollaa toimiakseen, ja sitä voidaankin käyttää esimerkiksi suoraan verkkoyhteyskerroksen päällä. [7] EAP määrittelee kolme todennukseen osallistuvaa osapuolta, jotka ovat asiakas (peer), todentaja (authenticator) sekä todennuspalvelin (AAA, backend authentication server). Asiakas on yhteyden se pää, joka vastaa todentajalle. Todentaja on yhteyden se pää, joka käynnistää todennuksen, yleensä esimerkiksi jokin verkkolaite. Todennuspalvelin tarjoaa todennuspalvelun todentajalle. Todentaja ja todennuspalvelin voivat sijaita myös samassa laitteessa/palvelimessa, jolloin erillistä todennuspalvelinta ei tarvita Pakettityypit EAP protokolla käyttää neljän tyyppisiä paketteja, joilla on kaksi erilaista otsaketta Code Identifier Length Data... Kuva 4: Yleinen EAP otsake EAP protokollan otsake on esitetty kuvassa 4. Code kenttä on yhden oktetin mittainen ja sisältää pyynnön tyypin. Codella on neljä eri arvoa, ja mikäli kenttä sisältää muun kuin jonkin näistä neljästä arvosta, jätetään paketti huomiotta. Arvot ovat pyyntö (Request, 1), vastaus (Response, 2), onnistuminen (Success, 3) sekä epäonnistuminen (Failure, 4). Yhden oktetin pituisella Identifier kentällä pystytään yhdistämään saatu vastaus oikeaan pyyntöön. Kahden oktetin pituinen Length kenttä kertoo EAP paketin kokonaispituuden mukaanlukien sekä otsakkeen että datan. Data kentän (0 bittiä tai enemmän) muoto määrittyy Code kentän perusteella. Mikäli pakettia vastaanotettaessa pituus ylittää Length kentässä ilmoitetun pituuden, jätetään yli menevä osuus huomiotta. Mikäli taas pituus on ilmoitettua pienempi, jätetään koko paketti huomiotta. Pyyntö ja vastauspakettien otsake (Code arvot 1 ja 2) on esitetty kuvassa 5. Pyynnöillä ja vastauksilla on lisäksi Type kenttä (8 bittiä), jonka arvo kertoo todennuksen tyypin. Kaikkien EAP toteutusten täytyy tukea ainakin Type arvoja identify (1), notification (2), nak (3) sekä MD5 Challenge (4).

19 Code Identifier Length Type Type Data... Kuva 5: EAP otsake, pyynnöt ja vastaukset Lisäksi itse EAP:n määrittelyssä on listattu tyypit 5 (kerta avain, One Time Password), 6 (Generic Token Card, GTC) ja 254 (laajennetut tyypit). Näistä kaikkien toteutusten tulisi tukea laajennettuja tyyppejä. EAP tyyppien listaa ylläpitää nykyään IANA (Internet Assigned Numbers Authority) ja tyyppejä on rekisteröity n. 50 [8]. Kenttä Type Data sisältää pyynnön tai vastauksen mukana välitettävän datan. Success ja Failure pakettien otsake on identtinen kuvassa 4 esitetyn yleisen otsakkeen kanssa Todennusprosessi EAP todennusprosessilla on kaksi osapuolta: asiakas ja todentaja. Todentajan tavoitteena on todentaa asiakas esiteltyä prosessia käyttäen. EAP todennusprosessi on esitetty kuvassa 6. Prosessissa todentaja lähettää todentautumispyynnön (Request) asiakkaalle. Pyyntö sisältää pyynnön tyypin (Type kenttä), joka kertoo mitä pyynnössä halutaan. Tyypillisesti ensimmäisessä pyynnössä pyydetään asiakasta tunnistautumaan (Identity), mutta tämä ei välttämättä ole aina tarpeen. Asiakas vastaa pyyntöön vastauspaketilla (Response). Myös vastauspaketti sisältää vastauksen tyypin, joka vastaa pyynnön Type kenttää ja saa saman arvon. Tämän jälkeen todentaja lähettää uuden pyynnön ja asiakas vastaa vastauspaketilla. Tätä ketjua jatketaan niin kauan, kunnes todentaja pystyy joko todentamaan asiakkaan tai kieltäytymään todentamasta tätä. Mikäli todentaminen epäonnistuu, vastaa todentaja EAP Failure paketilla. Onnistuneessa tapauksessa vastataan EAP Success paketilla. EAP protokolla on määritelty siten, että kerrallaan liikkeellä voi olla vain yksi paketti (pyyntö tai vastaus). Koska protokolla ei ota siirtotiehen kantaa, tukee se virheenkorjauksena uudelleenlähetystä, mutta ei esimerkiksi fragmentointia, ellei käytettävään todennustapaan ole rakennettu erikseen sille tukea. [7] 2.4 TLS TLS (Transport Layer Security) on protokolla, jonka tarkoituksena on mahdollistaa viestinnän yksityisyys (privacy) ja viestin koskemattomuus (data integrity) osapuolten välillä. TLS:n uusin versio on 1.2, ja se on kuvattu RFC 5246:ssa. TLS:n vanhemmat versiot ovat 1.1 ja 1.0 ja niitä edelsivät SSL protokollan (Secure Sockets Layer) versiot 1, 2 ja 3. TLS sisältää mekanismin, jolla yhteys voidaan muodostaa parhaalla mahdollisella salauksella, jota molemmat osapuolet ymmärtävät. Sen vuoksi se

20 10 Asiakas Todentaja EAP-Response Identity EAP-Request Identity EAP-Request x EAP-Response x EAP-Request y EAP-Response y EAP-Success / EAP-Failure Kuva 6: Asiakkaan todennusprosessi EAP protokollalla sisältää myös yhteensopivuuden taaksepäin aikaisempien protokollaversioiden kanssa. Koska osa aikaisemmista versioista on nykymittapuulla heikkoja tai murrettavissa, on taaksepäin yhteensopivuutta rajoitettu myöhemmin. Kaikki SSL protokollan versiot ovat tietoturvasyistä vanhentuneita eikä niitä pitäisi käyttää [9]. Lisäksi RC4 salakirjoitus on vanhentunut eikä sitä pitäisi käyttää [10]. TLS rakentuu kahdesta kerroksesta, eikä sinänsä ota kantaa käytettävään siirtotiehen sen enempää kuin että sen tulee olla luotettava [11]. TLS:n alempi kerros on TLS tietueprotokolla (TLS Record Protocol), jota käytetään tiedon välittämiseen turvallisesti. Ylempi kerros sisältää neljä protokollaa: kättelyprotokollan (handshake protocol), virheviestiprotokollan (alert protocol), salakirjoituksen vaihtoprotokollan (change cipher spec protocol) sekä sovellusdataprotokollan (application data protocol) [11]. Nämä ylemmän kerroksen protokollat käyttävät tietueprotokollaa tiedonsiirtoon. Lisäksi TLS protokollaa voidaan laajentaa uusilla tietueiden sisältötyypeillä. Näistä protokollista käsitellään itse tietueprotokollan lisäksi kättelyprotokolla sekä sovellusdataprotokolla.

21 Tietueprotokolla Tietueprotokolla pitää yllä yhteyden tilaa. Tila sisältää käytettävän pakkausalgoritmin, salakirjoitusalgoritmin ja MAC algoritmin (Message Authentication Code), sekä niiden parametrit. TLS protokollalla on kullakin hetkellä neljä yhtäaikaista tilatietoa: nykyiset luku ja kirjoitustiedot sekä vireillä olevat luku ja kirjoitustilat. Vireillä olevia tilatietoja voidaan muuttaa kättelyprotokollan avulla ja käytössä oleva tila voidaan vaihtaa salakirjoituksen vaihtoprotokollan avulla. Tilatieto sisältää seuraavat arvot [11]: Yhteyden pää: onko kyseessä yhteyden asiakas vai palvelinpää. PRF algoritmi (pseudorandom function): satunnaislukualgoritmi, jolla luodaan avaimet pääsalasanasta. Salakirjoitusalgoritmi: algoritmi, jolla viestit salakirjoitetaan sisältäen avaimen pituuden. MAC algoritmi: viestin todennukseen käytettävä algoritmi. Pakkausalgoritmi: datan pakkaamiseen käytettävä algoritmi. Pääsalasana: 48 tavun mittainen jaettu salaisuus. Asiakkaan satunnaisluku: 32 tavun mittainen satunnaisluku. Palvelimen satunnaisluku: 32 tavun mittainen satunnaisluku. Yhdessä näitä kutsutaan yhteyden turvallisuusparametreiksi (Security Parameters). Turvallisuusparametrien avulla tietuekerros luo asiakkaalle ja palvelimelle MAC avaimen, salausavaimen sekä alustusvektorin. Tietueprotokollan toiminta on esitetty kuvassa 7. Tietueprotokolla jakaa siirrettävän tiedon tietueisiin, jotka sisältävät enintään tavua tietoa. Tietueet sisältävät neljä kenttää, jotka ovat protokollaversio, tietueen tyyppi, tietueen pituus sekä tietueen data [11]. Protokollaversio on lukupari, joka kertoo käytetyn protokollaversion. TLS 1.2 käyttää versiokentässä arvoa (3,3). Tietueen tyyppi kertoo nimensä mukaisesti tietueen tyypin. Tietueen pituus kertoo sen sisältämän datakentän pituuden, joka voi olla enintään (2 14 ) tavua. Datakenttä kattaa loput tietueesta ja sisältää siirrettävän tiedon. Kättelyn jälkeisessä liikenteessä turvallisuusparametreista päättämisen jälkeen viestien sisältö pakataan ja salakirjoitetaan käyttäen turvallisuusparametreista muodostettuja avaimia ja pituuskenttä päivitetään vastaavasti. Viestiä vastaanotettaessa suoritetaan samat toimenpiteet käänteisessä järjestyksessä. Pakkaus ja salakirjoitus voivat lisätä tietueen datan pituutta ja siten ylittää pituuden maksimiarvon. Pakkaus voi lisätä tietueen pituuteen enintään 1024 tavua, salakirjoitus enintään 2048 tavua. Kuitenkin, jos salakirjoituksen ja pakkauksen purkamisen jälkeen tietueen pituus on yli tavua, on kyseessä virhetilanne, josta lähetetään virheviesti. Jokaista ylemmän kerroksen protokollaa vastaa oma tietuetyyppi. Sallitut sisältö-

22 12 Sovelluksen data Fragmentointi Pakkaus MAC Salakirjoitus Tietueotsakkeen lisäys Kuva 7: TLS tietueprotokollan toiminta tyypit ja niiden numerot ovat [11]: salakirjoituksen vaihtoviesti (Change Cipher Spec, 20), virheviesti (Alert, 21), kättelyviesti (Handshake, 22) sekä sovellusdata (Application data, 23). Lisäksi on olemassa laajennettuja tyyppejä, joita ei kuitenkaan tässä käsitellä. Mikäli vastaanotetaan paketti, jonka sisältötyyppi on tuntematon, lähetetään vastauksena virheviesti. TLS yhteys muodostetaan kättelyprosessin avulla. Yhteyden muodostamisen jälkeen voidaan osapuolten välillä välittää dataa yleensä muita protokollia TLS tietueiden sisällä sovellusdataprotokollan avulla Kättelyprosessi Kättelyprotokollan tehtävä on sopia istunnon parametreista sekä muodostaa niiden pohjalta turvallisuusparametrit. Prosessi on pääpiirteittäin seuraava: 1. Algoritmeista sopiminen ja satunnaislukujen luominen. 2. Salausparametrien jakaminen, jotta asiakas ja palvelin voivat sopia yhteisen salaisuuden. 3. Varmenteiden jakaminen osapuolten todentamiseksi. 4. Pääsalasanan luominen aiemmin sovitun yhteisen salaisuuden ja jaettujen satunnaislukujen avulla. 5. Turvallisuusparametrien asettaminen tietuekerrokselle.

23 6. Asiakas ja palvelin varmistavat päätyneensä samoihin turvallisuusparametreihin, ja että kättelyprosessiin ei ole päästy kajoamaan ulkopuolelta. 13 Asiakas Palvelin TLS-ClientHello Varmenne Avaintenvaihto Varmenteen tarkistus TLS-Finished TLS-ServerHello Varmenne Avaintenvaihto Varmennepyynt TLS-Finished Kuva 8: TLS kättelyprosessi Kättelyprosessi on esitetty kuvassa 8. Ensin asiakas lähettää ClientHello paketin, joka sisältää ehdotuksen käytettävästä TLS versiosta ja listan asiakkaan tukemista salakirjoitus ja pakkausalgoritmeista. Palvelin vastaa ServerHello paketilla, joka sisältää tiedon palvelimen valitsemista algoritmeista sekä TLS versiosta. Lisäksi palvelin lähettää varmenteensa. Palvelin voi myös pyytää asiakkaalta varmennetta. Asiakas ja palvelin vaihtavat istunnon salausavaimet käyttäen varmenteen tai varmenteiden julkisia avaimia istuntoavainten salakirjoittamiseen. Tämän jälkeen muodostetaan vireillä olevat tilatiedot ja vaihdetaan ne käyttöön salakirjoituksen vaihtoprotokollan avulla. 2.5 EAP TLS EAP TLS on EAP protokollan laajennus, joka mahdollistaa osapuolten molemminpuolisen tunnistuksen varmenteiden avulla. Se on määritelty RFC 5216:ssa. Käytännössä kyse on tavasta suorittaa TLS kättely EAP protokollaan upotettuna. EAP TLS:n etuna on moneen muuhun EAP tyyppiin verrattuna se, että varmenteiden ansiosta voidaan tunnistaa liikenteen molemmat osapuolet. Lisäksi pakettien sisältö on salattu siten, että ne voidaan tarvittaessa lähettää myös turvattoman siirtotien läpi.

24 14 Koska EAP TLS viestit voivat kasvaa yli siirtoprotokollan paketin maksimikoon tai siirtotien MTU arvon (maximum transmission unit), eikä EAP protokolla tee oletuksia siirtotien suhteen, on EAP TLS:ään rakennettu erikseen pakettien fragmentointi, eli osiin jakaminen ja uudelleen koonti. Osittaisia paketteja kutsutaan fragmenteiksi Pakettityypit EAP TLS paketin rakenne on esitetty kuvassa 9. Paketin sisältämät kentät ovat paketin tyyppi (Code), paketin tunniste (Identifier), paketin pituus (Length), EAP tyyppi (Type), pakettia kuvaavat binäärimuuttujat (Flags), paketin sisältämän TLS viestin pituus (TLS Message Length) sekä itse TLS sisältö (TLS Data) Code Identifier Length Type Flags TLS Message Length TLS Message Length TLS Data... Kuva 9: EAP TLS paketin rakenne Code, Identifier, Length ja Type kentät on kuvattu luvussa 2.3 EAP protokollan yhteydessä. EAP TLS viesteissä Type kentän arvo on 13. Flags bittikenttä sisältää protokollan tarvitsemia binäärimuuttujia. Kenttä on määritelty erikseen pyynnöille ja vastauksille. Pyynnön Flags kentälle on määritelty kolmen ensimmäisen bitin merkitys, vastaukselle kahden LMS RRRRR Kuva 10: EAP TLS pyynnön Flags kenttä Pyynnön Flags kenttä on esitetty kuvassa 10. L binäärimuuttuja kertoo, sisältääkö paketti pituuskentän. M binäärimuuttuja kertoo onko tulossa lisää fragmentteja ja S binäärimuuttuja on EAP TLS aloitusmerkintä. R bitit ovat varattuja. L bitti kertoo, että viesti sisältää neljän oktetin pituisen TLS Message Length kentän. L bitin tulee olla päällä pyynnön ensimmäisessä fragmentissa. M bitti kertoo, että sen sisältävää pakettia seuraa yksi tai useampia fragmentteja. S bitti asetetaan päälle aloitusviestissä ja se erottaa aloitusviestin fragmentin vastaanottoviestistä. Varatut bitit tulee asettaa nollaksi ja sivuuttaa LMRRRRRR Kuva 11: EAP TLS vastauksen Flags kenttä

25 Vastauksen Flags kenttä on esitetty kuvassa 11. Kirjainten merkitykset ovat samat kuin edellä pyynnöissäkin, mutta S kenttää ei voi esiintyä. Varatut bitit tulee asettaa nollaan ja sivuuttaa kuten pyyntöjenkin yhteydessä. TLS Message Length kenttä on neljän oktetin pituinen ja sisältyy pakettiin ainoastaan, kun L bitti on asetettu. Kenttä sisältää fragmentoitavan TLS viestin tai viestiketjun koko pituuden. TLS Data kenttä sisältää itse upotetun TLS paketin Fragmentointi EAP TLS protokolla sisältää TLS viestejä ja yksittäisen TLS viestin koko voi olla hyvinkin suuri. Tämän vuoksi laajennuksen käyttäminen edellyttää, että protokollaan rakennetaan tuki suurille paketeille. Koska EAP:ssa pakettien järjestys määräytyy Identifier kentän avulla ja kadonneet tai virheelliset paketit lähetetään uudelleen, fragmenttien paikkaa ketjussa ei tarvitse erikseen mainita toisin kuin esimerkiksi IP(v4):n fragmentoinnissa. Tuki fragmentoinnille on toteutettu Flags kentän avulla [12]. Fragmentoidun viestin ensimmäisessä paketissa on oltava asetettuna sekä L että M bitit ja paketin tulee sisältää TLS Message Length kenttä. Vastaanotettaessa pakettia, jonka M bitti on asetettu, tulee pakettiin vastata osapuolesta riippuen EAP TLS pyynnöllä tai vastauksella, joka ei sisällä dataa. Tästä toinen osapuoli tietää, että fragmentti on vastaanotettu ja lähettää seuraavan osan. Todentaja kasvattaa Identifier kentän arvoa yhdellä jokaisen fragmentin yhteydessä, ja uudelleenlähetetyissä paketeissa täytyy säilyttää sama Identifier kenttä. Viimeisen paketin (ensimmäinen paketti, jonka M bitti ei ole päällä) vastaanottamisen yhteydessä viesti kootaan. Erilaisten DoS (denial of service) yms hyökkäysten estämiseksi EAP TLS paketille on mahdollista asettaa maksimikoko, esimerkiksi 64kB [12] Todennusprosessi Todennusprosessi on identtinen EAP protokollan todennusprosessin kanssa, mutta koska viestit voivat olla suuria ja niitä voidaan joutua fragmentoimaan, ovat Request Response ketjut yleensä pidempiä. Koska varmenteiden avulla voidaan tunnistaa viestinnän molemmat osapuolet, tulee erityisesti EAP Identity viestissä saatujen tietojen käyttämistä välttää, mikäli ne ja varmenteen tiedot eroavat toisistaan [12]. 2.6 PEAP PEAP (Protected EAP) on Microsoftin ja Ciscon määrittelemä tapa välittää EAP liikennettä TLS:n läpi. Se on määritelty IETF luonnoksessa, mutta varsinaista virallista standardidokumenttia siitä ei ole. PEAP versioita on kolme (v0, v1 ja

26 16 v2), mutta käytännössä näistä käytössä on lähes yksinomaan PEAPv0. Teknisesti PEAPv0 on hyvin läheistä sukua EAP TLS:lle. Kuitenkin sen sijaan, että TLS protokollaa käytettäisiin osapuolten todentamiseen, luodaan sitä käyttäen salattu yhteys, jonka sisällä todennetaan käyttäjä (jälleen) EAP protokollan avulla käyttäen jotain toista EAP metodia [13]. PEAP:lla on oma EAP tyyppi 25 [8] Code Identifier Length Type Flags Ver TLS Message Length TLS Message Length TLS Data... Kuva 12: PEAPv0 paketin rakenne PEAP paketin rakenne on esitetty kuvassa 12. Verrattaessa kuvia 12 ja 9 huomataan niiden olevan muuten identtiset, mutta PEAP paketin Flags kenttä on lyhyempi kuin EAP TLS:n vastaava, ja otsakkeeseen on lisätty versiokenttä. PEAP:n Flags kentän rakenne on esitetty kuvassa 13. Versiokenttä on kahden bitin pituinen. PEAPv0 määrittelyssä ensimmäinen bitti on varattu ja toinen LMS RRR Kuva 13: PEAPv0 protokollan Flags kenttä PEAPv0 protokollaa käytetään muodostamaan TLS yhteys todennukseen osallistuvien osapuolten välille. Tämän TLS yhteyden sisällä välitetään sen jälkeen EAP paketteja, joiden avulla suoritetaan varsinainen todennus. TLS yhteydellä saavutetaan kaksi etua: varmenteiden ansiosta todennuspalvelin voidaan tunnistaa ja salatun yhteyden sisällä voidaan tarvittaessa käyttää todennustapoja, joilla on tunnettuja heikkouksia. Eräs PEAP:n yhteydessä yleisesti käytetty tällainen todennustapa on MS CHAPv2 protokolla (Microsoft Challenge Handshake Authentication Protocol version 2), joka on määritelty RFC 2759:ssa ja käyttää heikkoa DES salausta [14]. Koko kerrosrakenne on esitetty kuvassa 14. PEAP TLS EAP Esim. MS CHAPv2 Kuva 14: PEAP kerrostus uloimmasta sisimpään

27 Fragmentointi PEAP:n fragmentointi on mekanismiltaan identtinen EAP TLS:n fragmentoinnin kanssa, poislukien EAP Type kentän arvo. EAP TLS:n fragmentointi on esitelty luvussa RADIUS RADIUS (Remote Authentication Dial In User Service) on protokolla, joka on määritelty RFC 2865:ssa. Se on tarkoitettu käyttäjän todennukseen verkkoon liittymisen yhteydessä, alunperin mm. modeemiyhteyksissä. Protokolla sinänsä on kuitenkin hyvin monikäyttöinen ja laajennettavissa. [15] RADIUS liikenteellä on kaksi osapuolta: verkkopääsyn mahdollistava palvelin (Network Access Server, käytännössä asiakas) sekä RADIUS palvelin. RADIUS palvelin pystyy lisäksi ohjaamaan pyyntöjä muille RADIUS palvelimille tai muunlaisille todennuspalvelimille. Verkkopääsyn mahdollistava palvelin tarjoaa käyttäjän tiedot RADIUS palvelimille ja vastauksen perusteella mahdollistaa pääsyn verkkoon. RADIUS palvelin taas vastaanottaa yhteyspyynnöt, todentaa käyttäjän ja palauttaa asiakaskoneelle tarvittavat konfigurointitiedot, jotta tämä voi palvella käyttäjää. Protokolla tukee useita eri todennustapoja ja sitä voidaan laajentaa uusilla toiminnallisuuksilla. RADIUS liikenteen yhteydessä voidaan välittää myös EAP paketteja todennustietona [16]. RADIUS palvelin ja verkkopääsyn mahdollistava palvelin käyttävät liikenteessään turvamekanismina vaihtuvaa Authenticator kenttää sekä jaettua salaisuutta, joka on käytännössä salasana. Salasana voi ja sen pitäisi olla eri asiakkaille eri. Asiakas tunnistetaan pyynnön lähdeosoitteen perusteella, jolloin osataan käyttää ko. asiakkaan kanssa jaettua salasanaa. Salasanan pitäisi protokollamäärittelyn mukaan olla vähintään 16 oktettia pitkä ja noudattaa normaaleja suosituksia hyvälle salasanalle. [15] RADIUS käyttää UDP protokollaa ja porttia Pakettityypit RADIUS paketti on esitetty kuvassa 15. Paketin sisältämät kentät ovat Code, Identifier, Length, Authenticator sekä Attributes [15]. Code kenttä on yhden oktetin pituinen ja kertoo RADIUS paketin tyypin. Protokollamäärittely määrittelee 9 koodia, joista koodit 12 (Status Server) ja 13 (Status Client) on varattu tulevaan käyttöön. Mikäli vastaanotetaan paketti, jonka koodi ei ole mikään määritellyistä, paketti sivuutetaan. Kaikki Code kentän mahdolliset arvot ja siten pakettityypit on listattu taulukossa 1.

28 Code Identifier Length Request / Response Authenticator Attributes... Kuva 15: RADIUS paketin muoto Taulukko 1: RADIUS-paketin Code kentän mahdolliset arvot Nro Merkitys 1 Access Request 2 Access Accept 3 Access Reject 4 Accounting Request 5 Accounting Response 11 Access Challenge 12 (Status Server) 13 (Status Client) 255 Varattu Identifier kenttä (tunniste) on yhden oktetin pituinen ja sisältää tunnisteen, jonka avulla voidaan havaita kahdennetut pyynnöt. Mikäli pyynnössä on sama lähettäjän IP osoite, sama lähettäjän portti ja sama tunniste pienen ajan sisällä, katsotaan se duplikaatiksi. Length kenttä on kahden oktetin pituinen ja kertoo paketin pituuden sisältäen Code kentän, Identifier kentän, Length kentän, Authenticator kentän ja Attribute kentät. Jos paketti on pidempi kuin Length kenttä kertoo, sivuutetaan ylimenevä osa. Mikäli paketti on lyhyempi, sivuutetaan koko paketti. Minimipituus on 20 ja maksimipituus 4096 tavua. Authenticator kenttä on kuudentoista oktetin pituinen. Merkitsevin oktetti lähetetään ensin. Arvoa käytetään todentamaan RADIUS palvelimen vastaus sekä salasanan piilottamiseen. Authenticator kentän sisältö on pyynnöissä (tällöin kentälle käytetään nimeä Request Authenticator) 16 oktetin pituinen satunnainen merkkijono. Kentän sisältö ei saisi olla ennustettavissa eikä sama arvo saisi toistua yhden jaetun salaisuuden elinaikana. Vastauksissa (Access Accept, Access Reject ja Access Challenge paketit) kentästä käytetään nimeä Response Authenticator, ja se sisältää MD5 tiivisteen muiden

29 19 kenttien sisällöstä. Kentän sisältö muodostetaan seuraavasti: Resp.Auth. = MD5(Code + ID + Length + Req.Auth. + Attributes + Secret), jossa + tarkoittaa merkkijonojen yhdistämistä peräkkäin. [15] Attribuuttien muoto on esitetty kuvassa 16. Jokainen attribuutti sisältää kolme kenttää, jotka ovat type (attribuutin numero), length (attribuuttikentän pituus), sekä value (attribuutin arvo/sisältö) [15]. Attribuuttinumeroiden rekisteröintiä hoitaa IANA (The Internet Assigned Numbers Authority), ja tällä hetkellä rekisteröityjä attribuutteja on toista sataa [17]. Attribuutteja listataan tässä työssä sitä mukaa, kun ne ovat toiminnan kannalta oleellisia Type Length Value... Kuva 16: RADIUS Attribuutit Todennusprosessi RADIUS todennusprosessi on esitetty kuvassa 17. RADIUS protokollassa asiakas on verkkopääsyn mahdollistava palvelin. Asiakas lähettää RADIUS palvelimelle Access Request paketin. RADIUS palvelin voi vastata tähän pyytämällä tietoja Access Challenge paketilla, jolloin asiakkaan tehtävä on toimittaa lisätiedot uudessa Access Request paketissa. Kun RADIUS palvelin on saanut tarpeeksi tietoja, jotta se voi tehdä päätöksen käyttäjän todentamisesta, vastaa se joko Access Accept tai Access Reject paketilla EAP liikenteen välittäminen RADIUS paketeissa Koska EAP protokolla ei ole sidottu mihinkään tiettyyn siirtotiehen, voidaan sitä käyttää myös RADIUS protokollan yli. Tämä toiminnallisuus on kuvattu RFC 3579:ssa. EAP:n välittämistä varten RADIUS protokollaan lisätään kaksi attribuuttia. Nämä attribuutit ovat EAP Message ja Message Authenticator [16]. EAP Message attribuutti sisältää upotetun EAP paketin. Message Authenticator kenttää käytetään EAP liikenteen varmentamisessa. Pyynnöissä (Access Request) Message Authenticator kenttä sisältää HMAC MD5 tiivisteen koko paketista käyttäen jaettua salaisuutta avaimena [16]: M sg Auth. = HM AC M D5(T ype+identif ier+length+req.auth.+attributes) Vastauspaketeissa (Access Challenge, Access Accept ja Access Reject) kentän sisältö määräytyy samalla tavalla kuin pyynnöissäkin sillä erotuksella, että käytettävä Request Authenticator arvo otetaan suoraan pyynnöstä [16].

30 20 Asiakas RADIUS-palvelin RADIUS Access-Request RADIUS Access-Request RADIUS Access-Challenge RADIUS Access- Accept / Access-Reject Kuva 17: Asiakkaan todennusprosessi RADIUS protokollalla RFC 3579 suosittelee IPsec suojauksen käyttöä liikenteessä sisällön salaamiseksi. Käytännössä tähän kuitenkin käytetään joko EAP TLS:a tai PEAP:ia (tai langattomissa verkoissa myös EAP TTLS:a) RADIUS kirjanpitoprotokolla RADIUS kirjanpitoprotokolla eli RADIUS Accounting on protokolla, joka on määritelty RFC 2866:ssa. Se käyttää UDP porttia 1813 ja sitä voidaan käyttää RADIUS palvelun lokitukseen. RADIUS palvelinta kutsutaan usein AAA palvelimeksi (Authentication, Authorization and Accounting). RADIUS protokolla toteuttaa näistä todennuksen ja valtuutuksen, kirjanpidon toteuttaa RADIUS Accounting. Protokollassa asiakas (verkkopääsyn mahdollistava palvelin) lähettää RADIUS protokollaa käyttäen Accounting Request paketin, joka sisältää lokitettavan istunnon tiedot. Palvelin vastaa parhaansa mukaan Accounting Response paketilla. RADIUS Accounting protokolla on mainittu kokonaisuuden vuoksi, mutta sitä ei tässä työssä käsitellä tätä tarkemmalla tasolla.

31 21 3 Tietoverkot Tässä kappaleessa esitellään tietoverkkoihin liittyviä käsitteitä, verkon topologioita sekä verkon jakamista virtuaalisiin lähiverkkoihin eli VLAN:eihin. Lopuksi käydään läpi Aalto yliopiston verkon rakennetta sekä Ethernet verkkojen heikkouksia. Koska työssä keskitytään lähiverkkoihin (Local Area Network, LAN), rajataan käsittelyn ulkopuolelle laajempiin verkkoihin (Wide Area Network, WAN) liittyviä käsitteitä. 3.1 Kerrosmallit Tietoverkkojen toimintaa havainnollistetaan usein kerrosmalleilla, sillä tiedon siirron voidaan katsoa tapahtuvan eri kerroksina, riippuen tiedoista ja datan esitystavasta. Eräs malli tietoverkkojen toiminnan hahmottamiselle on niin kutsuttu OSI malli (Open Systems Interconnection model). Se on julkaistu standardina ISO/IEC sekä ITU T:n dokumenttina X.200. Malli jakaa verkon seitsemään kerrokseen, joista alin on fyysinen kerros ja ylin sovelluskerros. Kerrokset ja kerroksien suhteet on esitetty kuvassa 18. Sovelluksen data 7. Sovelluskerros Esitystapaotsake 6. Esitystapakerros Istunto-otsake 5. Istuntokerros Kuljetusotsake 4. Kuljetuskerros Verkko-otsake 3. Verkkokerros Siirtoyhteysotsake 2. Siirtoyhteyskerros Fyysinen otsake 1. Fyysinen kerros Kuva 18: OSI kerrosmalli OSI mallissa jokainen seitsemästä kerroksesta saa dataa edelliseltä kerrokselta, tekee sille tarvittaessa jotain (esimerkiksi salaa sen esitystapakerroksessa), ja lisää oman otsakkeensa. Lähetettäessä sovelluksen data kuljetetaan alempien kerrosten läpi, siirretään fyysisellä kerroksella bitteinä vastaanottajalle ja vastaanottaja vastaanottaa bitit ja siirtyy kerroksissa ylöspäin, kunnes tällä on jäljellä sovelluskerroksella alunperin lähetetty data. OSI malli ei sellaisenaan sovellu reaalimaailman kuvaamiseen, sillä useat käytännön protokollat sisältävät piirteitä useammista kerroksista, eikä ole välttämättä selvää,

32 22 mihin kerrokseen ne kuuluvat. Malli on kehitetty ennen kuin nykyiset verkkoprotokollat on kehitetty, eikä käytössä siten ole ollut kaikkea sitä käytännön tietoa, josta olisi voinut olla hyötyä. Toinen tunnettu kerrostusmalli on IETF:n ylläpitämä TCP/IP kerrosmalli, jossa on neljä kerrosta. Kerrokset on kuvattu RFC 1122:ssa [18]. TCP/IP mallin kerrokset on esitetty kuvassa 19. Malli keskittyy enimmäkseen protokollien luokitteluun, eikä sisällä fyysistä kerrosta ollenkaan. Mallin protokollat ovat yleisessä käytössä kaikkialla, mutta itse mallia näkee käytettävän sellaisenaan harvoin. DNS, HTTP(S), SSH, DHCP,... TCP, UDP 4. Sovelluskerros 3. Kuljetuskerros IP, ICMP, IGMP,... ARP, Ethernet, Internet kerros 1. Yhteyskerros Kuva 19: TCP/IP kerrosmalli Molempien mallien perimmäinen ajatus on sama, eli jokainen alempi kerros lisää oman osansa ylempään kerrokseen. Koska kummatkin mallit ovat yksinään vajavaisia, on esitetty monia vaihtoehtoisia malleja. Näistä esitellään tässä Andrew Tanenbaumin esittelemä malli, joka sisältää viisi kerrosta. Kerrokset on esitetty kuvassa 20. Kerrokset ovat käytännössä samoja kuin OSI mallissa, mutta siitä on karsittu todellisuuteen huonosti sopivia kerroksia [19]. Tässä työssä verkkokerroksiin viitatessa viitataan Tanenbaumin malliin. HTTP 5. Sovelluskerros TCP HTTP 4. Kuljetuskerros IP TCP HTTP 3. Verkkokerros Eth IP TCP HTTP 2. Siirtoyhteyskerros Fyysinen kerros Kuva 20: Tanenbaumin hybridimalli esimerkkiprotokollilla Fyysinen kerros ja siirtoyhteyskerros Fyysinen kerros keskittyy bittien ja tavujen siirtämiseen paikasta toiseen. Fyysinen kerros voi olla langaton tai tietoa voidaan välittää esimerkiksi valopolkua tai kierrettyä

33 parikaapelia pitkin. Fyysisen kerroksen abstraktoiminen erilleen mahdollistaa sen, että siirtotiestä riippumatta voidaan käyttää samoja ylemmän tason toiminnallisuuksia. Yleisimpiä fyysisen kerroksen toteutuksia ovat IEEE 802 verkot. IEEE 802 standardit (Ethernet IEEE sekä WLAN IEEE ) eivät ole aivan puhtaasti fyysisen kerroksen standardeja, vaan ne määrittelevät myös siirtoyhteyskerroksen jakaen sen usein kahteen alikerrokseen, joita kutsutaan nimillä LLC (Logical Link Control), sekä MAC (Medium Access Control). Laajalle levinneitä fyysisen kerroksen toteutuksia on myös esimerkiksi matkaviestinverkoissa käytetty LTE (Long Term Evolution), jonka päälle siirtoyhteyskerros toteutetaan yleensä PPP:n avulla (Point to Point Protocol). Parikaapelilla toteutetussa Ethernet verkossa fyysisen kerroksen yhdistävä laite on keskitin eli porttitoistin. Se monistaa yhden portin liikenteen kaikkiin muihin portteihin. Keskittimiä ei tavallisessa verkkoinfrastruktuurissa enää nykyään käytetä, vaan ne on korvattu siirtoyhteyskerroksessa toimivilla kytkimillä. Teknisesti erilaisia fyysisiä kerroksia voidaan yhdistää siirtoyhteyskerroksessa toimivien siltojen (bridge) avulla, jotka välittävät pakettien sisällön eri fyysisten segmenttien välillä. Siirtoyhteyskerroksen tehtävänä on tarjota palveluita verkkokerrokselle [19] siirtämällä kehyksiä, eli äärellisen mittaisia tavujonoja siirtoverkon laitteelta toiselle. Siirtoyhteyskerrokset voidaan luokitella joko yksityiseksi siirtotieksi tai jaetuksi siirtotieksi. Yksityinen siirtotie yhdistää suoraan viestinnän kaksi osapuolta, ja jaettu siirtotie yhdistää useita osapuolia samalla kertaa. Jaetulla siirtotiellä voidaan lähettää myös ns. broadcast viestejä, jotka on osoitettu kaikille siirtotien jakaville asiakkaille. Käytännössä siirtoyhteyskerroksen tehtävänä on siirtää sille annettu data siirtotien päästä toiseen. Tämän työn yhteydessä ei ole syytä käsitellä siirtoyhteyskerroksen standardeja sen tarkemmin, mutta kytkettyyn Ethernetiin perehdytään luvussa 3.3 niiltä osin kuin työn kannalta on tarpeen. Ethernet otsakkeeseen perehdytään tarkemmin virtuaalisista lähiverkoista kertovassa luvussa 3.4. Tässä työssä fyysiseen ja siirtoyhteyskerrokseen viitattaessa tarkoitetaan jatkossa ainoastaan Ethernet verkkoja (IEEE 802.3) ellei erikseen muuta mainita Verkkokerros Verkkokerroksen tehtävänä on välittää paketit koko matkan lähettäjältä vastaanottajalle [19]. Kerroksen tärkeimpiä tehtäviä onkin osoitteistus ja pakettien reititys osoitteiden välillä. Yhteyden verkkokerroksen ja siirtoyhteyskerroksen välille tarjoaa ARP protokolla (Address Resolution Protocol, RFC 826), joka etsii IP osoitetta (verkkokerros) vastaavan siirtoyhteyskerroksen osoitteen. Verkkokerroksen tärkeimmät protokollat ovat IP (Internet Protocol) sekä ICMP (Internet Control Message Protocol). Nimensä mukaisesti IP protokollaa käytetään Internetissä, ja siitä on tällä hetkellä käytössä kaksi versiota, versiot 4 ja 6 (IPv4

34 24 ja IPv6). Tämän työn varsinaisen sisällön kannalta IP versio ei ole olennainen. Kuitenkin, koska Aalto yliopiston verkko käyttää vielä toistaiseksi ainoastaan IPv4 protokollaa, käsitellään tästä eteenpäin IP protokollasta puhuttaessa sen versiota 4, joka on kuvattu RFC 791:ssa. ICMP protokollaa käytetään välittämään tietoa viestien välityksessä tapahtuneista virheistä. Se käyttää tukenaan IP protokollaa, kuten korkeamman tason protokollat, mutta on verkon toiminnan kannalta äärimmäisen tärkeä ja kaikkien IP toteutusten täytyy tukea sitä [20]. ICMP on kuvattu RFC 792:ssa. Verkkokerroksen osoiteavaruus on jaettu aliverkkoihin (yksi aliverkko vastaa yleensä myös yhtä siirtoyhteyskerroksen ositusta) ja liikennettä verkosta toiseen välittävät reitittimet Kuljetuskerros Kuljetuskerroksen tehtävänä on tarjota palveluita sovelluskerrokselle, jolloin jokaisen sovelluksen ei tarvitse erikseen toteuttaa esimerkiksi yhteyden muodostamista osapuolten välille. Yleisesti käytetyt kuljetuskerroksen protokollat ovat TCP (Transmission Control Protocol) ja UDP (User Datagram Protocol). TCP on yhteydellinen protokolla, joka muodostaa yhteyden kahden IP verkkoon liitetyn isäntäkoneen välille ja varmistaa pakettien perillemenon sekä säilyttää niiden järjestyksen kuittausten ja uudelleenlähetyksen avulla [21]. UDP toimii best effort periaatteella, jolloin pakettien perillemenoa tai järjestystä ei voida taata [22]. UDP:n etu TCP protokollaan nähden on sen keveys sekä joissain tapauksissa yhteydettömyys (broadcast viestit sekä useille vastaanottajille tarkoitetut multicast viestit). Ylemmän tason protokollat käyttävät näistä jompaakumpaa riippuen käyttötarkoituksesta ja vaatimuksista Sovelluskerros Kerrosten 1 4 voidaan katsoa tarjoavan kuljetuspalvelun ja sovelluskerros on sen käyttäjä [19]. Sovelluskerroksen protokollat keskittyvät tiedon esittämiseen ja tiedon kanssa toimimiseen ja käyttävät viestien välittämiseen alempia kerroksia. Sovelluskerros sisältää muutaman verkon päivittäisen toiminnan kannalta tärkeän tukiprotokollan, joihin monet muut sovelluskerroksen protokollat tukeutuvat. Näistä voidaan mainita esimerkkeinä DNS (Domain Name Service), joka yhdistää koneen ihmisille ymmärrettävän nimen ja koneen IP osoitteen, sekä tässä työssä pinnallisesti esiteltävä TLS, joka tarjoaa yhteyden salauksen. Käytännössä kaikki tässä työssä esiteltävät protokollat ovat sovelluskerroksen protokollia.

35 Verkon topologia Topologia tarkoittaa verkon muotoa ja tapaa, jolla se on järjestetty. Yleensä voidaan erottaa fyysinen topologia ja looginen topologia, jotka voivat olla yksittäiselle verkolle erilaisetkin. Nykyään voidaan katsoa käytettävän kolmea erilaista topologiatyyppiä, jotka ovat hierarkinen tähti, väylä ja rengas. [23] Tähti Rengas Kuva 21: Verkkotopologiatyypit Väylä Topologialuokat on esitetty kuvassa 21. Väylätopologiassa kaikki verkon solmut kytkeytyvät yhteiseen väylään. Väylätopologiaa käyttivät aikanaan mm. koaksiaalikaapelia käyttäneet Ethernet toteutukset (10BASE5 ja 10BASE2). Nämä ovat kuitenkin siirtonopeutensa puolesta vanhentuneita, eikä väylätopologia ole käytössä moderneissa Ethernet verkoissa. Rengastopologiassa jokainen verkon solmu on aina yhdistetty kahteen viereiseen solmuun ja jokainen solmu välittää liikennettä eteenpäin. Rengastopologia on keskeinen osa esimerkiksi Token Ring verkkojen toimintaperiaatetta (IEEE:n standardi 802.5). Token Ring verkoissa solmujen välillä kulkee eräänlainen viestikapula token ja ainoastaan solmu, jolla token on saa lähettää dataa. Kapula siirtyy renkaassa aina seuraavalle solmulle. Token Ring verkot ovat myös hyvä esimerkki verkosta, jonka looginen topologia eroaa fyysisestä topologiasta. Solmut kytketään fyysisesti toisiinsa tähtitopologiaan keskitetyn MAU:n (Media Access Unit) kautta, mutta ne on MAU:n sisällä kytketty loogiseksi renkaaksi. Tähtitopologiassa kaikki verkon solmut kytkeytyvät yhteen keskussolmuun, esimerkiksi keskuskytkimeen. Tähtitopologiasta esimerkkinä voi toimia esimerkiksi pientoimiston verkko, jossa kaikki tietokoneet on kytketty yhden kytkimen kautta toisiinsa. Hierarkinen tähtitopologia on tähden muotoinen verkko, jossa keskuskytkimen ja asiakassolmun välissä on toisia kytkimiä tai aktiivisia toistimia. Lähes kaikki nykyaikaiset paikallisverkot ovat ainakin fyysiseltä topologialtaan hierarkisia tähtiä [23]. Hierarkista tähteä nimitetään usein myös puutopologiaksi. 3.3 Ethernetin toiminta ja alueet Ethernet on yhteisnimitys IEEE:n standardin mukaisille verkoille. Ethernetin siirtoyhteyskerros koostuu kahdesta erillisestä kerroksesta, joiden nimet ovat LLC

36 26 (Logical Link Control), sekä MAC (Media Access Control). Näistä LLC kerros toteuttaa ylemmille kerroksille yhtenäisen rajapinnan, joka piilottaa alla olevan fyysisen toteutuksen. MAC kerros hoitaa osoitteistuksen sekä tiedon siirtämisen. Keskitin Kytkin Reititin Kuva 22: Yksinkertainen verkko broadcast ja törmäysalueineen Ethernet verkko on pienimmillään yksittäinen verkkosegmentti, jossa samaan jaettuun siirtotiehen kytkeytyy useita asiakkaita. Verkko voi jakautua ns. broadcast domaineihin (broadcast alue) sekä collision domaineihin (törmäysalue). Broadcast alue on sellainen siirtoyhteyskerroksen ositus, johon kaikille verkon solmuille tarkoitetut broadcast viestit levitetään. Samaan broadcast alueeseen liitetyt verkon solmut näkevät toisensa suoraan. Kehysten välittäminen broadcast alueelta toiselle vaatii ylempien kerrosten toiminnallisuutta, käytännössä reitittimen. Törmäysalue on yksittäinen siirtotie, jolla voi tapahtua törmäyksiä. Kuvassa 22 on esitetty yksinkertainen verkko, jossa on 5 asiakasta, jotka on kytketty toisiinsa yhdellä kytkimellä ja yhdellä keskittimellä. Broadcast alueet on merkitty katkoviivalla ja törmäysalueet harmaalla. Ethernet käytti alkujaan CSMA/CD (Carrier Sense, Multiple Access / Collision Detection) metodia tiedonsiirtoon yhteisellä siirtotiellä (Multiple Access, siirtotie jolla useat asiakkaat voivat lähettää). Tällöin lähettävä asiakas kuuntelee siirtotietä nähdäkseen lähettääkö jokin muu asiakas (Carrier Sense, sanatarkasti kantoaallon havaitseminen). Mikäli ei lähetä, yrittää asiakas lähettää oman kehyksensä. Mikäli huomataan, että joku toinen solmu aloitti lähetyksen päällekkäin samaan aikaan (Collision Detection, törmäysten havainnointi) eli tapahtui törmäys, lopetetaan lähettäminen välittömästi. Tällöin solmu odottaa satunnaisen ajan, jonka jälkeen yritetään uudelleenlähetystä. Satunnaisesta odotusajasta johtuen on epätodennäköistä, että samat 2 asiakasta yrittävät lähetystä yhtäaikaa useita kertoja peräkkäin. Kehys hylätään vasta, jos sen lähettäminen on epäonnistunut 16 kertaa. Suurempia verkkokokonaisuuksia kohti siirryttäessä on hyödyllistä paloitella törmäys ja broadcast alueita. Kytkinten käyttö keskitinten sijaan pienentää törmäysalueita, sillä kytkin ohjaa suurimman osan ajasta asiakkaalle ainoastaan sille kuuluvat viestit sekä broadcast viestit. Kuvassa 22 on väritetty harmaalla neljä törmäysaluetta, yksi

37 kytkimen kullakin puolella. Jokainen keskittimeen kytketty solmu saa kaiken keskittimen kautta kulkevan liikenteen, joten ne jakavat törmäysalueen. Broadcast alueet ovat aina kytketyn verkon laajuisia. Virtuaalisia lähiverkkoja käytettäessä voidaan käyttää yhteistä verkkoinfrastruktuuria, mutta jakaa se useisiin broadcast alueisiin. Eri broadcast alueet yhdistetään reitittimellä, joka välittää verkkoyhteyskerroksen liikennettä. Virtuaalisia lähiverkkoja käsitellään enemmän luvussa 3.4. Verkkoyhteyskerroksen reititystä ei tässä työssä käsitellä syvemmin Kytkinten toiminta ja MAC learning Kytkimet välittävät siirtoyhteyskerroksen liikennettä siten, että kukin asiakas saa vain itselleen kuuluvan liikenteen. Jotta tämä on mahdollista, täytyy kytkinten tietää, missä kukin asiakas verkossa sijaitsee. Asiakkaan yksilöi Ethernet verkossa MAC osoite, joka on 6 oktetin pituinen numerosarja, joka esitetään useimmiten heksadesimaalimuodossa xx:xx:xx:xx:xx:xx. MAC osoitteiden tulisi olla maailmanlaajuisesti uniikkeja, eli kahdella laitteella ei saisi olla samaa MAC osoitetta. Tämä mahdollistaa minkä hyvänsä laitteiden kytkemisen samaan verkkoon ilman ennakkokonfigurointia. Kolme ensimmäistä oktettia numerosarjasta yksilöi laitteen valmistajan ja loput laitteen. Kytkimet käyttävät tähän mekanismia nimeltään MAC Learning, joka on alunperin määritelty standardissa IEEE 802.1D, ja myöhemmin myös IEEE 802.1Q. Jokainen kytkin pitää yllä taulukkoa, johon se tallentaa MAC osoitteita ja tiedon portista, jossa kukin MAC osoite on havaittu. Vastaanottaessaan Ethernet kehyksen kytkin lukee kehyksestä lähettäjän ja vastaanottajan MAC osoitteet. Lähettäjän osoitetta verrataan taulukkoon, ja mikäli sitä ei taulukosta löydy, lisätään se sinne sen portin kera, josta kehys vastaanotettiin. Seuraavaksi verrataan vastaanottajan osoitetta taulukkoon. Mikäli osoite on jo yhdistetty johonkin porttiin, lähetetään kehys ainoastaan siihen porttiin. Mikäli osoite ei ole tunnettu, lähetetään kehys kaikkiin portteihin lukuunottamatta porttia, josta se vastaanotettiin. Kytkin oppii uusia osoitteita ainoastaan vastaanottaessaan kehyksiä [24]. Käytettäessä virtuaalisia lähiverkkoja (käsitellään tarkemmin luvussa 3.4) tallennetaan osoitteen yhteyteen myös VLAN tunniste [24]. Osoiterivit poistuvat taulukosta vanhentuessaan tai kun portin yhteys katkeaa. Oletusarvo vanhenemiselle on 300 sekuntia, mutta sallitut arvot ovat 10 1,000,000 sekuntia [24]. 3.4 Virtuaaliset lähiverkot Tietoverkko on mahdollista jakaa osiin eri tavoin. Toisaalta suurempi verkkokokonaisuus voidaan jakaa pienempiin loogisiin verkkoihin verkkokerroksessa, toisaalta taas suurempi fyysinen verkkokokonaisuus voidaan jakaa pienempiin fyysisiin kokonaisuuksiin siirtoyhteyskerroksessa. Usein nämä myös kytkeytyvät yhteen siten, että

38 28 yksi virtuaalinen lähiverkko, eli siirtoyhteyskerroksen ositus, vastaa yhtä loogista verkkokerroksen aliverkkoa. Verkon osittaminen on usein tärkeää organisaation rakenteen vuoksi, jolloin esimerkiksi yrityksissä eri organisaatioyksiköiden verkot voidaan eriyttää ja niitä voidaan hallita yksitellen. Toinen tekninen syy verkkojen osittamiselle on broadcast alueiden pitäminen pieninä, jolloin yksittäisen asiakaskoneen kannalta turhan verkkoliikenteen määrä pysyy pienempänä ja törmäysten määrä pysyy siten hallinnassa. Tällöin verkon läpi voidaan siirtää enemmän hyödyllistä dataa. Virtuaaliset lähiverkot eli VLAN:t on tapa eriyttää useita samaa kytkininfrastruktuuria käyttäviä verkkoja. Virtuaalinen lähiverkko toimii käyttäjän kannalta kuten mikä tahansa Ethernet verkko. Niitä käyttämällä voidaan samoja kytkimiä käyttäen luoda useita rinnakkaisia siirtoyhteyskerroksen verkkoja eli erillisiä broadcast alueita, ilman, että jokaista verkkoa varten tarvitaan erillinen laitteisto. Ethernet verkoille virtuaaliset lähiverkot on määritelty standardissa 802.1Q. Erityisesti kytkininfrastruktuurin kannalta olennaista on standardissa esitelty 4 tavun lisäys Ethernet kehykseen, jossa voidaan kertoa mihin VLAN:iin välitettävä paketti kuuluu. Laajennettu kehys on esitetty kuvassa 23. Preamble (7 oktettia) Start of frame delimiter (1 oktetti) MAC destination (6 oktettia) MAC source (6 oktettia) 802.1Q tag (4 oktettia) Length/Type (2 oktettia) Payload ( oktettia) Frame check sequence (4 oktettia) Kuva 23: Ethernet kehys ja paketti 802.1Q merkillä TPID PCP D E I VID Kuva 24: VLAN merkin rakenne VLAN merkin muoto on esitetty kuvassa 24. Se sisältää seuraavat kentät [24]: TPID (Tag Protocol Identifier): Normaalikehyksen EtherType:n kohdalle laajennetussa kehyksessä tuleva kenttä sisältää arvon 0x8100, joka on myös VLAN merkille

39 29 varattu EtherType. PCP (Priority Code Point): Prioriteetin määräävä 3 bitin kenttä. Prioriteetit on määritelty IEEE:n standardissa 802.1p. DEI (Drop Eligible Indicator): 1 bitin pituinen kenttä, joka kertoo voiko kehyksen jättää kokonaan huomiotta, mikäli verkko on ruuhkainen. VID (VLAN tunniste): 12 bitin pituinen kenttä, joka kertoo, mihin VLAN:iin kehys kuuluu. VLAN tunnisteella on kaksi erityistä arvoa, 0x000 ja 0xFFF. 0x000 kertoo, että paketti ei sisällä VLAN tietoa, vaan pelkän prioriteetin. 0xFFF on varattu toteutusten sisäiseen käyttöön. Kehykset siirretään yleensä kytkinten välillä merkittyinä, jolloin yhtä fyysistä kytkentää pitkin siirretään useiden verkkojen liikennettä. Kytkin poistaa merkit, kun kehykset lähetetään päätelaitteelle. Tällöin kytkinportti on kiinteästi asetettu johonkin VLAN:iin ja kaikki sieltä tuleva liikenne merkitään eteenpäin siirrettäessä tähän VLAN:iin ja muualta tuleva kytkinporttiin asetetun VLAN:in liikenne tarjotaan portista ilman merkkiä Multiple VLAN Registration Protocol MVRP (Multiple VLAN Registration Protocol) on IEEE:n standardissa 802.1Q 2011 (aiemmin 802.1ak) kuvattu protokolla, jonka avulla VLAN yhteensopivat kytkimet voivat välittää toisilleen VLAN konfiguraatiotietoa. Protokolla toimii suoraan siirtoyhteyskerroksen päällä [24]. MVRP käyttää samassa standardissa määriteltyä MRP protokollaa (Multiple Registration Protocol), ja on sen eräs sovellus. MRP protokollan tietoyksikön rakenne on esitetty kuvassa 25 Protocol Version (1 oktetti) Message 1 (5+ oktettia). Message n (5+ oktettia) End Mark (2 oktettia, 0x0000) 1 n viestikenttää Kuva 25: MRP protokollan tietoyksikkö Tietoyksikön kentät ovat protokollaversio (protocol version), viesti (message) sekä loppumerkki (end mark). Protokollaversio riippuu sovelluksesta. MVRP:n protokollaversio on 0 (0x00). Viestikenttä koostuu yhdestä tai useammasta attribuutista. Yksi MVRP viesti voi koostua yhdestä tai useammasta viestikentästä. Viestikentän rakenne on esitetty kuvassa 26. MVRP viestikenttä sisältää attribuutin tyypin (attribute type), attribuutin pituuden (attribute length) sekä itse attribuuttilistan. Attribuutin tyyppi saa MVRP-

40 Type Length List... Kuva 26: MVRP Message kentän rakenne protokollassa aina arvon 1. Attribuutin pituus sisältää attribuutin FirstValue kentän pituuden oktetteina. MVRP:n tapauksessa tämä on aina 2. Attribuuttilista sisältää itse attribuutit. [24] LAE No. of Values First Value Vector. LAE No. of Values First Value Vector End mark (0x0000) Vector Attribute rakenne, n. kpl attribuutteja Kuva 27: MRP Attribute List kentän rakenne Attribuuttilistan rakenne on esitetty kuvassa 27. Attribuuttilistan sisältämät kentät ovat LAE (Leave All Event), arvojen määrä (number of values), VLAN:n tunnus (first value) sekä maksimissaan kolmen 8 bitin arvon vektori (vector). Vektorin arvot ovat tyyppiä AttributeEvent. AttributeEvent arvot on listattu taulukossa 2. Taulukko 2: Attribuuttivektoreissa käytettävät AttributeEvent arvot Nro Tyyppi Selite 0 New Uusi tieto, jota ei välttämättä ole rekisteröity 1 JoinIn Julistettu, rekisteröity 2 In Ei julistettu, rekisteröity 3 JoinMt Julistettu, ei rekisteröity 4 Mt Ei julistettu, ei rekisteröity 5 Lv Aikaisemmin rekisteröity, nyt vedetty pois MRP määrittelee tiedolle kaksi tilaa: julistettu ja rekisteröity. Näitä varten laitteet toteuttavat kaksi eri tilakonetta jokaiselle attribuutille nimiltään Applicant ja Registrar. Nämä huolehtivat tietojen jakamisesta ja rekisteröinnistä laitteiden välillä. MRP:ssä verkkolaite tekee tai vetää takaisin attribuuttien julistuksia. Applicant tilakone tallentaa julistuksia ja huolehtii niiden julistamisesta eteenpäin muille verkon solmuille. Registrar tilakone nimensä mukaisesti rekisteröi muiden julistamia attribuutteja. Rekisteröinti poistetaan ainoastaan, mikäli kaikki muut protokollaan osallistuvat tahot vetävät rekisteröintiin johtaneen julistuksen pois. Rekisteröinti tarkoittaa esimerkiksi MVRP:n tapauksessa sitä, että VLAN levitetään porttiin, johon sitä on pyydetty.

41 Kukin attribuutti sisältää, kuten kuvasta 27 ilmenee, listan VLAN numeroita sekä lähettävän kytkimen tilatiedon niille. Kuvassa 2 listatut AttributeEvent arvot kertovat lähettävän kytkimen tilan ko. VLAN:lle. Protokolla määrittelee jokaiselle attribuutille kolme ajastinta. Nämä ovat liittymisajastin (Join timer), poistumisajastin (Leave timer) sekä LeaveAll ajastin. Protokollaan liittyvät tilakoneet käyttävät näitä ajastimia tilan vaihtamiseen. Viestin vastaanottava kytkin levittää tilatietoja eteenpäin kunnes ne ovat levinneet kaikille verkon kytkimille. Protokolla pyrkii varmistamaan sen, että jokaisella kytkimellä on kullakin hetkellä levitettynä ainoastaan sen tarvitsemat VLAN verkot. MRP tietojen leviäminen verkkoon julistuksina ja rekisteröinteinä on esitetty kuvassa 28. Kuvassa harmaalla merkittyyn kytkinporttiin asetetaan uusi VLAN, jolloin ko. kytkin julistaa uuden VLAN:n kaikkia runkoliitäntöjään pitkin. Muut verkon laitteet levittävät tilatiedot koko MVRP sovellusta käyttävään verkkoon ja kytkimet alkavat välittää halutun VLAN:n liikennettä sitä tarvitseville kytkimille. MVRP:n tapauksessa yleensä kaikki sovellukseen osallistuvat verkon laitteet ovat siltoja ja kytkimiä. MVRP liikennettä ei välitetä verkkoon kytketyille päätelaitteille eikä sitä oteta niiltä vastaan. 31 R J R R J J R J J J J Silta/kytkin J R LAN segmentti R J J J J R julistus rekisteröinti Kuva 28: MRP protokollan attribuuttien levittäminen Koska rekisteröinnit poistetaan ainoastaan, kun kaikki sovellusta käyttävät solmut ovat vetäneet sen takaisin, voidaan attribuutti nollata säännöllisin väliajoin LeaveAll viestillä. Tällöin kaikki laitteet joutuvat lähettämään ja muodostamaan ko. attribuutin tilatietonsa uudelleen. Täten tila pysyy jatkuvasti ajan tasalla. Näiden viestien lähettämistä kontrolloi LeaveAll ajastin. Koska protokolla toimii suoraan siirtoyhteyskerroksen päällä, on sillä oma EtherType arvonsa, joka on 88 F5. MAC kohdeosoite on aina 01:80:C2:00:00:21, joka on MVRP protokollalle varattu broadcast osoite.

42 32 Mikäli kytkinportti käyttää MVRP:tä, pitää kytkin yllä dynaamista VLAN konfiguraatiota. Portilla voi olla sen lisäksi myös staattisesti asetettu konfiguraatio Q standardi mahdollistaa MVRP:n avulla levitettävien verkkojen rajoittamisen asettamalla kytkin tilaan, jossa se hyväksyy ainoastaan sellaisten VLAN tunnusten MVRP Join viestit, joiden VLAN tunnus on myös portin staattisessa konfiguraatiossa. 3.5 Aalto yliopiston langallinen tietoverkko Aalto yliopiston langallinen tietoverkko on hierarkinen tähti, jossa keskuskytkimiin on kytketty paikallisia kytkimiä. Kytkinverkon rakenne on esitetty kuvassa 29. Keskimmäisenä kuvassa ovat keskuskytkimet. Keskuskytkimet on kytketty eri rakennusten ja etäkohteiden talokytkimiin jotka ovat seuraavana keskuskytkimistä ulospäin. Ne on on edelleen kytketty latvakytkimiin, joihin asiakaslaitteet kytketään. Talokytkimiä on kymmeniä, latvakytkimiä satoja, ja latvakytkimissä on kymmeniä kytkinportteja. Kokonaisuudessaan verkkoon liittyy tuhansia asiakaslaitteita. Talokytkin Reititin, Internet Talokytkin Latvakytkin Latvakytkin Latvakytkin Keskuskytkin Latvakytkin Talokytkin Talokytkin Latvakytkin Keskuskytkin Latvakytkin Latvakytkin Talokytkin Talokytkin Latvakytkin Latvakytkin Kuva 29: Aalto yliopiston tietoliikenneverkon topologia Kaapelointi on useimmissa rakennuksissa toteutettu kierretyllä parikaapeloinnilla. Yhteydet keskuskytkimiltä talokytkimiin on toteutettu valopoluilla Q merkityt VLAN:t levitetään keskuskytkimiltä latvaan käsin tarpeen mukaan, eikä prosessia ole automatisoitu. VLAN merkit poistetaan latvakytkimillä ja asiakaskoneiden portit on kytketty kerrallaan vain yhteen VLAN:iin ilman 802.1Q merkkiä. MVRP ei ole käytössä.

43 Keskuskytkimet on kytketty yhdyskäytäväreitittimeen, joka hoitaa verkkokerroksen reitityksen Ethernet verkkojen heikkoudet Tässä kappaleessa on esitelty muutamia lähiverkkoinfrastruktuurien heikkouksia sekä miten niitä vastaan voidaan hyökätä ARP Spoofing Address Resolution Protocol on protokolla, joka etsii verkkokerroksen osoitetta vastaavan siirtoyhteyskerroksen osoitteen. ARP on tärkeä osa kaikkien IEEE 802 verkkojen toimintaa. Protokollalla on kuitenkin perustavanlaatuinen ominaisuus: se ei sisällä minkäänlaista todennusta tai mekanismia, jolla viestin aitous voitaisiin varmistaa. Tästä syystä hyökkääjä, joka voi liittyä verkkoon, voi häiritä verkon toimintaa lähettämällä väärennettyjä ARP viestejä, jotka vaikuttavat muiden verkon laitteiden toimintaan. [25] Verkkolaitteet tallentavat niiden havaitsemien ARP kyselyiden vastaukset ARP tauluun ja käyttävät tallennettua tietoa hyväkseen [26]. Tämän ansiosta ARP protokollan heikkouksien avulla hyökkääjä voi esimerkiksi varastaa toisen asiakkaan tai jopa koko verkon verkkoliikenteen itselleen tai pyrkiä sekoittamaan verkon toimintaa muulla tavoin. ARP hyökkäyksiä kutsutaan yleensä nimellä ARP spoofing tai ARP poisoning DHCP-hyökkäykset DHCP (Dynamic Host Configuration Protocol) on sovelluskerroksen protokolla, jonka avulla voidaan jakaa konfiguraatiotietoa verkkoasiakkaille. Yleensä protokollaa käytetään verkoissa uuden asiakkaan IP osoitteen ja tarvittavien verkkoasetusten automaattiseen määrittämiseen. Lisäksi protokollan avulla voidaan esimerkiksi tarjota vaihtoehtoinen käynnistyslevykuva asiakastyöasemille. Protokolla on määritelty RFC 2131:ssa. DHCP sisältää vastaavanlaisen heikkouden kuin ARP protokollakin: se ei sisällä sellaisenaan MAC osoitetta lukuunottamatta mitään tapaa tunnistaa pyynnön tai vastauksen lähettäjää. Hyökkääjä voi kytkeä verkkoon oman DHCP palvelimensa ja jakaa sitä kautta koneille väärää tietoa. Tämä väärä tieto voi olla esimerkiksi väärä yhdyskäytävä tai osoite, jolloin hyökkääjä voi joko reitittää kohteen liikennettä haluamallaan tavalla tai lähettää omat DNS palvelinasetukset (Domain Name Service), jota kautta voidaan syöttää kohteelle lisää väärää tietoa [25, 27]. Toinen mahdollinen DHCP hyökkäys voidaan suorittaa verkon olemassaolevaa DHCP infrastruktuuria vastaan. Lähettämällä useita (virheellisiä) DHCP pyyntöjä voidaan saada koko verkolle annettu IP osoiteavaruus varattua, jolloin uusi asiakas ei välttä-

44 34 mättä enää saa DHCP:n kautta osoitetta, kunnes jokin jo myönnetyistä osoitteista vapautuu [27]. Tätä hyökkäystä voidaan pyrkiä lieventämään asettamalla tunnetuille asiakkaille kiinteä DHCP varaus sekä rajoittamalla kytkinporteissa yhden portin sallimien MAC osoitteiden määrää Man in the Middle Man in the Middle on yleisnimitys erilaisille tekniikoille, joissa hyökkääjä asettaa itsensä kohteen liikenteen väliin, toimien eräänlaisena välimiehenä. Kun kohteen liikenne kulkee hyökkääjän kautta, voidaan liikennettä tallentaa tai muuttaa. Esimerkiksi edellämainittujen ARP ja DHCP hyökkäysten avulla on mahdollista kaapata kohteen verkkokerroksen liikenne ja muokata sitä haluamallaan tavalla. [25] On myös mahdollista asentaa kohteen ja kytkimen väliin jokin aktiivilaite, joka tarkkailee ja/tai muokkaa kohteen verkkoliikennettä.

45 X porttitodennus Tässä luvussa esitellään 802.1X porttitodennusstandardi ja siihen liittyviä käsitteitä X on IEEE:n standardi, joka määrittelee porttitason todennuksen langallisissa ja langattomissa lähiverkoissa. Standardin uusin versio on vuodelta Tarkemmin standardi määrittelee EAP todennusprotokollan käytön suoraan lähiverkon verkkokerroksen päällä (EAPOL, EAP over LAN), sekä todennusprosessin asiakkaan ja verkon välillä. [28] 4.1 Todentaminen Asiakas Todentaja Todennuspalvelin EAP-Response Identity (EAPOL-Start) EAP EAP EAP-Request Identity RADIUS Access-Request RADIUS EAP EAP-Request RADIUS RADIUS Access- Challenge EAP-Response EAP RADIUS Access-Request RADIUS EAP EAP-Success RADIUS RADIUS Access-Accept Kuva 30: Asiakkaan todentaminen 802.1X määrittelee kolme osapuolta, jotka osallistuvat asiakkaan todentamiseen. Nämä ovat asiakas (Supplicant, EAP määrittelyssä peer), todentaja (Authenticator) sekä todennuspalvelin (Authentication Server).

46 36 Asiakas on yleensä verkkoon liitettävä päätelaite, joka pyrkii todentamaan itsensä verkkolaitteelle. Asiakkaalla voidaan myös käsittää päätelaitteessa ajettava ohjelmisto, joka hoitaa varsinaisen todentamisen. Todentaja on verkkolaite esimerkiksi kytkin tai WLAN tukiasema joka todentaa muut verkkoon kytkettävät laitteet (asiakkaat). Todentaja välittää EAP liikenteen asiakkaalta todennuspalvelimelle ja todennuksen onnistuessa kytkee asiakkaan todennuspalvelimen valtuuttamaan verkkoon. Todennuspalvelin määrittää asiakkaan antamien todennustietojen perusteella, onko asiakkaalla valtuutus todentajan tarjoamaan palveluun, ja välittää tämän tiedon todentajalle. Todentaminen itsessään noudattaa ylemmällä tasolla EAP protokollaa, mutta todentaja välittää pyynnöt todennuspalvelimelle, joka on yleensä RADIUS palvelin. Todennuksen kulku on esitetty kuvassa EAPOL EAPOL on tapa käyttää EAP protokollaa suoraan siirtoyhteyskerroksen päällä. EAPOL tietoyksikön rakenne on esitetty kuvassa 31. MAC destination (6 oktettia) MAC source (6 oktettia) Type (2 oktettia) Version (1 oktetti) Packet Type (1 oktetti) Packet Body Length (2 oktettia) Packet Body Frame Check Sequence (4 oktettia) Kuva 31: EAPOL protokollan tietoyksikkö Tietoyksikkö sisältämät kentät ovat MAC otsake, Ethernet tyyppi, versio, pakettityyppi, paketin pituus sekä paketin sisältö [28]. MAC otsake sisältää vastaanottajan ja lähettäjän MAC osoitteet. Ethernet-tyyppi (Ethernet Type) sisältää oktetit 88 8e, joka on EAPOL protokollalle määrätty koodi. Versiokenttä sisältää EAPOL versionumeron X 2010 standardin mukainen versionumero on 0x03. Paketti-

47 tyyppi on EAPOL paketin tyyppi. Paketin pituus sisältää paketin sisällön pituuden okteteissa. Mikäli koko on 0, paketilla ei ole sisältöä. Paketin sisältö sisältää paketin varsinaisen sisällön. Sallitut EAPOL pakettityypit on esitetty taulukossa Taulukko 3: EAPOL pakettityypit Nro Tyyppi 1 EAPOL EAP 2 EAPOL Start 3 EAPOL Logoff 4 EAPOL Key 5 EAPOL Encapsulated ASF Alert 6 EAPOL MKA 7 EAPOL Announcement (Yleinen) 8 EAPOL Announcement (Erityinen) 9 EAPOL Announcement Req EAPOL Start viesti aloittaa EAPOL viestinvaihdon asiakkaan ja todentajan välillä. EAPOL Logoff viestillä asiakas ilmoittaa poistumisestaan ja portti siirretään takaisin valvomattomaan tilaan. EAPOL EAP viestit sisältävät yhden EAP protokollan mukaisen paketin. Asiakas lähettää EAPOL viestit varattuun ryhmäosoitteeseen 01:80:C2:00:00:00, jota todentaja kuuntelee. Muut EAPOL pakettityypit eivät ole työn kannalta oleellisia, joten ne sivuutetaan. 4.3 Porttien tila Kukin kytkinportti, jossa käytetään porttitodennusta, on perustilassa valvomattomassa tilassa (Uncontrolled Port). Tällöin portti tukee ainoastaan EAPOL liikennettä (sekä muutamia muita protokollia, mm. Wake on LAN). Kuvassa 32 on esitetty valvomattoman ja valvotun portin toiminta. Kun porttiin kytketään asiakaslaite, odotetaan asiakkaalta EAPOL Start viestiä ja sitä kautta tunnistautumista. Mikäli tunnistautuminen onnistuu, siirtyy portti valvottuun tilaan (Controlled Port). Tällöin laite on kytkettynä todennettuun sisäverkkoon ja se voi liikennöidä normaalisti. Mikäli kytkimeen kytkettävä laite ei koskaan aloita todennusprosessia EAPOL Start viestillä, voidaan asiakas yhdistää toteutuksesta riippuen aikakatkaisun jälkeen esimerkiksi erikseen asetettuun vierasverkkoon tai jättää portti valvomattomaan tilaan. Toteutuksesta riippuu myös, mitä tapahtuu todennuksen epäonnistuessa. Jaetulla siirtotiellä (langattomat verkot) joudutaan lisäksi vaihtamaan salausavaimia, mutta langallisessa tapauksessa tämä riittää, koska siirtotien voidaan katsoa olevan turvallinen.

48 38 Asiakas EAPOL Valvomaton portti RADIUS Todennuspalvelin Todennus Valvottu portti LAN Kuva 32: Valvottu ja valvomaton tila Käytettäessä MVRP protokollaa 802.1X todennuksen kanssa, toimii protokolla vasta valvotussa portissa [24]. 4.4 RADIUS 802.1X:ssä RADIUS palvelimen avulla voidaan määrittää VLAN, johon todennettu asiakas (tai oikeammin kytkinportti) kytketään. RADIUS attribuutit tätä varten määritellään RFC 2868:ssa. VLAN:n asettamat attribuutit ovat nimeltään Tunnel Type, Tunnel Medium type sekä Tunnel Private Group ID [29]. Tunnel Type attribuutilla on 13 määriteltyä arvoa [17]. VLAN:n määräämiseen käytetään arvoa 13 (VLAN). Tunnel Medium Type attribuutille on 15 rekisteröityä arvoa, VLAN:n määräämiseen käytetään arvoa 6 (802). Tunnel Private Group ID sisältää VLAN:n numeron merkkijonona esitettynä. Nämä attribuutit välitetään tavallisesti Access Accept paketissa, mutta todentaja voi halutessaan vihjata sopivista VLAN:eista sisällyttämällä nämä kentät Access Request pakettiin. 4.5 Tunnetut heikkoudet 802.1X todennuksessa on muutamia tunnettuja heikkouksia, jotka on esitelty tässä. Heikkoudet mahdollistavat asiakkaan verkkoliikenteen häiritsemisen tai olemassaolevan asiakkaan todennetun verkkoyhteyden käyttämisen, mutta eivät valvomattomassa tilassa olevan kytkinportin käyttämistä ilman todennusta EAPOL Logoff EAPOL Logoff paketit eivät sisällä mitään todennukseen käytettävää tietoa [28]. Mikäli hyökkääjällä on pääsy jaettuun siirtotiehen, voi hän lähettää EAPOL Logoff viestejä tunnetun asiakkaan (väärennetyllä) MAC osoitteella, ja täten pudottaa asiakkaan verkosta.

49 Heikkoutta on pyritty lieventämään MACsec laajennuksella uusimmassa standardiversiossa 802.1X 2010, mutta laajennus ei ole laajasti käytössä. MACsec salaa siirtoyhteyskerroksen liikenteen sekä muuttaa EAPOL Logoff pakettien toiminnallisuutta. Käytännössä heikkoutta vastaan riittää kohtuullinen fyysinen turvallisuus, jolloin hyökkääjän on vaikea päästä siirtotielle Man in the Middle Mikäli hyökkääjällä on pääsy siirtotielle, eli langallisen verkon tapauksessa pääsy asiakkaan ja todentajan väliin, voi hän asentaa väliin hubin eli keskittimen ja kytkeä oman tietokoneensa siihen. Asettamalla oman MAC ja IP osoitteensa samoiksi, kuin porttiin kytketyllä työasemalla, voi hän lähettää ja vastaanottaa ICMP ja UDP liikennettä. [30] Kehittyneempi versio samasta hyökkäyksestä mahdollistaa myös TCP yhteydet. Tällöin verkkoasiakkaan ja kytkimen väliin asetetaan aktiivilaite, joka kuuntelee ja muokkaa liikennettä asiakkaan ja kytkimen välillä ja pitää käynnissä olevista TCP yhteyksistä tilatietoa. Täten se voi välittää edelleen asiakkaalle sille kuuluvan liikenteen ja lähettää ja vastaanottaa omaa liikennettään esiintyen asiakkaana. [31] Myös tätä heikkoutta on pyritty korjaamaan MACsec laajennuksella.

50 40 5 Toteutus Tässä luvussa esitellään työssä suunniteltu käytännön toteutus. Luku on jaoteltu todennukseen liittyviin osiin, kytkinten konfigurointiin, työasemien konfigurointiin sekä virtuaalisten lähiverkkojen levittämiseen. Lopuksi kerrotaan havaituista ongelmista sekä tunnetuista vioista. 5.1 Suunnittelu ja reunaehdot Aalto yliopiston tietotekniikkapalveluiden näkökulmasta ohjaus liikkuvuuden mahdollistamiseen eri tavoin tulee suoraan Aalto yliopiston strategiasta. Strategiassa todetaan kampuksen kehittämisestä mm. seuraavaa: Edistetään uusia työskentelytapoja, monenlaisille käyttäjille soveltuvia tilaratkaisuja, liikkuvuutta, joustavuutta, yhdessä tekemistä ja hyvinvointia. [32] Koska kaikkia käyttötapauksia ei voida toteuttaa langattomalla verkolla, täytyy nämä reunaehdot pystyä toteuttamaan myös langallisessa verkossa. Erityisesti nykyiset langallisen verkon rajoitukset tulevat esiin eri rakennusten neuvotteluhuoneissa, joissa samassa palaverissa saattavat langallista verkkoa tarvita useiden eri yksiköiden työntekijät. Tämä strateginen ohjaus antaa suunnittelulle päämäärän: käyttäjien liikkuvuus kampuksen sisällä täytyy saada mahdollisimman vaivattomaksi. Kuitenkin esimerkiksi luvussa 3.6 esiteltyjen heikkouksien vuoksi myös tietoturvanäkökulma on syytä ottaa huomioon, koska verkkopääsy täytyy mahdollistaa myös paikoissa, joissa fyysistä turvallisuutta ei välttämättä voida taata, eikä verkkoon kytkeytyviä laitteita ja/tai käyttäjiä välttämättä tunneta etukäteen. Tähän onkin annettu ohjaus Aalto yliopiston työasemapolitiikassa, jossa todetaan: Kaikki julkisissa tiloissa (mm. aulat, luokat, kokoustilat, salit) sijaitsevat verkkopisteet suojataan siten, että kytkettävä työasema tunnistetaan ja sijoitetaan automaattisesti oikeaan verkkosegmenttiin. Tunnistamattomat työasemat voidaan liittää vain Aalto yliopiston avoimeen verkkoon. [33] Hyviä ohjeita ja reunaehtoja suunnittelulle tarjoavat Valtionvarainministeriön ylläpitämät VAHTI ohjeet, jotka sisältävät yksityiskohtaisiakin ohjeita valtionhallinnon ja siihen rinnastettavien tahojen tietoturvaan ja käytäntöihin. VAHTI ohjeissa käytetään kolmea eri tasoa kuvaamaan niiden asettamien vaatimusten vahvuutta. Ne ovat: [34] Pakollinen vaatimus: Organisaatiolle pakollinen vaatimus, josta voi poiketa vain, jos kirjallisen riskianalyysin perusteella riski on pieni ja toiminnallisuuden toteuttaminen vaatii runsaasti resursseja ja toteutettava poikkeus hyväksytään etukäteen. Vahva suositus: Vaatimus, josta voidaan poiketa kirjallisen riskianalyysin perusteella.

51 Suositus: Hyvä käytäntö, joka voidaan haluttaessa ottaa käyttöön. Koska Aalto yliopisto on itsenäinen säätiö, eivät VAHTI ohjeet ole suoraan sitovia, mutta ne ovat erinomainen lähtökohta palveluiden toteuttamiselle. Suunnittelua rajoittavat myös Aalto yliopiston IT politiikat sekä erilaiset tietotekniikkapalveluiden sisäiset linjaukset Verkot Liikkuvuuden mahdollistamiseksi täytyy käyttäjän päästä käsiksi oman yksikkönsä tai tutkimusryhmänsä sisäverkkoon, jotta tällä on pääsy kaikkiin tarvitsemiinsa palveluihin. Jotta tämä olisi mahdollista, täytyisi jotenkin pystyä tunnistamaan käyttäjä tai käyttäjän päätelaite, ja pystyä tarjoamaan pääsy oikeaan verkkoon. Koska käyttäjien liikkuvuus tulee uusien työtilaratkaisujen myötä Aallossa lisääntymään [32], ei tulevaisuudessa enää riitä verkon levittäminen pyynnöstä manuaalisesti käyttäjän kulloisellekin työpisteelle. Mekaanisen työn sijaan rajalliset henkilöresurssit tulisi pystyä keskittämään kehitystehtäviin ja automaation astetta nostaa. Käsin tehtäessä myös virheiden mahdollisuus kasvaa. Verkot voitaisiin levittää valmiiksi kaikkiin kytkimiin, mutta edelleen jouduttaisiin tekemään käsityötä kytkinporttien suhteen. Aalto yliopiston työasemaverkot on jo nyt rajattu siten, että niihin saa kytkeä vain Tietotekniikkapalveluiden ylläpitämiä työasemia. Tuntemattomien laitteiden kytkemistä verkkoon ei kuitenkaan ole tähän asti teknisesti estetty. Koska verkkorajaus antaa kuitenkin siihen mahdollisuuden, VAHTI ohjeet suosituksen ja Aallon työasemapolitiikka osittaisen vaatimuksen julkisten tilojen osalta [33], voidaan tietoturvanäkökulman toteuttamiseksi käyttää 802.1X porttitodennusta X:n etuna on sen laaja käyttö ja huolellinen määrittely. Se on myös teknologiana riittävän iäkäs ja laajalle levinnyt, joiden ansiosta voidaan olla varmoja sen toimivuudesta ja soveltuvuudesta tarkoitukseen. Kytkinporttien todennus ja portin kytkeminen todennuksen yhteydessä käyttäjätunnukselle tai koneelle määriteltyyn VLAN:iin ratkaisee samalla myös viimeisen vaiheen automatisoinnin ongelman. Kytkinportteja ei tarvitse konfiguroida käsin päätelaitteen tai käyttäjän vaihtuessa. Taulukkoon 4 on kerätty VAHTI sisäverkko ohjeesta joitakin suunnittelun kannalta olennaisia vaatimuksia VLAN:ien levittäminen Kuten luvussa 3.5 on kerrottu, tietotekniikkapalveluiden langallinen verkko koostuu useiden eri valmistajien kytkimistä. Kuitenkin kaikkien latvakytkinmallien pitäisi toteuttaa sekä 802.1X että 802.1Q 2011 riittäviltä osin, jotta teknistä estettä porttitodennuksen tai MVRP:n käyttämiselle ei ole.

52 42 Taulukko 4: Valikoituja VAHTI sisäverkko ohjeen vaatimuksia [34] Viite Vaatimus Perustason vaatimus 5.9 Verkkoliitännät yleisölle avoimissa tiloissa on pakollinen vaatimus suojattu siten, että organisaation sisäverkkoon on pääsy ainoastaan sallituilla osapuolilla. 7.1 Sisäverkon suojaaminen perustuu riskianalyysiin vahva suositus 9.5 Käyttämättömät liitäntäpisteet on irrotettu suositus aktiivilaitteesta tai ao. laitteen portit estävät oletuksena uusien asemien vapaan liittämisen sisäverkkoon Sisäverkkoon liitetyt aktiivilaitteet tunnistetaan suositus vahvasti esim X menettelyllä, jolla estetään tuntemattomien laitteiden liittäminen Tunnistautumisen lajeista on valittu sopivat vahva suositus menetelmät ja valinta perustuu analyysiin tunnistautumistarpeesta Käytössä olevista varmenteista on ajantasainen vahva suositus lista Pelkän päätelaitetunnistautumisen perusteella suositus annetaan verkkoon vain hyvin rajattu pää- sy Tunnistautumisessa käytetään menetelmiä, joissa tunnistautumiseen käytettävät tiedot, kuten käyttäjätunnukset ja salasanat eivät kulje verkon yli salaamattomana pakollinen vaatimus Työasemat Aalto yliopiston tietotekniikkapalveluiden hallinnassa on n työasemaa kolmella eri käyttöjärjestelmällä. Näistä n on Windows työasemia, n. 750 Mac työasemia, sekä n. 750 Linux työasemia. Työasemista yli puolet on kannettavia tietokoneita. Tässä työssä suunniteltavaa verkkoratkaisua on pystyttävä käyttämään kaikilla näistä alustoista. Työasemat on kytketty tietotekniikkapalveluiden Windows domainiin, ja ne todentavat käyttäjät Active Directorya vasten. Jokaisella työasemalla on myös tietotekniikkapalveluiden omalla juurivarmenteella allekirjoitettu varmenne sekä Active Directoryn konetili, joka on erillinen omalla salasanalla varustettu käyttäjätunnus. Lisäksi käyttöjärjestelmäkohtaisesti työasemilla voi olla muitakin alustakohtaisia identiteettejä, usein varmenteita. Windows ja Mac ympäristöissä käytetään käyttöjärjestelmän sisäänrakennettuja

53 ominaisuuksia verkkoasetusten hallintaan. Tuetussa konfiguraatiossa Linux työasemien verkkoasetuksia hallitaan NetworkManagerin avulla. Kirjoitushetkellä käytössä olevat käyttöjärjestelmien versiot ovat Windows 7, Mac OS X 10.10, Mac OS X sekä Ubuntu Linux Active Directory tarjoaa Kerberos todennuksen sekä LDAP hakemistopalvelun (Lightweight Directory Access Protocol). Kerberos on todennusprotokolla joka on määritelty RFC 4120:ssa. LDAP on hakemistojärjestelmä, joka on määritelty RFC dokumenteissa (osia myös muissa dokumenteissa). Niitä käytetään työasemissa käyttäjän todentamiseen sekä käyttäjätietojen välittämiseen. Niitä ei kuitenkaan käsitellä tässä työssä syvemmin Työasemien identiteetit, PKI ja RADIUS Todennuksessa verkkoon on tarpeen pohtia, millä käyttäjätunnuksella verkkoon kirjaudutaan. Koska verkkoon kirjautumiseen on tarpeen sitoa myös VLAN tieto, ja Aallon työasemaverkkojen yksi edellytys on, että niihin kytketään ainoastaan Aalto yliopiston tietotekniikkapalveluiden domainiin kytkettyjä työasemia, on syytä käyttää jotain käytettävään laitteeseen yksilöitävää tietoa käyttäjän tunnistuksen sijaan. Tällöin voidaan laitekohtaisesti päättää, mihin verkkoon laite kuuluu. VLAN tieto on jo tallennettuna Active Directoryyn langattoman verkon käyttöä varten. Tällaisia laitekohtaisia identiteettejä on työasemissa kaikilla käytössä olevilla käyttöjärjestelmäalustoilla Active Directoryn konetili ja sen salasana sekä konekohtainen varmenne, joka on allekirjoitettu Aallon omalla CA varmenteella. Lisäksi eri alustoilla saattaa olla alustakohtaisia identiteettejä, esimerkiksi varmenteita eri ylläpitojärjestelmiin. Käytännössä joudutaan kuitenkin käyttämään joko salasanalla varustettua konetiliä tai lopputahovarmennetta. Tietotekniikkapalveluilla on ennestään olemassa RADIUS palvelin, jota käytetään mm. langattoman verkon sekä kansainvälisen Eduroam verkon 802.1X todennuksessa. Eduroam verkko on kansainvälinen tutkimusverkko, jota voidaan käyttää siihen kuuluvien organisaatioiden tunnuksilla. Eduroam verkossa paikallinen verkko operaattori ketjuttaa RADIUS liikenteen asiakkaan oman kotiorganisaation RADIUS palvelimelle. Tässä yhteydessä todennukseen liittyvä liikenne saattaa kulkea useiden tahojen kautta, joita ei voida katsoa luotettaviksi. Tämän vuoksi Eduroam määrittelee käytettäväksi joko käyttäjätunnuksen ja salasanan EAP TTLS:n tai PEAP protokollan yli tai molemminpuolisen tunnistautumisen X.509 varmenteilla (EAP TLS) [35]. Koska langallisenkin verkon 802.1X todennusta varten voidaan käyttää samaa RADIUS palvelinta, ei ole mitään syytä käyttää heikompia tunnistustapoja kuin jo käytössä olevat. Käyttämällä PEAP:ia tai EAP TLS:ää voidaan työasema todentaa käyttäen joko konetiliä ja salasanaa tai varmenteita. Voidaan siis valita käyttöön ko. todennustavat. Todennukseen on toki mahdollista käyttää tavallista käyttäjätunnusta tai suoraan käyttäjälle myönnettyä varmennetta, mutta tällöin työasemaa ei voida tunnistaa, ja asiakastyöasema liitetään vierailijaverkkoon. EAP TTLS on suunniteltu kiertämään langattoman siirtotien rajoitteita [36], joten sitä ei välttä-

54 44 mättä tarvitse langallisessa verkossa käyttää. Myös verkkolaitevalmistaja Ciscon mukaan EAP TLS ja PEAP ovat yleisiä EAP metodeita 802.1X verkoissa, ja Cisco suositteleekin niiden käyttöä [37]. RADIUS palvelin todentaa käyttäjän Active Directoryn LDAP palvelun kautta. Lisäksi palvelimen välittämä VLAN tieto kullekin koneobjektille luetaan LDAP:sta. Taulukon 4 vaatimuksista tämän osa alueen osalta mielenkiintoisimpia ovat vaatimukset sekä Vaatimus saadaan täytettyä sillä, että verkkoon voidaan lähtökohtaisesti kytkeä ainoastaan keskitetysti hallittuja työasemia, jolloin verkon käyttäminen työaseman avulla edellyttää käyttäjän tunnistamista työasemassa. Vaatimukset 15.1 ja täyttyvät valitsemalla EAP TLS sekä PEAP tunnistautumismetodeiksi. 5.3 Verkkojen levittäminen Käytännössä verkkoliikenteen hallinnan kannalta ihanteellisinta olisi, mikäli kuhunkin kytkimeen voitaisiin levittää vain siinä kulloisellakin hetkellä tarvittavat verkot, jolloin runkoverkossa ei kulkisi turhaa liikennettä. Tämän toteuttamiseen on erilaisia tapoja. Verkon tulee toimia aina, sillä laskennallisestikin jokainen verkkokatko tulee Aalto yliopistolle erittäin kalliiksi henkilökunnan menetetyn työajan muodossa. Tämän johdosta työasemaverkot täytyy todellisessa maailmassa olla joko jatkuvasti levitettynä kaikkialle, missä niitä pitää pystyä käyttämään tai ne täytyy pystyä levittämään nopeasti ja toimivasti, ihanteellisessa tilanteessa automaattisesti. Aluksi verkkoja voidaan levittää tarpeeseen käsin, jolloin saavutetaan ennen pitkää tilanne, jossa verkossa on jatkuvasti vähimmäismäärä verkkoja levitettynä ja käsityön määrä vähenee koko ajan. Tällä tavalla saadaan rajoitettua turhaa liikennettä runkoverkossa. Tehokkainta on kuitenkin ottaa käyttöön MVRP protokolla, sillä sen avulla prosessi voidaan automatisoida. Koska verkossa on käytännössä kolmentasoisia kytkimiä, voidaan protokolla kytkeä päälle joko talokytkinten ja latvakytkinten välillä, tai myös keskuskytkimissä. Koska talokytkinverkko on kohtalaisen muuttumaton, riittää automatisoinnin tasoksi se, että MVRP kytketään käyttöön talokytkimien ja latvakytkimien välillä. Tällöin talokytkimille levitetään käsityönä ne työasemaverkot, joita kytkimen alueella katsotaan tarvittavan. Latvakytkimiin konfiguroidaan kiinteästi ainoastaan vierailijaverkko ja loput VLAN asetukset saadaan MVRP:n avulla. Ihannetapauksissa kaikkiin latvakytkimiin voidaan asettaa identtinen peruskonfiguraatio ja muokata tarvittaessa ainoastaan yksittäisten verkkoliitäntöjen asetuksia. 5.4 Kytkinkonfiguraatiot Aalto yliopistossa on käytössä useiden eri kytkinvalmistajien eri kytkinmalleja, joille täytyy etsiä toimivat 802.1X sekä MVRP verkkokonfiguraatiot mallikohtaisesti. Käyttämällä 802.1X porttitodennusta useimmissa porteissa erityisesti julkisissa tiloissa sijaitseviin verkkorasioihin kytketyissä porteissa saadaan täytettyä taulu-

55 kon 4 vaatimukset 5.9, 9.5 sekä 11.4 sekä työasemapolitiikasta seuraava työaseman tunnistamisen vaatimus. Lisäksi työasemapolitiikan vaatimuksen tunnistamattomien asiakaslaitteiden sijoittamisesta avoimeen verkkoon täyttämiseksi on kytkimille määriteltävä vieras VLAN, johon todentamattomat työasemat kytketään Junos Kytkinvalmistaja Juniperin kytkimissä käytetään FreeBSD pohjaista Junos käyttöjärjestelmää. Järjestelmän konfiguraatio sijaitsee sisäkkäisessä tietorakenteessa, jota voidaan muokata komentoriviltä. Toimivaksi havaittu Junos konfiguraatio on esitetty olennaisilta osiltaan listauksessa A.1. Kytkimelle asetetaan RADIUS palvelin ja jaettu salaisuus. Sen jälkeen luodaan todennusprofiili, joka asetetaan käyttämään pelkästään RADIUS:ta ja profiilin RADIUS palvelimena käytetään aikaisemmin tehtyä palvelinta. Asetusrakenteen Protocols haaraan luodaan todentaja asetukset käyttäen edellä luotua profiilia. Asetuksiin lisätään RADIUS asiakkaan parametri use vlan id, jolloin VLAN, johon verkkoasiakas yhdistetään, luetaan RADIUS vastauksesta. Lopuksi todentaja merkitään erikseen käyttöön jokaiseen verkkoliitäntään, jossa sitä halutaan käyttää. Supplicant asetus single secure antaa todentaa ainoastaan yhden asiakkaan kussakin kytkinportissa. Guest vlan asetus kertoo, mihin verkkoon asiakas yhdistetään, mikäli tämä ei aloita EAPOL todennusta. Server reject vlan asetus kertoo, mihin verkkoon asiakas kytketään, mikäli tunnistautuminen epäonnistuu (RADIUS palvelin vastaa Access Reject:lla). Molempien VLANien asetukset on oltava konfiguroituna kytkimessä staattisesti. Lisäksi otetaan MVRP käyttöön kytkimen trunk liitännässä HPE Comware Hewlett Packard Enterprise käyttää kytkimissään Comware käyttöjärjestelmää. Järjestelmän konfiguraatiota voidaan muokata komentoriviltä. Listauksessa A.2 on esitetty olennaisimmat asetukset. Kytkimelle täytyy asettaa RADIUS palvelinten tiedot, sekä kytkeä 802.1X päälle. Jokaisen verkkoliitännän osalta täytyy asettaa vieras VLAN sekä VLAN, johon asiakas kytketään todennuksen epäonnistuessa. Jotta saavutetaan vastaava toiminnallisuus, kuin Junos kytkimien single secure, asetetaan porttiin kytkettävien asiakkaiden maksimimääräksi 1. Lisäksi kytketään MVRP päälle. 5.5 Työasemien konfigurointi Jotta toteutus saadaan toimivaksi, täytyy asiakkaiden pystyä kirjautumaan siihen. Tässä osassa esitellään kolmen käytössä olevan työasemakäyttöjärjestelmän konfiguraatiot.

56 Windows Windows työasemissa käytetään Wired AutoConfig palvelua, joka on osa normaalia käyttöjärjestelmäasennusta. Palvelun järjestelmän sisäinen nimi on dot3svc. Palvelu hoitaa oikein konfiguroituna EAPOL todennuksen läpinäkyvästi ilman, että käyttäjän tarvitsee syöttää mitään tietoja tai tietää käytetäänkö porttitodennusta. Mikäli porttitodennusta ei tarvitse käyttää, muodostetaan verkkoyhteys normaalisti. Kuva 33: Windows työasemien PEAP asetukset Palvelu voidaan ottaa työasemissa käyttöön ryhmäkäytännön (Group Policy) avulla. Samalla voidaan määritellä palvelun asetukset. Windows työasemissa voidaan käyttää PEAP:ia sekä MSCHAP v2 protokollaa [38]. Tämä konfiguraatio käyttää koneobjektin tunnusta ja salasanaa. Ryhmäkäytännön konfiguraatio on esitetty kuvassa 33. Konfiguraatiosta voidaan määrätä erikseen, minkä varmenteen asiakas hyväksyy todennuspalvelimelta. Connect to these servers kenttä määrittää ne nimet, joille myönnetyt varmenteet hyväksytään. Lisäksi voidaan määritellä hyväksyttävät CA varmenteet. Dot3svc asiakas käyttää koneobjektin tunnusta ja salasanaa ilman, että käyttäjän tarvitsee niitä tietää ja ilman, että käyttäjä saa niitä sen kautta haltuunsa. Windows 7:ssä on 802.1X toiminnallisuuksiin liittyviä ohjelmointivirheitä, joihin Microsoft on julkaissut hotfix päivityksiä. Toimivuuden kannalta kriittiseksi osoittautui päivitys tunnisteella KB Ilman päivitystä osa käytössä olevista työasemamalleista ei pystynyt yhdistämään 802.1X todennettuun verkkoon ollenkaan [39].