NO318842B1 - Autentisering og tilgangskontroll - Google Patents

Abstract

Denne oppfinnelsen omhandler generelt autentisering, autorisering, og tilgangskontroll, og mer spesifikt en metode og et system for generell Public Key Infrastructure basert på autentisering som tillater brukerne å ha kun én elektronisk ID for sikker tilgang til alle tjenester. Systemet beskrevet overgår dagens teknologi ved å tilveiebringe generell, PKI-basert autentisering. Ved å tilby validering og muligens også autoriseringstjenester til andre tjenestetilbydere, kan systemet tilveiebringe en infrastruktur for generell, PKI- basert autentisering, og håndtering av elektroniske ID'er fra i prinsippet enhver utgiver av slike.

Description

Denne oppfinnelsen omhandler generelt autentisering, autorisering, og tilgangskontroll, og mer spesifikt en metode og et system for generell PKI (Public Key Infrastructure) basert på autentisering som tillater brukere å ha bare én elektronisk ID for sikker tilgang til alle tjenester.

Bakgrunn for oppfinnelsen

Autentisering, autorisering, og tilgangskontroll er tre områder som er essensielle for

de fleste (kommunikasjons) tjenestetilbydere. De eneste unntakene er totalt åpne tjenester og anonyme betaling-pr.-bruk tjenester. Denne spesifikasjonen dekker den normale situasjonen, hvor navngitte brukere blir autorisert for bruk av spesifikke tjenester. Ved vellykket autentisering, blir en bruker gitt tilgang til disse tjenestene, underlagt tilgangskontrollprosedyrer.

Dagens autentiseringsløsninger ovenfor ISP (Internet Service Provider) eller andre tilbydere av IP-baserte (Internet Protocol) kommunikasjonsinfrastruktur er hovedsakelig basert på brukernavn og passord. RADIUS (Remote Authentication Dial-In Service) protokoll (og andre protokoller som TACACS+ (Terminal Access Controller Access Control System)) tilveiebringer tilgang til tjenester som tilveiebringer sentralisert administrasjon og vurdering av både

autentiseringsinformasjon og av autoriseringer som er tilegnet til (autentisert), brukernavn. Arbeidet i IETF (Internet Engineering Task Force) er pågående for "

neste generasjon av slike protokoller gjennom Diameterarbeidsgruppen.

Vanligvis må brukeren ha et separat passord for hver tjeneste. Passordbasert autentisering blir komplisert etter som flere og flere tjenester er tilveiebrakt, spesielt siden hver tjeneste vanligvis trenger en separat passordautentisering. For å håndtere denne kompleksiteten, velger vanligvis brukere passord som er lett å huske, og bruker det samme (brukernavn og) passord igjen og igjen.

Ettersom flere verdiskapende tjenester blir tilbudt over Internett, er det viktig å gi brukerne åpen PKI-basert (Public Key Infrastructure) brukerautentisering for å

erstatte kompleksiteten og svakhetene til passordbasert autentisering, beskytte brukeren mot tyveri av tjenester, og forenkle påloggingsprosedyrene (én elektronisk ID for tilgang til alle tjenester). Sterk autentisering vil også være nødvendig for å beskytte kunder og tjenestetilbydere mot svindel.

Det nyeste på PKI-området har fremdeles ikke dette generaliseirngsnivået.

Istedenfor står nå ofte brukerne overfor bruk av ulike PKl-løsninger (i stedet for

ulike brukernavn og passord) for tilgang til ulike tjenester. Det er dessuten ikke mange tjenester som nå er «PKI-muliggjorte», selv om denne funksjonaliteten kan være latent for mange tjenester i form av SSL/TLS (Secure Socket Layer/Transport Layer Security) klientautentiseirngsprosedyrer. Systemet beskrevet overgår det

nyeste på området ved å tilveiebringe generell, PKI-basert autentisering. Ved å tilby

validering og muligens også autoriseringstjenester til andre tjenestetilbydere, kan systemet tilveiebringe en infrastruktur for generell, PKI-basert autentisering.

Publikasjonen EP-1 175 038 beskriver en løsning for å fremskaffe et sertifikat ved bruk av en PKI-løsning. Ifølge denne løsningen genereres to sertifikater, hvorav ett er et "single sign-on certificate" med kort levetid, som øyensynlig representerer brukerens rettigheter. Publikasjonen kan ikke sees å beskrive et system der brukeren kan benytte et i prinsippet hvilket som helst sertifikat, herunder et sertifikat som ikke er generert av systemet selv.

. Sammendrag av oppfinnelsen

I samsvar med den foreliggende oppfinnelse er det oppnådd et system for tilveiebringelse av sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, som angitt i det etterfølgende patentkrav 1.

Videre i samsvar med den foreliggende oppfinnelse er det oppnådd en fremgangsmåte for å tilveiebringe av sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, som angitt i det etterfølgende patentkrav 10.

Ytterligere fordelaktige utførelsesformer fremgår av de uselvstendige krav.

Spesifikasjonen beskriver en forbedret løsning for autentisering, autorisering og tilgangskontroll ved bruk av sertifikater og PKI-teknologi, såvel som muliggjøringsmekanismer for betalingstjenester tilveiebrakt over datamaskinnettverk. Hovedfordelene med PKI-løsning er generalitet, skalabilitet, og, økt funksjonalitet (nøkkelhåndtering for kryptering, digital signatur). I fremtiden bør en bruker ha én nøkkelbeholder (f.eks. smartkort) inneholdende private nøkler og sertifikater som danner brukerens elektroniske ID. En elektronisk ID består vanligvis av to eller flere forskjellige private nøkkel/sertifikatpar for ulike formål. De fleste løsningene bruker to par, ett for kryptering (som kun tillater backup av denne spesielle private nøkkelen) og et annet for alle andre formål. Det er ofte anbefalt å tildele den digitale signaturfunksjonen til et separat, tredje par, men dette har ikke oppnådd utstrakt støtte i produkter eller tjenester.

Brukeren bør kunne velge utgiver av elektronisk ID (sertifikattjenestetilbyder). Tjenestene som brukeren ønsker å aksessere bør ikke umyndiggjøre bruk av spesifikke sertifikattilbydere. En bruker må uavhengig kunne få så mange elektroniske ID'er som ønskelig.

1 dag kan tjenestetilbydere som bruker PKI-basert autentisering av brukere typisk

akseptere sertifikater fra kun én av et fåtall sertifikattilbydere. Siden sertifikattjenester er forskjellige, må sertifikattilbydere i noen utstrekning integrere

separat mot alle tilbyderne. Dette blir fort for komplekst til å være brukbart, når sertifikater fra mer enn noen få tilbydere skal bli akseptert.

Samtidig er det i det minste flere hundre offentlige sertifikattilbydere i verden, og det kommer flere til. En tjenestetilbyder kan også ønske å akseptere sertifikater fra ulike selskapsinterne sertifikattjenester (som normalt er for intranettbruk).

Arkitekturen beskrevet separerer kompleksiteten av integrering mot et flertall av sertifikattilbydere til dedikerte komponenter, for derved å fjerne denne . kompleksiteten fra tjenesten i seg selv. En.bruker må registrere den elektroniske ID'en (dvs. sertifiktatet(ene)) som brukeren ønsker å bruke. Navnet på sertifikatet, og andre karakteristikker som dets kvalitetsnivå, er linket til brukerens service- eller tjenesteprofil.

Serviceprofilen er vedlikeholdt på en enkelt plass. Enkelte tjenester kan kreve en høykvalitets elektronisk ID for å tillate tilgang.

Navnet på sertifikatet trenger ikke å være brukerens faktiske navn. Avhengig av politikk, kan dette være et pseudonym, rollenavn, organisasjonsidentitet, abonnementsnavn, osv.

Ved å bruke den elektroniske ID'en kan en bruker til slutt logge på et nettverk og oppnå tilgang til alle tjenester som brukeren abonnerer på. Systemet beskrevet kan tilveiebringe enkel pålogging mot tjenester som er forberedt for dette. Mot tjenester som trenger deres egen autentisering, er fortreffeligheten av systemet at brukerens elektroniske ID kan bli brukt på nytt, i stedet for å måtte opprettholde et forskjellig passord for hver tjeneste. Brukeren må.autentisere flere ganger men bruker samme metode alle gangene. Dette er avhengig av tilgjengeligheten av den beskrevne valideringstjenesten, og i noen utstrekning også til autentiseringstjenesteh.

Fleksibiliteten til dette systemet muliggjør også at brukerne kan bruke operativsystem- fritt. Software for elektroniske ID-løsninger er ofte plattformavhengig. Med en åpen PKI-løsning, kan brukeren velge en elektronisk ID, som kan bli støttet av det ønskede operativsystemet.

Kredittkortselskaper begynner å kreve brukerautentisering for betalinger over Internett, og passordautentisering vil bare være akseptabel i det korte løp. Etablering av generell PKI vil tillate at kredittkortselskapene aksepterer elektronisk ID som allerede eies av brukeren (forutsatt at det kvalifiserer) istedenfor å måtte utgi separat elektronisk ID for bruk for å gjøre betalinger.

Systemet beskrevet vil tilveiebringe midler for sikker autentisering, autorisering, og tilgangskontroll for verdiøkende tjenester slik som video på etterspørsel (Video on Demand, VOD) såvel som tilveiebringelse av midler for sikker betaling.

