Federatiemanagement met DNS en DNSSEC: kan dat?

indi-2009-12-014

Federatiemanagement met DNS en DNSSEC: kan dat? Project Projectjaar Projectmanager Auteur(s) Opleverdatum Versie

: SURFtrust in het kader van SURFworks : 2009 : Remco Poortinga-van Wijnen : Bob Hulsebosch, Henk Eertink : Q4 2009 : 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 http://creativecommons.org/licenses/by/3.0/

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.

Colofon Programmalijn: Onderdeel: Activiteit: Deliverable: Toegangsrechten: Externe partij:

SURFworks SURFfederatie PoCs: Vertrouwen op grote(re) schaal 5.1.2 Detailstudie “Onderzoek naar methoden voor vertrouwen op grote(re) schaal” Publiek Novay, www.novay.nl

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 (www.surf.nl).

Voor deze publicatie geldt de Creative Commons Licentie “Attribution 3.0 Unported”. Meer informatie over deze licentie is te vinden op http://creativecommons.org/licenses/by/3.0/

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?

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 wie is het?

Voor alle partijen (IDPs, SPs en operators) in federaties en con-federaties.

Hoe werkt het?

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.

Wat kan je ermee?

Metadata uitwisselen behulp van de bestaande DNS infrastructuur om daarmee eenvoudig en inzichtelijk federaties en con-federaties te vormen.

Inhoudsopgave 1

2

Inleiding

1

1.1

Confederatie en metadata

1

1.2

Doelstelling en aanpak

2

DNS en DNSSEC voor federatiemanagement

3

2.1

3

2.2

2.3 3

DNS RR 2.2.1 SRV 2.2.2 NAPTR 2.2.3 CERT 2.2.4 TXT 2.2.5 Samenvatting DNSSEC

3 3 3 4 5 5 5

Toepassingen van DNS voor geconfedereerd identiteitsmanagement

9

3.1

Gerelateerd werk

9

3.2

Een confederatiescenario

9

3.3

Aanpak 1: De IdP publiceert de confederatiemetadata

10

3.4

Aanpak 2: Gedistribueerde metadata

10

3.5

Aanpak 3: Het inrichten van een beveiligde DNS zone

13

3.6

Aanpak 4: Een onafhankelijke DNS hiërarchie

18

3.7

4

DNS

Discussie 3.7.1 Welke aanpak? 3.7.2 DNSSEC voldoende?

Conclusies

Referenties

Federatiemanagement met DNS en DNSSEC

18 18 19 22 24

V

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?


