(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Transkrypt

1 RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP Urząd Patentowy Rzeczypospolitej Polskiej (96) Data i numer zgłoszenia patentu europejskiego: (97) O udzieleniu patentu europejskiego ogłoszono: Europejski Biuletyn Patentowy 2013/50 EP B1 (13) (51) T3 Int.Cl. H04L 29/06 ( ) H04M 1/725 ( ) H04W 12/06 ( ) H04W 76/00 ( ) H04W 76/02 ( ) (54) Tytuł wynalazku: Wspieranie połączeń bez UICC (30) Pierwszeństwo: US P (43) Zgłoszenie ogłoszono: w Europejskim Biuletynie Patentowym nr 2009/48 (45) O złożeniu tłumaczenia patentu ogłoszono: Wiadomości Urzędu Patentowego 2014/04 (73) Uprawniony z patentu: Nokia Corporation, Espoo, FI (72) Twórca(y) wynalazku: PL/EP T3 DAJIANG ZHANG, Beijing, CN CHANGHONG LI, Espoo, FI PASI ERONEN, Helsinki, FI (74) Pełnomocnik: rzecz. pat. Grażyna Palka JWP RZECZNICY PATENTOWI DOROTA RZĄŻEWSKA SP. J. ul. Żelazna 28/30 Sienna Center Warszawa Uwaga: W ciągu dziewięciu miesięcy od publikacji informacji o udzieleniu patentu europejskiego, każda osoba może wnieść do Europejskiego Urzędu Patentowego sprzeciw dotyczący udzielonego patentu europejskiego. Sprzeciw wnosi się w formie uzasadnionego na piśmie oświadczenia. Uważa się go za wniesiony dopiero z chwilą wniesienia opłaty za sprzeciw (Art. 99 (1) Konwencji o udzielaniu patentów europejskich).

2 18829/14/P-RO/GP EP Opis Tło wynalazku Dziedzina wynalazku Wspieranie połączeń bez UICC [0001] Wynalazek dotyczy sposobu i urządzenia do wspierania połączeń, takich jak połączenia alarmowe IMS (Internetworking Management System, system zarządzania współdziałaniem międzysieciowym) z terminala abonenta, niemającego modułu identyfikacji abonenta ( UICC-less (bez UICC) w sieci dostępu I-WLAN) (UICC, Universal Integrated Circuit Card, inteligentna karta do terminali mobilnych; I-WLAN, Interworking Wireless Local Area Network, współdziałająca międzysieciowo bezprzewodowa lokalna sieć komputerowa). Opis stanu techniki [0002] Rozprzestrzenianie się publicznych sieci WLAN zapewnia możliwość uzyskania przez odpowiednio wyposażone urządzenia końcowe (lub urządzenia użytkownika (UE) w nomenklaturze 3-ciej generacji) dostępu do komórkowych sieci macierzystych i sieci odwiedzanych poprzez takie sieci WLAN. Sieci WLAN, które zapewniają taką funkcjonalność współdziałania międzysieciowego są więc nazywane sieciami I-WLAN. Sieci I-WLAN są podłączone do publicznych sieci mobilnych operatorów telekomunikacyjnych (PLMN, public land mobile network) zapewniających urządzeniom UE dostęp do usług sieciowych w sieciach macierzystych (HPLMN, Home-PLMN) i sieciach odwiedzanych (VPLMN, Visited-PLMN). [0003] Urządzenia bezprzewodowe będą zobowiązane prawnie do wspierania połączeń alarmowych. Zgłaszanie zagrożenia powinno być możliwe nawet, gdy nie jest aktualnie aktywna sesja w danym kanale radiowym urządzenia wielodostępowego, tj. użytkownik nie jest aktualnie połączony z żadnym modułem radiowym lub modułem identyfikacji abonenta (SIM, subscriber identity module), albo SIM uniwersalnego mobilnego systemu telekomunikacyjnego (USIM, universal mobile telecommunications system SIM) nie jest aktualnie włożony do urządzenia. [0004] Zazwyczaj zgłoszenia zagrożeń, inicjowane przez pociągnięcie przełącznika lub połączenie się z numerem alarmowym, są ogólnie traktowane zgodnie z priorytetem, tak że dostęp jest ułatwiony dla wszczęcia alarmu o zagrożeniu. Jednak urządzenia bezprzewodowe mogą nie mieć niezawodnych funkcji lub nie mogą być użyte w sposób niezawodny podczas zagrożenia, tak że wprowadzanie haseł lub realizacja innych procedur uwierzytelniania mogą nie być przeprowadzone prawidłowo. Co więcej, urządzenie bezprzewodowe może znajdować się w pobliżu sieci lub sieci dostępu, ale nie być powiązane z tą siecią. Stąd, uwierzytelnianie nie jest potrzebne przed wszczęciem alarmu lub skontaktowaniem się z centrum zagrożeń w celu wykonania połączenia alarmowego. [0005] Dostęp I-WLAN (interactive wireless local area network, interaktywna bezprzewodowa lokalna sieć komputerowa) jest zdefiniowany w specyfikacji TS ,

3 , i dla konsorcjum 3GPP (3rd generation partnership project). Dla bezpośredniego dostępu IP (tzw. Scenario 2 ) i dostępu 3GPP IP (tzw. Scenario 3 ) stosowana jest procedura EAP (Extensible Authentication Protocol, protokół rozszerzalnego uwierzytelniania) SIM/AKA (Authentication and Key Agreement, porozumienie w zakresie uwierzytelniania i dystrybucji klucza) dla uwierzytelniania, przy czym uwierzytelnianie jest dokonane w oparciu o zweryfikowanie abonenta względem informacji znajdującej się w bazie danych abonentów, np. w serwerze abonentów macierzystych (HSS, home subscriber server). [0006] Identyfikator sieciowy W-APN (WLAN Access Point Name, nazwa punktu dostępu WLAN) do wspierania połączeń alarmowych IMS powinien przyjąć postać powszechnego, zarezerwowanego identyfikatora sieciowego, w postaci sos, na przykład sos.wapn.mnc012.mcc345.pub.3gppnetwork.org, jak zdefiniowano w TS [0007] Ten rodzaj W-APN wskazuje sieci dostępu WLAN lub serwerowi 3GPP AAA, że potrzebny jest dostęp dla połączenia alarmowego lub innego połączenia priorytetowego. [0008] Obecnie nie ma jeszcze uzgodnionego rozwiązania w 3GPP, jaki sposób uwierzytelniania lub identyfikacji użytkownika będzie wykorzystywany dla użytkowników bez UICC (użytkowników bez uniwersalnej karty do terminali mobilnych) do uzyskania dostępu I-WLAN dla zgłoszenia IMS. [0009] Możliwe jest użycie wspólnej nazwy użytkownika i wspólnego hasła dla wszystkich użytkowników w I-WLAN dla połączeń alarmowych IMS bez UICC. [0010] W tymczasowym dokumencie S of 3GPP TSG SA WG2 Architecture, 5-9 września 2005, a Voice over Internet Protocol (VoIP) opisano wsparcie dla połączeń alarmowych, w którym połączenia alarmowe VoIP (Voice over IP, głos poprzez Internet Protocol) są wspierane poprzez WLAN dzięki użyciu pseudo IMSI (International Mobile Subscriber Identity, międzynarodowy mobilny identyfikator abonenta) dla umożliwienia dostępu WLAN. Pseudo IMSI może być wtedy użyty dla utworzenia specyficznego dla użytkownika, pseudo identyfikatora dostępu sieciowego (NAI, network access identifier) dla początkowej procedury dostępu i uwierzytelniania. Pseudo IMSI jest utworzony z unikalnej kombinacji mobilnego kodu kraju (MCC, mobile country code) i mobilnego kodu sieci (MNC, mobile network code) oraz cyfr z IMEI (international mobile equipment identity, międzynarodowy identyfikator stacji ruchomej). Sieci VPLMN zgłaszane przez WLAN mogły by wszystkie mieć zdolność wspierania uwierzytelniania z użyciem pseudo NAI dla usług alarmowych albo mogły by być zgłoszone do UE w uszeregowanej priorytetowo kolejności wskazującej zdolność i chęć wsparcia. Taka sieć VPLMN traktowała by następnie UE jako tymczasowego abonenta macierzystego i albo pominęła uwierzytelnianie i autoryzację (AAA, authentication and authorization) albo zapewniła, że się one powiodą. [0011] Jednak również w tym przypadku sesja nie może być kontynuowana. [0012] W obecnym TS , wymaganiem dla połączeń alarmowych IMS jest zapewnienie dla UE WLAN zdolności ustanowienia połączenia IP (IP bearer) dla dostępu do połączeń alarmowych IMS, zarówno w przypadkach UICC, jak i bez UICC. Ponadto uwierzytelnianie

4 3 może (i) być całkowicie pominięte lub (ii) zastosować pozorny lub zerowy sposób uwierzytelniania. [0013] Tak więc obecnie nie jest określony żaden niezawodny mechanizm dla użytkowników połączeń alarmowych IMS bez UICC poprzez I-WLAN. I nie ma definicji ID użytkownika do użycia dla użytkowników bez UICC, jakie jest potrzebne dla utworzenia NAI (razem z W- APN). [0014] W dokumencie US B1 ujawniono sposób ustanawiania połączenia w komórkowej sieci mobilnej, w którym możliwe jest ustanowienie takiego połączenia, gdy nie jest dostępna karta SIM lub inna informacja identyfikująca użytkownika. W tym celu, proponuje się użycie standaryzowanych lub domyślnych identyfikatorów w miejsce tych, które zwykle są dostarczone przez SIM. [0015] W dokumencie WO 2005/112488A2 ujawniono sposób wspierania połączeń alarmowych w bezprzewodowej lokalnej sieci komputerowej. Ten dokument D1 opisuje w szczególności identyfikator do identyfikowania połączenia, jako połączenia alarmowego, przy czym zawarta jest również dodatkowa informacja, taka jak lokalizacja. Streszczenie wynalazku [0016] Zatem celem wynalazku jest rozwiązanie wspomnianego powyżej problemu i dostarczenie niezawodnego mechanizmu do obsługi połączeń, takich jak połączenia alarmowe IMS użytkownika bez UICC w systemie I-WLAN. [0017] Cel ten jest osiągnięty przez sposób przedstawiony w zastrzeżeniu 1 lub przez sposób przedstawiony w zastrzeżeniu 4 albo alternatywnie przez urządzenie przedstawione w zastrzeżeniu 9 lub przez urządzenie przedstawione w zastrzeżeniu 13. [0018] Zatem zgodnie z zastrzeżeniami uwierzytelnianie EAP/TLS jest realizowane przez procedurę (sposób lub protokół identyfikacji), która nie przeprowadza uwierzytelniania klienta, ale przeprowadza uwierzytelnianie serwera. [0019] W ten sposób połączenia alarmowe z terminali abonenta bez UICC mogą być obsługiwane w sposób niezawodny. Krótki opis rysunków [0020] Wynalazek jest opisany przez odniesienie do załączonych rysunków, na których: Fig. 1 przedstawia schemat sygnalizacji według pierwszego przykładu wykonania wynalazku i Fig. 2A do 2D przedstawiają podstawową konfigurację elementów sieci zaangażowanych w przykładzie wykonania wynalazku. Szczegółowy opis korzystnego przykładu wykonania [0021] Poniżej są opisane korzystne przykłady wykonania wynalazku w odniesieniu do załączonych rysunków.

5 4 [0022] Według przykładu wykonania proponuje się użycie rozszerzalnego protokołu uwierzytelniania - bezpieczeństwa warstwy transportu (EAP-TLS, extensible authentication protocol - transport layer security) jako sposobu uwierzytelniania w I-WLAN, dla użytkowników bez UICC, w przypadku alarmu IMS. Mianowicie, EAP-TLS może pominąć uwierzytelnianie klienta. Jednak wciąż zapewnione jest uwierzytelnianie serwera. Oznacza to, że wciąż możliwe jest uzyskanie kluczy dla kontynuacji i szyfrowania użytkownika jeśli jest to potrzebne. W ten sposób nie są wymagane zmiany we WLAN AN. [0023] Szczegółowa sekwencja sygnałów dla połączenia alarmowego użytkowników bez UICC jest przedstawiona na Fig. 1. Należy zauważyć, że tylko główne elementy sieci w tej sekwencji są pokazane, czyli jednostka użytkownika (UE), sieć dostępu (AN, Access Network) WLAN, która może być pojedynczym elementem sieci lub elementami rozproszonymi, brama danych pakietowych (PDG, packet data gateway) i serwer autoryzacji i rozliczania (AAA, authorization and accounting). [0024] W etapie 1, ustanawiane jest połączenie A między jednostką użytkownika WLAN (UE) i siecią dostępu (AN) WLAN, z użyciem procedury specyficznej dla technologii LAN (local area Network, lokalna sieć komputerowa). [0025] W etapie 2, WLAN AN wysyła EAP Request/Identity (żądanie/tożsamość) do WLAN UE. Należy zauważyć, że pakiety EAP są przesyłane poprzez interfejs Wireless LAN ujęty w specyficznym protokole technologii Wireless LAN. [0026] W etapie 3, UE WLAN wysyła komunikat EAP Response/Identity (odpowiedź/tożsamość). WLAN UE wysyła tożsamość użytkownika, zgodną z formatem identyfikatora dostępu sieciowego (NAI) określonym w 3GPP TS Część sfery (fragment identyfikacji użytkownika w ramach organizacji) w NAI w tożsamości użytkownika jest wypełniona sferą specyficzną dla alarmu. Czyli, jak wyżej wspomniano, sfera może zawierać na przykład sos. Tożsamością UE WLAN bez UICC może być IMEI, adres MAC lub lokalny adres IP przydzielony przez WLAN AN (jako przykładowe urządzenie dostępu sieci) razem z informacją WLAN AN, jak będzie to opisane bardziej szczegółowo poniżej. [0027] W etapie 4, komunikat jest trasowany w kierunku właściwego serwera uwierzytelniania 3GPP autoryzacji i rozliczeń (AAA) w oparciu o część sfery w NAI. Ścieżka trasowania może zawierać jeden lub kilka proxy AAA (niepokazanych na figurze). [0028] Zaznacza się, że odniesienie do protokołu Diameter może być zastosowane w celu znalezienia serwera AAA. [0029] W etapie 5, serwer 3GPP AAA odbiera pakiet EAP Response/Identify, który zawiera tożsamość terminala. Gdy część sfery w NAI w tożsamości użytkownika wypełniona sferą specyficzną dla alarmu, zdefiniowanym w 3GPP TS , serwer 3GPP AAA rozpoznaje, że użytkownik zgłasza żądanie połączenia alarmowego w oparciu o odebraną tożsamość. Serwer 3GPP AAA powinien ustawić flagę Emergency_Access (dostęp alarmowy).

6 5 [0030] Identyfikator sieci radiowej WLAN i adres MAC UE WLAN również powinny być odebrane przez serwer 3GPP AAA w tym samym komunikacie. [0031] W etapie 6, serwer 3GPP AAA inicjuje uwierzytelnianie z użyciem EAP-TLS, w którym uwierzytelnianie klienta jest pomijane. Czyli, nie jest sprawdzana jako taka tożsamość abonenta (np. tak jak byłaby w przypadku abonenta z UICC). [0032] W etapie 7, WLAN AN przekazuje EAP Request/TLS do UE WLAN. [0033] W etapie 8, UE WLAN odpowiada z EAP Response/TLS. [0034] W etapie 9, WLAN AN przekazuje EAP Response/TLS do serwera 3GPP AAA. [0035] W etapie 10, MSK (master session key, główny klucz sesji) jest uzyskany z TLS master secret, porównaj RFC [0036] W etapie 11, serwer 3GPP AAA wysyła komunikat EAP Success (sukces) do WLAN AN. WLAN AN może przechowywać materiał klucza (MSK), który może być użyty w komunikacji z uwierzytelnionym WLAN UE. [0037] W etapie 12, komunikat EAP Success jest przekazywany do WLAN UE. [0038] W etapie 13, WLAN UE i PDG wymieniają pierwszą parę komunikatów, znanych jako IKE_SA_INIT (patrz na przykład TS ), w których PDG i WLAN UE negocjują algorytmy kryptograficzne, wymieniają jednorazowe identyfikatory i wykonują wymianę Diffie_Hellman. [0039] W etapie 14, bez UICC WLAN UE wysyła tożsamość użytkownika (w ładunku ldi) i informację alarmową W-APN (w ładunku ldr) w tym pierwszym komunikacie fazy IKE_AUTH i rozpoczyna negocjować child security associations (potomne powiązanie bezpieczeństwa). WLAN UE informuje PDG za pomocą części sfery w NAI, że żądanie połączenia jest dla połączenia alarmowego i że chce użyć protokołu EAP IKEv2. [0040] Tożsamość użytkownika powinna być zgodna z formatem NAI (Network Access Identifier) określonym w IETF RFC 4282 (grudzień 2005: "The Network Access Identifier"). Zgodnie z IETF RFC 4306 (grudzień 2005: "Internet Key Exchange (IKEv2) Protocol"), shared sekret generowany w wymianie EAP (MSK) gdy jest realizowana poprzez IKEv2, powinien być użyty do generowania parametru AUTH. [0041] Jeśli zdalny adres IP dla WLAN UE musi być konfigurowany dynamicznie, WLAN UE powinien wysłać ładunek konfiguracji (CFG_REQUEST) wewnątrz komunikatu żądania IKE_AUTH w celu uzyskania zdalnego adresu IP. [0042] W etapie 15, PDG wysyła komunikat żądania uwierzytelniania z pustą parą (AVP, attribute-value pair) atrybut-wartość EAP do serwera 3GPP AAA, zawierającą tożsamość użytkownika. PDG powinien zawierać parametr wskazujący, że realizowane jest uwierzytelnianie dla ustanowienia tunelu. Pomoże to serwerowi 3GPP AAA odróżnić uwierzytelnianie dla dostępu WLAN i uwierzytelnianie dla ustanowienia tunelu.

7 6 [0043] W etapie 16, serwer 3GPP AAA powinien sprawdzić, czy flaga Emergency_Access jest ustanowiona dla użytkownika. Jeśli ustanowiona jest flaga Emergency_Access i W-APN nie jest dla sytuacji alarmowej, jak zdefiniowano w 3GPP TS , Result-Code powinien być ustawiony, jako DIAMETER_AUTHORIZATION_REJECTED. [0044] Gdy wszystkie sprawdzenia są pozytywne, serwer 3GPP AAA wysyła odpowiedź uwierzytelniania zawierającą EAP Success i materiał klucza do PDG. Ten materiał klucza powinien składać się z głównego klucza sesji (MSK) wygenerowanego podczas procedury uwierzytelniania. Gdy interfejs Wm (serwer PDG-3GPP AAA) jest zaimplementowany z użyciem protokołu Diameter, MSK powinien być zapakowany w parametrze EAP-Master- Session-Key, jak zdefiniowano w dokumencie RFC 4072 (sierpień 2005: "Diameter Extensible Authentication Protocol (EAP) Application"). [0045] W etapie 17, MSK powinien być użyty przez PDG do sprawdzenia parametrów AUTH w celu uwierzytelniania komunikatów fazy IKE_SA_INIT, zdefiniowanych w dokumencie IETF RFC 4306 (grudzień 2005: "Internet Key Exchange (IKEv2) Protocol ). [0046] W etapie 18, PDG odpowiada ze swoją tożsamością i certyfikatem. Kończy również negocjowanie potomnych powiązań bezpieczeństwa (child security associations). Komunikat EAP Success jest również przekazany do WLAN UE. [0047] Poniżej opisano, jak można sformować tożsamość użytkownika (użytą przykładowo w etapach 3 i 13). [0048] Mianowicie, jeśli wspólna nazwa użytkownika/hasło zostaną dostarczone do wszystkich użytkowników dla połączenia alarmowego IMS bez UICC, problemem jest, jak zdefiniować taką nazwę użytkownika/hasło, a jeśli ktoś celowo wykonuje fałszywe połączenie alarmowe, nie ma możliwości jego wyśledzenia w oparciu o wspólną nazwę użytkownika/hasło. [0049] Według przykładu wykonania proponowane są trzy rodzaje tożsamości dla UE bez UICC: międzynarodowa tożsamość urządzenia mobilnego (IMEI), adres sterowania dostępem do nośnika (MAC, medium access control) i adres IP. [0050] W szczególności, w przypadku gdy 3GPP ograniczy połączenie w taki sposób, że powinno ono być wykonywane z terminala mobilnego (tj. z terminala, do którego może być wprowadzona karta SIM), powinna być użyta IMEI lub skrócona IMEI. IMEI może być użyta w postaci skróconej ponieważ długość IMEI wynosi 15 bajtów, co może nie być odpowiednie dla wszystkich przypadków. IMEI lub skrócona IMEI może być wtedy użyta jako tożsamość użytkownika w etapie 3 i 14 na Fig. 1. [0051] Zaletą użycia skróconej IMEI w tym etapie jest to, że może to zapobiec podszywaniu się. UE może użyć skróconej IMEI w tym etapie 3 i użyć kompletnej oryginalnej IMEI w etapie 14. Tak więc gdy ktoś nieuprawniony może podsłuchać IMEI i użyć jej do rozpoczęcia innego połączenia alarmowego, może otrzymać prawidłową IMEI do użycia w etapie 14. Prawidłowa skrócona IMEI nie będzie wygenerowana w PDG, jeśli PDG odbierze niewłaściwą IMEI od osoby nieuprawnionej w etapie 14. Czyli, gdy skrócona IMEI jest

8 7 zawarta w EAP Response/Identity w etapie 3, osoba nieuprawniona potencjalnie mogła zdobyć tą skróconą IMEI przez podsłuchiwanie w łączu bezprzewodowym i mogła jej użyć do dołączenia PDG w etapie 14. Stąd, w przypadku gdy nieskrócona pełna IMEI jest użyta w AUTH_request w etapie 14, nawet gdy osoba nieuprawniona mogła zdobyć skróconą IMEI (w etapie 3), nie może ona jej użyć do zaatakowania PDG, ponieważ nie zna pełnej IMEI. [0052] Alternatywnie, w przypadku gdy 3GPP zezwoli innym WLAN UE takim jak PDA lub notebook na wykonywanie połączeń alarmowych, adres MAC może być użyty w następujące sposoby, w etapach 3 i 14: 1) Adres MAC. Każde WLAN UE powinno mieć unikalny adres MAC. Każde WLAN UE powinno mieć unikalny adres MAC. Długość ID jest najkrótsza. 2) Adres MAC + WLAN AN ID (SSID). Może to dostarczyć lokalizację połączenia alarmowego, podającą lokalizację zagrożenia lub dla wyśledzenia fałszywych połączeń. Gdy osoba nieuprawniona użyje innego adresu MAC w tej samej WLAN AN, zostanie wykryta. Alternatywnie, możliwe jest użycie skrótu (Adres MAC + WLAN AN ID (SSID)). 3) Lokalny adres IP (przydzielony przez WLAN AN) + WLAN AN ID (SSID). Może to dostarczyć lokalizację połączenia alarmowego, tak że możliwe jest wyśledzenie fałszywych połączeń. Gdy osoba nieuprawniona użyje innego adresu IP w tej samej WLAN AN, zostanie wykryta. Alternatywnie, użyta może być skrócona kombinacja lokalnego adresu IP i WLAN AN ID. [0053] Gdy UE łączy się z WLAN AN w celu uzyskania połączenia Scenario 2, może użyć identyfikatora użytkownika w etapie 3, np. userid@sos.w-apn.mnc012.mcc345.pub.3- gppnetwork.org. Czyli w początkowym komunikacie (etap 3) terminal abonenta używa identyfikatora użytkownika. W odpowiedzi na to, serwer AAA może uzyskać adres MAC/IP dla UE i informację o WLAN z WLAN AN. Tak więc w odpowiedzi na to, w etapie 5, serwer AAA może utworzyć ID użytkownika z MAC/IP (i informacją o WLAN AN) odebranych z WLAN AN. [0054] Gdy UE ustanawia połączenie Scenario 3 z PDG, ponieważ część sfery w NAI może wskazywać PDG, że żądanie połączenia jest dla połączenia alarmowego i że chce użyć EAP poprzez IKEv2 i że jest już wymieniony klucz (MSK) między WLAN UE i serwerem AAA, WLAN UE może wygenerować parametr AUTH i wysłać do PDG. PDG może uzyskać MSK z serwera AAA dla sprawdzenia AUTH. W ten sposób nie jest wymaganych więcej etapów niż w normalnej sytuacji Scenario 3. [0055] Tak więc, według przykładu wykonania, sposób uwierzytelniania, taki jak sposób uwierzytelniania EAP-TLS, w którym można pominąć uwierzytelnianie klienta, jest użyty w I-WLAN dla użytkowników bez UICC w przypadku połączenia alarmowego. [0056] W ten sposób wciąż zapewnione jest uwierzytelnianie serwera. Uwierzytelnianie serwera umożliwia generowanie wspólnego MSK między WLAN UE i serwerem AAA do użycia EAP poprzez IKE2.