Denne oppfinnelsen omhandler generelt autentisering, autorisering, og tilgangskontroll, og mer spesifikt en metode og et system for generell Public Key Infrastructure basert autentisering som tillater at brukerne kan ha kun én elektronisk ID for sikker tilgang til alle tjenester. Systemet beskrevet overgår det nyeste på området ved å tilveiebringe generell, PKI-basert autentisering. Ved å tilby validering og muligens også autoriseringstjenester til andre tjenestetilbydere, kan systemet tilveiebringe en infrastruktur for generell, PKI-basert autentisering.

Beskrivelse med henvisning til tegningene

Oppfinnelsen skal nå bli beskrevet med henvisning til medfølgende tegninger hvor: Fig. 1 viser oversikten over autentisering og autoriseringsarkitekturen; Fig. 2 viser en alternativ metode for å sjekke validiteten til et brukersetrifikat; Fig. 3 viser et flytskjema for autentisering, autoriseringssjekking og tjenestetilgangsprosessen;

Fig. 4 viser tilgang til verdiøkt tjeneste; og

Fig. 5 viser en oversikt over valideringstjenesten.

Fig. 1 viser systemarkitekturen i henhold til oppfinnelsen. Brukeren blir autentisert, typisk ved SSL/TLS klientautentisering, og gitt tilgang, på tilgangsserveren, til et nettgrensesnitt med en meny for abonnementssettet med tjenester. Kommunikasjonen mellom klient og tilgangsserver må være krypteringsbeskyttet. SSL/TLS er det foretrukne valget, siden dette er den vanlige måten å beskytte nett (HTTP) kommunikasjon, og kan inkorporere brukerautentisering. En løsning basert på IPSec/VPN (Internet Protocol Security/Virtual Private Network) mellom de to delene kan være et alternativ.

Autentiseringsprotokollen anvendt (som SSL/TLS med både klient- og serverautentisering) identifiserer underforstått brukeren ved navnet i brukerens sertifikat, som blir sendt over til tilgangsserveren som en del av protokollen. Brukeren må også bruke korresponderende privatnøkkel for å signere en utfordring/responssekvens som beviser besittelse av den private nøkkelen.

Gitt brukerens sertifikat og signatur, kan tilgangsserveren ferdigstille brukerens autentiseringsprosess. Imidlertid er, når utført skikkelig med tilbakekallings (eng: revocation) sjekking og på en måte som tillater ulike sertifikater fra ulike sertifikattilbydere, sertifikatvalidering en for tung prosess for kjøring på hver tilgangsserver. I arkitekturen er en separat komponent, valideringstjeneste, introdusert for å være ansvarlig for (og belaste) for (deler av) sertifikatprosesseringen. Valideringstjenesten kan bli duplisert dersom nødvendig. Til slutt kan tilgangsserveren rett og slett trekke ut brukerens sertifikat og sende den av gårde til valideringstjenesten. Svaret er et ja/nei svar på sertifikatets gyldighet, dets kvalitetsnivå (som kan være relevant med hensyn til autorisasjoner som kan bli gitt), brukernavnet, som blir utledet fra navnet i brukerens sertifikat, og muligens mer informasjon dersom ønskelig. Imidlertid, må en også dele lasten mellom tilgangsserver og valideringstjenesten forskjellig, dvs. ved å utføre flest sertifikatprosesser lokalt på tilgangsserveren, og etterlate hovedsakelig den (normalt ressurskonsumerende) oppgaven med tilbakekallingssjekking til valideringstjenesten.

Brukerens profil bør bli holdt på én plass, dvs. autoriseirngstjenesten. Kartleggingen av en brukers sertifikatnavn til korresponderende brukernavn er en del av profilen, og dermed kaller valideringstjenesten opp autoriseringstjenesten for å oppnå denne kartleggingen etter å ha-trukket ut navnet fra sertifikatet. Alternativt kan valideringstjenesten returnere sertifikatnavnet til tilgangsserveren, som da kan utføre navnkartleggingen ved et separat kall til autoriseringstjenesten. I dette tilfellet, er det ingen grensesnitt mellom valideringstjenesten og autoriseringstjenesten.

Fig. 2 viser et flytskjema av autentisering, autoriseringssjekking og tjenestetilgangsprosess. Flere protokoller kan bli brukt mot valideringstjenesten. Dersom valideringstjenesten skal bli tilbudt til tjenestetilbydere som en separat tjeneste, så må protokollen være av standard type. OCSPvl (On-line Certificate Status Protocol, version 1) er et alternativ som gjør det mulig å sjekke tilbakekallingsstatus til et sertifikat og returnere noe tilleggsinformasjon, som et brukernavn. Imidlertid er det ofte ikke mulig å sende over et komplett sertifikat til valideringstjenesten på en standardisert måte, men bare bruke en ikke-spesifisert «utvidelse». OCSPv2 er en avansert utkast RFC, og vil tilveiebringe muligheten for å sende et komplett sertifikat. SCVP (Simple Certificate Validation Protocol) har den samme statusen som OCSPv2, og tilveiebringer den samme funksjonaliteten. XKMS (XML Key Management Service) er et annet alternativ, som i andre XML-baserte mekanismer, f.eks. ved å bruke SOAP (Simple Object Access Protocol).

i

Gitt en autentisert brukeridentitet, forespør så tilgangsserveren autoriseringstjenesten om tilgangsrettigheter som den navngitte brukeren skal bli tillatt. Forespørselen kan bli utvidet ved tilleggsinformasjon som kvaliteten til brukerens autentiseringsprosedyre, og kontekstinformasjon som brukerens nåværende lokasjon, tid på dagen etc. Tilgang til autoriseringstjenesten bør være basert på standardprotokoll, som kan være LD AP (Lightweight Directory Access Protocol), RADIUS, sin planlagte etterfølger DIAMETER, eller en annen protokoll.

Det er også mulig å delegere oppslag mot autoriseringstjenesten til valideringstjenesten. I dette tilfellet vil tilgangsserveren utføre kall bare til valideringstjenesten, og få tilbake både brukernavn og annen informasjon relatert til autoriseringsprosedyren som beskrevet over, og autoriseringer som brukeren skal bli innvilget.

Etterfølgende denne prosedyren, vil brukeren bli presentert med riktig tjenestemeny. Tjenestevalg er det neste trinnet som beskrevet under.

Flytskjemaet i fig. 2 viser trinnene som blir tatt i autentisering, autoriseringssjekking og tjenestetilgangsprosedyrer.

I det følgende vil en typisk oppkoblingsoppsett og tilgang til tjeneste bli beskrevet. Brukerens utstyr eller hjemmenettverk blir forbundet til infrastrukturen tilbudt av nettverksoperatøren via en form for tilgangspunkt, som typisk tilveiebringer protokoller ved datalink eller tilgangslaget, og nettverkslaget, dvs. IP-protokollen. Tilgangspunktet er ikke vist i fig. 1, ettersom det bare opptrer som en ruter med hensyn til nett-tilgang fra brukeren til tilgangsserveren. Tilgangspunktet kan bli separert inn i to komponenter: én som tilbyr tjenester ved datalink/tilgangslaget, og en annen som er en IP-ruter.

Når brukerutstyr kobles til nettverksinfrastrukturen, er det typisk gitt tilgang til et default, minimumssett av tillatte kommunikasjonsstier. I arkitekturen vist, må ruten mot tilgangsserveren bli gjort tilgjengelig, og vanligvis må også en Domain Name Service (DNS) også bli gjort tilgjengelig. Videre tjenester/stier kan bli lagt til til denne minimale konfigurasjonen.

Når brukeren åpner en nettleser på brukerens utstyr, må denne bli rettet til URL til tilgangsserveren for at brukeren skal få tilgang til tjenestene. Brukeren må så gå gjennom autentiseringsprosedyren og autoriseringssjekker, og vil bli gitt tilgang til tjenestemenyen.

Det er primært tre typer tjenester tilgjengelige: kommunikasjonstjenester, nettbaserte tjenester, og mediatjenester innbefattende multimedia. Den tredje kategorien kan bli beskrevet som en kombinasjon av de andre to. Handlingene utført for hver av disse kategoriene blir beskrevet i det følgende.

Kommunikasjonstjenester: Når brukeren velger en kommunikasjonstjeneste, må denne forespørselen bli formidlet til brukerens tilgangspunkt, for å kunne være i. stand til å rute mot bestemmelsesstedet valgt. Ruten kan bli muliggjort ved IP-laget, som åpner opp for trafikk fra brukerens (utvalg) IP-adresse(r) til et visst (utvalg) - . bestemm els esst ed(er). Denne ruten kan også bli muliggjort via datalinklaget, dvs. ved etablering av en ATM (Asynchronous Transfer Mode) virtuell krets.

Ett eksempel på kommunikasjonstjeneste kan være generell internett-tilgang gjennom en ISP. Valg av internett-tilgang i tjenestemenyen vil muliggjøre en rute fra brukeren til ISP'ens tilgangsnode (grenseruter), fra hvilket tilgang kan fortsette. Tilgangsserveren trenger å formidle de riktige kommandoene til brukerens tilgangspunkt for å muliggjøre den forespurte kommunikasjonstjenesten. Flere protokoller kan være brukt til dette formålet, med RADIUS som det mest vanlige alternativet. DIAMETER er den planlagte etterfølgeren til RADIUS.