1

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?

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 SRV (voor het aanduiden van diensten), CERT (voor o.a. PKIX doeleinden), NAPTR (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.

2.2.1

SRV

Naast het vertalen van domeinnamen in IP-adressen kan DNS ook gebruikt worden om diensten te vinden in een netwerk. Het DNS Service of SRV record kan gebruikt worden voor het aanduiden van diensten in een bepaald domein [3]. Het SRV record heeft over het algemeen de volgende vorm: _Service._Protocol.DomainName TTL IN SRV Priority Weight Port Target Het volgende voorbeeld verklaart de meeste termen in het SRV-record: _sip._tcp.example.com. 86400 IN SRV 0 5 5060 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 86400 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 SRV 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 (DNSSD) ontwikkeld [4]. DNS-SD maakt ook gebruik van SRV-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 SRV-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.

2.2.2

NAPTR

Mogelijk is de Name Authority Pointer (NAPTR record) hiervoor een goede aanvulling. Dit record bevat geen IP-adres maar contactgegevens van de betreffende partij. De vorm van NAPTR is als volgt: $ ORIGIN foo.com order pref flags

service

regexp


replacement

3

IN NAPTR 100

100

"s"

"http+I2R"

""

_http._tcp.foo.com.

NAPTR maakt het mogelijk om informatie, zoals bijvoorbeeld federatiemetadata, te vinden. De SAML metadata specificatie geeft al aan dat hiervoor het beste het NAPTR-record gebruikt kan worden [5]. Met NAPTR 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 NAPTR ook aangegeven worden waar bijvoorbeeld de eindgebruiker te authenticeren is. Het vinden en aanroepen van de service gaat dan weer via een SRV-record. Liberty Alliance heeft het gebruik van DNS en NAPTR voor het publiceren en ophalen van metadata al eens beschreven [6]. Enkele voorbeelden van de in deze specificatie beschreven service velden zijn:  PID2U1+https:entity – representeert een entity metadatadocument dat via het https protocol benaderd kan worden.  PID2U+https:entity:si:pip – 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+https:entitygroup:idp – geeft de metadata voor een groep entiteiten waarvan providerID een lid is. De metadata beschrijft de IdPs in de groep.  NID2U2+https:idp – geeft een IdP providerID welke authenticatiediensten voor een principal kan leveren.  NID2U+https:authn – levert een URL op voor het authenticeren van een principal. Provider metadata NAPTR voorbeelden zijn dan: $ORIGIN provider.biz IN NAPTR 100 10 "U" PID2U+https:entity "!^.*$!https://host.provider.biz/some/directory/trust.xml!" "" IN NAPTR 110 10 "U" PID2U+https:entity:trust "!^.*!https://foo.provider.biz:144 3/mdtrust.xml!" "" IN NAPTR 110 10 "U" PID2U+uddi:entity "!^.*$ !https://this.uddi.node.provider.biz/libmd.wsdl" "" Name Identifier ofwel principal of IdP NAPTR voorbeelden zijn dan: $ORIGIN example.int. IN NAPTR 100 10 "U" NID2U+https:authn "!^([^@]+)@(.*)$!https://serv.example.int:8000/cgi -bin/getmd?\1!" "" IN NAP TR 100 10 "U" NID2U+https:idp "!^([^@]+)@(.*)$!https://auth.example.int/app/auth?\1" "" Waarbij de reguliere expressies aangeven hoe het record herschreven moet worden voor verder gebruik. In de bovenstaande NAPTR voorbeelden wordt bijvoorbeeld uit het e-mail adres van [email protected] de extensie example.int geëxtraheerd en via !^([^@]+)@ (.*)$ herschreven in https://auth.example.int/app/auth/user.

2.2.3

CERT

Het DNS CERT 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 CERT record is als volgt: name john 1 2

4

ttl

class IN

rr CERT

type 1

key tag 12179

algorithm 1

cert or crl (AQPmn12…dirQ)

PID2U resolvet een providerID identifier metadata URL. NID2U resolvet een nameIdentifier (principal) metadata URL.

Kan dat?

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.

2.2.4

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 sam.widgets.com

IN TXT "printer=lpr5" 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: idp.surffed.nl IN TXT “confederation=edugain” of of

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.

2.2.5

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 SRV-records, voor pointers naar de data of diensten NAPTR-records. De combinatie van NAPTR en SRV 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 CERT 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.


5

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)

www.surffed.nl A 130.59.138.34

nl.RRSIG DS…

surffed.nl.RRSIG DS…

www.surffed.nl RRSIG A

signed met private root key

signed met private .nl key

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?

w ww

root

w ww

d rff e . su

d rff e . su

.nl

?

Lokale DNS Server

2 Geldig

.nl

?

3

w surffed.nl w

ww

Ongeldig

urf w.s

fed

fe urf w.s

d.n

l?

1

4

.nl

novay.nl

Geldig

5

? .nl Ongeldig

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.


7

root

org

com

isc

verisign

nl

se

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 aanvallen4 en geen confidentialiteit5. 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?

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 certificaten6[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 SRV-records alleen zoals gedaan wordt in DNS-SD waarschijnlijk niet voldoende voor het vinden van metadata en diensten over federaties heen. NAPTR 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].


9



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 NAPTR, SRV en CERT? 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 NAPTR 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 e-mail adres of URL van de universiteit is. Op grond hiervan kan de SP via een NAPTR verzoek nagaan of Novay onderdeel uitmaakt van de eduGAIN confederatie. Immers Novay.nl publiceert de volgende metadata URL: $ORIGIN novay.nl IN NAPTR 100 10 “U” PID2U+https:entity “!^.*!https://host.edugain.org/some/directory/confmetadata.xml!” “” 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 NAPTR 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 NAPTR 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 NAPTR record: $ORIGIN Novay.nl. IN NAPTR 100 10 “U” NID2U+https:entity:si:fed

