Kerberizované internetové vyjednávání klíčů - Kerberized Internet Negotiation of Keys

Kerberizované internetové vyjednávání klíčů (KINK) je protokol definovaný v RFC 4430 slouží k založení IPsec bezpečnostní asociace (SA), podobně jako Internetová výměna klíčů (IKE) s využitím Kerberos protokol umožňující důvěryhodným třetím stranám centralizovaným způsobem zpracovávat ověřování partnerů a správu bezpečnostních politik.[1]

Jeho motivace je uvedena v RFC 3129 jako alternativa k IKE, ve které musí každý spolupracovník používat X.509 certifikáty pro autentizaci, použijte Výměna klíčů Diffie – Hellman (DH) pro šifrování, znát a implementovat bezpečnostní politiku pro každého partnera, se kterým se spojí,[2] s ověřením certifikátů X.509 buď předem připravených, nebo pomocí DNS, nejlépe s DNSSEC.[3] Při použití protokolu Kerberos musí být členové KINK pouze vzájemně ověřovat s příslušným ověřovacím serverem (AS), s a klíčové distribuční centrum (KDC) zase řídí distribuci klíčovací materiál pro šifrování, a tedy řízení bezpečnostní politiky IPsec.

Popis protokolu

KINK je protokol příkazů / odpovědí, který umožňuje vytváření, mazání a údržbu IPsec SAs. Každý příkaz nebo odpověď obsahuje společné záhlaví spolu se sadou užitečných dat typu délka-hodnota. Typ příkazu nebo odpovědi omezuje užitečné zatížení odeslané ve zprávách burzy.

Samotný KINK je bezstavový protokol v tom, že každý příkaz nebo odpověď nevyžaduje pro KINK uložení pevného stavu. To je na rozdíl od IKE, která používá hlavní režim k prvnímu vytvoření asociace zabezpečení internetu a protokolu správy klíčů (ISAKMP ) SA následované následnými výměnami v rychlém režimu.

KINK používá Kerberos mechanismy zajišťující vzájemnou autentizaci a ochranu přehrávání. Pro založení SA poskytuje KINK důvěrnost pro užitečné zatížení, které následuje po užitečném zatížení Kerberos AP-REQ. Návrh KINK zmírňuje útoky odmítnutí služby tím, že vyžaduje ověřené výměny před použitím jakýchkoli operací s veřejným klíčem a instalací jakéhokoli státu. Pokud neexistuje klíč sdílený mezi serverem a KDC, poskytuje KINK také způsob použití mechanismů Kerberos mezi uživateli. To je obvykle, ale není to omezeno na případ s IPsec peery, kteří používají PKINIT pro počáteční autentizaci.

KINK přímo znovu používá užitečné zatížení rychlého režimu definované v části 5.5 IKE, s několika drobnými změnami a opomenutími. Ve většině případů jsou výměny KINK jediným příkazem a jeho odpovědí. Při vytváření SA je vyžadována volitelná třetí zpráva, pouze pokud respondent odmítne první návrh od iniciátora nebo chce přispět materiály pro klíčování. KINK také poskytuje přepracování a Detekce mrtvého partnera.

Formát paketu

Zpráva KINK obsahuje následující pole:

KINK zpráva
Bitový offset 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0typverze délka
32doména tlumočení (DOI)
64ID transakce (XID)
96další užitečné zatíženíA délka kontrolního součtu
128
...		užitečné zatížení
...
...
...		kontrolní součet
...
  • typ: CREATE, DELETE, REPLY, GETTGT, ACK, STATUS nebo soukromé použití
  • version: hlavní číslo verze protokolu
  • délka: délka celé zprávy
  • doména tlumočení (DOI): DOI podle definice v Asociace pro zabezpečení internetu a protokol pro správu klíčů (ISAKMP)
  • ID transakce (XID): identifikace transakce, definovaná jako příkaz, odpověď a volitelné potvrzení
  • next payload: type of first payload after the message message as KINK_DONE, KINK_AP_REQ, KINK_AP_REP, KINK_KRB_ERROR, KINK_TGT_REQ, KINK_TGT_REP, KINK_ISAKMP, KINK_ENCRYPT nebo KINK_ERROR
  • Bit ACK nebo ACKREQ: 1, pokud respondér vyžaduje výslovné potvrzení, že odpověď byla přijata, jinak 0
  • délka kontrolního součtu: délka kryptografického kontrolního součtu zprávy v bajtech
  • užitečné zatížení: seznam užitečných zatížení typu / délky / hodnoty (TLV)
  • kontrolní součet: Kontrolní součet zadaný protokolem Kerberos za celou zprávu s výjimkou samotného pole kontrolního součtu

Užitečné zatížení

Užitečné zatížení KINK jsou definovány jako:

KINK užitečné zatížení
Bitový offset 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0další užitečné zatížení délka užitečného zatížení
32
...		hodnota
...
  • další užitečné zatížení: typ prvního užitečného zatížení
  • délka: délka užitečného zatížení

Jsou definována následující užitečná zatížení:

  • KINK_AP_REQ: užitečné zatížení, které přenáší Kerberos AP-REQ na odpovídač
  • KINK_AP_REP: užitečné zatížení, které předává Kerberos AP-REP iniciátorovi
  • KINK_KRB_ERROR: užitečné zatížení, které přenáší chyby typu Kerberos zpět na iniciátora
  • KINK_TGT_REQ: užitečné zatížení, které poskytuje prostředky k získání TGT od peer za účelem získání lístku služby mezi uživateli z KDC
  • KINK_TGT_REP: užitečné zatížení, které obsahuje TGT požadované v předchozím užitečném obsahu KINK_TGT_REQ příkazu GETTGT
  • KINK_ISAKMP: užitečné zatížení pro zapouzdření užitečných zatížení ISAKMP IKE Quick Mode (fáze 2), umožňující zpětnou kompatibilitu s IKE a ISAKMP, pokud dojde k následným revizím
  • KINK_ENCRYPT: užitečné zatížení k zapouzdření dalších užitečných zatížení KINK a je šifrováno pomocí klíče relace a algoritmu určeného jeho typem
  • KINK_ERROR: užitečné zatížení, které vrací chybový stav

Implementace

Následující otevřený zdroj implementace KINK jsou aktuálně k dispozici:

Viz také

Reference

  1. ^ RFC 3129: Požadavky na Kerberized Internet Negotiation of Keys, Pracovní skupina pro internetové inženýrství, Červen 2001, s. 2
  2. ^ RFC 3129: Požadavky na Kerberized Internet Negotiation of Keys, Pracovní skupina pro internetové inženýrství, Červen 2001, s. 1
  3. ^ RFC 4322: Oportunistické šifrování pomocí Internet Key Exchange (IKE), Pracovní skupina pro internetové inženýrství, Červen 2001, s. 5