NO338710B1 - Fremgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal, et kommunikasjonsnettverk og en terminal for et kommunikasjonsnettverk - Google Patents
Fremgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal, et kommunikasjonsnettverk og en terminal for et kommunikasjonsnettverk Download PDFInfo
- Publication number
- NO338710B1 NO338710B1 NO20080870A NO20080870A NO338710B1 NO 338710 B1 NO338710 B1 NO 338710B1 NO 20080870 A NO20080870 A NO 20080870A NO 20080870 A NO20080870 A NO 20080870A NO 338710 B1 NO338710 B1 NO 338710B1
- Authority
- NO
- Norway
- Prior art keywords
- authentication
- gateway
- operator
- tunnel
- aaa
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 73
- 238000013475 authorization Methods 0.000 title claims description 71
- 238000004891 communication Methods 0.000 title claims description 17
- 230000004044 response Effects 0.000 claims description 12
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 230000001131 transforming effect Effects 0.000 claims description 2
- 230000015572 biosynthetic process Effects 0.000 claims 2
- 238000012790 confirmation Methods 0.000 claims 2
- 238000012545 processing Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000005641 tunneling Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000007630 basic procedure Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Meter Arrangements (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Description
Oppfinnelsen angår en framgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal, et kommunikasjonsnettverk og en terminal for et kommunikasjonsnettverk, slik det framgår av den innledende del av henholdsvis patentkrav 1, 3 og 5.
Bakgrunn
IPSec (IP-sikkerhet) er en standard for sikring av Internett-protokoll (IP) kommunikasjon ved å kryptere og/eller autentisere alle IP-pakker. IPSec er en obligatorisk del av IPv6 (Internet-protokoll versjon 6), og forventes å bli mer utbredt når IPv6 blir mer populær. IPSec-protokoller er definert i IETF RFCs 2401-2412.
IPSec er et sett med kryptografiske protokoller for å sikre pakkestrømmer og nøkkelutveksling. IPSec inneholder to protokoller for å sikre pakkestrømmer, det vil si innkapsling av sikker nyttelast ("Encapsulating Security Payload, ESP"), og autentisering av pakkehodet ("Autentication Header AH"), og en nøkkelutvekslingsprotokoll, det vil si internett-nøkkelutveksling ("Internet Key Exchange, IKE") protokollen. IKE bruker en "Diffie-Hellman"-nøkkelutveksling for å sette opp en delt sesjonshemmelighet, fra hvilken kryptografiske nøkler er utledet. Offentlig nøkkelteknikker, eller alternativt forhåndsdelte hemmeligheter, brukes til gjensidig autentisering av de kommuniserende parter.
IPSec er hovedsakelig brukt til å bygge virtuelle private nettverk (VPN), hvorved IKE-protokollen brukes av virtuelle private nettverkene for å etablere en sikker forbindelse mellom en server og en ekstern klient. IPSec omfatter to driftsmodi, det vil si en tunnelmodus, hvor sikkerhet for pakketrafikken tilveiebringes til flere maskiner ved en enkel node (for eksempel en IPSec-gateway), og et transportmodus hvor endepunkt-datamaskinene foretar sikkerhetsprosesseringen. Hvis en VPN-sesjon er etablert som en ende-til-ende VPN-sesjon, mellom en ekstern klient og en bedrifts gateway, tilveiebringes komplett personvern og dataintegritet for bedriftsbrukere som får adgang til bedriftsnettet fra utsiden av et intranett. Imidlertid, fordi pakkene er kryptert ende-til-ende fra klienten til bedriftens VPN-gateway, er det likevel ikke mulig for nettverksoperatører eller tjenestetilbydere å tilveiebringe verdiøkende tjenester til disse bedriftsbrukerne, da slike tjenester trenger synlighet inn i pakkehoder og applikasjonsdata.
I et nettverksbasert VPN, avsluttes bruker VPN-sesjonen ved IPSec-gatewayen innenfor operatørnettverket, og en annen VPN-sesjon (enten en IPSec eller en ikke-IPSec sesjon) fra IPSec-gateway-en til bedriftens VPN-gateway brukes for å bære trafikk fra operatørnettverket til bedriftsnettverket. Siden pakkehodene og applikasjonsdataene på denne måten blir synlige for operatørnettverket, kan verdiøkende tjenester tilbys av operatøren. Fordelene ved den nettverksbaserte VPN-tilnærmingen tilveiebrakt for bedriftskunder er tydelig. Det er mulig for bedriften å sette bort verdiøkende tjenester som krever inspeksjon av pakke- og applikasjonshode, slik som brannveggtjeneste, internet-offload, hurtigbuffertjeneste, osv. Videre, siden datapakker fra alle VPN-brukere transporteres over en enkel VPN-sesjon fra operatøren til bedriftens VPN-gateway, kan mengden av VPN-sesjonsinformasjon, inkludert sikkerhetsassosiasjon- informasjon ("Security Assosiation, SA"), som trenger å bli vedlikeholdt ved bedriftens VPN-gateway, minimaliseres og følgelig kan betydelig dataaggregasjon oppnås.
Imidlertid muliggjør ikke IKE-protokollen eller IKEv2- protokollen (versjon 2), som for tiden standardiseres av IETF, at flere enn en autentiserings-/autorisasjonsprosedyre utføres mellom en VPN-klient og en VPN-gateway. I den nettverksbaserte VPN-tilnærmingen utføres denne autentiserings-/autorisasjonsprosedyren i gateway-serveren til operatørnettverket. Bedrifter kan anse dette som utilstrekkelig med tanke på intern sikkerhet og følgelig kan bedrifter være tilbakeholdende med å velge en nettverksbasert VPN-tjeneste. En videre autentiserings-/autoriserings prosedyre vil kreve flere kompliserte løsninger, for eksempel nestet tunnellering eller en ekstra sikkerhetsprotokoll innenfor IPSec-tunnelen, som ikke er i inngrep med den første autentiserings-/autorisasjonsprosedyren, og videre er de ikke støttet av IKEv2.
Publikasjonen av Malkin, G.S.: «Dial-in virtual private networks using layer 3 tunneling», i Local Computer Networks, 1997, IEEE Proceedings, 22nd Annual Conference i Minneapolis, USA, 2.-5. November 1997, s. 555-561 beskriver et nettverksbasert VPN der det er etablert en første tunell mellom en fjernbruker og en operatør-gateway (Remote Access Server), og (den første) bruker-VPN-sesjonen termineres ved operatør-gatewayen. Deretter blir det etablert en annen tunell mellom operatør-gatewayen (Remote Access Server) og gatewayen til bedriftsnettet, hvorved en annen VPN-sesjon fra operatør-gatewayen til bedrifts-VPN-gatewayen brukes til å bære trafikk fra operatørnettverket til bedriftsnettverket.
Oppfinnelsen
Ulempene med den kjente teknikk løses med en framgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal, et kommunikasjonsnettverk og en terminal for et kommunikasjonsnettverk, slik det framgår av den karakteriserende del av henholdsvis patentkrav 1, 3 og 5. En fordelaktig utførelse av framgangsmåten framgår av det uselvstendige patentkrav 2.
Nå er det oppfunnet en forbedret framgangsmåte og teknisk utstyr som implementerer framgangsmåten, ved hvilken IKEv2 kan brukes til autentisering og autorisering av en ekstern klient både i operatørnettverket og i bedriftsnettverket
Ifølge et første aspekt, er en framgangsmåte ifølge oppfinnelsen basert på ideen å tilveiebringe en autentisering/autorisasjon av en ekstern klient terminal i et nettverk som omfatter en operatørs gateway og en operatørs autentiseringsserver, og en ekstern gateway og en ekstern autentiseringsserver, hvori de nevnte autentiseringsserverne har blitt enige om en gjensidig autentiseringsprotokoll seg imellom. Framgangsmåten omfatter: Etablering av en sikker tunnel mellom klientterminalen og operatørens gateway ved bruk av en krypteringsnøkkel utvekslingsprotokoll; autentisering og autorisering av klientterminalen i operatørens autentiseringsserver; initiering av en andre autentiserings-/autorisasjons-prosedyre fra klientterminalen mot den eksterne autentiseringsserveren ved bruk av den sikre tunnelen; transformering, i operatørens gateway, av i det minste en melding involvert i den andre autentiserings-/autorisasjonsprosedyren, for å bli ifølge nevnte gjensidige autentiseringsprotokoll; og autentisering og autorisering av klientterminalen i den eksterne autentiseringsserveren.
Ifølge en utførelsesform er en andre tunnel etablert mellom operatørens gateway og den eksterne gateway-en.
Ifølge en utførelsesform er krypteringsnøkkel-utvekslingsprotokollen IKE-protokollen ("Internet Key Exchange"), hvorved framgangsmåten videre omfatter: kryptering av meldinger involvert i den andre autentiserings-/3utoriseringsprosedyren, når de sendes mellom klientterminalen i operatørens autentiseringsserver av den etablerte IKE-sikkerhetsassosiasjonen (SA).
Ifølge en utførelsesform omfatter meldingene som er involvert i den andre autentiserings-/autorisasjonsprosedyren i det minste en IKEv2 INFORMASJONS meldingsutveksling med et dedikert nyttelastfeltfor en andre autentiserings-/3utorisasjonsprosedyre.
Ifølge en utførelsesform, som svar på at den andre autentiserings-/autorisasjonsprosedyren ikke lykkes, indikeres feilen i en feilmelding med et dedikert nyttelastfelt for feilen til den andre autentiserings-/autorisasjonsprosedyren.
Arrangementet ifølge oppfinnelsen medfører betydelige fordeler. Siden den andre autentiserings-/autorisasjonsprosedyren mot en ekstern AAA-instans er utført på innsiden av en allerede etablert IKE SA (eller IPSec SA), er trafikken sikret med IKE SA. Videre trenger ikke den andre autentiserings-/autorisasjonsprosedyren IPSec; den trengs bare når IKEv2-oppkobling er støttet. Videre, den tofasede autentiserings-/autorisasjonsprosedyren forblir fordelaktig bakover kompatibel med den nåværende IKEv2, det vil si hvis en klientterminal eller en gateway ikke støtter de nye meldingene, kan IKEv2-protokollen fremdeles bli brukt; kun de karakteristiske trekkene til den andre autentiserings-/autorisasjonsprosedyren er ikke tilgjengelige. Fra bedriftens ståsted tilbyr den tofasede autentiserings-/autorisasjonsprosedyren en enkel måte å tilveiebringe klientautentisering også i bedriftsnettverket. Fra operatørens ståsted forbinder den tofasede autentiserings-/autorisasjonsprosedyren autentiserings-/autorisasjonsprosedyren nærmere til operatørens nettverk ved å utnytte eksisterende infrastruktur i operatørens nettverk. Dette gjør det også enklere for operatøren å tilby ulike verdiøkende tjenester.
Ifølge et andre aspekt er det tilveiebrakt et kommunikasjonsnettverk som omfatter en klientterminal, en operatørs gateway og en operatørs autentiseringsserver; en ekstern gateway og en ekstern autentiseringsserver; i hvilket nettverk er besluttet en gjensidig autentiseringsprotokoll mellom de nevnte autentiseringsserverne, hvori klientterminalen og operatørens gateway settes opp for å etablere en sikker tunnel mellom hverandre ved bruk av en krypteringsnøkkel-utvekslingsprotokoll; operatørens autentiseringsserver er anordnet til å autentisere og autorisere klientterminalen; klientterminalen er anordnet til å initiere en andre autentiserings-/autorisasjonsprosedyre mot den eksterne autentiseringsserveren ved bruk av en sikker tunnel; operatørens gateway er anordnet til å transformere i det minste en melding involvert i den andre autentiserings-/autorisasjonsprosedyren til å være i samsvar med den nevnte gjensidige autentiseringsprotokollen; og den eksterne autentiseringsserveren er satt opp til å autentisere og autorisere klientterminalen.
Ifølge et tredje aspekt er det tilveiebrakt en terminal anordnet til å operere ifølge framgangsmåten til oppfinnelsen.
Eksempel
I det følgende vil ulike utførelsesformer av oppfinnelsen bli beskrevet mer detaljert, med henvisning til de vedlagte tegningene, hvor: Fig. 1 viser et typisk tilfelle for bruk av VPN, hvor en klientterminal forbinder seg tilbake til sitt bedriftsnettverk gjennom en IPSec-beskyttet tunnel; Fig. 2 viser et signaleringsdiagram for en autentiserings-/autoriseringsframgangsmåte ifølge en utførelsesform av oppfinnelsen; Fig. 3a viser et eksempel på et nyttelast-typeformat for en nøkkelutvekslingsmelding ifølge en utførelsesform av oppfinnelsen; Fig. 3b viser et annet eksempel på et nyttelast-typeformat for en nøkkelutvekslingsmelding ifølge en utførelsesform av oppfinnelsen; og Fig. 4 viser en klientterminal ifølge en utførelsesform av oppfinnelsen i et redusert blokkdiagram.
Beskrivelse av utførelsene
For å illustrere aspektene ved oppfinnelsen er noen grunnleggende prosedyrer ved IKEv2 diskutert i korthet heri. For en mer komplett redegjørelse rundt den nåværende status på IKEv2, refereres det til internettutkast: " Internet Key Exchange ( IKEv2) Protocol", draft-ietf-ipseq-ikev2-17, 23. September, 2004.
IKE utfører gjensidig autentisering mellom to parter og etablerer en IKE-sikkerhetsassosiasjon (SA) som omfatter informasjon om delt hemmelig informasjon som kan brukes til effektivt å etablere SA-er for ESP ("Encapsulation Security Payload") og/eller AH ("Authentication Header") og et sett med kryptografiske algoritmer som skal brukes av SA-ene for å beskytte trafikken de bærer. SA-ene for ESP og/eller AH som får oppsett gjennom IKE_SA-en kalles CHILD_SA-er.
Alle IKE-kommunikasjoner består av par av en forespørselsmelding og en svarmelding. Paret av meldinger kalles en "utveksling" ("Exchange"). Når man etablerer en IKE_SA, kalles de to første utvekslinger IKE_SA_INIT-utveksling og IKE_AUTH-utveksling. Når IKE_SA-en er etablert, er de etterfølgende IKE-utvekslingene enten CREATE_CHILD_SA-utvekslinger eller INFORMATIONAL-utvekslinger. I en normal prosedyre er det en enkel IKE_SA_INIT-utveksling og en enkel IKE_AUTH-utveksling (totalt fire meldinger) for å etablere IKE_SA-en og den første CHILD_SA-en. Likevel kan det i noen eksepsjonelle tilfeller være mer enn én av hver av disse utvekslingene. Ikke desto mindre må alle IKE_SA_INIT-utvekslinger være fullført før noen annen utvekslingstype, så må alle IKE_AUTH-utvekslinger bli fullført, og bare da kan ethvert antall CREATE_CHILD_SA- og INFORMATIONAL-utvekslinger finne sted i enhver rekkefølge.
Den første utvekslingen til IKE-sesjonen (det vil si IKE_SA_INIT) forhandler sikkerhetsparametrene for IKE_SA-en, sender "engangstall" ("nonces, number used once", det vil si tidsvariabler som forhindrer at gamle kommunikasjoner blir gjenbrukt i gjentakelsesangrep), og sender Diffie-Hellman-verdier. Den andre utvekslingen til en IKE-sesjon (det vil si IKE_AUTH) overfører identiteter, påviser kjennskap til hemmelighetene som korresponderer til de to identitetene, og setter opp en SA for den første (og ofte bare) AH og/eller ESP CHILD_SA-en. Følgelig vil det i mange tilfelle bare være nødvendig med en enkel CHILD_SA mellom IPSec-endepunktene og derfor vil det ikke være noen ytterligere utvekslinger.
Likevel kan påfølgende utvekslinger brukes til å etablere ytterligere CHILD_SA-er mellom det samme autentiserte paret av endepunkter (det vil si CREATE_CHILD_SA-utveksling) og for å utføre driftsfunksjoner, som å fjerne en SA, rapportere feiltilstander, osv. (det vil si INFORMATIONAL-utveksling). Disse etterfølgende utvekslinger kan ikke bli brukt før de innledende utvekslinger er fullført.
Hver IKE-melding begynner med IKE-hodet (HDR), som følges av en eller flere IKE-nyttelaster som hver er identifisert ved et "Neste nyttelast"-felt i den foregående nyttelasten. Nyttelaster er prosessert i den rekkefølgen de kommer til syne i en IKE-melding ved å påkalle den passende prosesseringsrutinen ifølge det "Neste nyttelast"-feltet i IKE-hodet og deretter ifølge "Neste nyttelast"-feltet i IKE-nyttelasten selv, inntil et "Neste nyttelast"-felt lik null indikerer at ingen nyttelaster følger. En INFORMATIONAL-forespørsel uten nyttelast (annet enn den tomme krypterte nyttelasten krevd av syntaksen) er vanlig å bruke som en sjekk på om det er liv i en sesjon.
Det finnes en mengde nyttelasttyper som er definert for å bli brukt i IKE-meldinger med ulike formål. Disse nyttelasttypene er allokerte verdier mellom 0 og 255. Nyttelast-typeverdi 0 indikerer at det ikke finnes noen neste nyttelast. Nyttelast-typeverdier 1 - 32 brukes i kodetildelinger for IKEvl. Nyttelast-typeverdier 33 - 48 er definert for IKEv2 for å utføre ulike handlinger i IKE-sesjonshåndteringen. Nyttelast-typeverdier 49 - 127 er reservert for IANA for framtidig tildeling i IKEv2-en. Nyttelast-typeverdier 128-255 er for privat bruk mellom gjensidig enige parter.
I tillegg til autentisering ved bruk av offentlig nøkkelsignaturer og delte hemmeligheter, støtter IKE en autentiseringsprosess som bruker framgangsmåter fra utvidbar autentiseringsprotokoll ("Extensible Authentication Protocol, EAP") definert i RFC 3748. EAP-en tilveiebringer en asymmetrisk autentiseringsprosess, designet med den hensikten å være en brukerautentisering for en server, for hvilken grunn EAP-en, hvis den er brukt innenfor IKE-en, må bli brukt i samsvar med en offentlig nøkkelsignaturbasert autentisering av den som svarer den som spør, det vil si fra serveren til terminalklienten. Følgelig er EAP-en implementert i IKE som tilleggs IKE_AUTH-utvekslinger som må fullføres for å kunne initialisere IKE_SA-en. IKE omfatter en separat nyttelasttype definert for EAP-en (nyttelast-typeverdi 48).
EAP-autentiseringen kan fortrinnsvis benyttes hvis det finnes en separat autentiseringsserver, for eksempel et såkalt AAA-system ("Autentisering, Autorisering, Avregning"), forbundet med IPSec-gateway-en. AAA-serverne kan for eksempel være RADIUS- eller Diameterservere, som støtter EAP-autentiseringen. Autentiseringssignaleringen utføres ved bruk av en protokoll som er spesifikk for det benyttede AAA-systemet. Følgelig sjekker serveren at brukeridentifikasjons-informasjonen er korrekt, og hvis den aksepteres, vil serveren autorisere tilgang til systemet beskyttet av IPSec-gateway-en og velge en IP-adresse, L2TP-parametre osv. AAA-serveren vil også bli underrettet når sesjonen starter og stopper, slik at brukeren kan faktureres som følge derav, eller dataene kan bli brukt for statistiske formål.
I et typisk tilfelle ved bruk av VPN, som illustrert i Fig. 1, forbinder en beskyttet klientterminal 100 (typisk en mobilterminal eller en bærbar nettstreifende datamaskin) seg tilbake til sitt bedriftsnettverk 106 gjennom en IPSec-beskyttet tunnel. Aksessnettverket 102 kan være ethvert ledningsbasert eller trådløst kommunikasjonsnettverk som støtter IP-basert kommunikasjon, for eksempel offentlig internett, et 2G/3G mobilt nettverk, eller et WLAN. Tunnelen er etablert via en tunnel-gateway 108 (for eksempel en IPSec-gateway) i operatørnettverket 104 til en IPSec-gateway 112 i bedriftsnettverket 106. Både operatørnettverket 104 og bedriftsnettverket 106 kan videre omfatte AAA-systemer 110, 114 for autentisering og autorisering av terminalen. Brukeren av terminalen kan bruke denne tunnelen bare for å få tilgang til informasjon i bedriftsnettverket eller all terminaltrafikken kan tunnelleres tilbake gjennom bedriftsnettverket for å kunne ha fordelen av beskyttelsen tilveiebrakt skapt av en bedrifts brannvegg. I begge tilfeller trenger terminalen en IP-adresse assosiert med bedriftens IPSec-gateway slik at pakker som returneres til den først vil gå til sikkerhets-gateway-en og så sendes via tunnelen tilbake.
En utførelsesform av en autentiserings-/autorisasjonsframgangsmåte som utnytter IKEv2 for å utføre en tofaset autentisering/autorisasjon av en klientterminal, det vil si mot en operatørs AAA-system i den første fasen og mot et eksternt AAA-system i den andre fasen, er videre illustrert i signaleringsdiagrammet i Fig. 2. Operasjonen starter når etableringen av en ende-til-ende IPSec-tunnel mellom terminalen (CL) og operatørens IPSec-gateway (OP GW) er startet. Dette omfatter den grunnleggende IKEv2-forhandlingen beskrevet over, det vil si IKE_SA_INIT-utveksling (200) og IKE_AUTH-utveksling (202) blir utført mellom terminalen og IPSec-gateway-en.
Imidlertid, siden den faktiske autorisasjonen er utført i operatørens AAA-system (OP AAA), involverer initialiseringen av IKE_SA-en ytterligere IKE_AUTH-utvekslinger (204). Hvis AAA-autorisasjonen er utført som EAP-autorisasjon, er EAP nyttelasttype brukt for å innkapsle autorisasjonsinformasjonen og overføre (206) den til AAA-systemet. AAA-systemet sjekker (208) autorisasjonsinformasjonen, og hvis den aksepteres (det vil si at det er slått fast at abonnenten er en kunde hos operatøren og at han/henne har anskaffet tjenesten), så vil operatørens AAA-system innvilge tilgang til nettverket og bekrefte dette via IPSec-gateway-en til terminalen (210, 212). Da er en sikret IPSec-tunnel (214) etablert mellom terminalen og operatørens gateway.
Nå, til forskjell fra en konvensjonell IKEv2-forhandling, initierer terminalen en ny autentiserings-/autorisasjonsprosedyre på innsiden av den allerede etablerte IKE_SA (eller IPSec SA) mot en ekstern AAA-instans (for eksempel bedriftens AAA-system). Ifølge en utførelsesform er denne nye autentiserings-/autorisasjonsprosedyren utført ved bruk av IKEv2 INFORMATIONAL-utveksling
(216), for hvilken det er definert en ny nyttelasttype dedikert for dette formålet.
Følgelig transformerer (218) operatørens IPSec-gateway AAA-meldinger/protokoll båret på innsiden av denne nye IKEv2 INFORMATIONAL-utvekslingsnyttelast til en standard AAA-protokoll (for eksempel RADIUS/Diameter) som er støttet av det eksterne AAA-systemet. Så sender (220) operatørens IPSec-gateway meldinger til det eksterne AAA-systemet, som sjekker (222) autorisasjonsinformasjonen. Igjen, hvis autorisasjonsinformasjonen aksepteres av det eksterne AAA-systemet (det vil si det er slått fast at abonnenten har anskaffet denne tjenesten), så vil det eksterne AAA-systemet innvilge tilgang til det eksterne nettverket (for eksempel et bedriftsnettverk). Så bekrefter (224) det eksterne AAA-systemet den innvilgede tilgangen til terminalen ved bruk av en svarmelding ifølge den standard AAA-protokollen. Hvis henholdsvis autorisasjonsinformasjonen ikke aksepteres av det eksterne AAA-systemet (det vil si at abonnenten ikke har anskaffet tjenesten), så nekter det eksterne AAA-systemet tilgang til det eksterne nettverket, noe som også bekreftes for terminalen ved bruk av en svarmelding.
Operatørens IPSec-gateway tolker AAA-svarmeldingen og transformerer (226) den til en IKEv2 INFORMATIONAL-utveksling med dedikert nyttelast, etter hvilket operatørens IPSec-gateway fullfører IKEv2 INFORMATIONAL-utvekslingen (228). Hvis tilgang tillates, etablerer (230) operatørens IPSec-gateway en annen tunnel til IPSec-gateway-en til det eksterne nettverket. Det skal noteres at denne tunnelen mellom operatørens IPSec-gateway og IPSec-gateway-en til det eksterne nettverket ikke nødvendigvis må være en IPSec-tunnel, men den kan også være enhver IP-tunnel. På den andre side, hvis tilgangen ble nektet, starter operatørens IPSec-gateway nedkobling av den allerede etablerte IPSec-tunnelen mellom operatørens gateway og terminalen.
Følgelig, i den tofasede autentiserings-/autoriseringsprosedyren ifølge utførelsesformen, utføres den andre autentiserings-/autorisasjonsprosedyren på innsiden av den allerede etablerte IKE_SA, hvorved meldingene i den andre fasen med fordel blir kryptert ved IKE_SA-en. Følgelig trenger ikke den andre autentiserings-/autorisasjonsprosedyren og andre fasetunnelen nødvendigvis å støtte hele IPSec; det kreves bare at IKEv2-forhandlingen støttes av gateway-ene.
Ifølge en utførelsesform er gateway-ene og de etablerte tunnelene "stateful" i den utstrekning at en forandring i en tunnel også påvirker den andre tunnelen. Dette kan lett implementeres, siden operatørens IPSec-gateway tolker AAA-svarmeldingene og styrer driften ifølge dette. For eksempel hvis tunnelen til den første fasen blir fjernet, blir også tunnelen til andre fasen fjernet, og omvendt. Likeledes, hvis autentiserings-/autorisasjonsprosedyren til den andre fasen resulterer i nektelse av tilgang, fjernes tunnelen fra første fase automatisk. Den faktiske fjerningsprosedyren til den gjenværende tunnelen kan initieres enten av operatørens IPSec-gateway eller klientterminalen. Dette er en betydelig fordel sammenlignet med eksisterende løsninger, hvori fjerningen av tunnelen mellom terminalen og operatørens gateway krever en separat påvisning av ikke-eksistensen til den eksterne tunnelen.
Ifølge en utførelsesform utføres autentiserings-/autorisasjonsprosedyren til den andre fasen ved bruk av INFORMATIONAL-utvekslingen til IKEv2-en, hvori en ny nyttelasttype er definert for denne dedikerte hensikt. IKEv2-en omfatter nyttelasttyper for transport av forskjellige AAA-mekanismer, for eksempel EAP-nyttelasten og CERT-nyttelasten. Ifølge en utførelsesform kan disse eksisterende nyttelasttyper bli gjenbrukt ved bestemmelse av ny nyttelasttype i den betydningen at strukturen til det nye nyttelastformatet ellers kan være lik disse EAP- og CERT-nyttelasttypene, men det "Neste Nyttelast"-feltet som definerer nyttelast-typeverdiene må naturligvis være forskjellige.
Følgelig er to mulige nyttelast-typeformater framlagt i Figurene 3a og 3b. Nyttelast-typeformatet i Fig. 3a gjenbruker strukturen i EAP-nyttelast-formatet hvori den første bitgruppen av meldingshodet omfatter "Neste Nyttelasf-feltet, hvori nyttelast-typeverdien er definert. Den nye nyttelasttypen kan fortrinnsvis være allokert enhver ubrukt verdi av nyttelast-typeverdiene 49 - 127 som er reservert til IANA. Den andre bitgruppen i meldingshodet omfatter flagg, hvori det "kritiske" flagget (C) settes til null (C=0) hvis senderen ønsker at mottakeren skal droppe denne nyttelasten (stille forkasting), hvis den ikke forstår nyttelast-typekoden i "Neste Nyttelasf-feltet, og det settes til en (C=l) hvis senderen ønsker at mottakeren skal forkaste hele meldingen og svare med en feilmelding UNSUPPORTET_CRITICAL_PAYLOAD i varslings-nyttelasten hvis den ikke forstår nyttelasttypen. Resten av flaggene i den andre bitgruppen blir sendt som nuller og de ignoreres ved mottak. De neste to bitgruppene er allokert for "Nyttelast lengde"-feltet, som indikerer lengden på den gjeldende nyttelasten, omfattende det generiske nyttelasthodet. Hodet er så etterfulgt av den faktiske AAA-meldingen. Fig. 3b viser et annet mulig nyttelast-typeformat for den nye nyttelasttypen, hvori nyttelast-typeformatet gjenbruker strukturen til CERT-nyttelastformatet. Sertifikat-nyttelasten tilveiebringer et middel for å transportere sertifikater eller annen autentiseringsrelatert informasjon via IKE. Følgelig er det mulig å utnytte sertifikater i autentiseringsprosedyren mot det eksterne AAA-systemet. Sertifikat-nyttelaster er omfattet i en utveksling hvis sertifikater er tilgjengelige for senderen. Igjen, de fire bitgruppene i hodefeltet er lik de i nyttelast-typeformatet framlagt i Fig. 3a. CERT-nyttelastformatet omfatter "CERT-koding"-feltet som indikerer typen på sertifikatet eller sertifikatrelatert informasjon inneholdt i "sertifikatdata"-feltet. Nyttelast-typeverdien for den originale sertifikat-nyttelasten er 37, men for å kunne atskille denne nye nyttelasttypen, er det fortrinnvis allokert en hvilken som helst av de ubrukte nyttelast-typeverdiene 49 -127.
Ifølge en utførelsesform er det definert i det minst en ny feilmelding og en samsvarende feilkode er definert for IKEv2. I IKEv2-en er feilsituasjoner informert om ved bruk av varslings-nyttelasten, som kan forekomme i enhver svarmelding, som vanligvis spesifiserer hvorfor en forespørsel ble forkastet, i en INFORMATIONAL-utveksling, eller i enhver annen melding for å indikere sender om mulighetene eller for å modifisere betydningen av forespørselen. IKEv2-en omfatter en feilmelding AUTHENICATION_FAILED, som har feilkoden 24. Følgelig er den nye feilmeldingen fortrinnsvis definert som SECOND_AUTENTICATION_FAILED, og den kan bli allokert enhver av de ubrukte feilkodeverdiene i området 0 -16383.
Ved å bruke de ovenfor beskrevne nyttelastmeldingene forblir den tofasede autentiserings-/autoriseringsprosedyren med fordel bakover kompatibel med den gjeldende IKEv2-en, det vil si hvis en klientterminal eller en gateway ikke støtter de nye meldingene, kan IKEv2-protokollen fremdeles bli brukt; kun trekkene i den andre autentiserings-/autoriseringsprosedyren er ikke tilgjengelige. Ikke desto mindre er det klart for en fagutdannet mann at nyttelastmeldingene ovenfor bare er tilfeldige eksempler på egnete nyttelastmeldinger for INFORMATIONAL-utveksling, og at det er ulike andre muligheter for å definere meldingene.
Videre, ifølge en utførelsesform, kan den tofasede autentiserings-/autoriseringsprosedyren beskrevet ovenfor utføres slik at istedenfor for å bruke INFORMATIONAL-utveksling, defineres en helt ny utvekslingstype for prosedyren.
Oppfinnelsen er med fordel anvendelig ved autentiseringen/autoriseringen av en klientterminal via enhver tilgangsteknologi designet for den tredje generasjons (3GPP) eller enhver videre generasjons mobile nettverk. Oppfinnelsen er spesielt anvendelig når det gjelder å skaffe tilveie en ytterligere autentiserings-/autoriseringsprosedyre i en situasjon, hvori man får tilgang til de mobile nettverkstjenestene over en ulisensiert spektrumteknologi, inkludert Bluetooth og IEEE 802.11. Disse tilgangsystemene omfatter i det minste ulisensiert mobiltilgang ("Unlicensed Mobile Access, UMA"), 3GPP GAN og 3GPP l-WLAN. Følgelig kan operatørens IPSec-gateway beskrevet ovenfor fortrinnvis være en 3GPP l-WLAN pakkedata-gateway (PDG) omfattet i 3GPP-arkitekturen (versjon 6). Naturligvis kan et WLAN brukes som tilgangsnettverk uten noe mellomliggende mobilt nettverk.
Klientterminalene A og B kan være PC-baserte datamaskiner, kjent som slike, koblet til ethvert datakommunikasjonsnettverk, eller klientterminalene A og B kan være trådløse terminaler, lik mobile stasjoner eller PDA-innretninger, koblet til ethvert kommunikasjonsnettverk via et mobilt kommunikasjonsnettverk. Følgelig omfatter klienterminalen som illustrert i Fig. 4, minne MEM, brukergrensesnitt Ul, l/O-midler l/O for å arrangere dataoverføring med andre innretninger, og én eller flere sentrale prosessorenheter CPU som omfatter i det minste en prosessor. Minnet MEM omfatter en permanent del for lagring av applikasjoner som styrer sentralprosessorenheten CPU og andre data som skal lagres og en flyktig del beregnet for bruk for midlertidig dataprosessering.
Handlingene til utførelsesformene er fortrinnsvis automatisert i klientterminalene i den utstrekning at ingen brukerinngripen er påkrevet under autentiserings-/autoriseringsprosedyren ifølge utførelsesformene. Trinnene ifølge utførelsesformene kan i stor grad implementeres med programkommandoer eksekvert i de sentrale prosessorenheter CPU i klientterminalen illustrert i Fig. 4. Følgelig, de nevnte midler for å utføre framgangsmåten beskrevet ovenfor er fortrinnsvis implementert som datamaskinprogramvarekode. Datamaskinprogramvaren kan bli lagret i ethvert minnemiddel, slik som harddisken på en PC eller en CD-ROM-plate, fra hvor det kan bli lastet inn i minnet til klientterminalen. Datamaskinprogramvaren kan også lastes opp gjennom et nettverk, for eksempel ved bruk av en TCP/IP-protokollstakk. Det er også mulig å bruke maskinvareløsninger eller en kombinasjon av maskinvare- og programvareløsninger for å implementere oppfinnelsens midler.
Claims (5)
1. Framgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal (100;CL) i et nettverk som omfatter en operatørs gateway (108; OP GW) og en operatørs autentiseringsserver (110; OP AAA), og en ekstern gateway (112; Corp GW) og en ekstern autentiseringsserver (114; Corp AAA), hvori de nevnte autentiseringsserverne er enige om en gjensidig autentiseringsprotokoll, framgangsmåten omfatter: etablering (200 - 214) av en første sikker tunnel mellom klientterminalen (100; CL) og operatørens gateway (108; OP GW) ved bruk av en krypteringsnøkkel-utvekslingsprotokoll; autentisering (208) og autorisering av klientterminalen (100; CL) i operatørens autentiseringsserver (110; OP AAA); initiering (216) av en andre autentiserings-/autorisasjonsprosedyre fra klientterminalen (100;
CL) mot den eksterne autentiseringsserveren (114; Corp AAA) ved bruk av den første sikrede tunnelen; transformering (218), i operatørens gateway (108; OP GW), av i det minste én melding involvert i den andre autentiserings-/autorisasjonsprosedyren for å være i samsvar med nevnte gjensidige autentiseringsprotokoll; autentisering (222) og autorisering av klientterminalen (100, CL) i den eksterne autentiseringsserveren (108: OP GW) (114; Corp AAA); etablering (230) av en andre tunnel mellom operatørens gateway (108; OP GW) og den eksterne gateway-en (112; Corp GW) (114; Corp AAA),karakterisert vedat krypteringsnøkkel-utvekslingsprotokollen er internett nøkkelutvekslings-protokollen ("Internet Key Exchange, IKE"), hvorved framgangsmåten videre omfatter: kryptering av meldingene involvert i den andre autentiserings-/autoriseringsprosedyren, når de overføres mellom klientterminalen (100; CL) (108; OP GW) og den eksterne autentiseringsserveren (114; Corp AAA) (100; CL), ved den etablerte IKE-sikkerhetsassosiasjon (SA), hvilke meldinger omfatter minst en IKEv2 IN FORMATION AL meldingsutveksling med et dedikert nyttelastfelt for en andre autentiserings-/autoriseringsprosedyre; og styring av driften av den første sikrede tunnelen og den andre sikrede tunnelen i operatørens gateway (108; OP GW) slik at som svar på fjerning av den første tunnelen, blir den andre tunnelen også fjernet automatisk.
2. Framgangsmåte ifølge patentkrav 1,karakterisert vedat som svar på at den andre autentiserings-/autorisasjonsprosedyren ikke lykkes, indikeres feilen i en feilmelding med et dedikert nyttelastfelt for feilen i den andre autentiserings-/autorisasjonsprosedyren.
3. Kommunikasjonsnettverk, hvilket omfatter: en klientterminal (100; CL) (108; OP GW); en operatørs gateway (108; OP GW) og en operatørs autentiseringsserver (110; OP AAA); en ekstern gateway (112; Corp GW) og en ekstern autentiseringsserver (114; Corp AAA); i hvilket nettverk det er enighet om en gjensidig autentiseringsprotokoll mellom nevnte autentiseringsservere, hvori klientterminalen (100; CL) og operatørens gateway (108; OP GW) er anordnet til å etablere en første sikret tunnel mellom hverandre ved bruk av en krypteringsnøkkel-utvekslingsprotokoll; operatørens autentiseringsserver (110; OP AAA) er anordnet til å autentisere og autorisere klientterminalen (100; CL); klientterminalen (100; CL) er anordnet til å initiere en andre autentiserings-/autorisasjonsprosedyre mot den eksterne autentiseringsserveren (114; Corp AAA) ved bruk av den første sikrede tunnelen; operatørens gateway (108; OP GW) er anordnet til å transformere i det minste én melding involvert i den andre autentiserings-/autorisasjonsprosedyren til å være i samsvar med nevnte gjensidige autentiseringsprotokoll; den eksterne autentiseringsserveren (114; Corp AAA) er anordnet til å autentisere og autorisere klientterminalen (100; CL); operatørens gateway (108; OP GW) er anordnet til å etablere en andre tunnel til den eksterne gateway-en (112; Corp GW) for å innvilge tilgang til terminalen,karakterisert vedat krypteringsnøkkel-utvekslingsprotokollen er internett nøkkelutvekslings-protokollen ("Internet Key Exchange, IKE"); meldingene involvert i den andre autentiserings-/autorisasjonsprosedyren, når de overføres imellom klientterminalen (100; CL) og den eksterne autentiseringsserveren (114; Corp AAA), er anordnet til å bli kryptert av den etablerte IKE-sikkerhetsassosiasjon (SA), hvilke meldinger omfatter minst en IKEv2 IN FORMATION AL meldingsutveksling med et dedikert nyttelastfelt for en andre autentiserings-/autoriseringsprosedyre; og operatørens gateway (108; OP GW) er anordnet til å styre driften av den første sikrede tunnelen og den andre sikrede tunnelen slik at som svar på fjerningen av den første tunnelen, vil den andre tunnelen også bli fjernet automatisk.
4. Kommunikasjonsnettverk ifølge patentkrav 3,karakterisert vedat som svar på at den andre autentiserings-/autorisasjonsprosedyren ikke lykkes, er feilen anordnet til å bli indikert i en feilmelding med et dedikert nyttelastfelt for feilen til den andre autentiserings-/autorisasjonsprosedyren.
5. En terminal (100; CL) for et kommunikasjonsnettverk, hvor terminalen omfatter: midler (CPU, MEM) for etablering av en første sikret tunnel mellom terminalen og en operatørs gateway som brukeren krypteringsnøkkel-utvekslingsprotokoll; hjelpemiddel l/O for å motta en autentiserings-/autorisasjonsbekreftelse fra en operatørs autentiseringsserver;
midler (CPU, MEM) for å initiere en andre autentiserings-/autorisasjonsprosedyre mot en ekstern autentiseringsserver ved bruk av en sikret tunnel; midler (l/O) for å motta en autentiserings-/autorisasjonsbekreftelse fra en ekstern autentiseringsserver; midler (CPU, MEM) for å etablere en andre tunnel mellom operatørens gateway og den eksterne gateway-en,karakterisert vedat krypteringsnøkkel-utvekslingsprotokollen er internett nøkkelutvekslings-protokollen ("Internet Key Exchange, IKE"); hvori terminalen videre omfatter: midler (CPU, MEM) for å kryptere meldinger som er involvert i den andre autentiserings-/autorisasjonsprosedyren ved den etablerte IKE-sikkerhetsassosiasjonen (SA), hvilke meldinger omfatter minst en IKEv2 INFORMATIONAL meldingsutveksling med et dedikert nyttelastfelt for en andre autentiserings-/autoriseringsprosedyre; og midler (l/O) for å styre operatørens gateway, som svar på oppdagelse av at den første sikrede tunnelen, er anordnet til å starte fjerning av den andre tunnelen automatisk.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20055442A FI119863B (fi) | 2005-08-22 | 2005-08-22 | Etäasiakkaan aitouden ja oikeuksien varmistaminen |
| PCT/FI2006/050361 WO2007023208A1 (en) | 2005-08-22 | 2006-08-21 | Authentication and authorization of a remote client |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| NO20080870L NO20080870L (no) | 2008-04-21 |
| NO338710B1 true NO338710B1 (no) | 2016-10-03 |
Family
ID=34896341
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| NO20080870A NO338710B1 (no) | 2005-08-22 | 2008-02-19 | Fremgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal, et kommunikasjonsnettverk og en terminal for et kommunikasjonsnettverk |
Country Status (5)
| Country | Link |
|---|---|
| EP (2) | EP2159988B1 (no) |
| DK (1) | DK2159988T3 (no) |
| FI (1) | FI119863B (no) |
| NO (1) | NO338710B1 (no) |
| WO (1) | WO2007023208A1 (no) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2475236A (en) | 2009-11-09 | 2011-05-18 | Skype Ltd | Authentication arrangement for a packet-based communication system covering public and private networks |
| GB2475237B (en) | 2009-11-09 | 2016-01-06 | Skype | Apparatus and method for controlling communication signalling and media |
| GB201005454D0 (en) | 2010-03-31 | 2010-05-19 | Skype Ltd | Television apparatus |
| US9717090B2 (en) | 2010-12-31 | 2017-07-25 | Microsoft Technology Licensing, Llc | Providing notifications of call-related services |
| US8963982B2 (en) | 2010-12-31 | 2015-02-24 | Skype | Communication system and method |
| US10404762B2 (en) | 2010-12-31 | 2019-09-03 | Skype | Communication system and method |
| US10291660B2 (en) | 2010-12-31 | 2019-05-14 | Skype | Communication system and method |
| US9019336B2 (en) | 2011-12-30 | 2015-04-28 | Skype | Making calls using an additional terminal |
| GB201301452D0 (en) | 2013-01-28 | 2013-03-13 | Microsoft Corp | Providing notifications of call-related services |
| US10609008B2 (en) | 2017-06-08 | 2020-03-31 | Nxp Usa, Inc. | Securing an electronically transmitted communication |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050165953A1 (en) * | 2004-01-22 | 2005-07-28 | Yoshihiro Oba | Serving network selection and multihoming using IP access network |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4201466B2 (ja) * | 2000-07-26 | 2008-12-24 | 富士通株式会社 | モバイルｉｐネットワークにおけるｖｐｎシステム及びｖｐｎの設定方法 |
-
2005
- 2005-08-22 FI FI20055442A patent/FI119863B/fi active IP Right Grant
-
2006
- 2006-08-21 EP EP09177452.1A patent/EP2159988B1/en not_active Not-in-force
- 2006-08-21 DK DK09177452.1T patent/DK2159988T3/en active
- 2006-08-21 WO PCT/FI2006/050361 patent/WO2007023208A1/en active Application Filing
- 2006-08-21 EP EP06778544A patent/EP1917776A1/en not_active Ceased
-
2008
- 2008-02-19 NO NO20080870A patent/NO338710B1/no not_active IP Right Cessation
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050165953A1 (en) * | 2004-01-22 | 2005-07-28 | Yoshihiro Oba | Serving network selection and multihoming using IP access network |
Non-Patent Citations (3)
| Title |
|---|
| CHARLIE KAUFMAN: "Internet Key Exchange (IKEv2) Protocol", Draft-IETF-IPSec-IKEv2-17, Internet Engineering Task Force, IETF, CH, 2004-09-23., Dated: 01.01.0001 * |
| KARA A.: "Secure remote access from office to home", Communications Magazine, IEEE, Piscataway, USA, vol.: 39, Issue: 10, Oct. 2001, pages 68-72., Dated: 01.01.0001 * |
| MALKIN, G.S.: "Dial-in virtual private networks using layer 3 tunneling", Local Computer Networks, 1997. IEEE, Proceedings, 22nd Annual Conference on Minneapolis, USA 2-5 November 1997, pages 555-561., Dated: 01.01.0001 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FI119863B (fi) | 2009-04-15 |
| WO2007023208A1 (en) | 2007-03-01 |
| DK2159988T3 (en) | 2018-06-25 |
| EP1917776A1 (en) | 2008-05-07 |
| EP2159988A1 (en) | 2010-03-03 |
| EP2159988B1 (en) | 2018-03-21 |
| FI20055442A (fi) | 2007-02-23 |
| NO20080870L (no) | 2008-04-21 |
| FI20055442A0 (fi) | 2005-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| NO338710B1 (no) | Fremgangsmåte for å tilveiebringe en autentisering/autorisering av en ekstern klientterminal, et kommunikasjonsnettverk og en terminal for et kommunikasjonsnettverk | |
| Patel et al. | Securing L2TP using IPsec | |
| US8639936B2 (en) | Methods and entities using IPSec ESP to support security functionality for UDP-based traffic | |
| FI120072B (fi) | Pakettidatan lähettäminen verkon yli tietoturvaprotokollaa käyttäen | |
| EP2561663B1 (en) | Server and method for providing secured access to services | |
| EP3860039B1 (en) | System, method and devices for mka negotiation between the devices | |
| US20170155625A1 (en) | Scalable intermediate network device leveraging ssl session ticket extension | |
| US20110113236A1 (en) | Methods, systems, and computer readable media for offloading internet protocol security (ipsec) processing using an ipsec proxy mechanism | |
| US20130276060A1 (en) | Methods and systems for fallback modes of operation within wireless computer networks | |
| US9516065B2 (en) | Secure communication device and method | |
| US20080137863A1 (en) | Method and system for using a key management facility to negotiate a security association via an internet key exchange on behalf of another device | |
| EP2055078B1 (en) | Method and apparatus for interworking authorization of dual stack operation | |
| US20040010713A1 (en) | EAP telecommunication protocol extension | |
| EP3510803B1 (en) | Secure link layer connection over wireless local area networks | |
| WO2021068777A1 (en) | Methods and systems for internet key exchange re-authentication optimization | |
| US20020178356A1 (en) | Method for setting up secure connections | |
| US7702799B2 (en) | Method and system for securing a commercial grid network over non-trusted routes | |
| TWI448128B (zh) | 用於雙堆疊操作互通授權的方法及裝置 | |
| KR100596397B1 (ko) | 모바일 ＩＰｖ６ 환경에서 라디우스 기반 ＡＡＡ 서버의세션키 분배 방법 | |
| Patel et al. | RFC3193: Securing L2TP using IPsec | |
| Xenakis et al. | Alternative Schemes for Dynamic Secure VPN Deployment in UMTS | |
| CN115278660A (zh) | 接入认证方法、装置及系统 | |
| Zorn et al. | Network Working Group B. Patel Request for Comments: 3193 Intel Category: Standards Track B. Aboba W. Dixon Microsoft | |
| Vintilă | Potential Applications of IPsec in Next Generation Networks | |
| Hoeper | EMU Working Group S. Hartman, Ed. Internet-Draft Painless Security Intended status: Standards Track T. Clancy Expires: May 2, 2012 Electrical and Computer Engineering |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM1K | Lapsed by not paying the annual fees |