europeisk patentskrift

Transkript

1 (12) Oversettelse av europeisk patentskrift (11) NO/EP B1 (19) NO NORGE (1) Int Cl. H04L 29/06 (06.01) H04M 1/72 (06.01) H04W 12/06 (09.01) H04W 76/00 (09.01) H04W 76/02 (09.01) Patentstyret (21) Oversettelse publisert (80) Dato for Den Europeiske Patentmyndighets publisering av det meddelte patentet (86) Europeisk søknadsnr (86) Europeisk innleveringsdag (87) Den europeiske søknadens Publiseringsdato () Prioritet , US, P (84) Utpekte stater AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR (73) Innehaver Nokia Corporation, Keilalahdentie 4, 0210 Espoo, FI-Finland (72) Oppfinner ZHANG, Dajiang, No. 26, Building 111Nan Hu Xi Yuan, Beijing, CN-Kina LI, Changhong, Makslahdentie 1 B 3, FI-021 Espoo, FI-Finland ERONEN, Pasi, Leikosaarentie 29 c 3, FI Helsinki, FI-Finland (74) Fullmektig Tandbergs Patentkontor AS, Postboks 170 Vika, 0118 OSLO, Norge (4) Benevnelse Støtte av anrop uten UICC (6) Anførte publikasjoner US-B WO-A-0/99 WO-A-0/112488

2 1 Beskrivelse Bakgrunn for oppfinnelsen: Oppfinnelsens fagfelt [0001] Oppfinnelsen vedrører en fremgangsmåte og anordning for understøttelse av anrop som for eksempel IMS nød-anrop fra en abonnentterminal som ikke har noen abonnentidentitetsmodul (uten UICC) i I-WLAN-nettverk. Beskrivelse av beslektet teknikk [0002] Veksten i offentlige WLAN-nettverk gir en mulighet for riktig utstyrte terminalenheter (eller brukerutstyr (UE) i tredje generasjons terminologi) å få tilgang til cellulære nettverk hjemme og besøke nettverk via slike WLAN. WLAN som gir en slik interaktiv («interworking») funksjonalitet blir derfor referert til som I-WLAN. I- WLAN-nettverk er koblet til offentlige landmobilnett (PLMN) som muliggjør at UE får tilgang til nettverkstjenester på hjemmenettverk (HPLMN) og besøkte nettverk (VPLMN). [0003] Trådløse enheter vil være bundet av loven til å støtte nødanrop. Rapportering av en krise bør være mulig selv når ingen sesjon er aktiv over en bestemt radiokanal til en multitilgangsenhet, det vil si at brukeren for tiden ikke er knyttet til noen radio, eller brukeridentitetsmodul (»Subscriber Identity Module» - SIM) eller «Universal Mobile Telecommunications system SIM» (USIM) er for tiden ikke satt inn i enheten. [0004] Vanligvis er nødrapporter initiert ved å trekke en bryter eller ringe et nødnummer generelt behandlet på en prioritert måte, slik at tilgangen er lett tilgjengelig for å aktivere krisealarm. Imidlertid kan trådløse enheter ha upålitelige funksjoner eller ikke brukes pålitelig i et nødstilfelle, slik at bruk av passord eller andre autentiseringsprosesser ikke gjøres på riktig måte. Videre kan en trådløs enhet være i nærheten av et nettverk eller tilgangsnettverk, men ikke være knyttet til dette nettverket. Derfor er autorisasjon ikke nødvendig før alarmen aktiveres eller kontakt gjøres til alarmsentralen for å fremskynde nødanropet. [000] I-WLAN (interaktiv trådløst lokalt nettverk) tilgang er definert i spesifikasjonene TS 23,234, 33,234, 24,234 og 29,234 av den tredje «Generation Partnership Project» (3GPP). For direkte IP-tilgang (såkalt Scenario 2) og 3GPP IP-tilgang (såkalt Scenario 3), en utvidbar autentiseringsprotokoll («Extensible Authentication Protocol» - EAP) SIM / AKA (autentiserings og nøkkelavtale «Authentication and Key Agreement») prosedyren brukes til autentisering, der autorisasjon er gjort basert på en abonnentsjekk mot informasjon holdt på en abonnentdatabase, for eksempel, en hjemmeabonnentserver (HSS). [0006] W-APN nettverksidentifikator for støtte til IMS nødanrop skal skje i form av en