Det finnes tre forskjellige scenarier for brukertilgang til nettbaserte tjenester fra tjenestemenyen til tilgangsserveren.

I det første scenario, formidler tilgangsserveren direkte tilgang til tjenesten i en enkel påloggingsmåte, ved å sende over et enkelt påloggingsmerke (eng: token) til tjenesten. I den enkleste formen, er dette et brukernavn og passordet til tjenesten til en HTTP Post operasjon, for derved å logge brukeren transparent til tjenesten. Brukeren blir så enten omdirigert til tjenesten, eller tilgangsserveren fortsetter operasjonen som en HTTP-proxy mellomledd. Det finnes flere produkter og teknologier for enkel pålogging tilgjengelig, og merker fra slike teknologier kan bli brukt. Tilgangsserveren kan muligens også skrive en «cookie» til brukerens nettleser, som vil bli gjenkjent og akseptert som et enkelt påloggingsmerke når . brukeren tar direkte tilgang til tjenesten. Tjenesten kan ha tilgang til autoriseringstjenesten, f.eks. for å sjekke flere detaljerte privilegier relatert til tjenestebruken.

I et annet scenario, blir tjenesten tilbudt innenfor domenet av systemer beskrevet, men trenger en separat autorisering. Brukerens elektroniske ID (privat nøkkel og sertifikat) blir brukt mot tjenesten, dvs. brukeren har en enkel mekanisme. Tjenesten har tilgang til valideringstjenesten, og kan også bruke autoriseringstjenesten.

I et tredje scenario, blir tjenesten tilbudt på utsiden av domenet til systemet beskrevet. Dersom tjenesten blir muliggjort for slik autentisering, så kan brukerens elektroniske ID (privatnøkkel og sertifikat) bli brukt, dvs. brukeren har en enkel mekanisme. Tjenesten har tilgang til valideringstjenesten, men siden den ikke er i systemets domene, vil den ikke vanligvis ha tilgang til autoriseringstjenesten.

Valideringstjenesten er generell, som kan, bli tilbudt til samarbeidende selskaper både på innsiden og utsiden av systemets domene. Valideringstjenesten kan bli konfigurert for å returnere ulik informasjon (f.eks. ulike brukernavn) avhengig av tjenesten som kaller den opp. Dette er et direkte resultat av den generelle naturen til PKI-basert autentisering. En kan ikke tillate denne form for tilgang av. passordbasert autentisering, siden passord vil bli vist til eksterne selskaper.

Autentiseringstjenesten bør imidlertid normalt bare være aksesserbar innenfor domenet til systemet. Å tillate eksterne selskaper tilgang til domeneintern autoriseringsinformasjon eller også å håndtere autoriseringsinformasjon gjennom samme tjeneste vil i de fleste tilfellene ikke være akseptabelt. Media/multimediatjenester: Som sagt kan (multi-)mediatjenester bli betraktet som en kombinasjon av kommunikasjonstjenester og nettbaserte tjenester. Noen mediatj en ester kan bli implementert i sin helhet på nettbaserte eller kommunikasjonstjenester, men det vanlige scenariet er en tjeneste som

tilveiebringer et nettbasert'grensesnitt for tjenesteoppsett, og en tjenesterealisering som stoler på funksjonaliteten i nettverket. Dersom tilgangsserveren opptrer som en proksy mellom brukeren og mediatj enesten, kan den fange opp kommunikasjon og utføre støttehandlinger som initiering av en VPN mellom dem, eller tilveiebringe informasjon til en «multicast membership system».

Fig. 3 viser en alternativ måte å sjekke valideringen til et brukersertifikat. Istedenfor å sende brukerens sertifikatnavn til en autoriserings tjeneste, blir det sendt til en tilgangsserver, som i tur mottar den navngitte brukeridentiteten fra

autoriseringstjenesten.

Fig. 4 viser et eksempel på autentisering, autorisering, og tilgang til en verdiøkende

tjeneste slik som Video on Demand (VOD) såvel som sikker betaling (på en betaling pr. bruk basis).

Brukeren blir autentisert ved å bruke auténtiseringsarkitektur beskrevet i fig. 1. Innholdet blir beskyttet ved kryptering under hele varigheten av sesjonen, og betaling blir sikret på en betaling pr. bruk basis. Innholdet kan bli dekryptert ved å bruke brukerens nøkler tilveiebrakt av den elektroniske ID'en. Brukeren kan velge en metode for betaling f.eks. faktura eller kredittkort, og signere transaksjonen ved å bruke den elektroniske ID'en brukt for autentisering. Alternativt kan brukeren velge en ekstern mekanisme som skal brukes for betaling og sikring av

transaksjonen.

Oppfinnelsen vil nå bli beskrevet i mer detalj med henvisning til fig. 2. Tilgangsserveren opptrer som brukerens tilgangspunkt til tjenestene ved autentisering av brukeren, og tilveiebringelse av dem med passende tjenestemeny. For å utføre sin rolle i systemet må tilgangsserververen: - Støtte HTTPS (HTTP over SSL/TLS) eller alternativt være i stand til å tilveiebringe andre midler for sikre kommunikasjonskanaler; - Være i stand til å autentisere seg selv til klienter/brukere, fortrinnsvis ved bruk av PKI-teknologi (f.eks. SSL/TLS-serverautentisering); - Støtte protokollene som er nødvendig for å kommunisere med valideringstjenesten og autoriseringstjenesten; - Støtte én eller flere protokoller fra PKI-basert klient/brukerautentisering, vanligvis SSL/TLS med klientautentisering; - Implementere funksjonaliteten som er nødvendig for å fremvise nødvendig informasjon (slik som tjenestemeny) til brukeren, og håndtere brukerens innmating; - Være i stand til å opptre som en proksy mellom brukeren og tjenesten, dvs. videreformidle informasjon som er transparent mellom dem.

Brukeren må rette nettleseren til nettgrensesnittet tilveiebrakt av tilgangsserveren for å kunne få tilgang til tjenestene. Normalt vil brukeren autentisere straks gjennom SSL/TLS med klientautentisering, som beskrevet over.

Det finnes to alternative metoder: Dersom en annen PKI-basert autentiseringsmetode blir brukt, kan en SSL/TLS-sesjon bli etablert med kun serverautentisering, og brukerautentiseringsprotokoll kan bli kjørt på denne sikre kanalen. Dersom flere alternativer eksisterer for autentiseringsmetode, kan brukeren bli vist en klar tekst (dvs. ren HTTP) side for valg av metode. Etter valget, fortsetter autentisering, f.eks. ved å etablere en SSL/TLS-sesjon med klientautentisering.

Som beskrevet stoler tilgangsserveren på å få brukerens sertifikat fra brukeren. Andre midler for å oppnå sertifikatet, f.eks. et registeroppslag, kan i tillegg bli implementert.

Sorri beskrevet i seksjonen under, når det gjelder valideringstjenester, bør så mye

. som mulig av lokal sertifiseringsprosessering bli koblet ut i tilgangsserveren, og etterlatt til valideringstjenesten i stedet. Tilgangsserveren må validere brukerens sertifikat ved hjelp av valideringstjenesten, verifisere brukerens signatur på anropsdelen til autentiseringsprotokollen, og opptre i henhold til suksess eller feiling av denne autentiseringen. Laging av anrop, og verifisering av signaturen på anropet, kan bli gjort eksternt til tilgangsserveren. Siden tilgangsserveren er eksponert til angrep fra brukeren, kan en ønske å bruke en mer beskyttet datamaskin for sikre kritiske operasjoner.

Den første handlingen etterfølgende brukerautentisering vil vanligvis være å hente brukerens tjenesteliste fra autentiseringstjenesten, dersom ikke denne allerede har blitt mottatt fra valideringstjenesten. Senere opptrer tilgangsserveren i henhold til brukerens innmating, i henhold til reglene som er i kraft, og i samarbeid med autoriseringstjeneste for handlinger som trenger sjekk mot brukerens profiler. Som beskrevet i fig. 1 kan en enkel påloggingsmekanisme bli implementert.

Valideringstjenesten er optimalisert for sertifikatprosessering. Den mottar et sertifikat, eller identifikasjon av sertifikat og dens utgiver, og:

- Leser navnet fra utgiveren.

- Henter utgiverens fellesnøkkel fra en for-evaluert liste av «gode» nøkler. Alle kryss-sertiifkatregimer eller hierarkier har blitt for-prosessert, og alle utgiverfellesnøkler blir direkte stolt på, dvs. ingen prosessering av sertifikatlenker er nødvendig. - Utføre tilbakekallingssjekker, fortrinnsvis ved lokalt oppkall til forprosessert tilbakekallingsinformasjon oppnådd av regulær for-henting av CRL

(certificate revocation list).

- Dersom det komplette sertifikatet har blitt mottatt, analysere sertifikatet, sjekke signatur og gyldighetsperiode og trekke ut innholdet. Dette må bli behandlet individuelt foT ulike sertifikatprofiler. - Trekker ut informasjon kartlagt fra sertifikatinformasjonen, som brukernavn utledet fra navn i sertifikatet, kvalitetsnivå (forhåndsbestemt basert på en analyse av sertifikatpolitikken), osv. Informasjonen kan være generell, eller spesifikt målrettet mot enheten som kalte opp for sertifikatvalidering.