9 8 [0057] Zatem uwierzytelnianie jest wykonywane jedynie dla serwera, nie dla klienta. Tak że sieć nie odrzuci połączenia alarmowego (połączenia EM, emeergency). Są dwa cele tego uwierzytelniania. Jednym jest zachowanie niezmienionej WLAN AN. W innym przypadku WLAN AN powinien sprawdzić NAI dla UE w celu stwierdzenia, czy jest on dla połączenia alarmowego. Drugim jest generowanie MSK do użycia w procedurze Scenario 3. [0058] Ponadto możliwe jest ustanowienie szyfrowanego tunelu do PDG, jeśli serwer AAA nie ma wektorów uwierzytelniania dla tego terminala (w przypadku bez UICC). Czyli, jak to opisano powyżej, MSK może być wygenerowany z TLS master secret jak to określono w RFC 4346 w UE i serwerze AAA. PDG może uzyskać MSK z serwera 3GPP AAA. Tak więc między UE i PDG może być ustanowiony szyfrowany tunel. [0059] Nie ma potrzeby wprowadzania zmian w WLAN AN. Serwer AAA musi utworzyć ID użytkownika z MAC/IP (i WLAN AN ID). [0060] Zatem ustanowione może zostać niezawodne i uwierzytelnione połączenie w przypadku bez UICC. [0061] Poniżej opisany zostanie drugi przykład wykonania wynalazku, w przypadku którego rozpatrywana jest sytuacja, gdy osoba nieuprawniona rozpoczyna dwa połączenia alarmowe. [0062] W szczegółach, według TS jednoczesne sesje są dozwolone zarówno w Scenario 2 jak i w Scenario 3 (tj. w dostępie poprzez IP jak i w dostępie 3GPP), a liczba jednoczesnych sesji jest zależna od polityki operatora. Żądanie ustanowienia dwóch jednoczesnych sesji jest ważne szczególnie w przypadku rozdzielenia WLAN UE. Przykładowo, użytkownik może użyć jego mobilny terminal do odwiedzenia strony sieci WWW operatora i użyć notebooka dla dostępu do VPN (Virtual Private Network, wirtualna sieć prywatna) swojej firmy w tym samym czasie. [0063] Jednak gdy użytkownik wykonuje połączenie alarmowe IMS przez terminal bez UICC (jak przykładowo opisano w pierwszym przykładzie wykonania), nie jest rozsądne wykonywanie jednoczesnych połączeń alarmowych IMS. Jeśli tak się zdarzy, drugie połączenie może być fałszywe i może być przejawem wandalizmu wobec usług alarmowych. Tak więc jednoczesne połączenia alarmowe IMS poprzez terminal bez UICC powinny być zabronione. [0064] Według przykładu wykonania, odpowiednie sterowanie jest realizowane przez PDG, tj. W-APN dla połączeń alarmowych zamiast serwera AAA, ponieważ WLAN UE może nie odebrać komunikatu EAP Success (w etapie 12 z Fig. 1) i nie rozpocznie procedur Scenario 3. [0065] Gdy PDG odbierze żądanie z WLAN UE (w etapie 14), powinna sprawdzić czy nie ma już sesji dla użytkownika. Jeśli jest, powinna odrzucić nowe żądanie zamiast jego akceptacji. Powodem jest to, że trudno osobie atakującej znać ID ofiary zawczasu, ale może je przechwycić podczas ustanawiania przez UE połączenia według Scenario 2. [0066] Z ID UE, PDG może wiedzieć, że jest to połączenie alarmowe IMS bez UICC. [0067] Zatem, według przykładu wykonania, podwójne połączenia alarmowe mogą być w sposób niezawodny wykryte i zablokowane.