3 2 felles, reservert nettverksidentifikator i form av "sos", for eksempel "sos.wapn.mnc012.mcc34.pub.3gppnetwork.org", som definert i TS [0007] Denne typen W-APN indikerer til et WLAN-tilgangsnettverk eller til en 3GPP AAA server at tilgang er nødvendig for et nødanrop, eller en annen prioritert samtale. [0008] For øyeblikket er det ingen enighet om løsning i 3GPP ennå for hvilken type autentiseringsmetode og bruker-id som skal brukes for brukere uten UICC (brukere uten et universelt integrert kretskort) for å få tilgang til I-WLAN for IMS nødsituasjon. [0009] Det er mulig å bruke et felles brukernavn og felles passord for alle brukere i I- WLAN for IMS nødanrop uten UICC. [00] I det midlertidige dokument S av 3GPP TSG SA WG2 Arkitektur, - 9 september 0, beskrives en «Voice over Internet Protocol» (VoIP) nødanrop-støtte, der VoIP nødanrop er støttet via en WLAN ved hjelp av en pseudo IMSI («International Mobile Subscriber Identity») for å legge til rette for WLAN-tilgang. Pseudo IMSI kan deretter brukes til å lage en brukerspesifikk pseudo-nettverkstilgangsidentifikator (NAI) som skal brukes for første tilgang og autentiseringsprosedyren. Pseudo IMSI består av en unik kombinasjon av mobil landskode (MCC) og mobilnettkode (MNC) og tall fra den internasjonale mobilutstyrsidentitet (IMEI). VPLMN utlyst av WLAN kan enten alle være i stand til å støtte autentisering ved hjelp av pseudo NAI for nødetatene eller kan bli presentert for en UE i en prioritert rekkefølge som indikerer evne og vilje til å støtte dette. VPLMN vil da behandle UE som en midlertidig hjemmeabonnent og enten droppe autentisering og autorisasjon (AAA) eller sørge for at det virker. [0011] Men også i dette tilfellet, kan sesjonen ikke fortsettes. 3 4 [0012] I dagens TS 23,234, er kravet for å støtte IMS nødanrop å gi WLAN UE IP bæreevne for å få tilgang til IMS nødanrop for tilfeller både med UICC og uten UICC. Videre kan autentisering (i) droppes fullstendig eller (ii) å bruke en dummy eller nullautentiseringsmetode. [0013] Dermed er det for tiden ingen pålitelig mekanisme spesifisert for brukerens IMS nødanrop over I-WLAN uten UICC. Og det er ikke noen definisjon av bruker-id som kan brukes av brukere uten UICC, som er nødvendig for å danne NAI (sammen med W-APN). [0014] Dokument US 6, 97, 060 B1 beskriver en metode for etablering av en samtale i et cellulært mobilt nettverk, der det er mulig å etablere en slik samtale når et SIM-kort eller annen identifiseringsinformasjon for brukeren kan utledes. For dette, foreslås det å bruke standardiserte eller standardidentiteter i stedet for de som normalt gis av en SIM. [001] Dokument WO 0/ A2 beskriver en fremgangsmåte for understøttelse av nødanrop i et trådløst lokalnettverk. Dette dokumentet D1 beskriver spesielt en