Disse operasjonene kan bli optimalisert i valideringstjenesten, for å tilveiebringe de nødvendige, raske responstider. Spesielt pålegger prosessering av sertifikatkjeder og tilbakekallingssjekking normalt tung last på serveren. Av denne grunn er skikkelig tilbakekallingssjekking ofte undertrykket i dagens PKI-muliggjorte tjenester. Valideringsserveren stoler på for-prosessering av tilbakekallingsinformasjonen for å kunne få en raskere prosess.

Flere protokoller kan bli brukt mot valideringstjenesten. OCSP (On-line Certificate Status Protocol) versjon 1 er tilgjengelig i dag men har ingen standard måte å overføre et komplett sertifikat. OCSP versjon 2, som er under utvikling som et intemettutkast, legger til denne muligheten. Alternative protokoller som kan være et tillegg til eller erstatte OCSP, er SCVP (Simple Certification Validation Protocol), som er en internettutkastprotokoll og XKMS (XML Key Management System). Protokoller kan også være basert på SOAP (Simple Object Access Protocol, essensielt XML over HTTP) eller lignende teknologier, eller noen beskyttet protokoll kan bli designet. Alle disse protokollene tilveiebringer muligheten for å returnere tilleggsinformasjon til oppkalleren, sammen med ja/nei/ukjent svar til valideringsforespørselen selv.

OCSP er primært målsatt som en erstatning av CRL-utgivelse fra en sertifikatmyndighet. Istedenfor, eller i tillegg til, CRL, tilveiebringer sertifikatutgiveren et OCSP-grensesnitt som svarer på forespørsler om gyldigheten til sertifikatene kun utgitt av denne sertifikatmyndigheten. I vår kontekst, vil valideringstjenesten tilveiebringe en OCSP-tjeneste for alle sertifikatmyndighetene som er støttet.

OCSPvl beskriver tilbakekallingssjekking som den eneste funksjonaliteten til en OCSP-tjeneste. Dette er for snevert, og det er foreslått å forbedre denne. For det første bør valideringstjenesten ikke bare sjekke om sertifikatet har blitt tilbakekalt eller ikke, men også om det er innenfor gyldighetsperioden, og om utgiverens signatur på sertifikatet er riktig. Videre bør valideringstjenesten også analysere sertifikatet og handle overfor innholdet ved å bestemme kvalitetsnivået og brukernavnet, muligens også mer informasjon.

OCSP tilveiebringer klientautentisering og integritetsbeskyttelse av forespørsler ved muligheten av å la oppkalleren digitalt signere (deler av) forespørselen. Likeledes kan valideringsserveren også signere responsene. Dette kan bli implementert for andre protokollalternativer. Signerte responser kan være veldig viktig, siden falske eller manipulerte responser kan være en signifikant trussel. Signerte forespørsler kan være nødvendig for å kunne returnere oppringerspesifikk informasjon, dersom ikke oppringeren er autentisert på annen måte.

Imidlertid, siden signaturprosessering (som vanligvis også medfører sertifikatprosessering) er forholdsvis tidskonsumerende, det kan være bedre å sørge for at oppkall til valideringstjenesten blir gjort over en sikkeT kanal, f.eks. ved hjelp av en VPN-løsning. Dette bør definitivt være tilfelle for kanalen mellom en tilgangsserver og valideringsserver, muligens også fra andre domeneinterne tjenester mot valideringstjenesten. Dersom valideringstjenesten er tilveiebrakt mot eksterne selskaper, må tilveiebringelse av signerte forespørsler og svar være implementert, siden en sannsynligvis ikke kan erhverve VPN eller lignende for alle slike eksterne selskaper.

Det følgende dekker behovene på serverne som bruker valideringstjenesten. Spesielt er dette tilgangsserveren.

Særlig ligger en slik server på en tilgangsserver. For å kunne bruke valideringsserveren, bør (deler av) sertifikatprosesseringen være «kortsluttet» ved disse tjenestene. Noen scenarioer for prosessering i en server blir beskrevet i det følgende: - SSL-klientautentisering: SSL-prosessering ved serveren må trekke ut klientens sertifikat, og enten videreformidle disse til valideringstjenesten uten videre prosessering, eller utføre noen prosessering lokalt før videreformidling av det komplette sertifikatet eller informasjon utledet fra dette. Basert på svaret, vil SSL-oppsett enten fortsette eller avbryte. - Kvittering av en digitalt signert beskjed: Klientens (sender) sertifikat kan bli trukket ut fra beskjeden (eller oppnådd fra andre midler) og sendt til valideringstjenesten. Alternativt kan noen sertifikatprosessering bli utført lokalt før sertifikatet, eller informasjon utledet fra dette, blir sendt til valideringstjenesten. Etterfølgende en vellykket validering, kan signaturen av beskjeden selv bli verifisert lokalt. Valideringstjenesten kan også bli hevet til å håndtere alle signaturprosesseringer i systemet, på beskjed såvel som sertifikater. - Validering av et sertifikat som etterfølgende vil bli brukt for (nøkkelhåndtering for) kryptering av beskjeder eller kanaler mot en gitt motpart: Prosessering vil bli analog til mottak av sertifikat i en digitalt signert beskjed. - Etablering av en VPN: Prosessering vil bli omtrent nøyaktig som SSL-kl i entautenti seri ngsscenario. - Andre PKI-baserte autentiseringsprotokoller: Serveren må få klientens

sertifikat, og deretter kalle opp valideringstjenesten som indikert i scenarioet over, sertifikatprosessering kan enten bli gjort i sin helhet på valideringstjenesten, eller noen form for lokal prosessering kan bli utført.

For å implementere oppkallet (protokollalternativene listet over) til valideringstjenesten, er modifikasjoner til serversoftwaren nødvendig. Mengden av lokal prosessering som kan bli «kortsluttet» avhenger av modifikasjonene som er mulig for den spesifikke serverplattformen. For optimal ytelse, bør oppkall til valideringstjenesten bli innfelt med andre prosesseringer i serveren, og delvis eller fullt erstattet funksjonalitet (lokal sertifikatprosessering) som allerede er på plass i de fleste serverplattformer. Slike modifikasjoner blir vanligvis heller kompliserte,

og avhenger av åpenheten til plattformen. Alternativet er tillegg av ekstra funksjonalitet på topp av tilgjengelige, åpne grensesnitt, med lokal sertifikatprosessering kun kortsluttet i den utstrekning som er mulig av konfigurasjonsparameterne.

Det er også mulig å tilveiebringe brukergrensesnitt for brukere (klienter) mot valideringstjenesten. I dette tilfellet, er sertifikatprosessering i brukerens nettleser (typisk, kan også være annen software i brukerens utstyr) i sin helhet eller delvis erstattet av oppkall til valideringstjenesten i stedet for lokal

sertifiseringsprosessering. Den primære bruken av slike grensesnitt vil være prosessering av SSL-serversertifikater, men det brukes også relatert til VPN-

oppsett, mottak av digitalt signerte beskjeder, og validering av sertifikater som vil bli brukt for kryptering av beskjeder/trafikk mot motparter. I dette tilfellet, kan svar fra valideringstjenesten bli signert, og forespørsler fra brukeren kan bli signert. Dersom valideringstjenesten verifiserer signaturene på sertifikatet på vegne av brukeren, kan listen av (i dag rundt 150) sertifikattilbyder offentlige nøkler, som er for-konfigurert i standard nettlesere (og f.eks. i nyere Microsoft OS versjoner) bli fjernet fra brukerens utstyr. Brukerens håndtering av (og tillitt til) slike utgiveroffentlige nøkler er en hovedhindring for PKI-bruk.

Med hensyn til støtte for forskjellige sertifikatutgivere, er det to grunnleggende

idéer bak introduksjonen av valideringstjenesten:

- Effektivitet, ved optimalisering av tjeneste for sertifikatprosessering,

spesielt ved å kvitte seg med prosessering av sertifikatkjeder og ved å sjekke tilbakekalling av et lokalt databaseoppslag i stedet for CRL-prosessering.

- Tilveiebringelse av et enkelt punkt med integrering for tjenester som

ønsker å akseptere sertifikater fra mer enn én sertifikatutgiver.

I dag må tjenester som bruker PK.I-basert autentisering integrere individuelt mot

hver sertifikatutgiver som de ønsker å godta sertifikater fra. Integreringskompleksiteten spesielt har å gjøre med forskjellige sertifikatformater, forskjellige navnskjemaer, ulike tilgangspunkter for tilbakekallingsinformasjon, og

håndtering av utgivers offentlige nøkler. En tjeneste kan dermed bare integrere med et fåtall av valgte sertifikatutgivere direkte. Valideringstjenesten fjerner denne kompleksiteten fra tjenestene.

Imidlertid", har selv valideringstjenestene et kompieksitetsproblem når mange sertifikatutgivere skal bli støttet. Hovedkompleksiteten er å bestemme kvalitetsnivået, som forklart i det neste avsnittet. Håndtering av offentlige nøkler av utgivere må være pålitelig og kontinuerlig overvåket for tilbakekalling og andre oppdateringer. Sertifikatformater fra ulike utgivere må det redegjøres for ved spesifikke analyser (selv om standardiserte profiler i noen grad muliggjør denne oppgaven; men en trenger å bestemme profilen som er forespurt). Valideringstjenesten er ikke for komplisert fra et teknisk synspunkt, men håndtering av tjenesten trenger ressurser. Imidlertid er det i mange sammenhenger bedre å sentralisere denne kompleksiteten i stedet for å måtte håndtere den for hver eneste tjeneste separat.