10 9 [0068] Poniżej opisane są elementy sieci zaangażowane w opisanych powyżej przykładach wykonania w odniesieniu do Fig. 2A do 2D. Zaznacza się, że na Fig. 2A do 2D pokazane są tylko podstawowe elementy dla uproszczenia rysunków. [0069] Fig. 2A przedstawia podstawową konfigurację terminala A abonenta. Terminal A abonenta zawiera sterownik A1 i odbiornik-nadajnik A2. Odbiornik-nadajnik A2 może zawierać CPU i różne rodzaje jednostek pamięci, takie jak RAM, ROM itp. Program komputerowy może być przechowywany w pamięci i może zawierać części kodu oprogramowania do realizacji sposobu według przykładów wykonania. Ten program komputerowy może być przechowywany na nośniku zapisywalnym, takim jak na przykład CD ROM i może być zdolny do jego bezpośredniego załadowania do pamięci roboczej sterownika. Alternatywnie, program komputerowy może być załadowany poprzez sieć do pamięci sterownika. [0070] Fig. 2B przedstawia podstawową konfigurację serwera AAA B, który zawiera sterownik B1 i odbiornik-nadajnik B2. Sterownik B1 może być skonfigurowany w podobny sposób co sterownik. Czyli również sterownik B2 może zawierać CPU i różne jednostki pamięci, takie jak RAM, ROM, dysk twardy, czytnik CD ROM lub DVD ROM itp. Program komputerowy może być dostarczony do serwera AAA w sposób podobny do opisanego powyżej. Odbiornik-nadajnik B2 może zawierać jeden lub więcej interfejsów, za pomocą których zapewnione może być połączenie poprzez sieć z innymi elementami sieci. [0071] Fig. 2C przedstawia podstawową konfigurację PDG C, która jest podobna do konfiguracji serwera AAA B więc jej opis nie będzie powtarzany. [0072] Fig. 2D przedstawia podstawową konfigurację WLAN AN, która jest również podobna do konfiguracji serwera AAA B, tak że pominięty zostanie opis szczegółowy. [0073] Wynalazek nie jest ograniczony do opisanych powyżej przykładów wykonania i możliwe są różne modyfikacje. [0074] Poza tym identyfikator terminala abonenta nie jest ograniczony do IMEI. To znaczy, że zastosowany może być jakikolwiek inny identyfikator, który w unikalny sposób identyfikuje terminal. [0075] Ponadto zaangażowane sekwencja uwierzytelniania i elementy sieci nie są ograniczone do szczegółów pokazanych na Fig. 1 i opisanych powyżej. [0076] Ponadto wspomniane powyżej połączenie alarmowe IME jest tylko przykładem połączenia bez UICC. W szczególności mogą istnieć inne sytuacje, w których połączenie bez UICC może być dozwolone. Na przykład połączenie bez UICC może być dozwolone przez sieć w celu skontaktowania się z operatorem dostawcy. Sporządziła i zweryfikowała Grażyna Palka Rzecznik patentowy