4 3 identifikator for å identifisere et anrop som et nødanrop, der også ytterligere informasjon som plasseringen er inkludert. SAMMENFATNING AV OPPFINNELSEN 1 [0016] Derfor er det et formål med den foreliggende oppfinnelse å løse problemet nevnt ovenfor, og å tilveiebringe en pålitelig mekanisme for å håndtere anrop som for eksempel IMS nødanrop fra en bruker uten UICC i I-WLAN systemet. [0017] Dette formål løses ved en fremgangsmåte som angitt i krav 1, eller ved en fremgangsmåte som angitt i krav 4, eller alternativt ved et apparat som angitt i krav 9, eller ved et apparat som angitt i krav 13. [0018] Derfor, i henhold til kravene, er EAP / TLS-autentisering utført av en prosedyre (autentiseringsmetode eller protokoll) som ikke utfører en klientautentisering, men utfører en serverautentisering. [0019] På denne måten kan nødanrop fra abonnentterminaler uten UICC håndteres sikkert. KORT BESKRIVELSE AV TEGNINGENE [00] Oppfinnelsen er beskrevet ved å henvise til de vedføyde tegningene, der: Fig. 1 viser et meldingssignaleringsdiagram i henhold til en første utførelsesform av oppfinnelsen, og Fig. 2A til 2D basiskonfigurasjoner av nettverkselementer som er involvert i de utførelsesformer av den foreliggende oppfinnelse. DETALJERT BESKRIVELSE AV DEN FORETRUKNE UTFØRELSESFORM 2 3 [0021] I det etterfølgende er foretrukne utførelsesformer av den foreliggende oppfinnelse beskrevet ved å henvise til de vedføyde tegninger. [0022] Ifølge den foreliggende utførelsesform er det foreslått å bruke en utvidet autentiseringsprotokoll transportlagssikkerhet (EAP-TLS) som autentiseringsmetode i I-WLAN for Brukere uten UICC i tilfelle en IMS nødsituasjon. EAP-TLS kan nemlig droppe klientautentisering. Men serverautentisering er fortsatt tilgjengelige. Det betyr at det fortsatt er mulig å få nøkler for videreføring og bruke koding hvis det er nødvendig. På denne måten, er ingen endringer i WLAN AN nødvendig. [0023] En detaljert signalsekvensen for et nødanrop til en Brukere uten UICC er vist i fig. 1. Det skal bemerkes at bare de viktigste nettverkselementer i denne sekvensen er vist, nemlig en brukerenhet (UE), et WLAN-tilgangsnettverk (AN), som kan være et enkelt nettverkselement eller distribuerte elementer, en pakkedataport (PDG) og en autorisasjons- og regnskaps- (AAA) server.

5 4 [0024] I trinn 1, etableres forbindelsen mellom WLAN brukerenheten (UE) og WLAN tilgangsnettet (AN), ved hjelp av en trådløs LAN-teknologi spesifikk prosedyre [002] I trinn 2, sender WLAN AN en EAP forespørsel/ identitet til WLAN UE. Det bemerkes at EAP-pakker transporteres over Wireless LAN-grensesnittet innkapslet i en protokoll spesifikk for trådløs LAN-teknologi. [0026] I trinn tre, sender WLAN UE en EAP respons / identitetsmelding. WLAN UE sender en brukeridentitet, i samsvar med nettverkstilgangsidentifikator (NAI) formatet som er angitt i 3GPP TS 23,003. Dataområdedelen av NAI i brukeridentiteten inneholder det nød-spesifikke dataområdet. Det betyr, som nevnt ovenfor, at dataområdet omfatter "sos", f.eks. WLAN UE identiteten uten UICC kan være IMEI, MAC-adresse eller IP-adresse tildelt av WLAN AN (som et eksempel på et tilgangsnettverkselement) sammen med WLAN AN info, som vil bli beskrevet i det følgende i mer detalj. [0027] I trinn 4, blir meldingen rutet mot riktig 3GPP autentisering, autorisering og rapportering (AAA) server basert på den dataområdedelen av NAI. Rutingsbanen kan omfatte én eller flere AAA-proksier (ikke vist i figuren). [0028] Det skal bemerkes at også en diameter henvisning kan anvendes for å finne AAA-serveren. [0029] I trinn, mottar 3GPP AAA Server EAP respons / identitetspakke som inneholder terminalens identitet. Med dataområdedelen av NAI i brukeridentiteten inneholdende det nød-spesifikke dataområde som definert i 3GPP TS 23,003, identifiserer 3GPP AAA serveren at brukeren ber om et nødanrop, basert på den mottatte identitet. 3GPP AAA serveren skal vise et nød-tilgangsflagg. [00] Identifikatoren til det WLAN radionettverket og MAC-adressen til WLAN UE skal også være mottatt av 3GPP AAA serveren i den samme meldingen. [0031] I trinn 6, initierer 3GPP AAA serveren autentisering ved hjelp av EAP-TLS, der klientautentisering er utelatt. Det vil si at ingen abonnentidentitet som sådan (dvs. som det ville bli i tilfelle av en abonnent med en UICC) sjekkes. [0032] I trinn 7, videresender WLAN AN EAP forespørsel / TLS til WLAN UE. [0033] I trinn 8, svarer WLAN UE med EAP respons / TLS. [0034] I trinn 9, videresender WLAN AN EAP respons / TLS til 3GPP AAA Server. [003] I trinn, er en hovedsesjonsnøkkel (MSK) utledet fra TLS hovednøkkel, jfr. RFC [0036] I trinn 11, sender 3GPP AAA serveren EAP suksess melding til WLAN AN. WLAN AN kan lagre nøklingsmaterialet (MSK) som kan brukes i forbindelse med det autentiserte WLAN UE.