Dette peker på spørsmålet om hvor mange, og hvilke sertifikatutgivere en ønsker å . støtte gjennom tjenesten. Flere hundre offentlige sertifikatutgivertj enester eksisterer

rundt om i verden, med flere etterfølgende. I tillegg vil en finne økende samarbeidende (intranett) systemer, som kan være basert på standardprodukter fra f.eks. Microsoft eller IBM/Lotus som tillater enhver å etablere en sertifikatutgivende tjeneste. Mens de fleste av disse tjenestene vil oppnå svært dårlig kvalitet og tillitt, f.eks. utgitt uten å være understøttet av en målsetning og i store trekk ubrukelig utenfor selskapets intranett, kan situasjoner oppstå hvor en

ønsker å være i stand til å akseptere sertifikater fra et samarbeidende selskap eller samarbeidende kunde.

Bestemmelsene rundt dette spørsmålet har mer en håndterings- enn en teknisk natur, så lenge som valideringsservertj enest ens implementasjonsskaleringsegenskaper er tilstrekkelige.

En viktig nødvendighet er at sertifikatet må tilveiebringe, direkte eller indirekte, informasjonen som er nødvendig for videre prosessering, særlig et navn som kan bli brukt for tilgangskontroll og regnskap.

Med hensyn til kategorisering av sertifikater og kvalitetsnivåer, er en sertifikatutgivende tjeneste definert av de følgende komponentene: - Lovrammeverk og avtaler; - Sertifikat politikk, som tilveiebringer behov for prosedyrer relatert til tjenesten, og vanligvis dekker mange av aspektene til lovrammeverket og avtalene, (som imidlertid ofte må gjøres eksplisitt, og dermed garanterer et separat punkt); - Sertifikatpraktiserende uttalelse, som forklarer hvordan behovene til politikken blir møtt ved denne spesifikke sertifikatutgivertj enesten - kan referere til interne prosedyredokumenter; Sertifikatformater, spesielt navnkonvensjoner; - Pålitelighetsmodeller mot andre aktører, og spesielt holdning mot hierarkistrukturer og kryss-sertifikatregimer; - Informasjon/registertjenester for sertifikater, tilbakekallingsinformasjon, politikkinformasjon og annen relevant informasjon.

Kvalitetsaspekter av sertifikattjeneste blir i hovedsak utledet fra sertifikatpolitikken. Politikken markerer behov for registreringsprosedyren som en bruker må gå gjennom for å oppnå sertifikatet (f.eks. elektronisk søknad kontra personlig tilstedeværelse med fysisk autentisering, etc.), forpliktelser som brukeren er enig i å påta seg dersom feil oppstår, sikkerhetsbehov pålagt på opereringen av tjenesten, osv. Heldigvis finnes det et fåtall standard rammeverk for å skrive fremgangsmåtepolitikk (eng: policies), og de fleste sertifikatutgiverne holder seg til

én av disse. Sertifikatfremgangsmåtepolitikker kan derfor bli sammenlignet punkt for punkt.

Imidlertid er kategorisering av sertifikatfremgangsmåtepolitikker en stor manuell oppgave som trenger noe ekspertise. Det er et behov for et kategoriseringskriterium og en metodisk fundamentering for kategoriseringen. Hvilket kriterium må bli tilfredsstilt for å nå et spesifikt kvalitetsnivå? Legg til videre kompleksiteter som fremgangsmåtepolitikker skrevet på et utenlandsk språk, og referer til lover og reguleringer fra utlandet. Dersom ikke noen kommer opp med en uavhengig tjeneste for kategorisering/klassifisering av fremgangsmåtepolitikker, er en tvunget til å gå

gjennom evalueringsprosesser uavhengig for alle utgiverne. Dette betyr at en må starte med et fåtall av viktige utgivere, og utvide dette senere etter behov.

Uavbrutt overvåkning av de støttede fremgangsmåtepolitikkene må bli utført. Imidlertid vil vanligvis politikkene beskrevet forandre prosedyrene, og mange utgivere vil støtte aktive notifikasjoner på andre selskaper dersom det finnes store forandringer i fremgangsmåtepolitikkene.

En kvalitétskategorisering kan kun være en enkel nummerisk verdi, f.eks. 1-4 med 1 som toppnivå og 4 som dårlig kvalitetsnivå. Det har vært svært lite arbeid på standardisering av slike nivåer. Innenfor EU, har «kvalifisert sertifikat» nivå blitt (mer eller mindre) etablert som en høykvalitetsindikator som støtter formelle digitale signaturer. I USA definerer «federal bridge certificate authority» noen kvalitetsnivåer. En sertifikatutgiver som tilveiebringer tjenester mot den føderale sektoren bør kryss-sertifisere med broen som indikerer en fremgangsmåtepolitikk-kartlegging mellom sin egen politikk og det passende kvalitetsnivå som definert av broen. ETS I arbeider nå på et «ikke-kvalifisert politikkrammeverk», som vil definere noen indikatorer som bør tas hensyn til ved kategorisering av fremgangsmåtepolitikk.

Kvalitetskategorisering kan også bli mye mer fingradert enn bare en nivåindikator. Basert på politikkrammeverket og ETSI's foreliggende arbeid, kan noen parametere bli utledet fra fremgangsmåtepolitikken inn i en struktur som kan bli returnert til oppkalleren. Som et eksempel har ansvaret som en sertifikatutgiver er villig til å ta en påvirkning på verdien av transaksjonene som kan bli understøttet av en autentisering basert på sertifikatet fra utgiveren. Domsmakten indikert av fremgangsmåtepolitikken er en annen viktig parameter.

Bemerk at en annen sak er om kvalitetsnivået (politikken og relatert praksis) kun

blir krevd av sertifikatets utgiver, eller om kravet er understøttet av tredjeparts bevis. Mange sertifikatpolitikker krever tredjeparts revisjon av tjenester, for å sørge for at faktisk operasjon er i henhold til fremgangsmåtepolitikken, praktiske

redegjørelser, og interne prosedyrer. Slike revisjonsrapporter vil sannsynligvis medføre en høyere kvalitetsrate, eller i det minste mer sikkerhet rundt ratingen.

Sertifikater som ISO9000 eller ISOl 7799 vil også telle her.

Bemerk til slutt af kvaliteten på tjenester ikke nødvendigvis medfører troverdighet. Det (tenkte) «Mafia CA» kan oppnå en kvalitetsrating, men det er fremdeles ikke klart om dets sertifikat bør bli akseptert.

I tillegg til sertifikatfremgangsmåtepolitikk og kvalitetsnivå, må andre aspekter til sertifikatutgivende tjeneste bli tatt hensyn til. Spesielt må en pålegge behov på sertifikatformatene, som spesifikke felt, egenskaper eller utvidelser som må være

tilstede, eller som ikke skal være tilstede. Navngivning er en separat sak, og for systemene som er definert i dag, må det være mulig å oversette fra navnet i

. sertifikatet til et gyldig brukernavn. Et annet behov som kan komme frem i noen" tilfeller er at brukernavnet må være «reelt», og ikke et pseudonym. Fig. 5 viser foreslått arkitektur av valideringstjenesten. Det består av de følgende delene: - En OCSP-server som prosesserer syntaks og semantikk relatert til denne protokollen. Videre frontmaskiner fra.andre protokoller kan bli lagt til senere, indikert som stiplede linjer. - En valideringsmaskin som prosesserer sertifikatene, sjekker gyldighet og utleder informasjon. - En separat prosess for for-henting og prosessering av CRL fra alle sertifikatmyndigheter som blir håndtert av valideringstjenesten. - En OCSP-klient kan være nødvendig for tilgang til tilbakekallingsinformasjon fra sertifikatutgivere som ikke støtter CRLs. - En database som har informasjon om sertifikatutgivere, offentlige nøkler, politikker og relaterte kvalitetsnivåer, tilbakekallingsinformasjon som oppdatert av prosessen nevnt over, og tilleggsinformasjon som kan være utledet fra sertifikatene.

Et grensesnitt (sannsynligvis LD AP) mot autoriseringstjenesten for å kunne utlede oversettelser fra navnet i sertifikatet til et gyldig brukernavn for systemets domene, og muligens andre navns formater for andre domener. Dette grensesnittet kan være fra tilgangsserveren istedenfor Valideringstjenesten, som diskutert over. - Tjenesten vil nesten helt sikkert kreve kryptografisk hardware (ikke vist i fig. 5).

Med hensyn til operasjon, forespørsler og svar, utfører OCSP-serveren, og andre frontmaskiner, protokollen avhengig av prosessering relatert til valideringstjenesten.' Dette innbefatter validering og generering av signaturer på digitalt signerte forespørsler og svaT.

Frontmaskinene har en API mot valideringsmotoren. Valideringsmotoren må analysere sertifikatet, dersom innbefattet, eller på annen måte opptre på forelagt. sertifikatinformasjon.

