Kaksi identiteettiä yhdessä IKEv2-kirjautumisessa: ensin kone, sitten käyttäjä

Asiakasvarmenne validoidaan, ensimmäinen vaihto suoritetaan loppuun, ja sitten yhteys pysähtyy virheeseen ylimääräisestä todennuskierroksesta. Varmenneketjussa ei ole mitään väärää eikä verkossa ole muuttunut mikään. Yhdyskäytävä on määritetty vaatimaan toinen todiste yhdistyvältä puolelta, eikä asiakas koskaan lähetä sellaista. Sen päättäminen, kuka todistaa mitä ja missä järjestyksessä, on koko tehtävä, ja se alkaa lukemalla käytäntö siltä päätepisteeltä, jolla seisot. Kaksi erilaista todistetta kiinteässä järjestyksessä on suunnittelupäätös eikä valintaruutu.

Oire: epäonnistuminen onnistuneen ensimmäisen todisteen jälkeen

Ensimmäinen vaihto suoritetaan loppuun ja loki näyttää terveeltä, kunnes yhdyskäytävä pyytää käyttäjän identiteettiä EAP:n kautta. Silloin kättely pysähtyy tai palauttaa protokollavirheen, joka nimeää ylimääräisen kierroksen. Täysin kelvollinen konevarmenne hylätään syystä, jolla ei ole mitään tekemistä sen kelpoisuuden kanssa. Käytäntö pyysi toista todistetta, eikä asiakkaan vastausta koskaan tullut.

Molemmat kuvaukset tästä epäonnistumisesta ovat oikeita riippuen siitä, missä seisot. Asiakkaan puolelta se näyttää palvelimelta, joka hylkää kelvollisen varmenteen, ja palvelimen puolelta asiakkaalta, joka ei saa kirjautumista valmiiksi. Sama tapahtuma luetaan toisessa lokissa luottamusongelmaksi ja toisessa kyvykkyysongelmaksi. Vain määritetty käytäntö kertoo, kumpi se on.

Mitä laajennus lisää ja mitä ei

IKEv2 kuljettaa laajennusta useamman kuin yhden todennusvaihdon suorittamiseen yhdessä istunnossa. RFC 4739 hahmottelee muiden sekvenssien ohella asiakkaan, joka todistaa varmenteen identiteetin ja todennus sen jälkeen henkilön EAP:n kautta. Asiakirja on Experimental, mikä tarkoittaa, ettei mikään toteutus ole sinulle tuota ominaisuutta velkaa. Älä oleta tuesta mitään ennen kuin vastapuoli neuvottelee siitä.

Molempien osapuolten on tuettava laajennusta ja sovittava siitä vaihdon aikana. Toiselle kierrokselle määritetty yhdyskäytävä ei voi pakottaa asiakasta suorittamaan sellaista, eikä sitä tukeva asiakas käytä sitä, ellei palvelin pyydä. Juuri tämä epäsymmetria on syy siihen, että epäonnistuminen ilmenee yleensä aikakatkaisuna tai protokollavirheenä selvän kyvykkyyslausunnon sijaan. Yhden puolen kokoonpanon lukeminen kertoo sinulle puolet siitä, mitä tapahtuu.

Yksi todiste päätepistettä kohti on tavallinen muoto, eikä tämä ole se suunnittelu. Yhdyskäytävä esittää varmenteensa, käyttäjä vastaa EAP:lla, ja kumpikin puoli on todennut toisen täsmälleen kerran. Nuo kaksi todistetta tulevat vastakkaisilta päätepisteiltä, joten kumpikaan ei sano erikseen mitään koneesta ja sitä käyttävästä henkilöstä.

EAP-TLS on kolmas muoto, eikä sekään ole tämä. Siinä asiakasvarmenne esitetään EAP-menetelmän sisällä, joten asiakas suorittaa silti yhden IKE-todennuksen. Tunnistetiedot voivat näyttää samoilta kuin monikierroksisessa tapauksessa, vaikka protokolla kuljettaa yhden kierroksen kahden sijaan. Siksi EAP-TLS-käyttöönotosta kopioitu suunnittelu epäonnistuu juuri siinä kohdassa, jossa toista todistetta odotetaan.

Sama tiedosto luetaan yhdyskäytävällä eri tavalla

Sama swanctl-tiedosto luetaan eri tavalla riippuen siitä, missä se ajetaan, ja juuri se osa saa ihmiset kompastumaan. Kannettavassa yhdyskäytävä on vastapuoli, ja yhdyskäytävässä kannettava on vastapuoli, joten kirjoita local-puoli muotoon kuka minä olen ja remote-puoli muotoon kenet otan vastaan. local-lohko kuvaa, miten tämä päätepiste todentaa itsensä, ja remote-lohko ilmoittaa, mitä se vaatii toiselta päästä. Lohkon kopioiminen tiedostojen välillä kääntää sen merkityksen ilman, että yksikään merkki muuttuu. Tiedostojen vertaileminen ei kerro sinulle juuri mitään, koska samat sanat tarkoittavat kummassakin päinvastaista.