6 [0037] I trinn 12, er EAP suksessmeldingen videresendt til WLAN UE [0038] I trinn 13, utveksler WLAN UE og PDG de første par meldinger, kjent som IKE_SA_INIT (se TS 33,324, for eksempel), der PDG og WLAN UE forhandler om kryptografiske algoritmer, utveksler «nonces» og utfører en «Diffie-Hellman» utveksling. [0039] I trinn 14, sender WLAN UE uten UICC brukeridentitet (i Idi-nyttelasten) og nød- W-APN informasjon (i Idr nyttelasten) i denne første meldingen av IKE_AUTH fase, og begynner forhandling av barnesikkerhets forbindelser. WLAN UE indikerer av dataområdedel i sin NAI til PDG at forespørselen om tilkobling er for nødanrop og at den ønsker å bruke EAP over IKEv2. [00] Brukeridentiteten skal være kompatibel med (NAI) formatet som er angitt i Nettverkstilgangsidentifikatoren IETF RFC 4282 (desember 0 "The Network Access Identifier"). Ifølge IETF RFC 46 (desember 0 "Internet Key Exchange (IKEv2) Protocol»), skal den delte hemmeligheten generert i en EAP utveksling (MSK), når de brukes over IKEv2, brukes til å generere AUTH parametere. [0041] Hvis WLAN UE Remote IP-adresse må konfigureres dynamisk, skal WLAN UE deretter sende konfigurasjonsnyttelast (CFG_REQUEST) innenfor IKE_AUTH forespørselsmeldingen for å få en ekstern IP-adresse. [0042] I trinn 1, sender PDG autentiseringsforespørselsmelding med et tomt EAP attributtverdi-par (AVP) til 3GPP AAA serveren, som inneholder brukerens identitet. PDG skal omfatte en parameter som indikerer at autentiseringen blir utført for tunneletablering. Dette vil bidra til at 3GPP AAA serveren kan skille mellom autentiseringer for WLAN-tilgang og autentiseringer for tunneletablering. [0043] I trinn 16, skal 3GPP AAA serveren sjekke om nød-tilgangsflagget er vist for brukeren. Hvis nød-tilgangsflagget er satt og W-APN ikke er det for beredskap som definert i 3GPP TS 23,003, skal resultatkoden settes til DIAMETER_AUTHORIZATION_REJECTED. [0044] Når alle kontroller er vellykket, sender 3GPP AAA serveren Autentiseringssvar inkludert en EAP suksess og viktig materiale til PDG. Denne nøkkelen materialet skal bestå av master sesjonsnøkkel (MSK) generert i løpet av autentiseringsprosessen. Når Wm-grensesnittet (PDG-3GPP AAA serveren) er implementert ved hjelp av Diameter skal MSK bli innkapslet i EAP-hovedsesjonsnøkkelparameteren, som definert i referanse RFC 72 (August 0: "Diameter Extensible Authentication Protocol (EAP) Application"). [004] I trinn 17, skal MSK brukes av PDG for å kontrollere AUTH-parametere for å autentisere IKE_SA_INIT fasemeldingene, slik det er angitt i referanse IETF RFC 46 (desember 0 "Internet Key Exchange (IKEv2) Protocol)". [0046] I trinn 18, svarer PGD med sin identitet og et sertifikat. Den fullfører også