Valideringssjekker blir deretter utført på sertifikatet: signatur OK, sertifikatformat OK, innenfor valideringsperiode, ikke tilbakekalt eller suspendert. Noen av disse sjekkene er avhengig av et komplett sertifikat, og kan ikke bli utført dersom kun utdrag av sertifikater blir forelagt. Kvalitetsnivå blir hentet basert på politikken indikert i sertifikatet (eller fra for-konfigurert kjennskap i det spesielle tilfellet hvor utgiver ikke innbefatter anbefalt politikkidentifikatorutvidelse i sine sertifikater). Utledet informasjon blir deretter hentet fra databasen, og alle blir returnert over API til OCSP-serveren (eller annen frontmaskin) i formen spesifisert av API.

Tilbakekallingssjekking skal normalt bare være et lokalt databaseoppslag, siden CRL for-hentingskomponenten skal samle nødvendig informasjon (beskrevet under). Imidlertid dersom en sertifikatutgiver bare tilveiebringer et OCSP-grensesnitt for tilbakekallingssjekking, og ingen CRL-utgivende tjeneste, så vil valideringsmotoren faktisk kalle opp utgiverens OCSP-tjeneste.

En kan også tenke seg situasjoner hvor valideringstjenestene kan bli lenket sammen, og oppkall ble gjort ved å bruke en protokoll (ikke nødvendigvis OCSP) understøttet av frontmaskinen til fjern valideringstjenesten.

De fleste sertifikatmyndigheter i dag, bruker etter vår kjennskap signert CRL for å informere om tilbakekalling og suspensjon av sertifikater. CRL blir vanligvis utgitt regulært, med hver CRL innbefattende en planlagt tid for utgivelse av neste versjon. Imidlertid kan CRL bli utgitt før planen dersom nødvendig. Komplette CRL'er er vanlige, dvs. en CRL inneholder serietallene til alle tilbakekalte sertifikater. Et sertifikat blir fjernet fra fremtidige CRL'er når tid og utgivelse av neste CRL er etter normalutløpstid til sertifikatet. Delta-CRL'er også kalt inkrementelle CRL'er kan bli brukt hvor en CRL inneholder kun nye inntastinger siden tidligere CRL. Med delta-CRL'er, blir komplette CRL'er utgitt regulært, men mye mindre hyppig enn tilfelle er når kun komplette CRL'er blir brukt.

Dermed er normaltilfellet hvor CRL for-hentingskomponenten å kjøre en «daemon-prosess» for hver støttede sertifikatutgiver, og å hente og å prosessere utgivernes komplette CRL i en tid svært nær etter planlagt tidsutgivelse. Resultatet av prosesseringen blir lagret i databasen. Imidlertid finnes det noen varianter som må bli understøttet, og valideringstjenesten trenger å vite CRL-strategiene til forskjellige sertifikatutgivere, som dokumentert i deres fremgangsmåtepolitikker. Valideringstjenesten trenger selvfølgelig også å vite distribusjonspunkter for CRL, og den trenger å aksessere disse punktene. CRL'ene bør være åpent tilgjengelig, men noen utgivere kan ønske å fakturere for henting, i hvilket tilfelle må kostnadene enten bli overført til oppringeren, eller tatt hensyn til på annen måte.

Dersom en utgiver støtter delta-CRL'er, bør dette bli utnyttet av CRL for-hentingskomponenten siden mengden av data som er må nedlastes fra hver

. henteoperasjon vil være mye større enn de komplette CRL'ene.

Dersom en utgiver har spesifiserte lange intervaller mellom CRL'ene, er det sannsynlig at dette innebærer en «utgi CRL når nødvendig» strategi. I dette tilfellet bør CRL for-hentingskomponenten polle for ny CRL regulært i stedet for å vente på neste planlagte utgivelse. Intervallet som valideringstjenesten bør være villig til å akseptere mellom CRL'ene er en innstillingsparameter som influerer kvaliteten til valideringstjenesten. Dette intervallet bør være lik pollingstiden, og alle utgiverne med en CRL-frekvens over intervallet bør bli pollet.

For stor-skala, internasjonal operasjon, vil en sentralisert installasjon som henter potensielt svært store CRL'er fra alle utgiverne klart være inneffektivt. En installasjon i Norge som hver time trenger å hente mange. MB'er fra informasjon fra hundrevis av utgivere rundt om i verden kan virke, men den vil være inneffektiv, og utbredelse av tilbakekallingsinformasjon vil bli treg. Derfor vil en distribuert arkitektur være mer passende for CRL for-hentingskomponenten, men å beskrive denne videre er utenfor omfanget til dette dokumentet.

Det kan til slutt være noen utgivere som ikke bruker CRL<*>er i det hele tatt, men er kun avhengig av et OCSP-grensesnitt for tilbakekallingssjekking. I dette tilfellet kan ikke CRL for-hentingskomponenten gjøre noen ting, og valideringsmotoren må kalle opp passende OCSP-grensesnitt (eller annen valideringstjeneste som bemerket over) når det er nødvendig!

Strategiene brukt av CRL for-hentingskomponenten må bli innstilt i mer detalj, ettersom flere parametere enn de nevnt over vil influere resultatene. Hovedbehovet er mengde av forsinkelse som er akseptabelt å introdusere med hensyn til utbredelse av tilbakekallingsinformasjon. Det vil nødvendigvis være et «gap» eller mellomrom mellom utgivelsen av CRL og tiden når denne CRL har blitt prosessert av CRL for-hentingskomponenten. En forespørsel som ankommer ved valideringstjenesten

under dette gapet, må enten motta en forsinket respons - dersom

valideringstjenesten venter for CRL for-hentingskomponenten til å gjøre denne jobben - eller risikere et feilaktig svar dersom valideringstjenesten svarer med én gang basert på gammel tilbakekallingsinformasjon.

Det er en risiko for at en utgivers .CRL distribusjonstjeneste er overbelastet av forespørsler hver gang en planlagt CRL blir utgitt, fordi mange selskaper samtidig prøver å laste ned en ny CRL til den lokale cachen. For å håndtere dette implementerer noen utgivere en «over-issuing» strategi. CRL'ene blir utgitt oftere enn fremgangsmåtepolitikken sier. Den CRL for-hentende komponenten må ta slike forhold i betraktning.

Databasen vil lagre informasjon om hver sertifikatutgiver og dens fremgangsmåtepolitikker, og tilbakekallingsinformasjon. Det er også mulig å lagre bruketrelatert informasjon, men i den beskrevne systemkonteksten er det bedre å beholde lagring og håndtering av brukerinformasjon til autoriseringstjenesten.

Utgiverinformasjon vil bestå av utgivernavn (som spesifisert i utgivemavnfeltet i sertifikatene), identifikasjon av fremgangsmåtepolitikk som er relevant (OID

(Object Identifier) for politikken er (nesten) alltid innbefattet i sertifikatene),

offentlig nøkkel eller liste av offentlige nøkler (med valideringsintervaller og nøkkelidentifikator/nøkkelverdi) som må bli brukt for å validere sertifikatene, og kvalitetsegenskaper relatert til fremgangsmåtepolitikken og utgiveren som diskutert tidligere.

Håndtering av utgiveroffentlige nøkler er en hodepine i dag, siden dette alltid er i form av en lokal liste med pålitelige sertifikatutgivere og deres nøkler, ofte i form

av selvsignerte sertifikater (som tilveiebringer integritetsbeskyttelse men ingen autentisering). I systemet beskrevet, er utgivernøkkelhåndtering fortrinnsvis sentralisert i valideringstjenesten. Dette er kun mulig dersom komplette sertifikater blir sendt over til valideringstjenesten, og lokal sjekking av utgiverens signatur på sertifikater kan bli kortsluttet av det oppkallende systemet.

Utgivernøkler blir validert i en prosess som er delvis manuell (for å sikre kvalitet)

og delvis automatisk, og lagret i databasen. Tilbakekalling av en utgivers nøkkel er en svært sjelden hendelse, men dette er også en svært alvorlig.hendelse. Informasjonskanaler må bli overvåket for å kunne sørge for at slik tilbakekalling

blir fanget. I noen tilfeller vil tilbakekalling være gjennom CRL fra utgiver ved et høyere nivå i et hierarki. 1 andre tilfeller vil sertifikatsutgiveren som det gjelder ikke være medlem av en tillitsstruktur og må arrangere tilbakekalling på egenhånd. Imidlertid skal alltid tilbakekallingsnotifikasjon være beskrevet i fremgangsmåtepolitikken.

Noen utgivere vil kun ha et par nøkler i bruk til enhver tid, bortsett fra det vil nøkkeloverlapping fra en utgiver vanligvis medføre en overlapp hvor gammel offentlig nøkkel fremdeles er gyldig for sertifikatvalidering, mens privatnøkkelen ikke er gyldig for signering av nye sertifikater. Andre utgivere kan tilpasse en politikk for hyppige nøkkelforandringer, i hvilket tilfelle mange nøkler kan være gyldige (i det minste for sertifikatvalidering) til samme tid. Det er sannsynligvis et behov for manuelle prosedyrer for å holde databasen med en utgivers offentlige nøkler oppdatert.

Håndtering av tilbakekallingsinformasjon ble gjort av CRL for-hentingskomponenten. Tilbakekallingssjekking ble gjort lokalt ved databasesøk for å se om serienummeret til sertifikatet som er aktuelt er listet som tilbakekalt. Tilbakekallingsinformasjon må være tidsstemplet: tidspunkt for henteoperasjon for følgende informasjon, og planlagt tid for neste henting.