11 10 Zastrzeżenia patentowe 1. Sposób obejmujący inicjowanie sesji z terminala abonenta, przy czym terminal abonenta nie zawiera specyficznego modułu identyfikacji użytkownika; tworzenie tymczasowej identyfikacji terminala użytkownika; na bazie, przynajmniej częściowo, tymczasowej identyfikacji, realizację uwierzytelniania serwera bez wykonywania uwierzytelniania klienta, przy czym zastosowana procedura uwierzytelniania jest rozszerzalnym protokołem uwierzytelniania protokołu bezpieczeństwa warstwy transportu, EAP/TLS, a część uwierzytelniania klienta, protokołu bezpieczeństwa poziomu rozszerzalnego protokołu uwierzytelniania, jest pomijana. 2. Sposób według zastrz. 1, w którym tymczasowa identyfikacja zawiera identyfikator użytkownika i sferę, przy czym sfera zawiera specyficzną wskazówkę sesji inicjowanej przez terminal abonenta. 3. Sposób według zastrz. 2, w którym identyfikator użytkownika jest utworzony przynajmniej częściowo w oparciu o jeden spośród: identyfikatora terminala, adresu sterowania dostępem nośnika terminala abonenta i adresu Internet Protocol, przydzielonego przez element sieci dostępu terminalowi abonenta. 4. Sposób obejmujący wysyłanie żądania uwierzytelniania do terminala abonenta dla uwierzytelniania sesji zainicjowanej z terminala abonenta; odbiór komunikatu Response/Identity uwierzytelniania z terminala abonenta, przy czym komunikat Response/Identity uwierzytelniania zawiera tymczasową identyfikację terminala abonenta; i uwierzytelnianie sesji przynajmniej częściowo w oparciu o tymczasową identyfikację terminala abonenta, przy czym uwierzytelnianie serwera jest przeprowadzane, ale uwierzytelnianie klienta jest pomijane, przy czym zastosowana procedura uwierzytelniania jest rozszerzalnym protokołem uwierzytelniania protokołu bezpieczeństwa warstwy transportu, EAP/TLS, a część uwierzytelniania klienta, protokołu bezpieczeństwa poziomu rozszerzalnego protokołu uwierzytelniania, jest pomijana. 5. Sposób według zastrz. 4, obejmujący ponadto generowanie wspólnego głównego klucza sesji, który może być użyty do szyfrowania danych użytkownika. 6. Sposób według zastrz. 4, w którym tymczasowa identyfikacja zawiera identyfikator użytkownika i sferę, przy czym sfera zawiera specyficzną wskazówkę dla sesji inicjowanej przez terminal abonenta, przy czym terminal abonenta nie zawiera specyficznego modułu identyfikacji użytkownika.