7 6 forhandlinger mellom barnesikkerhetsforbindelser. EAP suksessmeldingen videresendes også til WLAN UE [0047] I det følgende blir det beskrevet hvordan brukerens identitet (som anvendt i trinn 3 og 13, for eksempel) kan utformes. [0048] Hvis et felles brukernavn / passord gitt til alle brukere for IMS nødanrop uten UICC, er problemet hvordan man skal definere et slikt navn / passord, og hvis noen bevisst utfører et falskt nødanrop, er det ingen måte å spore det basert på felles navn / passord. [0049] I henhold til den foreliggende utførelsesform, er tre typer av identiteter foreslått for en UE uten UICS: adresse International Mobile Equipment identitet (IMEI), medium tilgangsstyring (MAC) og IP-adresse. [000] Spesielt i tilfellet av at 3GPP begrenser forbindelsen slik at den skal være fra en mobil terminal (dvs. fra en terminal, der et SIM-kort kan innføres i den), og deretter skal IMEI eller hashet IMEI benyttes. IMEI kan anvendes i en utydeliggjort form siden lengden av IMEI er 1 bytes, som kanskje ikke er egnet for alle tilfeller. IMEI eller hashet IMEI brukes deretter som brukeridentitet på trinn 3 og 14 i fig. 1. [001] Fordelen med å bruke hashet IMEI på dette trinnet er at det kan forhindre etterligning. UE kan bruke hashet IMEI på dette trinn 3 og bruker den originale komplette IMEI på trinn 14. Så selv en angriper kan tyvlytte på hashet IMEI og bruke den til å starte et nytt nødanrop, kan han få riktig IMEI som skal brukes på trinn 14. Den korrekte hashede IMEI vil ikke genereres ved PDG hvis PDG mottar en feil IMEI fra en angriper på trinn 14. Det betyr, at når en hashet IMEI er inkludert i EAP respons / identitet i trinn 3, kan en angriper muligvis få denne hashede IMEI ved å lytte på den trådløse forbindelsen og kunne bruke den til å feste PDG på trinn 14. Derfor, i tilfelle en ikke hashet full IMEI brukes i «AUTH_request» i trinn 14, da, selv om angriperen var i stand til å få hashet IMEI (i trinn 3), kan han / hun ikke bruke den til å angripe PDG, siden han ikke vet den fulle IMEI. [002] Alternativt, i tilfelle 3GPP tillater andre WLAN UE for eksempel PDA eller «notebook» å utføre IMS nødanrop, kan MAC-adressen brukes på følgende måter, på trinn 3 og 14: 1. MAC-adressen. Hver WLAN UE burde ha en unik MAC-adresse. Hver WLAN UE burde ha en unik MAC-adresse. Lengden av IDen er den korteste. 2. MAC-adresse + WLAN AN ID (SSID). Dette kan gi lokasjonen av nødanropet til å kjenne lokasjonen av krisen, eller å spore falske anrop. Hvis en angriper bruker en annen MAC-adresse i samme WLAN AN, vil det bli oppdaget. Alternativt er det mulig å bruke en hashet (MAC-adresse + WLAN AN ID (SSID)). 3. Lokal IP-adresse (tildelt av WLAN AN) + WLAN AN ID (SSID). Dette kan gi lokasjonen av nødanropet, slik at det er mulig å spore falske anrop.

