Miten IKEv1:n hybriditodennus siirtyy IKEv2:n käyttäjätodennukseen
Hybriditila erotti yhdyskäytävän todisteen käyttäjän todisteesta. Siirtyminen IKEv2:een säilyttää tämän eron mutta muuttaa vaihdon, EAP-menetelmän ja varmennetarkistukset.
Jokainen vanha VPN-profiili, joka pyytää ensin palvelinvarmennetta ja sitten käyttäjänimeä, kantaa kaksi todennustapahtumaa yhdessä vaihdossa, ja se muoto elää pidempään kuin sen tuonut protokolla. IKEv1:n hybriditila rakennettiin juuri tätä varten: yhdyskäytävä todistaa itsensä julkisella avaimella ja käyttäjä todistaa itsensä myöhemmin XAuthin kautta. IKEv2 ilmaisee saman kaksivaiheisen idean toisella mekanismilla, ja juuri näissä eroissa migraatiot epäonnistuvat. Mikään versionumero ei muunna toista toiseksi, ja vanhojen valintanimien kopioiminen uuteen profiiliin antaa asiakkaan, joka neuvottelee ja jättää sitten todentamatta mitään.
Mitä hybriditila teki IKEv1:n sisällä
Hybridiprofiilissa vastaava osapuoli allekirjoittaa ensimmäisen vaiheen vaihdon omalla varmenteellaan, kun taas aloittaja jättää tarkoituksella esittämättä yhtään. Identiteetin todiste on siis epäsymmetrinen, ja juuri se salli yhdyskäytävän säilyttää nykyisen PKI:n, kun käyttäjät säilyttivät hakemistosalasanansa. Kun ensimmäinen vaihe on valmis, XAuth toimii pyyntönä ja vastauksena, jotka kuljettavat käyttäjänimen ja salasanan attribuutit jo salatussa ISAKMP-kanavassa.
Huomaa, mihin luottamus laskeutuu. Varmenne vastaa, mihin yhdyskäytävään asiakas pääsi; XAuth vastaa, mikä käyttäjä haluaa pääsyn. Kumpikaan ei korvaa toista, ja asiakas, joka on asetettu hyväksymään mikä tahansa palvelinvarmenne, on hiljaa heittänyt ensimmäisen vastauksen pois. Hybridi-tunnusta käytetään myös aggressiivisessa tilassa, jossa on ennalta jaettu avain ja XAuth, toinen järjestely samalla käyttökokemuksella, joten lue profiili äläkä nimeä. Molemmat variantit tulevat luonnoksista, joista ei koskaan tullut standardeja, ja siksi kaksi valmistajaa voi toteuttaa hybriditilan eikä kumpikaan voi toimia yhdessä toisen kanssa.
Miten IKEv2 pääsee samoihin kahteen todisteeseen
IKEv2 jakaa työn IKE_SA_INIT:n ja IKE_AUTH:n kesken. Ensimmäinen vaihto sopii ehdotuksista ja avaimista täysin ilman identiteettejä; toinen kuljettaa IDi:n, IDr:n ja AUTH-hyötykuormat. EAP:n alla aloittajan ensimmäinen AUTH-hyötykuorma lähtee tyhjänä, vastaava osapuoli todentaa itsensä ensin varmenteellaan ja allekirjoituksellaan, ja sitten EAP-keskustelu kulkee IKE_AUTH-viestien sisällä.
Mekanismi, joka tekee tästä turvallista, on avainmateriaali. Onnistunut EAP-menetelmä vie istuntoavaimen ulos, ja aloittajan viimeinen AUTH-hyötykuorma lasketaan siitä, joten käyttäjän todiste ja tunnelin avaimet sidotaan yhteen. XAuthilla ei ole vastinetta: sen attribuutit saapuvat ensimmäisen vaiheen jälkeen eivätkä lisää avaimiin mitään. Juuri se aukko piti IKEv2:n kehyksen sulkea, ja siksi toimiva IKEv2-kirjautuminen validoi palvelinvarmisteen ennen kuin kysyy mitään.
Tämä järjestys on myös hyödyllinen diagnoosi. Kun asiakas valittaa tunnistetiedoista ennen kuin on näyttänyt sinulle varmenteen, se ei tee IKEv2:n EAP-vaihtoa lainkaan.
Pidä kolme identiteettiä erillään
Migraatio menee pieleen, kun kolme identiteettiä romahtaa yhteen kenttään. On yhdyskäytävän identiteetti, jonka asiakas validoi, yleensä DNS-nimi varmenteen subject- tai SAN-kentässä. On EAP:ssa esitettävä käyttäjän identiteetti, ehkä toimialueen kirjautuminen, osoite tai selkeä EAP-identiteettimerkkijono. Ja on valtuutuslähde, joka kartoittaa kyseisen käyttäjän verkkoihin ja reitteihin.
strongSwanin swanctl-syntaksi tekee erottelun näkyväksi: yhteys asettaa yhdyskäytävälle remote { auth = pubkey } ja käyttäjälle local { auth = eap-mschapv2 }, ja EAP-identiteetti kuljetetaan erikseen.
Kun uuden profiilin käyttäjän identiteetti eroaa vanhoista XAuth-attribuuteista, esimerkiksi UPN lyhyen nimen sijaan, todennuspalvelin näkee tuntemattoman käyttäjän ja vika näyttää väärältä salasanalta. Tarkista identiteettimerkkijono ennen tunnistetietojen tarkistamista.
Kartoita valinnat ja odota sitten ansoja
Kartoitus on lyhyt ja jokaisella rivillä on ansa, joka ilmestyy vain todennuksen hetkellä.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Mikään noista riveistä ei ole pelkkä uudelleennimeäminen. Kokoonpanon hyötykuorma toimittaa osoitteet ja ratkaisijat tyypitetyn attribuuttiluettelon kautta, kun taas XAuthin attribuuttiavaruus oli sen oma keksintö; niiden pitäminen vaihtokelpoisina on se tie, jolla profiili lopulta pyytää asetusta, jota yhdyskäytävä ei koskaan lähetä.
Liikenteen valitsimet ansaitsevat oman varoituksensa. IKEv1 ilmaisi kiinnostavan liikenteen välityspalvelimen ID:illä, jotka oli sidottu quick mode -vaihtoon, kun taas IKEv2 neuvottelee valitsimista IKE_AUTH:n aikana ja vastaava osapuoli voi kaventaa niitä. Epäjohdonmukaisuus tuottaa muodostetun IKE SA:n ilman child SA:ta, jonka jotkut asiakkaat näyttävät iloisesti yhdistettynä.
Kohtele vanhaa yhteyttä rajana
RFC 9395 julistaa IKEv1:n vanhentuneeksi, joten vanha hybridiyhteys on päivämäärällä varustettu yhteensopivuusraja, ei perusta. Aja molempia profiileja rinnakkain muutoksen aikana, koska tärkeä testi ei ole se, nouseeko uusi profiili, vaan se, pääseekö sama käyttäjä samalla laitteella samoihin resursseihin.
Pidä varmenteiden validointi tiukkana loppuun asti. Kun asiakas lopettaa oman varmenteensa esittämisen, kiusaus on löysätä palvelintarkistusta, kunnes kättely menee läpi, ja se vaihtaa ainoan jäljellä olevan todisteen vihreään kuvakkeeseen.
Kirjoita neljä asiaa ennen vanhan profiilin poistamista: EAP-menetelmä, identiteettimerkkijono, valtuutuslähde ja päivä, jolloin tuki päättyy.