Hovedmotivasjonen for autoriseringstjenesten er håndtering og beskyttelse av brukerrelatert informasjon på en enkelt plass. Det er vanlig i dag å ha separate autentiserings- og autoriseringssystemer for hver tjeneste, og i det minste for hver tjenesteplattform. Dermed blir håndtering av abonnementer/brukerinformasjon - inntasting av ny informasjon, forandring og sletting av informasjon - tungvint og sårbar for feil.

Autoriseringstjenesten beholder informasjon relatert til hver bruker i én database. Tjenesten og databasen kan bli replikert. En «bruker» vil vanligvis være et individ men det kan også være en abonnentidentitet, et gruppenavn eller noen annen navngitt entitet. Informasjonen er relatert til autentisering og autoriseringer. Kontoinformasjon kan lett bli lagt til systemet, selv om dette ikke er beskrevet i dokumentet. Informasjonen vil være sensitiv med hensyn til konfidensialitet og integritet, og autoriseringstjenesten og databasen må være tilstrekkelig sikret.

I dag burde to standardprotokoller være støttet av autoriseringstjenesten: LDAP og RADIUS. DIAMETER-protokollen bør være støttet når spesifikasjonene er klare. Andre protokoller kan være støttet. Siden autoriseringstjenesten håndterer sensitiv informasjon, må den utføre autentisering og tilgangskontroll med hensyn til entiteten som kaller den i før informasjonen blir returnert. Dette kan være e' n . del av protokollene brukt, være basert på underliggende protokoller (som SSL, TLS,

IPSec, eller andre VPN-teknologier), eller stole på dedikerte

kommunikasjonskanaler (fysiske eller logiske) mot motparten. På grunn av de ulike protokollene, er det et behov for protokollspesifikke frontsystemer, på den samme måten som beskrevet for valideringstjenesten.

Autoriseringstjenesten utfører navnkartlegging for autentisering og tjenestetilgang. De PKI-baserte autentiseringsprotokollene brukt vil autentisere navnet i sertifikatet. Dette navnet kan bli sendt til autoriseringstjenesten, som i retur vil korrespondere

på brukernavnet. Navnet på tjenesten hvilket brukernavn er nødvendig, bør være en parameter til oppkallet, siden brukeren kan ha ulike brukernavn mot ulike tjenester.

Et passord kan bli returnert sammen med brukernavnet dersom nødvendig og forespurt.

Ved senere trinn av sesjonen, kan autoriseringstjenesten bli kalt opp for å få flere brukernavn når det er nødvendig. Autoriseringstjenesten kan bli gitt et brukernavn/tjenestepar, og bli spurt om å oversette dette til et annet brukertiavn/tjenestepar for tilgang til annen tjeneste. Autoriseringstjenesten må registrere styrken av autentiseringsmekanismen sist brukt av den navngitte brukeren, og opptre i henhold til dette når det innvilges eller nektes tilgang til en tjeneste ved å returnere informasjon eller ikke.

Det første nivået med autorisering i systemene er for tilgang til tjenester i seg selv. En autorisering kan være linket til spesifikke tilstander, som bruk av autentiseringsmekanismer med tilstrekkelig kvalitet, tillate lokasjoner, kun bruk av spesifikt utstyr, tiden på dagen osv. En annen betingelse er bokføring og garantert betaling, som til nå er opptil de individuelle tjenestene men kan bli lagt til i autoriseringstjenesten senere. Alle slike betingelser må være oppfylt for å få tjenesten godkjent.

I tillegg kan tjenestespesifikke autorisasjoner bli lagret i databasen. I dette tilfellet kan autoriseringstjenesten bli kalt opp fra tjenesten i seg selv under tilgangs forsøk til spesifikke objekter (som et eller annet innhold), for å bestemme om tilgangsforespørselen skal bli gitt eller ikke.

Videre utvidelser til autoriseringstjenesten er:

- Utgivelse av kryptograferte beskyttede «merker» som bevis på autoriseringer, dette kan være basert på signerte privilegier (egenskaper) sertifikater, Kerberos billetter, eller lignende teknologier.

- Håndtering av utgivelse av autoriseringer fra én bruker/aktør til en annen.

- Sammensetning av autoriseringer fra flere brukere/aktører for tilgangsavgj ørel ser.

Disse punktene er ikke beskrevet videre i dette dokumentet.

Systemet beskrevet baserer autentisering på tilgjengelig kommersielle (eller ikke kommersielle) sertifikattjenester. All sertifikathåndtering, som registrering, navngiving, utgivelse, og tilbakekalling, skal bli tatt hånd om av sertifikattilveietilbydeme.

Autoriseringstjenesten trenger å opprettholde en database av brukernavn og relaterte privilegier. Navn i sertifikatene vil ikke være direkte brukbare i denne konteksten. En kartlegging trenger derfor å bli etablert mellom brukemavnet(navnene) i sertifikatet(ene) som en bruker ønsker å bruke for å autentisere. Dette kan videre bli utvidet ved flere brukernavn mot andre tjenester, muligens også passord eller annen autentiseringsinformasjon, for å muliggjøre at tilgangsserveren logger en bruker transparent på en tjeneste som kun tillater brukernavn/passord som en autentiseringsmekanisme. I tillegg til sertifikater, kan systemet bli utvidet til å ta hånd om andre autentiseringsmekanismer, som brukernavn/passord.

Det kan være tilfeller hvor navngivningsformatet brukt av en spesifikk sertifikatutgiver kan bli automatisk oversatt til et brukernavn. Imidlertid, i de fleste tilfellene, må kartleggingen fra sertifikatnavnet til brukernavnet være eksplisitt konfigurert i databasen. For å unngå administrativ kostnad, bør dette for hoveddelen være implementert som en selvtjenestegrensesnitt for brukerne. Imidlertid vil det også være behov for et administrativt grensesnitt og definisjon av operatører med utvidede tilgangsrettigheter til databasen.

Brukere må ha tilgang til et selvtjenestegrensesnitt hvor de kan sende inn et sertifikat og detaljer rundt deres abonnement, for å kunne ha sertifikatnavn registrert og linket til brukernavnet. Linken mellom to navnformater må selvfølgelig bli etablert på lignende måte. En mulighet er at nye brukere blir gitt to alternativer: Det første er å signere opp for en konto, og samtidig bestille en elektronisk ID fra en foretrukket partner av systemeieren, eller fra en liste av alternative sertifikatutgivere. Avhengig av politikken til sertifikatutgiveren, kan den elektroniske ID'en enten være tilgjengelig for bruk med én gang, eller den trenger å bli aktivisert på et senere tidspunkt (f.eks. dersom brukeren trenger å få et smartkort). Imidlertid er, for autoriseringstjenesten den viktige informasjonen navnet som vil være synlig i sertifikatet.

Det andre er å signere opp for en konto, og spesifisere eksisterende sertifikat som vil bli brukt for å autentisere brukeren. Anvendbarheten av sertifikatet må bli sjekket mot (sikkerhets) behovene, og en må verifisere at sertifikatet faktisk tilhører den nye brukeren. Det skal være tilstrekkelig å registrere ett sertifikat og la brukeren legge til flere sertifikater senere.

Eksisterende brukere må bli tillatt å registrere tilleggssetrifikater eller erstatninger for allerede registrerte sertifikater. Dette kan være en selvadministrerende prosedyre som kan være tilgjengelig som nettbasert tjeneste. Bemerk at den trenger å ha regler for akseptable autentiseringsmetoder relatert til den nye metoden (nytt sertifikat) som vil bli registrert. F.eks., kan en ikke først introdusere et lavkvalitetssertifikat, og deretter bruke dette for å registrere et høykvalitetssertifikat som en ny autentiseringsmetode. Høykvalitetssertifikatet vil i dette tilfellet effektivt tilveiebringe samme sikkerhet som autentiseringen basert på lavkvalitetssertifikatet men en gitt konfigurering kan begrense tilgang til lavkvalitetsmetoden mens den gir tilgang for en (som det ser ut til i dette tilfellet) høykvalitetsautentisering. Følgelig kan en autentiseirngsmetode bare bli brukt for å introdusere nye metoder med samme eller lavere sikkerhetsnivå.

For å oppgradere til en sterkere autentiseirngsmetode, må prosedyrer bli fulgt for

nye brukere. Noe selvadministrering er mulig, men det kan godt hende at manuelle prosedyrer må bli innlemmet til en viss grad.

Administratorer må bli tillatt til å legge til, slette eller forandre informasjon for

andre brukere. Administratorer kan være definert internt til organisasjonen som kjører autoriseringstjenesten, relativt til (tilveiebringere av) tjenester som kan bli nådd via systemet, eller relativt til f.eks. et selskaps kunder som trenger å håndtere abonnementer for flere brukere. Administratorer kan bruke samme grensesnitt som ordinære brukere, eller et annet dersom dette passer bedre. Muligheter for batchprosessering av informasjon, f.eks. for å legge til informasjon om mange brukere i én operasjon er nødvendig.

I de fleste tilfeller er det kostnadseffektivt å overlate administrasjon av