8 7 Hvis en angriper bruker en annen IP-adresse i samme WLAN AN, vil det bli oppdaget. Alternativt kan også en hashet kombinasjon av lokal IP-adresse + WLAN AN ID anvendes [003] Når en UE kobler til WLAN AN for å få en tilkobling ifølge scenario 2, kan den bruke en brukeridentifikasjon på trinn 3, for eksempel, «brukerid@sos.wapn.mnc012.mcc34.pub.3gppnetwork.org». Det betyr, at i en første melding (trinn 3), anvender abonnentterminalen brukeridentifikasjonen. Som svar på dette, kan AAAserveren får UE MAC / IP-adresse og WLAN AN info fra WLAN AN. Dermed som respons på dette, i trinn, kan AAA-serveren danne bruker-id fra MAC / IP (og WLAN AN info) mottatt fra WLAN AN. [004] Når UE setter opp en forbindelse ifølge scenario 3 med PDG, siden dataområdedelen i sin NAI kan indikere til PDG at tilkoblingsforespørselen er for nødanrop og den ønsker å bruke EAP over IKEv2, og at det allerede er delt nøkkel (MSK) mellom WLAN UE en AAA-server, kan WLAN UE generere AUTH parametere og sende til PDG. PDG kan få MSK fra AAA-serveren for å sjekke AUTH. På denne måten er ikke flere trinn nødvendige som i normalbanen 3. [00] Derfor, i henhold til foreliggende utførelse, er en autentiseringsmetode som EAP-TLS autentiseringsmetode, som kan hoppe over en klientautentisering, brukt i I- WLAN for brukere uten UICC i tilfelle av nødanrop. [006] På denne måte er en serverautentisering fortsatt tilgjengelig. Serverautentiseringen muliggjør generering av delt MSK mellom WLAN UE og AAA-serveren for å bruke EAP over IKE2. [007] Således er autentisering bare for serveren, ikke for klienten. Slik at nettverket ikke avviser nødanrop. Det er to grunner til autentiseringen. Det ene er å holde WLAN AN uendret. Ellers skal WLAN AN sjekke NAI til UE for å identifisere om det er for nødanrop. Den andre er å generere MSK til å bli brukt i scenario 3 prosedyren. [008] Videre er det mulig å sette opp kryptert tunnel til PDG hvis AAA-serveren ikke har autentiseringsvektorer for denne terminalen (tilfellet uten UICC). Nemlig, som beskrevet ovenfor, MSK kan genereres fra TLS hovednøkkel som angitt i RFC 4346 i UE og en AAA-serveren. PDG kan få MSK fra 3GPP AAA-serveren. Så den krypterte tunnelen kan opprettes mellom UE og PDG. [009] Det er ikke nødvendig å endre på WLAN AN. AAA-serveren må danne bruker- ID fra MAC / IP (og WLAN AN ID). [0060] Dermed kan en pålitelig og godkjent forbindelse etableres i et tilfelle uten UICC. [0061] I det følgende er en andre utførelse av oppfinnelsen beskrevet, der det betraktes et tilfelle der en angriper kan starte falske nødanrop.

9 8 1 2 [0062] I detalj, ifølge TS er samtidige økter tillatt i både scenario 2 og 3 (dvs. via IP-tilgang og 3GPP-tilgang), og tallene for de samtidige sesjoner er basert på operatørenes politikk. Forespørselen om å ha samtidige sesjoner er gyldig spesielt i tilfellet med delt WLAN UE. For eksempel kan en bruker bruke sin mobilterminal for å besøke et nettsted av operatør og bruke sin «notebook» for å få tilgang til VPN til hans firma på samme tid. [0063] Men når en bruker utfører et IMS nødanrop gjennom en terminal uten UICC (som beskrevet i den første utførelse, for eksempel), er det urimelig for ham å ha samtidige IMS nødanrop. Hvis det skjer, kan det andre være en svindel og kan være vandalisme mot beredskapen. Slik at samtidige IMS nødanrop med en terminal uten UICC skal være forbudt. [0064] I henhold til den foreliggende utførelsesform, er en tilsvarende styring utført med PDG, dvs. W-APN for nødanrop, i stedet for en AAA-server fordi WLAN UE ikke kan motta EAP suksessmeldingen (ved trinn 12 på fig. 1) og starter ikke scenario 3 prosedyrer. [006] Når PDG mottar forespørselen fra WLAN UE (på trinn 14), bør det sjekkes om det allerede finnes en sesjon for brukeren. Hvis ja, skal den nye forespørsel avises i stedet for å akseptere den. Begrunnelsen er at det er vanskelig for en angriper å vite offerets ID på forhånd, men kan snappe den opp når UE setter opp forbindelse ifølge scenario 2. [0066] Fra UE ID, kan PDG vite at det er et IMS nødanrop uten UICC. [0067] Derfor, i henhold til den foreliggende utførelsesform, kan dobbelt nødanrop registreres pålitelig og forhindres. 3 4 [0068] I det følgende er nettverkselementene som er involvert i de ovenfor beskrevne utførelsesformer beskrevet ved å henvise til fig. 2A til 2D. Det skal bemerkes at på fig. 2A til 2D er kun de grunnleggende elementer vist for å forenkle tegningene. [0069] Fig. 2A viser den grunnleggende konfigurasjonen av en abonnentterminal A. abonnentterminalen A omfatter en kontroller A1, og en transceiver A2. Kontrolleren A2 kan omfatte en prosessor, og ulike typer av minneenheter som for eksempel RAM, ROM, eller lignende. Et datamaskinprogram, kan lagres i minnet, og kan omfatte programkodedeler for utførelse av fremgangsmåten i henhold til utførelsesformene. Dette dataprogram kan være lagret på et registreringsmedium slik som en CD-ROM, for eksempel, og kan være direkte lastbare inn i arbeidsminnet til kontrolleren. Alternativt kan dataprogram lastes via nettverket inn i minnet på kontrolleren. [0070] Fig. 2B viser den grunnleggende konfigurasjonen av AAA-serveren B, som omfatter en kontroller B1 og en transceiver B2. Kontrolleren B1 kan være konfigurert på en lignende måte som kontrolleren. Det betyr, at også kontrolleren B2 kan omfatte en CPU og forskjellige typer minneenheter som for eksempel RAM, ROM, en harddisk, en CD- eller DVD-ROM-leser eller lignende. Et dataprogram kan