12 11 7. Sposób według zastrz. 6, w którym identyfikator użytkownika jest utworzony przynajmniej częściowo w oparciu o jedno spośród: międzynarodowej tożsamości urządzenia mobilnego, adresu sterowania dostępem nośnika i adresu Internet Protocol, przydzielonego przez element sieci dostępu terminalowi abonenta. 8. Sposób według któregokolwiek z zastrz. 4-7, obejmujący ponadto sprawdzanie, czy istnieje już sesja dla terminala użytkownika i odrzucenie nowej sesji w przypadku, gdy już istnieje sesja. 9. Urządzenie zawierające co najmniej jeden procesor i co najmniej jedną pamięć zawierającą kod programu komputerowego, przy czym co najmniej jedna pamięć i kod programu komputerowego są skonfigurowany, z co najmniej jednym procesorem, do spowodowania, że urządzenie realizuje co najmniej jedno spośród inicjowania sesji, przy czym urządzenie nie zawiera specyficznego modułu identyfikacji użytkownika; tworzenia tymczasowej identyfikacji i przynajmniej częściowo w oparciu o tymczasową identyfikację, przeprowadzenia uwierzytelniania serwera bez wykonywania uwierzytelniania klienta, przy czym zastosowana procedura uwierzytelniania jest rozszerzalnym protokołem uwierzytelniania protokołu bezpieczeństwa warstwy transportu, EAP/TLS, a część uwierzytelniania klienta, protokołu bezpieczeństwa poziomu rozszerzalnego protokołu uwierzytelniania, jest pomijana. 10. Urządzenie według zastrz. 9, w którym wygenerowany jest główny klucz sesji, który może być użyty do szyfrowania danych użytkownika. 11. Urządzenie według zastrz. 9, w którym tymczasowa identyfikacja zawiera identyfikator użytkownika i sferę, przy czym sfera zawiera specyficzną wskazówkę dla sesji alarmowej, inicjowanej przez urządzenie. 12. Urządzenie według zastrz. 11, w którym identyfikator użytkownika jest utworzony przynajmniej częściowo w oparciu o jedno spośród: międzynarodowej tożsamości urządzenia mobilnego, adresu sterowania dostępem nośnika terminala abonenta i adresu internetowego, przydzielonego przez element sieci dostępu terminalowi abonenta. 13. Urządzenie zawierające co najmniej jeden procesor i co najmniej jedną pamięć zawierającą kod programu komputerowego, przy czym co najmniej jedna pamięć i kod programu komputerowego są skonfigurowane, z co najmniej jednym procesorem, do spowodowania, że urządzenie realizuje co najmniej jedno spośród: wysłania żądania uwierzytelniania do terminala abonenta; odbioru komunikatu Response/Identity uwierzytelniania z terminala abonenta, przy czym komunikat Response/Identity uwierzytelniania zawiera tymczasową identyfikację terminala abonenta i