10

Kan dat?

“!^([^@]+)@(.*)$!https://fed.surffed.nl:8000/cgi-bin/getmd?\1!””” 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 NAPTR record de authenticatieserver aangeduid worden: IN NAPTR 100 10 “U” NID2U+https:idp “!^([^@]+)@(.*)$!https://idp.surffed.nl/saml/auth?\1”””

2.

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 NAPTR 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. 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 NAPTR 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 NAPTR record: IN NAPTR 100 10 “U” NID2U+https:entity:si:fed “!^([^@]+)@(.*)$!https://fed.edugain.org:8000/cgi-bin/getconfmd?\1!”””

3.

4.

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.org7, 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. 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 NAPTR 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.


11

Klaar als hier edugain tags in zitten novay.nl NAPTR?

novay.nl

Novay zit in surffed

www.surffed.nl/fedmetadata.xml SP DNS resolver surffed.nl N APTR?

Surffed zit in edugain

ww w.edugain.org/confedmetadata.xml DNS idp.surffed.nl A?

Waar moet ik zijn voor authenticatie?

10.10.0.200

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 NAPTR lookup moet doen voor surffed.nl. Dit kan bijvoorbeeld door te kijken naar het flag veld “U” in NAPTR. Dit geeft aan dat er geen verdere NAPTR 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 NAPTR 10 100 “..” “PID2U+https:fed” “!^.*$!http://surffed.nl/!” De DNS client weet dan dat Novay.nl deel uit maakt van de SURFfederatie, maar nog niet van welke confederatie. Een vervolg NAPTR 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?

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 edugain.org

sp.ch.switch.ch.edugain.org sp.ch.switch.ch.edugain.org SRV SRV

NAPTR NAPTR

switch.ch.edugain.org switch.ch.edugain.org

surffed.nl.edugain.org surffed.nl.edugain.org

SRV SRV

SRV SRV

NAPTR NAPTR

CERT CERT

NAPTR NAPTR

novay.nl.surffed.nl.edugain.org novay.nl.surffed.nl.edugain.org

CERT CERT

SRV SRV

NAPTR NAPTR

CERT CERT

uva.nl.surffed.nl.edugain.org uva.nl.surffed.nl.edugain.org

CERT CERT

SRV SRV

NAPTR NAPTR

CERT CERT

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 member_of.edugain.org switch.ch switch.ch SRV SRV

NAPTR NAPTR

surffed.nl surffed.nl CERT CERT

SRV SRV

member_of.switch.ch member_of.switch.ch xx.ch xx.ch SRV SRV

NAPTR NAPTR

SRV SRV

CERT CERT

member_of.surffed.nl member_of.surffed.nl novay.nl novay.nl

yy.ch CERT CERT

NAPTR NAPTR

CERT CERT NAPTR NAPTR

SRV SRV


uva.nl uva.nl SRV SRV


Figuur 6: DNS hiërarchie bij het gebruik van het member_of subdomein.


13

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 NAPTR?

novay.nl

novay.nl.member_of.surffed.nl _idp._tls.surffed.nl

Novay zit in surffed

surffed.nl NAPTR? SP DNS resolver

Surffed zit in edugain

surffed.nl.member_of.edugain.org _idp._tls.surffed.nl SRV? DNS idp.surffed.nl

Waar moet ik hem authenticeren?

idp.surffed.nl A? 10.10.0.200

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.nl8 2. De SP doet een NAPTR 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 NAPTR 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 NAPTR verzoek voor novay.nl een pointer naar de identity server van de SURFfederatie. Vervolgens kan via SRV en A verzoeken het IP-adres van de betreffende server bij SURFnet achterhaald worden. Dit is weergegeven in bovenstaande Figuur 7. 2. De SP krijgt bij het NAPTR 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 e-mail 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?

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 CERT records. Een contactpersoon voor het verkrijgen van metadata informatie kan makkelijk via een TXT record aangeboden worden9. Het zelfde geldt voor het resolven van certificaten uit DNS middels CERT verzoeken. Het opslaan van certificaten van aangesloten partijen in een door eduGAIN beheerde DNS zone heeft nog andere voordelen. Een SP kan via een CERT 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 D NS resolver