10 9 tilveiebringes for AAA-serveren på en lignende måte som beskrevet ovenfor. Transceiveren B2 kan omfatte én eller flere grenseflater, ved hvilke en forbindelse via et nettverk til andre nettverkselementer kan tilveiebringes. [0071] Fig. 2C viser en grunnleggende konfigurasjon av PGD C, som er lik konfigurasjonen til AAA-serveren B, slik at beskrivelsen av disse ikke gjentas. [0072] Fig. 2D viser en grunnleggende konfigurasjon av WLAN AN, som også er lik konfigurasjonen til AAA-serveren B, slik at den detaljerte beskrivelsen av disse er utelatt. [0073] Oppfinnelsen er ikke begrenset til de utførelsesformer som er beskrevet ovenfor, og forskjellige modifikasjoner er mulige. 1 2 [0074] Videre er abonnentterminalidentifikatoren ikke begrenset til IMEI. Det vil si at en hvilken som helst annen identifikator som identifiserer en terminal kan benyttes. [007] Videre er autentiseringssekvensen og nettverkselementene som er involvert ikke begrenset til de detaljer som er vist i fig. 1 og beskrevet ovenfor. [0076] Videre er IMS nødanrop som er nevnt ovenfor kun et eksempel på anrop uten UICC. Spesielt kan det være andre situasjoner der et anrop uten UICC kunne tillates. For eksempel kan et anrop uten UICC være tillatt av et nettverk for å kontakte en operatør til leverandøren.

11 Patentkrav En fremgangsmåte som omfatter å initiere en sesjon fra en abonnentterminal, der abonnentterminalen ikke omfatter en bestemt brukeridentifikasjonsmodul; å utforme en midlertidig identifikasjon av abonnentterminalen; basert i det minste delvis på midlertidig identifikasjon, å utføre en serverautentisering uten å utføre klientautentisering, der en autentiseringsprosedyre som er benyttet er en utvidbar autentiseringsprotokoll transportlagsikkerhets-protokoll, EAP / TLS, og en klientautentiseringsdel til den utvidede autentiseringsprotokollens nivåsikkerhetsprotokoll er utelatt. 2. Fremgangsmåte ifølge krav 1 eller krav 1, der den midlertidige identifikasjonen består av en bruker-id og et dataområde, der dataområdet omfatter en spesifikk indikasjon for en sesjon initiert av abonnentterminalen. 3. Fremgangsmåte ifølge krav 2, der brukeridentifikasjon er opprettet basert i hvert fall delvis på én av: en terminal-id, en medietilgangskontrolladresse for abonnentterminalen, og en internettprotokolladresse tildelt av et tilgangsnettverkselement til abonnentterminalen. 4. Fremgangsmåte som omfatter å sende en autentiseringsforespørsel til en abonnentterminal for å autentisere en sesjon initiert fra abonnentterminalen; å motta en autentiseringsrespons / identitetsmelding fra abonnentterminalen, der autentiseringsrespons / identitetsmelding omfatter en midlertidig identifikasjon for abonnentterminalen, og å autentisere sesjonen basert i det minste delvis på den midlertidige identifisering av abonnentterminalen, der en serverautentisering er utført, men klientautentiseringen er utelatt, der en autentiseringsprosedyre som er benyttet er en utvidbar autentiseringsprotokoll transportlagsikkerhetsprotokollen, EAP / TLS, og en klientautentiseringsdel til den utvidede autentiseringsprotokollens nivåsikkerhetsprotokoll er utelatt.. Fremgangsmåten ifølge krav 4, videre omfattende å generere en delt hovedsesjonsnøkkel som kan brukes til brukerdatakoding. 6. Fremgangsmåten ifølge krav 4, der den midlertidige identifikasjon omfatter en brukeridentifikasjon og et dataområde, der dataområdet omfatter en spesifikk indikasjon for sesjonen initiert av abonnentterminalen, der abonnentterminalen ikke omfatter en spesifikk brukeridentifikasjonsmodul. 7. Fremgangsmåten ifølge krav 6, der brukeridentifikasjonen er dannet basert i hvert fall delvis på én av: en internasjonal mobilutstyrsidentitet, en medietilgangskontrolladresse, og en internettadresse tildelt av et tilgangsnettverkselement til abonnentterminalen.

