Federatiemanagement met DNS en DNSSEC: kan dat?

Transcriptie

1 indi Federatiemanagement met DNS en DNSSEC: kan dat? Project : SURFtrust in het kader van SURFworks Projectjaar : 2009 Projectmanager : Remco Poortinga-van Wijnen Auteur(s) : Bob Hulsebosch, Henk Eertink Opleverdatum : Q Versie : v4, final Samenvatting Het op een betrouwbare manier vinden van identiteitsdiensten en federatiemetadata is cruciaal voor het creëren van vertrouwen tussen federaties onderling en tussen Service Providers (SPs) en Identity Providers (IdPs) binnen (confederaties van) federaties. Het in dit document beschreven onderzoek bestudeert de toepasbaarheid van DNS ( het telefoonboek van het internet ) als een oplossing hiervoor. De uitkomst van dit onderzoek is dat DNS in principe gebruikt kan worden voor het efficiënt managen van confederaties. Het vinden van de hiervoor essentiële confederatiemetadata kan eenvoudig en gedistribueerd via DNS, zonder hierbij data in DNS zelf op te slaan. Het vertrouwen komt door de toepassing van DNSSEC. DNSSEC verzekert de authenticiteit en integriteit van de resource records. Het zegt echter niet of deze records wel te vertrouwen zijn voor bijvoorbeeld het hoger onderwijs. Dit specifieke vertrouwen moet geborgd worden door de confederatie operator die de beveiligde DNS zone beheerd waarin alle resource records van de deelnemende partijen staan. Voor deze publicatie geldt de Creative Commons Licentie Attribution 3.0 Unported. Meer informatie over deze licentie is te vinden op

2 Echter, specifieke en behoorlijk intelligente middleware software is nodig voor het verwerken van de DNS/DNSSEC vragen en resultaten. Bovendien moeten Islands of Trust in DNS worden ondersteund omdat het gehele DNS nog niet getekend is. Dit maakt dat het gebruik van DNS en DNSSEC al met al behoorlijk complex wordt en ten opzichte van de huidige oplossingen slechts minimale voordelen met zich meebrengt. Daar waar de huidige oplossingen gericht zijn op het borgen van vertrouwen in de metadatafile zelf en de controle hiervan on the fly gedaan kan worden tijdens het verwerken van de file op applicatie niveau, is voor de DNS/DNSSEC oplossing additionele software nodig waardoor de drempel voor adoptie waarschijnlijk te hoog zal zijn. Dus, hoewel een DNS en DNSSEC gebaseerde architectuur een uitstekende kandidaat is voor een gedistribueerde en veilige oplossing voor confederatief identiteitsmanagement zullen andere oplossingen gemakkelijker te implementeren zijn.