10.10.0.200

idp.surffed.nl CERT? DNS X.509: RSA Public Key: O8:A8:F7…

Controle SUR Ffederatie

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 CERT 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.


15





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. NAPTR 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 9.

16

Kan dat?

feds.org feds.org SRV SRV

edugain.org edugain.org SRV SRV

NAPTR NAPTR

switch.ch switch.ch SRV SRV

NAPTR NAPTR

NAPTR NAPTR

CERT CERT

CERT CERT

SRV SRV

surffed.nl surffed.nl CERT CERT

SRV SRV

NAPTR NAPTR

surffed.nl surffed.nl NAPTR NAPTR

novay.nl novay.nl CERT CERT

SRV SRV

NAPTR NAPTR

CERT CERT

uva.nl uva.nl CERT CERT

SRV SRV

NAPTR NAPTR

CERT CERT

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 NAPTR record kan helpen eenvoudig(er) af te leiden of een partij onderdeel van een federatie. Bijvoorbeeld: Surffed.nl. NAPTR 10 100 “U” “PID2U+https:fed” “!^.*$!http://eduroam.org/!” NAPTR 20 100 “U” “PID2U+https:fed” “!^.*$!http://feds.org/!” 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 NAPTR 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.


17

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 3.7.1

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 SRV- of NAPTR-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?

De derde Aanpak 3 is als een tussentijdse oplossing realistisch. In de bij deze aanpak benodigde goed ingerichte DNS zone is het zelfs mogelijk om federatie en confederatie lidmaatschapcontroles te doen op basis van de URL listings zonder dat er sprake is van metadatafiles. Partijen verwijzen dan in hun records naar overkoepelende partijen hogerop in de DNS hiërarchie. De DNS hiërarchie weerspiegelt dan op impliciete manier de confederatie en federatie relaties. Als additionele metadata gewenst is dan zal er nog steeds een metadatafile uitgewisseld moeten worden. Dit kan natuurlijk weer via verwijzingen in de vorm van NAPTR records. In Aanpak 3 is, door het inrichten en beveiligen van een confederatiespecifieke DNS-zone wel sprake van een vertrouwensstructuur die confederatiespecifiek is. Partijen kunnen al op basis van de zoneindeling zien of ze elkaar kunnen vertrouwen. DNSSEC is van toegevoegde waarde om de integriteit en authenticiteit van de DNS records te borgen zodat er altijd zekerheid is dat partijen uit een confederatie met elkaar communiceren en niet met een partij van buiten. Mogelijk biedt de zone voldoende houvast voor partijen om met elkaar te communiceren en is additionele metadata en de uitwisseling ervan niet nodig. Dan is Aanpak 3 erg aantrekkelijk. Indien er toch additionele metadata nodig is komen weer andere oplossing als een PKI of gecontroleerde toegang tot de metadatafile weer in beeld als alternatieven. We merken op dat de praktijk heeft geleerd dat deze alternatieven niet altijd even succesvol zijn (zie bijvoorbeeld de continue discussie over metadata uitwisseling in eduGAIN). De DNS en DNSSEC aanpak is daarom een interessante oplossingsrichting die het proberen waard is. Voor zowel Aanpak 2 en 3 is een behoorlijk intelligente DNS-client vereist die zowel aan de SP als IdP/hub kant in staat is om de antwoorden uit DNS te interpreteren en te controleren of ze convergeren naar een gemeenschappelijk vertrouwenspunt (eduGAIN). Daarnaast kan het deel uitmaken van meerdere federaties van de IdP of SP roet in het eten gooien: er treedt dan geen convergentie op naar een gemeenschappelijk vertrouwenspunt of de eindgebruiker krijgt toegang tot de dienst in de context van een verkeerde federatie. Een proof-of-concept implementatie kan uitsluitsel geven of de gewenste DNS-client te realiseren is, of de SRV/NAPTR aanpak schaalt, en welke combinatie van SRV/NAPTR records hiervoor het beste geschikt is.