Osan sijainti määrää sen järjestyksen, ellei kierrosnumero syrjäytä sitä. Siksi ylimääräiset local- tai remote-osat kuvaavat ylimääräisiä kierroksia eivätkä vaihtoehtoja, ja selkeä kierrosnumero kohdassa swanctl.conf-viittauksessa on olemassa juuri siksi, että tämä järjestys olisi tarkoituksellinen. Ilman sitä lohkon siirtäminen muuttaa käyttäytymistä. Siksi myös kaksi paperilla samanarvoiselta näyttävää kokoonpanoa voivat käyttäytyä päinvastaisessa järjestyksessä.

Tämä järjestyssääntö tuottaa sen vikatilan, joka kannattaa muistaa. Toinen remote-lohko ei ole toinen hyväksyttävä vaihtoehto; se on toinen vaatimus, minkä vuoksi joko/tai-käytäntönä luettava käytäntö käyttäytyy kuin ja-sitten. Yhdyskäytävän käytäntö voi hyväksyä rekisteröidyn koneen varmenteen ja vaatia sitten kyseisen käyttäjän EAP-vaihdon juuri siinä järjestyksessä.

Erota kierrokset itsenäisistä tekijöistä

Kaksi kierrosta ei ole automaattisesti kaksi itsenäistä tekijää. Todisteen toistaminen tai kahden tunnistetiedon pitäminen samassa säilössä ei anna sitä vahvuutta, joka suunnittelun oli tarkoitus lisätä. Itsenäisyys on ominaisuus siitä, miten salaisuuksia säilytetään ja mikä ne vaarantaa, ei siitä, kuinka monta vaihtoa protokolla suorittaa. Suunnittelu, joka laskee kierrokset tekijöiksi, liioittelee sitä, mitä sillä on. Tämä ero on tärkein silloin, kun vaatimustenmukaisuuskysymys kysyy, kuinka monta tekijää kirjautuminen todella käyttää.

Konevarmenne todistaa hyväksytyn avaimensa hallussapidon eikä mitään muuta. Se ei ole laitteistoattestaation eikä laitteen terveysraportti, joten asennetietoa tarvitseva käytäntö tarvitsee toisen mekanismin. Subject-kenttä ei myöskään ole luotettava inventointitunniste, koska subjectin valitsee se, joka on myöntänyt tai rekisteröinyt varmenteen. Jos suunnittelu tarvitsee todisteen siitä, että kone on terve, sen todisteen on tultava komponentilta, joka mittaa konetta.

Kirjoita muistiin, mitä kukin kierros todella todistaa, ennen kuin lisäät sen. Kun kaksi kierrosta todistaa saman asian kahdesti, toinen lisää viivettä ja tukipyyntöjä varmuuden sijaan. Tuo muistiinpano on myös se, mikä lopettaa väittelyn siitä, ansaitseeko ylimääräinen kierros kustannuksensa.

Kirjoita paritussääntö ja testaa hylkäykset

Päätä, mitkä koneidentiteetit saavat parittua kenen kanssa, ja kirjoita sääntö sinne, missä valvonta sijaitsee. Kaksi kelvollista tunnistetietoa rinnakkain ei todista parituksesta mitään, koska paritus on valtuutuspäätös eikä todennuksen tulos. Rekisteröintitietojen tai todennuksen taustajärjestelmän on valvottava sitä suhdetta, jonka organisaatio haluaa.

Testaa sitten, minkä pitäisi epäonnistua: hyväksytty käyttäjä hyväksymättömällä koneella, hyväksymätön käyttäjä, jolla on koneen tunnistetieto, ja vastapuoli, joka ei pysty suorittamaan ylimääräistä kierrosta. Jos kaikki kolme saavat hiljaa saman pääsyn, käytäntö kuvaa aikomuksen sen sijaan että valvoisi sitä. Vertaa ilmoitettua kokoonpanoa siihen, mitä daemon raportoi, koska yhteys, joka ei koskaan täsmännyt, näyttää samalta kuin sääntö, joka meni läpi:

swanctl --list-conns
swanctl --list-sas

Tarkista neuvotellut kierrokset ja niistä seuraava valtuutus, älä vain onnistunutta kirjautumista. Äläkä tartu vanhoihin IKEv1 XAuth -asetuksiin oikotienä: sovita protokolla, roolit, järjestys ja asiakkaan todellinen käyttäytyminen sen sijaan että poistaisit vaaditun kierroksen, kunnes yhteys onnistuu. Epäonnistuvan kierroksen poistaminen on tapa, jolla kahden todisteen suunnittelu muuttuu hiljaa yhden todisteen suunnitteluksi, jota kukaan ei tarkistanut. Pidä poisto muutoslokissa.