3 Colofon Programmalijn: SURFworks Onderdeel: SURFfederatie PoCs: Vertrouwen op grote(re) schaal Activiteit: Deliverable: Detailstudie Onderzoek naar methoden voor vertrouwen op grote(re) schaal Toegangsrechten: Publiek Externe partij: Novay, Dit project is tot stand gekomen met steun van SURF, de organisatie die ICT vernieuwingen in het hoger onderwijs en onderzoek initieert, regisseert en stimuleert door onder meer het financieren van projecten. Meer informatie over SURF is te vinden op de website ( Voor deze publicatie geldt de Creative Commons Licentie Attribution 3.0 Unported. Meer informatie over deze licentie is te vinden op

4 5 dingen die je moet weten over Federatiemanagement met DNS/DNSSEC Context Het maken van koppelingen tussen Identity Providers en Service Providers in Identity Federations, en ook het koppelen van federaties onderling, wordt gedaan op basis van metadata. Het aanbieden en uitwisselen van deze metadata, en het beheer ervan is een kerntaak van een federatie. Wat is het? Voor wie is het? Hoe werkt het? Wat kan je ermee? DNS en DNSSEC zijn mechanismen om op een gedistribueerde wijze informatie op te zoeken en uit te wisselen (veelal over internet adressen), waarbij DNSSEC de beveiliging van deze uitwisseling kan garanderen. In dit rapport wordt bestudeerd of het DNS/DNSSEC mechanisme ook gebruikt kan worden bij het uitwisselen van federatie metadata. Voor alle partijen (IDPs, SPs en operators) in federaties en con-federaties. Er zijn een aantal mogelijkheden om informatie over federaties op te slaan in DNS, en daaruit op te halen. Deze mogelijkheden worden beschreven en geevalueerd. Essentieel is dat de deelnemende partijen in een federatie tools moeten ontwikkelen en gebruiken die interfacen met DNS om metadata te beheren. Metadata uitwisselen behulp van de bestaande DNS infrastructuur om daarmee eenvoudig en inzichtelijk federaties en con-federaties te vormen.

5 Inhoudsopgave 1 Inleiding Confederatie en metadata Doelstelling en aanpak 2 2 DNS en DNSSEC voor federatiemanagement DNS DNS RR TXT Samenvatting DNSSEC 5 3 Toepassingen van DNS voor geconfedereerd identiteitsmanagement Gerelateerd werk Een confederatiescenario Aanpak 1: De IdP publiceert de confederatiemetadata Aanpak 2: Gedistribueerde metadata Aanpak 3: Het inrichten van een beveiligde DNS zone Aanpak 4: Een onafhankelijke DNS hiërarchie Discussie Welke aanpak? DNSSEC voldoende? 19 4 Conclusies 22 Referenties 24 Federatiemanagement met DNS en DNSSEC V

6

7 1 Inleiding De SURFfederatie stelt studenten en werknemers in het hoger onderwijs in staat om op een betrekkelijk eenvoudige en vriendelijke manier toegang te krijgen tot online diensten en data. Door gebruik te maken van een federatieve identiteitsmanagementinfrastructuur kan een gebruiker met dezelfde credentials toegang krijgen tot meerdere externe bronnen. De identiteitsmanagementinfrastructuur zorgt ervoor dat identiteitsgegevens op de juiste manier tussen de betrokken partijen worden gecommuniceerd. In de SURFfederatie zijn dit typisch de identiteitsproviders (IdPs) van de gebruikers, de service providers (SPs), eventuele attribuut service providers (ASPs) en de centrale hub bij SURFnet. 1.1 Confederatie en metadata Het is niet ondenkbaar dat de SURFfederatie op korte termijn onderdeel gaat uitmaken van andere confederaties zoals edugain [1]. De activiteiten om dit te realiseren lopen al binnen edugain/geant verband. Echter, er is nog onduidelijkheid over de te kiezen infrastructuur voor het borgen van vertrouwen en het uitwisselen van de metadata in de confederatie. Dat beide aspecten niet geheel onafhankelijk van elkaar zijn is al gebleken uit eerder SURFworks onderzoek [2]. De metadata biedt niet alleen pointers naar IdPs en SPs in de confederatie maar ook zekerheid betreffende de authenticiteit van deze partijen tijdens het uitwisselen van identiteitsgegevens. Kortom, in een confederatie is de metadata een belangrijke bron voor het vinden van partijen en voor het creëren van vertrouwen tussen deze partijen. Echter, het managen van metadata in een confederatie is niet eenvoudig. Een geaggregeerde metadatafile waarin alle federatiemetadata staat lijkt voor de hand te liggen maar heeft zijn nadelen: Wie gaat deze centrale confederatiemetadatadienst bouwen en beheren en is er verantwoordelijk voor? Vaak ontbreekt een dergelijke partij. De file kan heel groot worden. Bovendien wordt over het algemeen slechts zaken gedaan met een klein aantal partijen uit deze file. Al het andere is dus overtollige ballast. De metadata van een federatie kan nog wel eens veranderen. Het up-to-date houden van de confederatiemetadatafile vereist dus discipline bij de (con)federatiemanagers of een vorm van geautomatiseerde synchronisatie tussen de confederatie- en federatiemetadata. Toegang tot de confederatiemetadatafile om veranderingen door te voeren moet beveiligd zijn. Deze toegangsbeveiliging vereist coördinatie vanuit de confederatie. In de gangbare SAML 2.0 methode bijvoorbeeld (voor point-to-point federaties) wordt de metadata gevonden via het EntityID welke een URL is. Deze URL verwijst dan naar een metadatafile. Dit is in een (multi-point-to-multi-point) confederatie vaak een centrale file. Daarnaast, wordt het vertrouwen in de metadata door weinig schaalbare out-of-band oplossingen geregeld zoals een PKI of het opnemen van certificaten of tags in de metadata zelf (zie ook [2] voor meer informatie hierover). Dit pleit voor een studie naar een meer decentrale en schaalbare aanpak voor het managen van confederatiemetadata en het borgen van vertrouwen hieromtrent. Een aanpak waarin bijvoorbeeld de federaties zelf, lokaal, hun eigen metadata managen. En waarin de confederatiemetadata slechts bestaat uit een lijstje van federatie end-points. De IdPs en SPs die in de aangesloten federaties participeren zijn niet in deze confederatiemetadata opgenomen en komen pas terug in de federatiemetadata. Maar ook deze aanpak is niet zonder uitdagingen: Het vinden van de metadatafile op een betrouwbare manier: hoe weet een SP bij welke federatie hij moet zijn om een eindgebruiker te laten authenticeren? Hoe weet de SP dat een bepaalde IdP participeert in de confederatie? Hoe weet de IdP dat een bepaalde SP participeert in de confederatie? Hoe zorg je ervoor dat deze gedistribueerde metadatafiles te vertrouwen zijn zonder te verzanden in complexe, dure en slecht schaalbare beveiligingsoplossingen? Federatiemanagement met DNS en DNSSEC 1

8 Mogelijk kan het Domain Name System (DNS) een antwoord geven op deze vragen. DNS maakt het mogelijk om via een URL op een snelle manier het bijbehorende IP-adres van SPs of IdPs te vinden op het Internet. Misschien kan het ook helpen bij het vinden van metadatafiles. En misschien kunnen de beveiligingsextensies van DNS (DNSSEC) ervoor zorgen dat dit op een betrouwbare manier gebeurt? Met andere woorden, kunnen DNS en DNSSEC van toegevoegde waarde zijn bij het betrouwbaar managen van confederatiemetadata? 1.2 Doelstelling en aanpak Het voorliggende document probeert een antwoord te geven op deze vraag door de mogelijkheden van DNS en DNSSEC voor confederatiemetadatamanagement te analyseren en te vergelijken met alternatieve oplossingen. Na een korte introductie van DNS en DNSSEC in hoofdstuk 2, zullen in hoofdstuk 3 enkele scenario s voor het gebruik van DNS en DNSSEC in een confederatie geschetst en geanalyseerd worden. Hoofdstuk 4 sluit af met een samenvatting van de bevindingen. 2 Kan dat?

9 2 DNS en DNSSEC voor federatiemanagement Dit hoofdstuk beschrijft kort DNS en DNSSEC en geeft een overzicht van de features die in potentie van belang zijn voor het uitwisselen van metadata. Waarbij DNS een alternatief is voor service discovery en metadata opslag en DNSSEC voor de security en trust. 2.1 DNS Het Domain Name System (DNS) is het systeem en protocol dat op het Internet voornamelijk gebruikt wordt om domeinnamen naar IP-adressen te vertalen en omgekeerd. Data in DNS wordt opgeslagen in een Resource Record (DNS RR). Een resource record heeft een type, een levensduur (TTL), een naam en data. De data kan bijvoorbeeld een IP-adres zijn of weer een andere naam. Dit is afhankelijk van het type van het resource record. Veel voorkomende types zijn A (voor het bepalen van het IPv4-adres bij een naam), AAAA (voor het bepalen van het IPv6-adres bij een naam) en MX (voor het bepalen van de mailserver voor een domein). De wat minder bekende record types - maar interessant voor dit werk - zijn (voor het aanduiden van diensten), (voor o.a. PKIX doeleinden), (naming authority pointer, voor bereikbaarheidsgegevens als bijvoorbeeld een URI) en TXT (gebruikt voor ieder door de gebruiker gewenst commentaar). De volgende sectie gaat dieper in op deze resource records. 2.2 DNS RR Verschillende DNS Resource Records zijn dus beschikbaar met elk hun eigen kwaliteiten. Deze sectie beschrijft de meest relevante records en geeft aan of ze geschikt zijn voor het vinden van metadata en IdP diensten in een confederatie Naast het vertalen van domeinnamen in IP-adressen kan DNS ook gebruikt worden om diensten te vinden in een netwerk. Het DNS Service of record kan gebruikt worden voor het aanduiden van diensten in een bepaald domein [3]. Het record heeft over het algemeen de volgende vorm: _Service._Protocol.DomainName TTL IN Priority Weight Port Target Het volgende voorbeeld verklaart de meeste termen in het -record: _sip._tcp.example.com IN sipserver.example.com Dit voorbeeld verwijst naar een server genaamd sipserver.example.com die beschikbaar is via TCP poort 5060 voor SIP connecties. De time to live (TTL) is seconden (24 uur), de prioriteit is 0 en het gewicht is 5 (het gewicht gaat een rol spelen bij records met een gelijke prioriteit). Een nadeel van records is dat slechts één dienst aangegeven kan worden. Om voor een gegeven domein pointers naar meerdere diensten mogelijk te maken is DNS gebaseerde service discovery (DNS- SD) ontwikkeld [4]. DNS-SD maakt ook gebruik van -records die dan beschrijven welke diensten op een domeinnaam draaien. Het bevat de prioriteit, gewicht, port en hostnaam van de dienst. Bij het zoeken van een dienst zal DNS-SD de parameters en hostna(a)m(en) van de service opzoeken. De hostnaam is opgeslagen in het -record en de eventuele parameters worden opslagen als key=value paren in een TXT-record. Let wel, DNS-SD werkt alleen voor een gegeven domein en service type Mogelijk is de Name Authority Pointer ( record) hiervoor een goede aanvulling. Dit record bevat geen IP-adres maar contactgegevens van de betreffende partij. De vorm van is als volgt: $ ORIGIN foo.com order pref flags service regexp replacement Federatiemanagement met DNS en DNSSEC 3

10 IN "s" "http+i2r" "" _http._tcp.foo.com. maakt het mogelijk om informatie, zoals bijvoorbeeld federatiemetadata, te vinden. De SAML metadata specificatie geeft al aan dat hiervoor het beste het -record gebruikt kan worden [5]. Met kan aangegeven worden waar bepaalde metadata staat, met welk protocol het opgehaald kan worden (https) en voor wie het bedoeld is (bijvoorbeeld de IdP van de eindgebruiker). Daarnaast kan met ook aangegeven worden waar bijvoorbeeld de eindgebruiker te authenticeren is. Het vinden en aanroepen van de service gaat dan weer via een -record. Liberty Alliance heeft het gebruik van DNS en voor het publiceren en ophalen van metadata al eens beschreven [6]. Enkele voorbeelden van de in deze specificatie beschreven service velden zijn: PID2U 1 + representeert een entity metadatadocument dat via het https protocol benaderd kan worden. PID2U+ herschrijft een PIP metadata URL voor een entity beschreven door een providerid via het https protocol. PID2U+uddi:entity:si:foo retourneert de locatie van een WSDL document dat een service instance "foo" beschrijft. PID2U+ geeft de metadata voor een groep entiteiten waarvan providerid een lid is. De metadata beschrijft de IdPs in de groep. NID2U 2 + geeft een IdP providerid welke authenticatiediensten voor een principal kan leveren. NID2U+ levert een URL op voor het authenticeren van een principal. Provider metadata voorbeelden zijn dan: $ORIGIN provider.biz IN "U" PID2U+ "!^.*$! "" IN "U" PID2U+ "!^.*! 3/mdtrust.xml!" "" IN "U" PID2U+uddi:entity "!^.*$! "" Name Identifier ofwel principal of IdP voorbeelden zijn dan: $ORIGIN example.int. IN "U" NID2U+ "!^([^@]+)@(.*)$! -bin/getmd?\1!" "" IN NAP TR "U" NID2U+ "!^([^@]+)@(.*)$! "" Waarbij de reguliere expressies aangeven hoe het record herschreven moet worden voor verder gebruik. In de bovenstaande voorbeelden wordt bijvoorbeeld uit het adres van user@example.int de extensie example.int geëxtraheerd en via!^([^@]+)@ (.*)$ herschreven in Het DNS record maakt het mogelijk om certificaten en gerelateerde informatie zoals revocation lists in DNS op te slaan [7]. Op deze manier kan het certificaat distributieprobleem opgelost worden. Partijen kunnen de sleutel uit het certificaat gebruiken voor encryptiedoeleinden. De syntax van het record is als volgt: name ttl class rr type key tag algorithm cert or crl john IN (AQPmn12 dirq) 1 PID2U resolvet een providerid identifier metadata URL. 2 NID2U resolvet een nameidentifier (principal) metadata URL. 4 Kan dat?

11 wat aangeeft dat het certificaat AQPmn12 dirq van John van het type X.509 is (een ander type is OpenPGP). De key tag is een 16 bit afgeleide van het certificaat en kan gebruikt worden om sneller een bepaald certificaat op te zoeken. De ttl is een time-to-live aanduiding voor de geldigheid van het record TXT Het DNS TXT record maakt het mogelijk om willekeurige leesbare tekst in DNS op te slaan. De vorm van een TXT record ziet er als volgt uit: host.widgets.com IN TXT "printer=lpr5" sam.widgets.com IN TXT "favoriete drank=appelsap" In principe is een TXT record geschikt om iets over de confederatie te zeggen. Bijvoorbeeld over een service aangeboden door een IdP, SP, federatie of confederatie. Dit kan er als volgt uitzien: of of idp.surffed.nl IN TXT confederation=edugain idp.novay.nl IN TXT federation=surffederatie service.sp.ch IN TXT federation=switch Op grond hiervan kan afgeleid worden in welke federatie(s) of confederatie(s) een partij zich bevindt. Voorwaarde is wel dat er een semantische en syntactische afstemming van de tekstelementen dient plaats te vinden. De grootte van het TXT record is beperkt tot enkele honderden bytes waardoor het niet mogelijk is om grote hoeveelheden metadata informatie erin te stoppen. Net als voor alle DNS resource records is de betrouwbaarheid van de informatie in het TXT record van essentieel belang Samenvatting Samenvattend: de keuze van de DNS records hangt af van de manier van aanbieden van de metadata en diensten voor bijvoorbeeld authenticatie. Voor een metadatadienst zijn dit -records, voor pointers naar de data of diensten -records. De combinatie van en records lijkt veelbelovend voor gebruik binnen een confederatie. De TXT records vereisen afstemming; zonder dit ontstaat er een risico op wildgroei van tekst elementen die verkeerd geïnterpreteerd kunnen worden in een confederatie. Het is onwaarschijnlijk dat deze afstemming op korte termijn gaat gebeuren. Het record kan van pas komen voor het lokaliseren van certificaten van partijen buiten de eigen federatie. Cruciaal is de betrouwbaarheid van de DNS resource records. Dit wordt geadresseerd in de volgende sectie. 2.3 DNSSEC Vanuit beveiligingsoogpunt kent DNS een aantal zwakheden: DNS data kan tussentijds veranderd worden door een hacker waardoor de eindgebruiker naar de verkeerde website gestuurd wordt. De DNS cache kan aangepast worden. Ook hier belandt de eindgebruiker op de verkeerde site. DNS data kunnen afgeluisterd worden. DNSSEC is ontwikkeld om deze zwakheden weg te nemen. DNSSEC is een veiligheidsextensie op DNS, waarbij de antwoorden op de lookups getekend worden met behulp van public-key cryptografie. Op die manier wordt de authenticiteit en integriteit van de DNS antwoorden gewaarborgd en weet men zeker dat het antwoord echt van de juiste partij afkomstig is en dus te vertrouwen is. Een browser is hierdoor bijvoorbeeld in staat te verifiëren of het IP-adres daadwerkelijk bij het domein hoort. DNSSEC is te vergelijken met een lakzegel; op ieder DNS antwoord zit een zegel waaraan te zien is of het antwoord authentiek is. Federatiemanagement met DNS en DNSSEC 5

12 In DNSSEC wordt een sleutel gesigned door het bovenliggende domein. Met deze sleutel kunnen de records in een zone worden gesigned. Het.nl-domein bevat dan een verwijzing naar de nameserver van surffed.nl, met de handtekening van de sleutel van surffed.nl. Op deze manier ontstaat er een Chain of Trust in de DNS hierarchie (zie Figuur 1). Chain of Trust DNSKEY public root key root DNSKEY public.nl key.nl DNSKEY public surffed.nl key surffed.nl nl.ds hash(dnskey) surffed.nl.ds hash(dnskey) A nl.rrsig DS signed met private root key surffed.nl.rrsig DS signed met private.nl key RRSIG A signed met private surffed.nl key Figuur 1: DNSSEC en de Chain of Trust. Het kapen van websites door aanvallen op DNS servers (cache poisoning) is met DNSSEC niet meer mogelijk. Hiermee is DNSSEC hét antwoord op het Kaminsky-probleem 3, dat tot nu toe enkel tijdelijk opgelost is. Met DNSSEC is de eindgebruiker er dus altijd zeker van dat hij/zij op de juiste website is. Figuur 2 laat zien hoe DNSSEC werkt in het geval van cache poisoning. 3 In januari 2008 ontdekt Dan Kaminsky een kwetsbaarheid in verschillende DNS implementaties. De kwetsbaarheid stelt kwaadwillenden in staat om de cache van DNS servers te vervuilen met foutieve informatie (cache poisoning). Via dergelijke foutieve informatie kan een kwaadwillende de gebruiker bijvoorbeeld naar kwaadaardige websites leiden zonder dat de gebruiker dit merkt. 6 Kan dat?

13 .nl root surffed.nl Geldig Geldig Ongeldig 4 Ongeldig Lokale DNS Server novay.nl surffed.nl Figuur 2: DNSSEC bescherming tegen cache poisoning. DNSSEC introduceert een aantal nieuwe resource records: DNSKEY met daarin de publieke sleutel, RRSIG waarin de handtekening zit, DS draagt een getekende hash van de sleutel, en NSEC/NSEC3 voor een geauthenticeerd bewijs voor het niet bestaan van namen in de zone. De root DNS servers zijn nog niet getekend. DNSSEC wordt al wel bij een aantal top level domeinen ingezet:.org is getekend en.gov en.eu worden binnenkort getekend. In Europa wordt DNSSEC al gebruikt in onder andere Zweden en Tsjechië. In Nederland is SIDN nog aan het onderzoeken of en wanneer zij DNSSEC zullen gaan invoeren. Meer informatie over DNSSEC is te vinden in de specificaties [8, 9, 10] en in bijvoorbeeld het SURFnet whitepaper [11]. De consequentie van het ontbreken van een volledig ondertekend DNS is dat er geen volledige Chain of Trust is en er sprake is van zogenaamde Islands of Trust. Deze Islands of Trust maken het moeilijker om de handtekeningen te valideren en vertrouwen te borgen over meerdere domeinen heen. De Islands of Trust zijn weergegeven in Figuur 3. Federatiemanagement met DNS en DNSSEC 7

14 root org com nl se isc verisign surffed nic www showcase www Island of Trust Island of Trust Island of Trust Figuur 3: Islands of Trust in de huidige DNS hiërarchie. Merk op dat DNSSEC geen garanties biedt over de betrouwbaarheid van de in het DNS opgeslagen informatie zelf of de betrouwbaarheid van de informatie die via DNS pointers is verkregen. Dit vertrouwen zal op een andere manier geborgd moeten worden; huidige federaties regelen dit out-ofband. Daarnaast biedt DNSSEC ook geen bescherming tegen denial of service aanvallen 4 en geen confidentialiteit 5. Verder ondersteund niet alle software DNSSEC waardoor de drempel voor adoptie (nog) groot is. Dit zijn belangrijke aspecten om in ogenschouw te nemen bij het inzetten van DNS en DNSSEC voor metadata uitwisseling. 4 Met DNSSEC wordt het eenvoudiger om gedistribueerde denial of service aanvallen uit te voeren. De security overhead van DNSSEC en de toename van de grootte van de DNS pakketten zijn hier debet aan. Kleine queries leveren grote antwoorden op. 5 TLS kan bijvoorbeeld gebruikt worden om in dit laatste te voorzien. 8 Kan dat?

15 3 Toepassingen van DNS voor geconfedereerd identiteitsmanagement Dit hoofdstuk gaat in op het gebruik van DNS en DNSSEC voor confederatiemanagement. 3.1 Gerelateerd werk Uit het vorige hoofdstuk blijkt duidelijk dat DNS meer kan dan alleen URLs vertalen in IP-adressen of omgekeerd. Zo kan DNS op een slimme manier gebruikt worden als een trusted directory service voor het opslaan van encryptiesleutels of certificaten 6 [12]. Het feit dat de sleutels in een door de federatie operator beheerde zone staan geeft aan dat de partijen deel uit maken van de federatie; de sleutels of certificaten uit de zone verzekeren partijen ervan dat ze met andere leden uit de federatie communiceren en niet met buitenstaanders of kwaadwillenden die zich voordoen als federatielid. Het gebruiken van DNSSEC garandeert in dit geval de authenticiteit en integriteit van de certificaten verkregen uit DNS. Het voordeel van deze aanpak is dat de federatie operator slechts een bepaalde DNS zone hoeft te beheren waarin de certificaten van alle aangesloten partijen staan. Bovendien profiteert deze federatie operator van verschillende andere voordelen van DNS zoals beschikbaarheid (gedistribueerdheid en bereikbaarheid) en robuustheid (caching). Keerzijde zijn de langzame updates en de mogelijk daaruit voortkomende inconsistenties in de gegevens. Een ander voorbeeld is het gebruik van DNSSEC voor het dynamisch creëren van vertrouwen tussen RADIUS authenticatieservers in een roaming scenario [13]. Ook, in de context van identiteitsmanagement kan DNS voor meerdere toepassingen gebruikt worden. Het gebruik van DNS-SD maakt het bijvoorbeeld mogelijk voor IdPs om zogenaamde Attribuut Service Providers te lokaliseren. Deze voorbeelden spelen zich af in een enkele federatie. Zaken worden ingewikkelder als er sprake is van een confederatie. DNS-SD bijvoorbeeld werkt alleen voor een gegeven domein en service type. In een confederatie is het juist zaak om uit te vinden wat het domein is alvorens een eindgebruiker te kunnen authenticeren bij een IdP dienst. Daarom is het gebruik van -records alleen zoals gedaan wordt in DNS-SD waarschijnlijk niet voldoende voor het vinden van metadata en diensten over federaties heen. records zijn dan nodig. Een bijkomende complexiteit is dat, in tegenstelling tot in de typische Liberty Alliance Circles of Trust, in de SURFfederatie de SP niet direct met de IdP van de eindgebruiker communiceert, maar dit via de hub doet. Een authenticatieverzoek zal dus door de SP naar de SURFfederatie hub gestuurd moeten worden. Waarop de hub vervolgens de IdP van de eindgebruiker de opdracht geeft deze te authenticeren. Deze indirectie vormt een extra moeilijkheid en vereist een uitbreiding van de in [6] beschreven aanpak voor metadata-uitwisseling die uitgaat van een directe communicatie tussen de SP en IdP. Bovendien zal rekening gehouden moeten worden met het feit dat de hub niet in alle gevallen transparant is. 3.2 Een confederatiescenario In een typisch confederatie scenario waarin een gebruiker gebruikt maakt van een bepaalde dienst in een andere federatie spelen de volgende vragen voor de SP: Bij welke IdP moet de SP zijn om de eindgebruiker te authenticeren en attributen te krijgen? 6 Bij het opslaan van gegevens in DNSSEC moet wel rekening gehouden worden met de beperkingen van het systeem hiervoor. Zo is de ruimte voor het opslaan van sleutel- of certificaatinformatie beperkt omdat een DNSSEC response bericht alleen een enkel, ongefragmenteerd pakketje ter grootte van maximaal 4000 bytes toestaat [RFC4034]. Federatiemanagement met DNS en DNSSEC 9

16 Is de federatie waarin de (IdP van de) gebruiker zit te vertrouwen? Met andere woorden, zit die federatie in de confederatie waarvan de federatie van de SP ook deel uit maakt? En de volgende vraag is voor de IdP van de gebruiker van belang: Zit de SP in een federatie die te vertrouwen is? Met andere woorden, zit die federatie in de confederatie waarvan de federatie van de IdP ook deel uit maakt? Kunnen deze vragen beantwoord worden door gebruik te maken van DNSSEC en resource records als, en? Om hier achter te komen gebruiken we het volgende concrete scenario: een werknemer van Novay.nl dat lid is van de SURFfederatie.nl wil gebruik van een service van een Zwitserse SP.ch die lid is van SWITCH.ch federatie. Beide federaties zijn zelf weer lid van de edugain.org confederatie. Dit alles staat op een of andere manier beschreven in een of meerdere metadatafiles. Op basis van dit scenario zijn verschillende DNS-gebaseerde aanpakken mogelijk. Deze zullen in de volgende secties beschreven worden. Bij elk van de aanpakken is het uitgangspunt dat DNS zoveel mogelijk als natuurlijke lookup dienst gebruikt wordt en niet misbruikt wordt voor het opslaan van allerlei metadata. 3.3 Aanpak 1: De IdP publiceert de confederatiemetadata Deze aanpak gaat er vanuit dat de IdP een record publiceert met daarin een pointer naar de confederatiemetadatafile. In deze file staan de EntityIDs van alle federatie hubs en de SPs en IdPs daarin. In het scenario publiceert Novay dus de edugain metadata. Zaak is dat de SP te weten komt waar de metadata staat. Een logische eerste stap hiertoe is dat de SP aan de werknemer vraagt wat zijn of haar adres of URL van de universiteit is. Op grond hiervan kan de SP via een verzoek nagaan of Novay onderdeel uitmaakt van de edugain confederatie. Immers Novay.nl publiceert de volgende metadata URL: $ORIGIN novay.nl IN U PID2U+ De SP kan hiermee de file ophalen en controleren of Novay.nl onderdeel uitmaakt van edugain. Hierbij wordt er vanuit gegaan dat Novay.nl bereid is en de kennis heeft om de edugain metadata te publiceren. Het is nog maar de vraag of dat zo is. Deze relatief simpele oplossing veronderstelt ook dat edugain ergens op een centrale plaats een geaggregeerde metadatafile van alle deelnemende federaties en hun leden (IdPs en SPs) aanbied. Echter, de haalbaarheid van een dergelijke centrale oplossing blijkt in de praktijk vaak niet haalbaar waardoor een meer gedecentraliseerde oplossing, waar op een meer impliciete manier de vertrouwensrelaties tussen de verschillende partijen uit DNS af te leiden valt, de voorkeur geniet [2]. In dat geval ligt het voor de hand dat Novay de SP via naar de SURFfederatie zal verwijzen voor meer informatie en ook voor het authenticeren van haar werknemer. Deze realistischere aanpak wordt in de volgende sectie beschreven. 3.4 Aanpak 2: Gedistribueerde metadata Deze aanpak gaat er vanuit dat iedere confederatie en federatie zijn eigen metadata beheert en publiceert. Dus, SURFnet publiceert de SURFfederatie metadata en edugain de confederatie metadata. Het volgende stappenplan treedt dan in werking: 1. De SP doet een verzoek voor novay.nl en krijgt als antwoord een URL waar de metadata file staat van de SURFfederatie waar de IdP lid van is. Om dit mogelijk te maken publiceert novay.nl het volgende record: $ORIGIN Novay.nl. IN U NID2U+ 10 Kan dat?

17 Gebruikelijk is om in de federatiemetada een pointer op te nemen naar de authenticatieserver of IdP. De SP kan deze pointer dan gebruiker voor verdere DNS verzoeken. Indien gewenst kan ook via een record de authenticatieserver aangeduid worden: IN U NID2U+ In een hub model, waarbij de SP niet direct met de authenticatieserver van de gebruiker communiceert maar via een hub, kan dit voordelen hebben. Als alternatief resultaat van dit verzoek zou een servicebeschrijving van de authenticatieserver van de SURFfederatie kunnen zijn: _idp._tls.surffed.nl. Een RSV verzoek hiervoor zou dan de service URL kunnen opleveren dat weer middels een A verzoek te herleiden is tot een IP-adres. 2. De SP haalt de door SURFnet getekende federatiemetadata op van de verkregen locatie en kan deze gebruiken om te controleren of novay.nl lid is van de SURFfederatie. Deze controle gebeurt op basis van de handtekening over de metadata. Vervolgens moet de SP checken of de SURFfederatie.nl lid is van de confederatie edugain en doet daarom op basis van de locatie van de metadata een verzoek voor surffed.nl. Dit verzoek levert een URL waar de metadatafile staat van edugain waar de SURFfederatie lid van is. Immers, de SURFfederatie publiceert het volgende record: IN U NID2U+ 3. De SP haalt de confederatiemetadata primair bestaande uit een (URL) lijstje van aangesloten federaties en hun domein - op bij edugain.org en controleert of de SURFfederatie onderdeel is van edugain.org. Als dat zo is, en wetende dat hijzelf ook lid is van edugain.org 7, weet de SP dat hij SURFfederatie.nl kan vertrouwen. Deze derde stap kan overgeslagen worden als in de metadata van de SURFfederatie tags zijn opgenomen die ondertekend zijn door edugain.org. Hierdoor komt ook de edugain metadata file te vervallen. Hoewel deze file niet groot zal zijn (het bevat slechts een lijstje van deelnemende federaties) kan dit een voordeel zijn omdat virtuele organisaties als edugain vaak niet zitten te wachten op extra activiteiten als het centraal aanbieden van confederatie metadata. De tags, echter, zullen wel gecreëerd moeten worden door edugain en in de metadata van de aangesloten federaties opgenomen worden. Dit vereist wel weer een centrale coördinatie en activiteit van edugain. 4. Als alles klopt wordt het tijd om de eindgebruiker te authenticeren. Op basis van de SURFfederatie metadata weet de SP waar hij de eindgebruiker kan authenticeren: hij stuurt de SURFfederatie (idp.surffed.nl) een authenticatieverzoek voor iemand van novay.nl. Voordat de SURFfederatie de IdP van novay.nl vraagt hem te authenticeren, controleert deze eerst of de SP wel te vertrouwen is. Dat betekent dat de SURFfederatie identiek aan de op de hierboven geschreven wijze nagaat of de SP lid is van de SWITCH federatie en van edugain. Als dat inderdaad zo is zal de werknemer verzocht worden zich te authenticeren tegenover zijn IdP en zal het antwoord via de SURFfederatie hub teruggestuurd worden naar de SP. De werknemer krijgt dan de juiste rechten toegewezen en toegang tot de dienst. Als het niet klopt dan zal de eindgebruiker geen de toegang tot de dienst krijgen. Op deze manier hebben alle betrokken partijen antwoord gekregen op de drie vragen die aan het begin van deze sectie gesteld zijn. De bijbehorende berichtenstroom is afgebeeld in Figuur 4. 7 Deze aanname hoeft niet waar te zijn. Als de SP hierover in onzekerheid is kan hij bij zijn eigen federatie SWITCH een verzoek doen naar de metadatafile. Als de locatie van deze metadatafile bij edugain.org is dan weet de SP dat hij via SWITCH ook onderdeel uitmaakt van de edugain confederatie. Een alternatief scenario is dat de SWITCH federatiemetadata edugain tags bevat. Federatiemanagement met DNS en DNSSEC 11

18 Klaar als hier edugain tags in zitten novay.nl novay.nl? Novay zit in surffed SP DNS resolver surffed.nl? Surffed zit in edugain idp.surffed.nl A? DNS Waar moet ik zijn voor authenticatie? SURFfederatie Figuur 4: Gedistribueerde metadatadiscovery via DNS. Ook in dit scenario geldt dat alle DNS resultaten DNSSEC beveiligd zijn en dat SSL/TLS gebruikt wordt om de communicatiekanalen tussen de verschillende partijen te beveiligen. Deze aanpak heeft verschillende voor- en nadelen. De voordelen zijn dat: Iedere partij zijn eigen metadata beheert en publiceert. Dat edugain slechts een lijstje met aangesloten federaties hoeft bij te houden wat minimale overhead creëert. De nadelen zijn dat: De hele DNS hiërarchie beveiligd moet zijn. Er zijn oplossingen beschikbaar om dit te omzeilen maar dit zijn slechts lapmiddelen (zie sectie 3.6 voor meer hierover). De SP DNS client intelligent genoeg is om de juiste metadata op te halen en te interpreteren en te weten dat hij in dit geval een tweede lookup moet doen voor surffed.nl. Dit kan bijvoorbeeld door te kijken naar het flag veld U in. Dit geeft aan dat er geen verdere verzoeken gemaakt hoeven te worden. Als het flag veld niet ingevuld is, betekent dit dat vervolgverzoeken nodig te zijn. Dit is bijvoorbeeld het geval voor Novay.nl: Novay.nl PID2U+ De DNS client weet dan dat Novay.nl deel uit maakt van de SURFfederatie, maar nog niet van welke confederatie. Een vervolg verzoek is nodig om dit uit te vinden. Een alternatieve manier voor het afleiden van lidmaatschap is door edugain een beschermde zone te laten inrichten voor haar leden. Dat brengt ons bij de derde aanpak. 12 Kan dat?

19 3.5 Aanpak 3: Het inrichten van een beveiligde DNS zone Deze aanpak gaat er vanuit dat de confederatie operator een DNS zone inricht waarin alle aangesloten federaties hun resource records publiceren. De DNS zone manager bepaalt van welke partijen er resource records in staan. Verder levert de confederatie operator het trust anchor voor de sleutels die gebruikt worden voor het DNSSEC ondertekenen van de records in de zone. Een voorbeeld van een dergelijke DNS-zone voor edugain is afgebeeld in Figuur 5. edugain.org switch.ch.edugain.org surffed.nl.edugain.org sp.ch.switch.ch.edugain.org novay.nl.surffed.nl.edugain.org uva.nl.surffed.nl.edugain.org Figuur 5: DNSSEC beveiligde zone ingericht door edugain voor het resolven van metadata informatie. De aanname hier is dat edugain.org DNSSEC-enabled is. In zo n zone is het eenvoudig om (con)federatie lidmaatschap te checken volgens een <member>.<(con)federatie> structuur. Bijvoorbeeld surffed.nl.edugain.org. Op dezelfde manier kan worden gecontroleerd of novay.nl lid is van surffed.nl: novay.nl.surffed.nl. Als die 'listing' bestaat, dan is novay.nl dus lid van surffed.nl. Een andere manier om lidmaatschappen uit te drukken is het gebruik van subdomeinen onder edugain of surffed: surffed.nl.member_of.edugain.org of novay.nl.member_of.surffed.nl. De DNS hiërarchie die hierbij hoort is weergegeven in Figuur 6. member_of.edugain.org switch.ch surffed.nl member_of.switch.ch member_of.surffed.nl xx.ch yy.ch novay.nl uva.nl Figuur 6: DNS hiërarchie bij het gebruik van het member_of subdomein. Federatiemanagement met DNS en DNSSEC 13

20 Het gebruik van dit soort subdomeinen vergroot de herkenbaarheid; DNS clients kunnen dan eenvoudig de member_of elementen eruit filteren voor het checken van (con)federatielidmaatschappen. De nadelen zijn dat er enige afstemming tussen de verschillende partijen vereist is over de naamgeving van de subdomeinen en dat de vertrouwenshiërarchie wat minder duidelijk is. We zullen deze hiërarchie aanhouden in onze verder voorbeelden. De bijbehorende berichtenstroom om via deze DNS hiërarchie te bepalen of partijen lid zijn van dezelfde confederatie en om te achterhalen waar de eindgebruiker geauthenticeerd kan worden is weergegeven in Figuur 7. novay.nl novay.nl? Novay zit in surffed novay.nl.member_of.surffed.nl _idp._tls.surffed.nl surffed.nl? Surffed zit in edugain SP DNS resolver surffed.nl.member_of.edugain.org _idp._tls.surffed.nl? idp.surffed.nl DNS Waar moet ik hem authenticeren? idp.surffed.nl A? SURFfederatie Figuur 7: Het checken van confederatie lidmaatschap via een gemanagede DNS-zone. Een korte toelichting: 1. De SP vraagt de eindgebruiker om de URL van zijn/haar werkgever: novay.nl 8 2. De SP doet een verzoek voor novay.nl bij DNS 3. Het resultaat is dat novay.nl lid is van de SURFfederatie: novay.nl.member_of.surffed.nl. 4. De SP doet vervolgens een verzoek voor surffed.nl. 5. Het resultaat is dat surffed.nl lid is van edugain: surffed.nl.member_of.edugain.org. Omdat de SP weet dat ze via SWITCH zelf ook participeert in edugain is het duidelijk voor haar geworden dat novay.nl te vertrouwen is. 6. Het spreekt voor zich dat de SURFfederatie hetzelfde doet om te controleren of de SP ook tot edugain behoort voordat het overgaat tot het communiceren van persoonsgegevens. De volgende stap betreft het authenticeren van de eindgebruiker. Dit kan op verschillende manieren gedaan worden: 1. De SP krijgt bij het verzoek voor novay.nl een pointer naar de identity server van de SURFfederatie. Vervolgens kan via en A verzoeken het IP-adres van de betreffende server bij SURFnet achterhaald worden. Dit is weergegeven in bovenstaande Figuur De SP krijgt bij het verzoek aan novay.nl ook een pointer naar de metadatafile van de SURFfederatie. Uit de metadata kan de SP dan halen waar de eindgebruiker geauthenticeerd moet worden. Deze variant komt overeen met de in Aanpak 2 beschreven berichtenuitwisseling (zie Figuur 4). 8 Dit kan ook op basis van een adres maar vanuit privacy oogpunt is besloten voor een URL te kiezen. De SP hoeft niet noodzakelijkerwijs de identiteit van de gebruiker te weten; het kan voldoende zijn te weten dat het iemand van Novay is. 14 Kan dat?

21 Het voordeel van deze derde aanpak is dat veel metadata informatie impliciet verwerkt is in de DNS hiërarchie: welke SPs en IdPs in de federatie zitten en wat hun endpoints zijn. Dit soort metadata hoeft dus niet meer verzameld en gepubliceerd te worden. Echter, de SAML Metadata specificatie beschrijft veel meer metadata elementen die het endpoint verder beschrijven (contactpersoon, rol) en die iets zeggen over de metadata zelf (geldigheid). Ook certificaten maken deel uit van de metadata. Als dit soort metadata van belang is binnen de confederatie betekend het dat er nog steeds metadata uitgewisseld moet worden. Dit kan via het publiceren van een link naar een metadatafile via DNS zoals in Aanpak 2 is beschreven. Bijvoorbeeld, een alternatief is om dit soort metadata ook in DNS te stoppen via TXT en records. Een contactpersoon voor het verkrijgen van metadata informatie kan makkelijk via een TXT record aangeboden worden 9. Het zelfde geldt voor het resolven van certificaten uit DNS middels verzoeken. Het opslaan van certificaten van aangesloten partijen in een door edugain beheerde DNS zone heeft nog andere voordelen. Een SP kan via een verzoek het certificaat van een IdP resolven en daaruit afleiden dat deze IdP in edugain zit. Daarnaast kan het certificaat gebruikt worden ter verificatie van de TLS verbindingen [12]: is het certificaat dat gebruikt is tijdens het opzetten van de TLS verbinding identiek aan het certificaat dat is geresolved uit DNS? Beide partijen kunnen dit doen en als de verificatie klopt dan zijn ze in ieder geval zeker dat ze met een partij uit dezelfde confederatie communiceren en elkaar dus kunnen vertrouwen. Het uitwisselen van certificaten via DNS is weergegeven in Figuur 8. idp.surffed.nl A? SP DNS resolver idp.surffed.nl? X.509: RSA Public Key: O8:A8:F7 DNS Controle SURFfederatie Figuur 8: Certificaatvalidatie via DNSSEC. Ook deze aanpak kent weer een aantal voor en nadelen. De voordelen zijn: De confederatie operator heeft de volledige controle heeft over de DNS zone en bepaalt wie erin komen te staan en wie eruit moet. Het toepassen van DNSSEC over deze zone is haalbaar en biedt de vereiste betrouwbaarheid van de gegevens uit de zone. Er kan meteen begonnen worden met het ondertekenen van de zone zonder dat er gewacht hoeft te worden tot DNS in zijn geheel ondertekend is. Met records kan een extra check ingebouwd worden. De nadelen zijn: Zit de confederatie operator te wachten op het beheren en tekenen van een DNS zone? DNSSEC sleutelmanagement is niet evident. Het wijzigen van een DNS-record is eenvoudig, maar het moet daarna wel weer getekend worden. Al met al dus relatief veel overhead voor de confederatie operator. 9 Mogelijk zal hiervoor enige standaardisatie nodig zijn. De IETF kan hierbij een rol spelen. Federatiemanagement met DNS en DNSSEC 15

22 Het ondertekenen van een zone kan resulteren in zogenaamde Islands of Trust. Als t.z.t. hoger in de DNS hiërarchie DNSSEC wordt gebruikt er twee trust anchors ontstaan (die van.edugain en die van.org bijvoorbeeld) waardoor de DNS resolver in de problemen kan komen: wie te vertrouwen? Mogelijk valt dit met goed configureren en prioriteren van trust anchors wel op te lossen maar het vereist wel aandacht. Er vertrouwensconflicten kunnen ontstaan tussen de DNSSEC beveiligde zone en de certificaten van de partijen daarin. De operator hoeft bijvoorbeeld geen vertrouwen te hebben in de uitgever van het certificaat dat in de door hem beheerde zone staat. Het bovenstaande scenario loopt mis als Novay in meerdere federaties zit en/of de SURFfederatie/SWITCH in meerdere confederaties participeert. De DNS-clients aan beide kanten hebben dan niet voldoende informatie om tot een juist antwoord te komen en het risico bestaat dat de eindgebruiker onder een andere federatie dan gewenst toegang krijgt tot de benaderde dienst. Dit kan van invloed zijn op de rechten en kosten van de eindgebruiker betreffende het gebruik van de dienst. Een oplossing om dit te voorkomen is de eindgebruiker te vragen onder welke federatie hij de dienst wil benaderen. Hierbij is het de vraag of de eindgebruiker voldoende begrijpt van wat er gevraagd wordt; niet iedereen zal weten dat hij onder de vlag van een bepaalde federatie handelt. Een andere oplossing is gebruik te maken van prioriteiten; de (con)federatie met de hoogste prioriteit geniet de voorkeur. voorziet hierin. Waarschijnlijk zal de IdP de prioritering aangeven, daarbij wel de opties van de gebruiker uitsluitend. Daarnaast ligt het voor de hand om de toegang dienst-specifiek te maken. Het type dienst bepaalt welke en hoeveel confederaties het vertrouwen genieten. Het is niet ondenkbaar dat voor een document service voor bijvoorbeeld studiemateriaal toegang via slechts één confederatie mogelijk is: de onderwijsconfederatie. Immers de eigenaar van de service zal niet zomaar gebruikers toegang verlenen met credentials van IdPs uit een andere (zeg commerciële) confederatie. Voor een gepersonaliseerde dienst ligt het voor de hand dat meerdere confederaties hierin kunnen voorzien. Hier ligt de nadruk veel minder op het verlenen van toegang om de content te beschermen maar meer op het personaliseren van de dienst. Waar precies de attributen vandaan komen voor de personalisatie is van minder belang. Een oplossing voor dit multi-(con)federatie probleem is de DNS zone structuur iets anders in te richten door een hoger federatie root domein te creëren en multihoming toe te passen. In plaats van te opteren voor een enkele door de confederatie operator gemanaged zone kan ook van een root domein voor alle confederaties en federaties uitgegaan worden. Door multihoming toe te staan kunnen partijen in verschillende zones onder de root opereren. Een scenario-specifieke illustratie van de bijbehorende DNS hiërarchie is weergegeven in Figuur Kan dat?

23 feds.org edugain.org surffed.nl switch.ch surffed.nl novay.nl uva.nl Figuur 9: DNS structuur met federatie root domein en multihoming. Onder het root domein feds.org, bevinden zich bijvoorbeeld de confederatie edugain.org en de federatie surffed.nl (en switch.ch). Binnen surffed.nl.feds.org staat dan weer een entry voor novay.nl(.surffed.nl.feds.org). In bijvoorbeeld de surffed.nl entry onder feds.org bevinden zich pointers naar surffed.nl.edugain.org. Op deze manier kan eenvoudig afgeleid worden in welke federatie novay.nl zich bevindt en in welke confederatie de gevonden federatie zich op zijn beurt weer bevindt. Vertrouwensrelaties kunnen dus eenvoudig op basis van de zone structuur afgeleid worden en nieuwe confederaties en/of federaties kunnen snel toegevoegd worden. Dit gaat wel ten koste van een toenemende DNS overhead en complexiteit voor de federaties omdat ze DNS entries in meerdere subdomeinen moeten managen waardoor de kans op fouten toeneemt. Daarnaast geldt ook hier dat het inrichten van een root domein over federaties en confederaties heen vereist is en het onduidelijk is wie dat gaat doen en of deze partij hiervoor voldoende geautoriseerd is. Het service veld van het record kan helpen eenvoudig(er) af te leiden of een partij onderdeel van een federatie. Bijvoorbeeld: Surffed.nl U PID2U U PID2U+ De fed service veld indicatie maakt het voor de DNS client eenvoudig mogelijk af te leiden (en eventueel te onthouden) van welke federaties een partij lid is. In het bovenstaande voorbeeld is surffed.nl lid van eduroam.org en feds.org. Als de DNS client een eigen fed lijstje heeft van federaties waarin hijzelf participeert kan eenvoudig gecontroleerd worden of er een match is, ofwel, dat beide partijen in dezelfde (con)federatie participeren. Indien er sprake is van lidmaatschap in meerdere (con)federaties kan via het order veld van het record de voorkeur uitgesproken worden betreffende welke federatie de voorkeur geniet. Het gebruik van het fed service veld op deze manier vereist wel standaardisatie en adoptie van het veld over alle (con)federaties heen. Federatiemanagement met DNS en DNSSEC 17

24 3.6 Aanpak 4: Een onafhankelijke DNS hiërarchie Deze aanpak bestaat uit het opzetten van een volledig onafhankelijke hiërarchie met aparte, eigen confederatiespecifieke DNS servers. De DNS en DNSSEC protocollen worden dan gebruikt om tussen deze eigen servers confederatie informatie uit te wisselen. Meeliften op de protocollen dus, zonder alles in de wereldwijde hiërarchie te hangen. Het voordeel hiervan is dat er een volledige controle is over de vertrouwensrelaties. Het nadeel is dat alle partijen hun eigen DNS servers voor een confederatie moeten optuigen. Daarnaast kan waarschijnlijk hetzelfde doel bereikt worden door een confederatiespecifieke PKI uit te rollen. Beide modellen lijken onrealistisch. 3.7 Discussie Welke aanpak? Het op een veilige manier vinden van federatiemetadata kan gefaciliteerd worden door DNS en DNSSEC. DNS biedt de mogelijkheid om federatiemetadata informatie op te slaan en aan te bieden; DNSSEC biedt de mogelijkheid om dit op een betrouwbare manier te doen. Afhankelijk van de manier van aanbieden van de metadata kunnen hiervoor de - of -records gebruikt worden. Meerdere DNS implementatie-aanpakken zijn mogelijk waarbij verschillende resource records gebruikt kunnen worden. Aanpak 1 valt af omdat niet verwacht kan worden dat federatieleden confederatiemetadata gaan bijhouden en publiceren. Het zelfde geldt eigenlijk voor Aanpak 4 waarin een eigen confederatiespecifieke DNS/DNSSEC infrastructuur wordt opgetuigd. Hoewel dit misschien wel de meest betrouwbare (controleerbare) aanpak is, zal het in de praktijk nooit gaan werken omdat het te duur is en erg veel medewerking vraagt van alle partijen. Aanpak 2 is voor de lange termijn interessant als DNS in zijn geheel getekend is. Om dit obstakel te omzeilen zijn er verschillende tijdelijke oplossingen die ingezet kunnen worden. IANA bijvoorbeeld biedt een Interim Trust Anchor Repository (ITAR, [14]) aan die de uitwisseling van sleutelmateriaal mogelijk maakt om DNSSEC top level verificatie te doen bij het ontbreken van een ondertekende root zone. Dit is een tijdelijke dienst totdat de root zone getekend is waarna het sleutelmateriaal naar de root zelf verplaatst wordt. De dienst bevindt zich nog in een bèta versie en wordt voornamelijk gebruikt om te oefenen voor een getekende root zone. Een variant hierop is DNSSEC Lookaside Validation (DLV, [15]). DLV biedt een repository van sleutels van verschillende ondertekende zones (waaronder bijvoorbeeld de ITAR inhoud). Hierdoor hoeven DNSSEC resolvers zelf niet meer al het sleutelmateriaal van de verschillende zones te configureren. Beide oplossingen zijn lapmiddelen die, naast dat ze weinig efficiënt zijn, ook nog eens vertrouwen vereisen in de aangeboden repositories (vooral bij DLV). Dan loont het misschien de moeite te wachten tot de root zone ondertekend gaat worden. De eerste testen hiervoor staan gepland voor december. Daarnaast rijst de vraag wat de meerwaarde van een geheel getekend DNS nu precies is. Het zorgt ervoor dat de gegevens uit DNS authentiek en integer zijn, maar zegt niets over de betrouwbaarheid ervan. Enige confederatie vertrouwenscontext hieromtrent ontbreekt in de tweede aanpak. Er wordt hierbij geheel vertrouwd op DNSSEC wat impliceert dat een of andere root CA vertrouwd wordt. Dit is misschien onvoldoende en het is niet onaannemelijk dat meer federatiespecifieke vertrouwenselementen nodig zullen zijn. Dit zou bijvoorbeeld geïntroduceerd kunnen worden door een PKI waarmee de metadatafiles beveiligd kunnen worden of door de toegang tot de metadata te beperken tot de partijen in de confederatie. Dan zou DNS voldoende zijn voor het vinden en uitwisselen van de metadata en dan zou het vertrouwen ervan geborgd worden door de PKI of toegangscontrole. Maar in plaats van DNS kan net zo goed een well-known location gebruikt worden voor het publiceren van de metadata (zie ook [2]). Ook voor deze alternatieve oplossing spelen zaken als de authenticiteit en integriteit van de well-known location en die worden in de DNSSEC aanpak juist mooi opgelost. Natuurlijk zijn er ook out-of-band oplossingen voor het uitwisselen van metadata maar die schalen slecht en zijn vaak weinig veilig. 18 Kan dat?