3.7.2

DNSSEC voldoende?

Biedt DNSSEC voldoende vertrouwen voor gegevensuitwisseling tussen IdPs en SPs in een confederatie of zijn er additionele maatregelen nodig? Uit de bovenstaande beschreven aanpakken volgt dat met DNS/DNSSEC het volgende bereikt kan worden:  Het betrouwbaar vinden van de locatie van de metadata file van een federatie en/of van een confederatie. DNSSEC garandeert de authenticiteit van de locatie-informatie. Metadata hoeft hierdoor niet meer centraal verzameld te worden en kan door de betreffende partijen zelf beheerd en aangeboden worden.  Het weerspiegelen van de confederatiestructuur in de DNS hiërarchie. Confederatie lidmaatschap checks kunnen op deze manier via DNS gedaan worden. Bijkomend voordeel is dat de metadatafile zelf slechts configuratie-informatie hoeft te bevatten en daardoor veel minder belangrijk wordt als basis voor vertrouwen. Het op een betrouwbare manier vullen van de DNS zone(s) met resource records is minder eenvoudig op te lossen. Hiervoor zal een veilig out-of-band kanaal nodig zijn.  Het borgen van de integriteit van de metadatafile zelf en het veilig ophalen ervan door SP of IdP. De integriteit van de metadatafile zelf kan afgeleid worden uit de handtekening die eronder staat. Dit kan een handtekening zijn van de confederatie operator, de federatie operator of zelfs een individuele SP of IdP. Het vertrouwen in de certificaten waarmee deze handtekeningen gezet zijn kan gecreëerd worden door certificaten in DNS op te slaan en te beveiligen. Door middel van het CERT record kan het certificaat van de betreffende partij opgehaald worden waarmee het mogelijk wordt om de handtekening onder de metadatafile te verifiëren. De zelfde handeling kan uitgevoerd worden om het certificaat te verifiëren dat gebruikt is tijdens het opzetten van een TLS verbinding voor het veilig communiceren van de file. Hierbij wordt er vanuit gegaan dat de certificaten die gebruikt worden voor het ondertekenen van de metadatafile en voor het veilig communiceren ervan identiek zijn aan degene die zijn opgeslagen in DNS. Bijkomend voordeel van het opslaan van DNSSEC getekende certificaten in DNS is dat dit ook self-signed certificaten kunnen zijn. Dat maakt het voor veel partijen wat makkelijker om mee te doen.


19

Een PKI oplossing kan als alternatief ingezet worden om de integriteit en confidentialiteit van de metadata te garanderen. Het nadeel van een PKI is dat dit slecht werkt over domeinen heen (iets wat typisch het geval is in een confederatie) en dat het duur is (aanschaf en beheer van certificaten). Nog een andere manier is om het vertrouwen via de metadata zelf creëren. Dit kan op de volgende manieren:  Het borgen van vertrouwen door certificaten van federaties in de confederatie metadata op te nemen. De moeilijkheid hierbij zit in het veilig verzamelen van alle certificaten door de confederatie operator. Dit probleem is te vergelijken met het veilig ‘vullen’ van de DNS zone.  Het borgen van vertrouwen door tags (door de confederatie operator ondertekende elementen) in de federatie metadata file op te nemen. Ook hier geldt dat het veilig verkrijgen van de tags niet eenvoudig is. Het vinden van de metadata file kan ook via het publiceren van een zogenaamde Well-Known Location (WKL). De SAML metadata specificatie beschrijft deze oplossing als een alternatief voor DNS. Een pointer naar een WKL kan bijvoorbeeld gebaseerd zijn op het SAML entityID element. De betrouwbaarheid van de pointer wordt nergens gegarandeerd en is gebaseerd op de authenticiteit van het SAML metadatafile. De onderstaande tabel vat de mogelijkheden van de verschillende oplossingen samen. Oplossing DNS & DNSSEC