13 12 realizacji uwierzytelniania, przynajmniej częściowo w oparciu o tymczasową identyfikację, przy czym uwierzytelnianie serwera jest wykonywane, ale uwierzytelnianie klienta jest pomijane, przy czym zastosowana procedura uwierzytelniania jest rozszerzalnym protokołem uwierzytelniania protokołu bezpieczeństwa warstwy transportu, EAP/TLS, a część uwierzytelniania klienta, protokołu bezpieczeństwa poziomu rozszerzalnego protokołu uwierzytelniania, jest pomijana. 14. Urządzenie według zastrz. 13, w którym tymczasowa identyfikacja zawiera identyfikator użytkownika i sferę, przy czym sfera zawiera specyficzną wskazówkę dla sesji inicjowanej przez terminal abonenta, przy czym terminal abonenta nie zawiera specyficznego modułu identyfikacji użytkownika. 15. Urządzenie według zastrz. 14, w którym identyfikator użytkownika jest utworzony przynajmniej częściowo w oparciu o jedno spośród: międzynarodowej tożsamości urządzenia mobilnego, adresu sterowania dostępem nośnika i adresu Internet Protocol, przydzielonego przez element sieci dostępu terminalowi abonenta. 16. Urządzenie według, któregokolwiek z zastrz , w którym procesor jest skonfigurowany do sprawdzenia, czy istnieje już sesja dla terminala użytkownika i do odrzucenia nowej sesji w przypadku, gdy sesja już istnieje. 17. Produkt programu komputerowego, wykonywany na nośniku czytelnym dla komputera, przy czym program komputerowy jest skonfigurowany do sterowania procesorem dla realizacji sposobu, sposobu według któregokolwiek z zastrz. 1 do 7. Sporządziła i zweryfikowała Grażyna Palka Rzecznik patentowy

14 13

15 14