12 11 8. Fremgangsmåte ifølge ethvert av kravene 4-7, videre omfattende å sjekke om det allerede finnes en sesjon for abonnentterminalen, og avvise en ny sesjon i tilfelle det allerede finnes en sesjon. 9. Et apparat, som omfatter minst én prosessor, og minst ett minne inkludert dataprogramkode for minst ett minne og dataprogramkode konfigurert til, med den minste ene prosessor, å få apparatet til å utføre i det minste følgende: å initiere en sesjon, der apparatet ikke omfatter en spesifikk brukeridentifikasjon modul; å danne en midlertidig identifikasjon, og basert minst på midlertidig identifikasjon, å utføre en serverautentisering uten å utføre klientautentisering, der en autentiseringsprosedyre som er benyttet er en utvidbar autentiseringsprotokoll transportlagsikkerhetsprotokollen, EAP / TLS, og en klientautentiseringsdel til den utvidede autentiseringsprotokollens nivåsikkerhetsprotokoll er utelatt.. Apparat ifølge krav 9, der en hovedsesjonsnøkkel genereres som kan anvendes for kryptering av brukerdata. 11. Apparat ifølge krav 9, der den midlertidige identifikasjon består av en bruker-id og et dataområde, der dataområdet omfatter en spesifikk identifikasjon for en nødanropssesjon initiert av apparatet. 12. Apparat ifølge krav 11, der brukeridentifikasjon er opprettet basert i det minste delvis på én av: en internasjonal mobilutstyrsidentitet, en medietilgangskontrolladresse til abonnentterminalen og en internettadresse tildelt av et tilgangsnettverkselement til abonnentterminalen 13. Et apparat som omfatter minst én prosessor, og minst ett minne inkludert dataprogramkode for minst ett minne og dataprogramkode konfigurert til, med minst én prosessor, å få apparatet til å utføre i det minste følgende: å sende en autentiseringsforespørsel til en abonnentterminal; å motta en autentiseringsrespons / identitetsmelding fra abonnentterminalen, der autentiseringsresponsen / identitetsmeldingen omfatter en midlertidig identifikasjon for abonnentterminalen, og å gjennomføre en autentisering basert i hvert fall delvis på midlertidig identifikasjon der en serverautentisering utføres mens klientautentiseringen er utelatt, der

13 12 en autentiseringsprosedyre som benyttes er en utvidbar autentiseringsprotokoll transportlagsikkerhetsprotokollen, EAP / TLS, og en klientautentiseringsdel til den utvidede autentiseringsprotokollens nivåsikkerhetsprotokoll er utelatt Apparat ifølge krav 13, der den midlertidige identifikasjon består av en bruker-id og et dataområde, der dataområdet omfatter en spesifikk identifikasjon for en sesjon initiert av abonnentterminalen, der abonnentterminalen ikke omfatter en spesifikk brukeridentifikasjonsmodul. 1. Apparat ifølge krav 14, der brukeridentifikasjon er dannet basert i hvert fall delvis på en av: en internasjonal mobilutstyrsidentitet, en medietilgangskontrolladresse til abonnentterminalen og en internettadresse tildelt av et tilgangsnettverkselement til abonnentterminalen. 16. Anordning ifølge et av kravene 13-1, der prosessoren er konfigurert til å sjekke om det allerede finnes en sesjon for abonnentterminalen, og å avvise en ny sesjon i tilfelle det allerede finnes en sesjon. 17. Et dataprogramprodukt på et datamaskinlesbart medium, der dataprogrammet er konfigurert til å styre en prosessor for å utføre en fremgangsmåte, fremgangsmåten ifølge ethvert av kravene 1 til 7.

14 13

15 14