Vinden van de metadata Via DNS, en de authenticiteit van de lokatie met DNSSEC.

Voordelen

Maakt hergebruik van de bestaande bewezen DNS/DNSSEC infrastructuur

Nadelen

Configureren DNS records en DNSSEC key management complex

In de metadata zelf

Via het publiceren van een WellKnown Location waar de metadata te vinden is.

20

Lidmaatschap check Via de door de confederatie operator beheerde en beveiligde DNS zone. Duidelijke hiërarchische structuur. Operator bepaalt wie er in de zone staan waardoor herroeping eenvoudig is. Inrichten van de zone nodig. Hoe krijg je de inhoud van de resource records veilig in de zone? Aparte, intelligente DNS software nodig voor het verwerken van de records. Via de in de metadata file aanwezige certificaten of tags.

Integriteit van de metadata Via verificatie met een uit DNS opgehaald certificaat.

Confidentialiteit van de metadata Via verificatie met een uit DNS opgehaald certificaat.

Betrouwbare manier om certificaten te vinden. Gebruik van selfsigned certificaten ook mogelijk.

Betrouwbare manier om certificaten te vinden. Gebruik van selfsigned certificaten ook mogelijk.

Ingewikkeld; veel DNS queries nodig en aanpasssing van het standaard TLS protocol.

Ingewikkeld; veel DNS queries nodig en aanpasssing van het standaard TLS protocol.

Via een PKI.

Via een PKI.

Kan dat?

Voordelen

Nadelen

Wordt nu ook al gedaan en is gespecificeerd in Dynamic SAML [16]. Lagere drempel voor adoptie door gebruik van EntityIDs in de vorm van URLs. Garanties over de authenticiteit van de Well-Known Location zijn moeilijk te geven.

Controle van de certificaten of tags wordt meegenomen in de algehele XMLfile verwerking; geen extra/aparte software nodig wat bij DNS wel het geval is. Hoe krijg je de certificaten of tags op een veilige en beheersbare manier in de metadata?


Is een standaard proces. Verder weinig echte voordelen in de context van confederaties omdat een PKI slecht schaalt over domeinen heen (zie nadelen). Bijhouden van trust anchor lists door elke partij waarin staat welk certificaat te vertrouwen is.

Is een standaard proces. Verder weinig echte voordelen in de context van confederaties omdat een PKI slecht schaalt over domeinen heen (zie nadelen). Bijhouden van trust anchor lists door elke partij waarin staat welk certificaat te vertrouwen is.

21