abonnementer (dvs. autorisering til tjenester) til individuelle brukere. Dermed må selvtjenesten som er beskrevet for administrasjon av autentiseringsinformasjon også dekke annen informasjon om brukeren (faktisk vil slik bruk sannsynligvis være herskende for håndtering av autentiseringsinformasjon).

Første nivå av autoriseringer er for tjenester slik - abonnere til en tjeneste, eller bestemme et abonnement. Med et mer fingradert nivå, kan autoriseringer relatert til karakteristikker av individuelle tjenester bli håndtert, dersom slettet fra tjenesten til autoriseringstjenesten. Et eksempel kan være å forandre abonnert båndbredde for en kommunikasjonstjeneste.

Når brukere utfører slike administrative prosedyrer, må autoriseringer og andre restriksjoner bli fulgt. Som et eksempel, kan ikke en bruker abonnere til en tjeneste som trenger en sterk autentiseringsprosedyre med mindre et sertifikat med tilstrekkelig kvalitet har blitt registrert for brukeren. Et annet eksempel er relatert til innholdsabonnement i en tjeneste, som kan være begrenset til personer over en viss alder.

Administratorer er også nødvendige for å håndtere autoriseringer. Som ett

eksempel, kan fremgangsmåtepolitikken diktere at kun definerte personer kan håndtere tilgangsrettigheter til spesielle tjenester for selskapets brukere. Et batch-orientert grensesnitt er nødvendig for å håndtere informasjon om mange brukere i én enkelt operasjon.

Claims (10)

1. System for tilveiebringelse av sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, hvor bruker og tjenestetilbyder er utstyrt med midler for forbindelse til et felles nettverk, karakterisert ved at det omfatter: - én eller flere tilgangsservere innrettet for å utføre trinnene: å motta en forespørsel fra brukeren, å autentisere brukeren og å spørre etter klientautentisering, å utføre en anrops/responssekvens, å forespørre om et sertifikat og bevis på eierskap av privatnøkkel fra bruker, . å videresende sertifikatet eller identifikasjon av sertifikatet til en valideringstjenesteenhet, i tilfelle av gyldig brukersertifikat, å motta brukernavn fra en autoriseringstj enesteenhet, å forespørre om en autoriseringstjenesteenhet for tilgangsrettigheter, å motta tilgangsrettigheter fra autoriseringstjenesteenheten,-å lokalisere en passende tjenestemeny, å presentere tjenestemenyen til brukeren, å overføre informasjon mellom brukeren og tjenestetilbyderen; én eller flere valideringstjenesteenheter, innrettet for å utføre trinnene: å motta et brukersertifikat eller en identifikasjon av et brukersertifikat fra tilgangsserveren, å kontrollere gyldigheten til brukersetrifikatet, dersom brukersetrifikatet er gyldig, enten å oversende brukersertifikatsnavnet til en autoriseringstjenesteenhet for oversetting til et brukernavn, og å oversende brukernavnet returnert fra autoriseringstjenesteenheten til tilgangsserveren, eller å oversende brukerens sertifikatnavn til tilgangsserveren, dersom brukerens sertifikat ikke er gyldig, å nekte brukeren tilgang til tjenesten; - én eller flere autoriseringstjenesteenheter, innrettet for å utføre trinnene: å motta en brukers sertifikatnavn fra en valideringstjenesteenhet eller en tilgangsserver, å' sende brukerens sertifikatnavn til en database, å motta brukerens navn og profil fra databasen, å oversende brukernavnet til en valideringstjenesteenhet eller tilgangsserveren, å motta en forespørsel om tilgangsrettigheter fra en tilgangsserver, å forespørre om abonnementsinfo fra databasen, r å motta abonnementsinfo fra databasen, å bestemme tilgangsrettigheter basert på nevnte abonnementsinfo, å oversende tilgangsrettigheter til tilgangsserveren; og - én eller flere autorisasjonsrolleenheter og tilhørende databaser, innrettet for å utføre trinnene: å motta en brukers sertifikat fra en autoriseringstjenesteenhet, å lokalisere brukerens navn og profil i databasen, å sende brukerens navn og profil til autoriseringstjenesteenheten, å motta en forespørsel om abonnementsinfo fra en autoriseringstjenesteenhet, å sende abonnementsinfo til autoriseringstjenesteenheten; hvilket medfører at systemet tillater brukeren å benytte ett og samme sertifikat, utstedt av en ekstern sertifikattilbyder, for sikker tilgang til tjenestene.

2. System i henhold til krav 1, karakterisert ved. at tilgangsserveren omfatter midler for: å støtte HTTPS eller andre midler for sikre kommunikasjonskanaler, autentisering av tilgangsserveren til klienter/brukere, fortrinnsvis ved bruk av PKI-teknologi, å støtte protokoller som er nødvendig for å kommunisere med valideringstjenesten og autoriseringstjenesteenheten, å støtte én eller flere protokoller for PKI-basert klient/brukerautentisering, å implementere funksjonaliteten som er nødvendig for fremvisning av informasjon til brukeren og for å håndtere brukerinnmating, å opptre som proksyserver mellom bruker og tjeneste.

3. System i henhold til krav 1, karakterisert ved at forespørring av sertifikat og privatnøkkel fra brukeren kan bli utført ved å bruke registeroppslag.

4. System i henhold til krav 1, karakterisert ved at tilgangsserveren blir tilpasset for å formidle direkte tilgang til tjenesten på en enkel påloggingsmåte.

5. System i henhold til krav 1, karakterisert ved at databasen som lagrer brukernavn og profil også lagrer annen brukerrelatert informasjon.

6. System i henhold til krav 2, karakterisert ved at når det brukes andre midler for sikring av kommunikasjonskanal, etablerer tilgangsserveren en sikker sesjon slik som en SSL/TLS-sesjon kun med serverautentisering, og som kjører brukerautentiseringsprotokoll på den etablerte sikre kanalen.

7. System i henhold til krav 2, karakterisert ved at i tilfelle av flere alternativer med autentiseringsmetoder, blir brukeren presentert med valgene, og tilgangsserveren etablerer en sikker sesjon slik som en SSL/TLS-sesjon med den valgte metoden til kli en taut enti seringen.

8. System i henhold til krav 4, karakterisert ved at tjenestetilbyderen er innbefattet i systemet og tilpasset for å ha tilgang til utvekslingsinformasjon med autoriseringsenheten.

9. Anvendelse av systemet i henhold til krav l for å tilveiebringe autentisering, autorisering og tilgang til verdiøkte tjenester slik som Video on Demand.

10. Fremgangsmåte for å tilveiebringe sikker tjenestetilgang for en bruker til i det minste én tjeneste fra en tjenestetilbyder, hvor kunden og tjenestetilbyderen er utstyrt med midler for forbindelse til et felles nettverk, karakterisert ved at det omfatter trinnene: - ved hjelp av én eller flere tilgangsservere: å motta en forespørsel fra brukeren, å autentisere brukeren og å spørre etter klientautentisering, å utføre en anrops/responssekvens, å forespørre om et sertifikat og bevis på eierskap til privatnøkkel fra brukeren, å overføre sertifikatet eller identifikasjon av sertifikatet til en valideringstjenesteenhet, i tilfelle av gyldig brukersertifikat, å motta et brukernavn fra en autoriseringstjenesteenhet, å forespørre en autoriseringstjenesteenhet om tilgangsrettigheter, å motta tilgangsrettigheter fra autoriseringstjenesteenheten, å lokalisere en passende tjenestemeny, å presentere tjenestemenyen til brukeren, å overføre informasjon mellom brukeren og tjenestetilbyderen; - ved hjelp av én eller flere valideringstjenesteenheter: å motta et brukersertifikat eller en identifikasjon av brukersertifikat fra en tilgangsserver, å kontrollere gyldigheten til brukersertifikatet, dersom brukersertifikatet er gyldig, enten å sende brukernes sertifikatnavn til en autoriseringstjenesteenhet for oversetting til et brukernavn, og overføring av brukernavnet returnert fra autoriseringstjenesteenheten til tilgangsserveren, eller å overføre brukerens sertifikatnavn til tilgangsserveren, dersom brukerens sertifikat ikke er gyldig, å nekte brukeren tilgang til tjenesten; - ved hjelp av én eller flere autoriseringstjenesteenheter: å motta en brukers sertifikatnavn fra en valideringsserviceenhet eller en tilgangsserver, å sende brukerens sertifikatnavn til en database, å motta brukernavn og profil fra en database, å overføre brukernavnet til en valideringstjenesteenhet eller tilgangsserver, å motta en forespørsel om tilgangsrettigheter fra en tilgangsserver, å forespørre om abonnementsinfo fra databasen, å motta abonnementsinfo fra databasen, å bestemme tilgangsrettigheter basert på abonnementsinfo, å overføre tilgangsrettigheter til tilgangsserveren, - ved hjelp av én eller flere autoriseringsrolleenheter og tilhørende databaser: å motta en brukers sertifikat fra en autoriseringstjenesteenhet, å lokalisere et brukernavn og profil i databasen, å sende brukernavnet og profilen til autoriseringstjenesteenheten, å motta en forespørsel om abonnementsinfo fra en autoriseringstjenesteenhet, å sende abonnementsinfo til autoriseringstjenesteenheten; hvilket medfører at fremgangsmåten tillater brukeren å benytte ett og samme sertifikat, utstedt av en ekstern sertifikattilbyder, for sikker tilgang til tjenestene.