eduroamin vianselvitys, osa 2: Yleisimmät syyt autentikaatiovirheisiin
Taustaa
Seuraava lista pohjautuu meidän (Arch Red) kokemuksillemme sekä eduroam Suomeen että Langattomaan Tampereeseen kuuluvien organisaatioiden ongelmien ratkaisussa koottuihin kokemuksiin. Jos listasta tuntuu puuttuvan syitä tai jotkin kaipaavat lisäkommentteja niin blogiartikkelin kommentteihin voi lisätä kysymyksiä tai omia näkemyksiään aiheista. Esitellyt ongelmat eivät ole missään erityisessä yleisyys- tai muussa järjestyksessä vaan niitä on kerätty sitä mukaa kun niitä on tullut mieleen. Alunperin nämä tuli kerättyä sähköpostiin, josta parhaita paloja on jo käsitelty MobileFunet-työryhmässä.
Päätelaitteiden konfigurointivirheet
Yleisellä tasolla päätelaitteiden konfigurointivirheet on ongelma numero 1. Virheet harvemmin johtuvat RADIUS-palvelinten väärinkonfiguroinnista. Juuripalvelinten tilastoinnissa epäonnistuneita autentikaatioita voi näkyä organisaatioiden osalta suurissakin määrissä, mutta niitä tulee jokatapauksessa koska yksikin virheellisesti konfiguroitu client pommittaa kyllä onnistuneesti organisaation kotipalvelinta kasvattaen virheiden tai epäonnistuneiden tunnistautumisten määrää tilastoissa.
Vanhemmat päätelaitteet ja tunnistamismenetelmäoletukset
Tälläisistä parhaana esimerkkinä toimivat Nokian vanhat puhelimet ja niissä 802.1X:n konfiguroinnin vaikeus. Symbian oletuksena tarjosi WPA/WPA2-autentikoiduille verkoille EAP-SIM/EAP-AKA -tunnistamista oletuksena. Tämä jouduttiin aktiivisesti kääntämään pois päältä sekä syöttämään sekä ulkoinen (eli vaikka anon@tut.fi) että sisäinen (karri@tut.fi) username erikseen sekä valikoimaan PEAP/EAP-TTLS asetuksista päälle. Tämä ongelma ei ole enää niin olennainen iOS-, Android- ja Windows Phone -laitteiden yleistyessä ja Symbianin vähitellen hävitessä. Myös kannettavien käyttöjärjestelmissä tämän konfigurointi on muuttunut helpommaksi, joskaan ei välttämättä turvallisemmaksi. Tämä virhe näkyy tyypillisesti 3gpp-realmien yrittämisenä organisaation proxyävällä RADIUS-palvelimena tai viimeistään juurella, jonne nuo realmit maadoitetaan.
Varmenteiden tarkistusongelmat
Kaikki WPA-asiakasohjelmat (WPA supplicant) eivät toimi samalla tavalla. Jotkut WPA-supplicantit on konfiguroitu toisia tiukemmaksi RADIUS-palvelimen varmenteen tarkastuksessa. Jos varmenteen tarkastus ei onnistu (tai tarkemmin jää kesken), eivät useimmat supplicantit luovuta vaan yrittävät aina vain uudelleen. Jotkut supplicantit eivät mahdollista varmenteen tarkistusta (ja joudutaan luottamaan MSCHAPV2 haaste-vasteeseen). Jotkut tarjoavat vain SSH:n tyyliin fingerprintin ja ilmoittavat uudelleen, jos varmenne on muuttunut (tämä ei ole varsinaisesti huono tapa). Jotkut taas vaativat, että supplicantille on määritelty palvelimen varmentavan CA:n varmenneketju, ja että RADIUS-palvelin palauttaa sen varmenteiden yhteydessä. Virheet RADIUS-palvelimen konfiguroinnissa tai käyttäjän tekemässä supplicantin konfiguroinnissa sitten aiheuttavat jälleen kerran epäonnistuneita autentikointiyrityksiä ja yleensä paljon ja nopeallakin vauhdilla.
Salasanan vaihtovaatimukset organisaatioissa
Tietyn kuukausimäärän sisään vaihtuvan salasanan käytäntö aiheuttaa sen, että käyttäjien päätelaitteisiin jää vanhoja salasanoja, jotka eivät kelpaa, mutta joita päätelaite sitten yrittää uudelleen ja uudelleen.
Kirjoitusvirheet konfiguraatiossa
Kirjoitusvirheet konfiguraatiossa esim. tuon aiemmin mainitun ulomman kuoren ja sisemmän kuoren tunnusten määrittelyssä aiheuttavat päätelaitteita, jotka jatkuvasti yrittävät hakata päätään organisaation tunnistuspalvelimelle tai verkkovierailupalvelun seinään.
Organisaatioiden virheelliset konfiguraatio-ohjeet: Ei realmia ohjeistuksessa
Tätä Suomessa on käsittääkseni vähemmän tavattu, mutta kaikki ne organisaatiot, jotka hyväksyvät organisaationsa sisällä tunnistautumiset, joissa ei konfiguroida realmia sekä ulko- että sisä-EAP:piin, saisivat muuttaa ohjeistustaan ja konfiguraatiotaan niin, että ilman tuota realmia, autentikaatio ei onnistu organisaation sisälläkään. Tämän perustelu on se, että käyttäjä pystyy tekemään organisaation sisällä näennäisesti toimivan, mutta roamauskelvottoman konfiguraation, joka ei sitten tietenkään toimi vierailtaessa jossain muualla.
Organisaatioiden virheelliset konfiguraatio-ohjeet: RADIUS-palvelimen varmenteen tarkistuksesta lintsaaminen
Tätä harrastetaan jonkin verran Suomessakin, sillä vastaan on tullut useampiakin ammattikorkeakoulujen ja yliopistojen ohjeita, joissa ohjeistetaan kääntämään esim. Windowsissa RADIUS-palvelimen varmenteen tai nimen tarkistus pois päältä. Kun RADIUS-palvelimen varmenteen tarkistuksen ohjeistamisesta on tällä tavoin lintsattu, aiheutetaan ongelmia niille käyttäjille, joiden supplicant vaatii sitä, että se konfiguroidaan tarkemmin tuon palvelinvarmenteen varmentamista varten. Tyypillinen tälläiseen johtava virhe konfiguraatio-ohjeissa on se, että ohjeistetaan, että RADIUS-palvelinvarmenteen varmentaminen pitää kytkeä pois päältä. Tälläinen lintsaaminen olisi syytä kitkeä pois ja ohjeistaa sekä CA-varmenteiden asennus, että tuo fingerprintin tarkistus, joka esim. Mac OS X:ssä ja Windows 8:ssa on käytössä.
Päätelaitteiden bugit käyttöliittymässä ja varmenteiden hallinnassa
Mm. Nokian N900- ja Nokian N9- sekä joillain Android-laitteilla, laitteistovalmistaja on tehnyt itse supplicantin hallinnan, siihen varmenteiden konfiguroinnin ja yleisen käyttöjärjestelmän varmenteiden hallinnan. Mainituilla Nokian laitteilla mm. eräs ongelma oli, että RADIUS-palvelimeen varmenteen varmistusta varten ei pystynyt käyttöliittymästä konfiguroimaan olemassa olevia juurivarmenteita kelvolliseksi varmentamaan RADIUS-palvelimen varmennetta. Ongelmaa pystyi jossain määrin kiertämään asentamalla päävarmentajan varmenteen uudelleen tai käyttämällä privaattipäävarmentajaa.
Androidissa puolestaan jotkut laitteistovalmistajat eivät tarjoa mahdollisuutta ollenkaan varmistaa RADIUS-palvelimen varmennetta. Jos varmenteen tarkistus on mahdollista, päävarmentajan varmenteet on asennettava erikseen ja mitä vanhempi Android-versio, sen hankalampi käyttäjälle. Tilanne on hieman parantanut Android 4.0+:ssa, mutta turvallisen konfiguraation tekeminen sielläkin vaatii hyvää ohjeistusta tai automatisointia. Kuten muissakin tilanteissa, virheet näissäkin sitten kostautuvat lisääntyneinä virhemäärinä tilastoissa.
Puolinaisen konfiguraation teko päätelaitteisiin
Tämä ongelma perustuu tilanteeseen, jossa käyttäjä aloittaa konfiguraation teon, mutta tekee konfiguroidessa jonkun virheen ja viallinen/puolitoimiva konfiguraatio jää mobiililaitteeseen. Käyttäjän tietämättä mobiililaite kuitenkin yrittää tuolla viallisella konfiguraatiolla verkkoon aiheuttaen kuormaa ja virheitä tilastoihin. Esim. vaikka tilanne, että ulkoinen realm on kunnossa, mutta sisäinen käyttäjätunnus, salasana tai niihin liittyvät asetukset on pielessä. Jälleen saadaan virheitä tilastoihin ilman, että käyttäjä edes huomaa laitteensa yrittävän hakata itseään sisälle eduroam-verkkoon.
Vaihtelevat eduroam-verkon konfiguraatiot
Tämä tarkoittaa organisaatioissa olevia erilaisia eduroam-verkon konfiguraatioita ja niitä aiheutuvia ongelmia. Esimerkiksi se, että eduroam-verkko tarjoaa sekä WPA2 että WPA1 -kykyisen tunnistaumisen, voi aiheuttaa sen, että osa päätelaitteista konfiguroituukin käyttämään ja olettamaan, että eduroam tarjoaa aina molemmat autentikaatiotavat tai vähintään WPA1:n. Erityisesti Windows voi kunnostautua siinä, että sille ei kelpaa saman nimisestä verkosta sekä WPA- että WPA2-profiilit, vaan käyttäjän on valittava joko tai. Olisikin yleisen toiminnallisuuden kannalta suotavaa, että eduroam lukittaisiin jo WPA2 only -profiiliin kaikkialla Suomessa ja WPA1 sekä siihen liittyvät kryptot poistettaisiin konfiguraatioprofiileista kaikkialla.
Loppukommentit
Ehdottomasti suurin osa eduroamin ongelmista liittyy nykyään siihen, miten organisaatioiden pitäisi ohjeistaa ja hoitaa käyttäjien päätelaitteiden konfigurointi tai sen oikeellisuus. Terena Mobility -työryhmässä tätä on pyritty ratkomaan ja siellä on kokeiltu apuohjelmia mobiilipuhelimiin (tämä voi mielestäni auttaa) sekä erillisiä supplicanteja kannettaviin (tämä taas on mielestäni huonompi idea). Konfiguraatiota avustava ohjelma/webbipalvelu on mielestäni hyvä idea siksi, että sillä tavalla voidaan puskea varmemmin toimiva konfiguraatio päätelaitteisiin. Oma supplicant on puolestaan huono idea sen takia, että erilaisia laitteita on paljon ja tuollaisen asentaminen voi sotkea niiden toimintaa muuten. Omaa supplicantia parempi lähestyminen on, että pysytään niistä standardi WPA2-autentikointitavoissa, joita päätelaitteiden käyttöjärjestelmien omat supplicantit tukevat natiivisti ja keskitytään niiden konfiguraation ohjeistamiseen ja automatisointiin.