4 Conclusies DNS is een geschikt medium om (con)federatie metadata te vinden. Het aanbieden van de metadata kan zo op een gedistribueerde manier gebeuren en over domeingrenzen heen. Dat wil zeggen, verschillende partijen bieden de federatie- en confederatiemetadata aan. Opslaan van metadata in DNS is niet nodig. Een vereiste is dat de via DNS verkregen pointers naar metadata betrouwbaar moeten zijn. DNSSEC biedt hiervoor een oplossing. De aanpak waarin het hele DNS getekend is, is misschien wel de meest aantrekkelijke omdat dit voor de confederatie operator de meeste voordelen oplevert in termen van management overhead. De vraag is echter of het gewenst en voldoende is om het vertrouwen binnen een confederatie te baseren op het vertrouwen dat DNSSEC te bieden heeft: is er niet meer confederatiespecifieke context nodig om dit vertrouwen te borgen? Een confederatiespecifieke PKI bijvoorbeeld – waardoor DNSSEC niet meer nodig is – en slechts met DNS het doel bereikt kan worden. Maar PKIs schalen niet altijd even goed, zeker niet over domeinen heen, en zijn complex en kostbaar. Hoewel er een sterke toename is in het aantal DNS zones dat gebruikt maakt van DNSSEC zal het nog wel even duren voordat het hele DNS ondertekend is. Het inrichten van een DNSSEC-beveiligde zone is dan een interessante oplossing. In deze oplossing beheert de confederatie operator een DNS zone waarin slechts de DNS resource records van de aangesloten federaties en de partijen daarin zich bevinden. Als een bepaald record bestaat in deze zone impliceert dat dat die partij aangesloten is bij de confederatie. De zone wordt getekend door een root key van de confederatie operator. Het inrichten van de zone weerspiegelt de confederatiestructuur zodat metadata niet meer nodig is om de hiërarchie te specificeren. Partijen kunnen elkaar via NAPTR en/of SRV records vinden en uit de informatie hierin afleiden of ze in dezelfde confederatie zitten. DNSSEC garandeert de authenticiteit en integriteit van de resource records. Problemen kunnen ontstaan als hoger in de DNS hiërarchie overgegaan wordt tot ondertekenen (DNSSEC). In dat geval ontstaan er voor de DNS client applicatie twee trusted anchors (een van de confederatie operator en eentje hoger in de hiërarchie) wat tot verwarring kan leiden. Het kiezen voor het hoger gelegen trust anchor kan een oplossing zijn en resulteert in de hierboven aanpak waarin het gehele DNS is getekend of in een soort ‘meta-zone’ voor alle confederaties en federaties. De meta-zone aanpak waaronder allerlei confederaties en federaties kunnen hangen heeft als voordeel dat er een gedeeld trust anchor is. Nieuwe (con)federaties kunnen hiervan eenvoudig gebruik maken en via multihoming, waarbij federaties in meerdere sub-zones kunnen zitten, is het eenvoudig verbanden te leggen tussen confederaties, federaties en de IdPs en SPs daarin. De vraag is echter wie de coördinatie van deze meta-zone op zich neemt. Vaak is zo’n partij moeilijk te vinden waardoor een door de confederatie operator beheerde zone de meest voor de hand liggende oplossing is. Tot slot is er nog een aanpak mogelijk waarin partijen in een confederatie zelf een op DNS en DNSSEC gebaseerde infrastructuur uitrollen voor het managen van de confederatie. Hoewel erg controleerbaar en vanuit vertrouwensperspectief dus interessant, lijkt de kans van slagen van deze aanpak minimaal. De meerwaarde van het gebruik van DNS komt voornamelijk uit het hergebruik van de bestaande infrastructuur, de schaalbaarheid ervan en uit het feit dat het met een zone aanpak wel degelijk mogelijk is om een confederatie te managen. In plaats van DNS/DNSSEC te gebruiken voor het managen van de confederatie kan hiervoor ook de metadata zelf gebruikt worden. Het opnemen van certificaten en tags in de metadatafile zelf zijn beproefde oplossingen om vertrouwen te creëren en voor het vinden van eindpunten. Een voordeel van deze oplossingen is dat het controleren van de certificaten of de tags op een eenvoudige wijze meegenomen kan worden in de algehele verwerking van de (XML-gebaseerde) metadatafile. Additionele, speciale DNS-software hoeft niet geïmplementeerd te worden waardoor de drempel voor adoptie van de huidige oplossingen waarschijnlijk lager zal zijn. Samenvattend kan geconcludeerd worden dat:

22

Kan dat?



 





DNS bruikbaar is voor het vinden van gedistribueerde metadata informatie in een confederatie. DNS wordt hierbij puur gebruikt voor lookups en is geen database om informatie (metadata) in op te slaan. De voordelen van DNS zoals beschikbaarheid, schaalbaarheid en robuustheid spelen hierbij een belangrijke rol. Het ongewenst is om het vertrouwen in een confederatie op te hangen aan het vertrouwen dat DNSSEC in zijn standaard/geëigende vorm kan bieden. Meer confederatiespecifieke context is noodzakelijk om het vertrouwen tussen alle partijen erin te creëren en te borgen. Een DNSSEC beveiligde zone insteek is daarbij de geschiktste oplossing die het beste van beide werelden combineert: de bruikbaarheid van DNS voor het vinden van informatie en de betrouwbaarheid van DNSSEC met confederatiespecifieke context door de zone te laten managen door de confederatie operator. Alternatieve oplossingen voor het borgen van vertrouwen (certificaten of tags in de metadata) en het veilig vinden en uitwisselen van metadata (EntityIDs als URLs) in een confederatie aanwezig zijn. Deze alternatieven lijken eenvoudiger aan te sluiten op het huidige gebruik van de metadata in federaties waardoor de drempel voor adoptie lager is. Toch moeten ook deze oplossingen zich nog bewijzen in confederatieverband en in het bijzonder betreffende hun schaalbaarheid en complexiteitsbeheersing. Het niet onverstandig is om meer praktische ervaring op te doen in de vorm van een proof of concept om daadwerkelijk na te gaan of beoogde voordelen van DNS en DNSSEC voor federatie management te realiseren zijn.


23

Referenties [1] [2]

[3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

[13] [14] [15] [16]

24

EduGAIN confederatie, zie www.edugain.org. Bob Hulsebosch, Maarten Wegdam en Robert de Groote, Vertrouwen in de SURFfederatie: Schaalt dat?, SURFup project in het kader van SURFworks, augustus 2009, zie http://www.surfnet.nl/Documents/indi-2009-09015%20(SURFfederatie%20Vertrouwen%20v1.1).pdf. A. Gulbrandsen, P. Vixie en L. Esibov, A DNS RR for specifying the location of services (DNS SRV), RFC 2782, februari 2000, zie http://www.ietf.org/rfc/rfc2782.txt. Stuart Cheshire en Marc Krochmal, DNS-Based Service Discovery, internet draft, 10 september 2008, draft-cheshire-dnsext-dns-sd-05.txt, zie http://files.dns-sd.org/draft-cheshire-dnsextdns-sd.txt. S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, maart 2005, document ID saml-metadata-2.0-os, zie http://docs.oasisopen.org/security/saml/v2.0/saml-metadata-2.0-os.pdf. P. Davis et al., Liberty Metadata Description and Discovery Specification, version 2.0, zie www.projectliberty.org/liberty/content/download/1226/7980/file/draft-liberty-metadata-v2.002.pdf. S. Josefsson, RFC 4398, Storing Certificates in the Domain Name System (DNS), IETF, 2006. R. Arends, R. Austein, M. Larson, D. Massey, en S. Rose, RFC 4033, DNS Security Introduction and Requirements, IETF, 2005. R. Arends, R. Austein, M. Larson, D. Massey, en S. Rose, RFC 4034, Resource Records for the DNS Security Extensions, IETF, 2005. R. Arends, R. Austein, M. Larson, D. Massey, en S. Rose, Protocol Modifications for the DNS Security Extensions, RFC 4035, IETF, 2005. R. van Rijswijk, 'Hardening the Internet', whitepaper over impact en belang van DNSSEC, februari 2009, zie http://www.surfnet.nl/Documents/DNSSSEC-web.pdf. J.F. Zandbelt, R.J. Hulsebosch, M.S. Bargh en R. Arends, "Trusted Directory Services for Secure Internet Connectivity Transport Layer Security Using DNSSEC," In Proceedings of the 3rd International Workshop on Security and Trust Management (STM’07), ESORICS workshop, 27 september, 2007, gepubliceerd in Electronic Notes in Theoretical Computer Science, Volume 197, Nummer 1, februari 2008, pagina’s 105-119. H. Eertink, A. Peddemors, R. Arends, em K. Wierenga, Combining RADIUS with Secure DNS for Dynamic Trust Establishment between Domains, extended abstract, TERENA Networking Conference (TNC), Poznan, Polen, 2005. IANA Interim Trust Anchor Repository, zie https://itar.iana.org/. S. Weiler, RFC 5074, DNSSEC Lookaside Validation (DLV), IETF, 2007. P. Harding, L. Johansson en N. Klingenstein, Dynamic Security Assertion Markup Language: Simplifying Single Sign-On, IEEE Security & Privacy, Volume 6, uitgave 2, maart-april 2008, pagina’s 83-85.

Kan dat?

Federatiemanagement met DNS en DNSSEC: kan dat?

Recommend Documents