BRPI0807096B1

BRPI0807096B1 - Método compreendendo iniciação de uma sessão de um terminal de assinante e aparelho

Info

Publication number: BRPI0807096B1
Application number: BRPI0807096-2A
Authority: BR
Inventors: Dajiang Zhang; Changhong Li; Pasi Eronen
Original assignee: Nokia Technologies Oy
Priority date: 2007-02-06
Filing date: 2008-02-05
Publication date: 2020-06-23
Also published as: PT2122983E; EP2122983B1; KR101195053B1; WO2008095918A1; US20100142499A1; JP5069320B2; CA2676997A1; MX2009008393A; KR20090116787A; AP2999A; EP2122983A1; CN101606372A; AU2008212898B2; RU2009133260A; AU2008212898A1; ES2445647T3; IL200154A0; PL2122983T3; RU2428809C2; JP2010518719A

Abstract

SUPORTE DE CHAMADAS SEM UICC A invenção refere-se a um método que compreende a iniciação de uma sessão de um terminal do assinante, cujo terminal do assinante não contém um módulo 5 específico de identificação do usuário e a autenticação da sessão com base numa autenticação temporária do terminal do assinante, usando um procedimento que executa uma autenticação do servidor, evitando a autenticação do cliente.

Description

BACKGROUND DA INVENÇÃO Campo da invenção

A invenção refere-se a um método e dispositivo para suportar chamadas tais como chamadas de emergência IMS de um terminal de assinante que não tem módulo de identidade.(Sem UICC na rede de acesso l-WLAN).

Descrição da arte relacionada

O crescimento de WLANs (Wireless LANs) oferece uma oportunidade para dispositivos terminais equipados apropriadamente (ou equipamentos do usuário (EU) na terminologia de terceira geração) para acessar redes domiciliares de celular e redes visitadas através de WLANs. WLANs que oferecem esse tipo de funcionalidade interconectada são portanto chamadas de l-WLANs. As l-WLANs são conectadas a redes públicas móveis (PLMNs) permitindo aos UEs acessar redes de serviço nas redes domésticas (HPLMNs) e redes visitadas (VPLMNs).

Dispositivos sem fio serão obrigados por lei a suportar chamadas de emergência. Relato de uma emergência deve ser possível mesmo quando nenhuma sessão esteja ativa em um determinado canal de rádio de um dispositivo de multiacesso, i. e., o usuário não está ligado a nenhum rádio ou módulo de identidade do assinante (SIM) ou um sistema de telecomunicações universal móvel SIM (USIM) não está no momento inserido no dispositivo.

Normalmente, relatos de emergência iniciados através de puxar uma chave ou chamar um número de emergência são tratados, em geral, de maneira prioritária, de modo que o acesso esteja prontamente disponível para pedir o alarme de emergência. Entretanto, dispositivos sem fio podem não ter funções confiáveis ou não ser usados confiavelmente durante uma emergência, de modo que a introdução de uma senha ou outros processos de autenticação podem não ser feitos corretamente. Mais ainda, um dispositivo sem fio pode estar perto de uma rede ou de uma rede de acesso, mas não associado a essa rede. Logo, a autorização não é necessária antes de soar o alarme ou ser feito contato com o centro de emergência, a fim de expedir a chamada de Emergência.

O acesso l-WLAN (interactive wireless local area network - rede interativa sem fio da área local) foi definido nas especificações TS 23.234, 33.234, 24.234 e 29.234 do projeto de parceria da terceira geração (3GPP). Para acesso direto IP (assim-chamado Cenário 2) e acesso 3GPP (assim-chamado Cenário 3), um procedimento de Protocolo de Autenticação Extensivo EAP) SIM/AKA (Autenticação e Acordo Chave) é usado para autenticação, quando a autorização é feita com base na verificação do assinante contra informações contidas numa base de dados do assinante, por exemplo, um servidor assinante doméstico.

O Identificador de Rede W-APN para o suporte de chamadas de Emergência IMS deverá tomar a forma de um Identificador de Rede comum, reservado, do tipo "sos", e.g. "sos.w-apn.mnc012.mcc345.pub.3gppnetwork.org", como definido em TS23.003.

Este tipo de W-APN indica a uma rede de acesso WLAN ou a um Servidor 3GPP AAA que o acesso é necessário para uma chamada de emergência ou outra chamada priorizada.

No momento, não existe ainda uma solução acordada no 3GPP para qual tipo de método de autenticação e ID do usuário usar para usuário sem UICC (usuários sem um cartão universal com circuito integrado) para acesso ao I- WLAN para emergência IMS.

É possível usar um nome de um usuário comum e uma senha comum para todos os usuários de l-WLAN para chamadas de emergência IMS sem UICC.

Em documento temporário S de Arquitetura 3GPP TSG SA WG2, de de Setembro de 2005, uma chamada de emergência de Voz sobre Protocolo de Internet (VoIP) foi descrita, em que as chamadas de emergência (VoIP) são suportadas através de uma WLAN, usando uma pseudo IMSI (Identidade de Assinante Móvel Internacional) para facilitar o acesso WLAN. O pseudo IMSI pode, pois, ser usado para criar um identificador de acesso à pseudo rede usuário-específica (NAI) para ser usado para acesso inicial e procedimentos de autenticação. O pseudo IMSI é feito de uma única combinação de código móvel do país (MCC) e código de rede móvel (MNC) e dígitos de identidade do equipamento móvel internacional (IMEI). Os VPLMNs de propaganda da WLAN podem todos ser capazes de suportar autenticação, usando o pseudo NAI para serviços de emergência ou podem ser apresentados a um UE em ordem de prioridade, indicando a capacidade e o desejo de suportá-la. O VPLMN tratará, pois, o UE como um assinante doméstico temporário e salta a autenticação e autorização (AAA) ou garante que elas tenham sucesso.

Entretanto, ainda neste caso, a sessão não pode continuar.

No atual TS 23.234, o requisito para as chamadas de emergência IMS é fornecer WLAN UEs com capacidade de suporte IP para acessar chamadas de emergência IMS para os casos com UICC e sem UICC. E mais, autenticação pode sert (i)deixada de lado inteiramente ou (ii) usar uma simulação ou método nulo de autenticação.

Assim, presentemente, nenhum mecanismo confiável está especificado para camadas de emergência sem UICC para usuários IMS através de l-WALN. E não existe definição da ID de usuário a ser usada para usuário sem UICC, que é necessária para formar o NAI (junto com o W-APN).

RESUMO DA INVENÇÃO

Portanto, ele é um objeto da presente invenção resolver o problema mencionado acima e fornecer um mecanismo confiável para lidar com chamadas como as chamadas de emergência IMS de um usuário sem UICC no sistema I- WLAN.

De acordo com a materialização da presente invenção, este assunto é resolvido por um método que compreende a iniciação de uma sessão de um terminal do assinante, cujo terminal do assinante não contém um módulo específico de identificação do usuário e a autenticação da sessão com base numa autenticação temporária do terminal do assinante, usando um procedimento que executa uma autenticação do servidor, evitando a autenticação do cliente.

Alternativamente, de acordo com a materialização da presente invenção, o assunto é resolvido por um dispositivo, compreendendo um controlador configurado para iniciar uma sessão em que o dispositivo do terminal do assinante não contém um módulo específico de identificação do usuário e para criar uma identificação temporária, em que um procedimento de autenticação é usado que executa uma autenticação do servidor e evita uma autenticação do cliente.

Outra alternativa, de acordo com a materialização da invenção, o assunto acima é resolvido por um dispositivo compreendendo um transceptor configurado para receber uma mensagem de pedido de autenticação de um terminal de assinante, em que o terminal do assinante mão contém um módulo específico de identificação do usuário e o controlador configurado para executar uma autenticação com base numa autenticação temporária, usando um procedimento que executa a autenticação de um servidor e evitando a autenticação do cliente.

Assim, de acordo com a propaganda, a autenticação é executada por um procedimento (método ou protocolo de autenticação) que não executa uma autenticação do cliente, mas executa uma autenticação do servidor.

Assim, as chamadas de emergência de terminais de assinantes sem UICC podem ser realizadas confiavelmente.BREVE DESCRIÇÃO DOS DESENHOS A invenção é descrita consultando os desenhos anexados, nos quais: Fig. 1 mostra um diagrama sinalizando uma mensagem de acordo com a primeira materialização da invenção e materialização da presente invenção. Fig. 2A a 2D configurações básicas de elementos de rede envolvidos na materialização da presente invenção.

DESCRIÇÃO DETALHADA DA MATERIALIZAÇÃO PREFERIDA

Na seguinte, a materialização preferida da presente invenção é descrita pela consulta dos desenhos anexados.

De acordo com a materialização presente, propõe-se usar um protocolo extensivo de autenticação - segurança de camada de transporte (EAP - TLS) como um método de autenticação em l-WLAN para usuários sem UICC no caso de uma emergência IMS. Especificamente, EAP-TLS pode pular a autenticação do cliente. Entretanto, a autenticação do servidor continua fornecida. Isto significa que é possível conseguir chaves para continuar e usar linguagem cifrada se necessário. Desta maneira, nenhuma mudança para o WLAN AN é necessária.

Uma sequência de sinalização detalhada para uma chamada de emergência de usuário sem UICC é mostrada na Fig. 1. Nota-se que somente os elementos principais da rede são mostrados nesta sequência, especificamente uma entidade do usuário (UE), uma rede de acesso WLAN (AN), que pode ser um elemento único de rede ou elementos distribuídos, um gateway de pacote de dados (PDG) e um servidor de autorização e conta (AAA).

No passo 1, uma conexão é estabelecida entre a entidade do usuário (EU) do WLAN e a rede de acesso WLAN do (AN), usando tecnologia específica da LAN sem fio.

No passo 2, o WLAN AN envia um Pedido/ldentidade EAP ao WLAN UE. Nota-se que os pacotes EAP são transportados pela interface da LAN sem fio encasulados com um protocolo específico de tecnologia LAN sem fio.

No passo 3, o WLAN EU envia uma mensagem de Resposta/ldentidade EAP. O WLAN UE envia uma identidade de usuário, adequada com um formato de identificador de acesso à rede (NAI) especificado em 3GPP TS 23.003. O reino do NAI na identidade do usuário está populado com o reino específico de emergência. Isto é, como mencionado acima, o reino pode incluir “sos”, por exemplo. A identidade sem UICC da WLAN EU pode ser um endereço IMEI, MAC ou um endereço local IP designado pela WLAN NA (como um exemplo para um elemento de acesso à rede) junto com info WLAN NA, como será descrito a seguir em maiores detalhes.

No passo 4, a mensagem e encaminhada ao próprio servidor de autenticação, autorização e conta (AAA) 3GPP, com base no reino do NAI. O roteiro do caminho de pode incluir um de vários servidores Proxy AAA (não mostrados na figura). encontrar um servidor AAA.

Nota-se também que um diâmetro de referência pode ser aplicado para encontrar um servidor AAA.

No passo 5, o servidor 3GPP AAA recebe o pacote Resposta/ldentidade EAP que contém a identidade do terminal. Com o reino do NAI na identidade do usuário populado com o reino específico de emergência como definido no Servidor 3GPP TS 23.003, 3GPP AAA, ele identifica que o usuário está solicitando uma chamada de emergência, com base na identidade recebida. O servidor 3GPP AAA colocará uma bandeira de Acesso de Emergência.

O identificador da rede de rádio WLAN e o endereço MAC da WLAN EU serão também recebidos pelo Servidor 3GPP AAA na mesma mensagem.

No passo 6, o Servidor 3GPP AAA inicia a autenticação usando EAP-TLS, no qual a autenticação do cliente é omitida. Isto é, nenhuma identidade do assinante como tal (i. e., como seria no caso de um assinante com uma UICC) é verificada. 3GPP AAA.

No passo 7, a WLAN NA encaminha o Pedido/TLS EAP para a WLAN EU.

No passo 8, a WLAN EU responde com a Resposta/TLS EAP.

No passo 9, a WLAN NA encaminha a Resposta/TLS EAP para o Servidor 3GPP AAA.

No passo 10, uma chave de sessão máster (MSK) é derivada da máster secreta TLS, cf. RFC 4346.

No passo 11, o Servidor 3GPP AAA manda a mensagem de sucesso do EAP para a WLAN AN. A WLAN AN pode armazenar o material-chave (MSK) que pode ser usado na comunicação com o WLAN UE autenticado.

No passo 12, a mensagem de sucesso EAP é encaminhada para a WLAN UE.

No passo 13, o WLAN UE e o PDG trocam o primeiro par de mensagens, conhecidas como IKE_SA_INIT (veja TS 33.324, por exemplo), em que os algoritmos criptográficos de negociação PDG e WLAN UE, trocam nonces e executam uma troca em Diffie_Hellman.

No passo 14, o sem UICC WLAN UE manda a identidade do usuário (no Idi payload) e a informação de emergência W-APN (no Idr payload) nesta primeira mensagem da fase IKE_AUTH, e começa negociação de associações de segurança de crianças. Os WLAN UE's indicam pelo reino no seu NAI para o PDG que o pedido de conexão e para chamada de emergência e que deseja usar o EAP através do IKEv2.

A identidade do usuário será compatível com o formato do Identificador de Acesso à Rede (NAI) especificado no IETF RFC 4282 (Dezembro de 2005: “O Identificador de Acesso à Rede”). DE acordo com IETF RFC 4306 (Dezembro de 2005: "Protocolo de Troca de Chave na Internet (IKEv2)"), o segredo compartilhado gerado numa troca do EAP (o MSK), quando usado através do IKEv2, será usado para gerar o parâmetro AUTH.

Se o endereço IP Remoto do WLAN UE's necessitar ser configurado dinamicamente, o WLAN UE mandará a carga útil de configuração (CFG_REQUEST) dentro da mensagem de pedido IKE_AUTH para obter um Endereço IP Remoto.

No passo 15, o PDG manda a mensagem de pedido de autenticação com um par de valor-atributo EAP vazio (AVP) para o Servidor 3GPP AAA, contendo a identidade do usuário. O PDG incluirá um parâmetro indicando que a autenticação está sendo executada para o estabelecimento de túnel. Isto ajudará o Servidor 3GPP AAA a distinguir entre autenticação por acesso ao WLAN e autenticação por configuração de túnel.

No passo 16, o Servidor 3GPP AAA verificará se a bandeira de Acesso de Emergência foi colocada para o usuário. Se a bandeira de Acesso de Emergência estiver ajustada e o W-APN não for de emergência como definido no 3GPP TS 23.003, o Código-Resultado deverá ser ajustado para DIAMETER-AUTHORIZATION-REJECTED.

Quando todas as verificações forem bem sucedidas, O Servidor 3GPP AAA manda a Resposta de Autenticação incluindo um EAP bem sucedido e o material-chave para o PDG. Esse material-chave consistirá de uma chave de sessão máster (MSK) gerada durante o processo de autenticação. Quando a interface Wm (Servidor PDG-3GPP AAA) estiver implementada usando Diameter, o MSK será encapsulado no parâmetro EAP-Master-Session-Key (Chave de Sessão Máster), como definido na referência RFC 4072 (Agosto de 2005: “Aplicativo de Protocolo de Autenticação Extensível de Diâmetro (EAP)”).

No passo 17, o MSK deverá ser usado pelo PDG para verificar os parâmetros AUTH, a fim de autenticar as mensagens de fase IKE_SA_INIT, como especificado na referência IETF RFC 4306 (Dezembro de 2005: “Protocolo de Troca de Chave nas Internet (IKEv2)”).

No passo 18, o PDG responde com sua identidade e um certificado. Ele completa a negociação das associações de segurança da criança também. Uma mensagem de sucesso EAP é também mandada para o WLAN UE.

A seguir, descreve-se como a identidade do usuário (como usado nos passos 3 e 13, por exemplo) pode ser formada.

Especificamente, se o nome/senha de um usuário comum fornecidos para todos os usuários para chamada de emergência sem UICC IMS, o problema consiste em definir esse nome/senha e se alguém faz deliberadamente uma chamada de emergência falsa, não há maneira de rastreá-lo com base em nome/senha comum.

De acordo com a materialização atual, três tipos de identidades são propostas para sem UICC UE. Identidade de equipamento móvel internacional (IMEI), endereço com controle de acesso médio e endereço IP.

Em particular, em caso de 3GPP restringir a conexão tal como possa ser de um terminal móvel (i.e., de um terminal no qual um cartão SIM pode ser inserido), então o IMEI ou um IMEI “hashed” pode ser usado. O IMEI pode ser usado de forma "hashed" já que o comprimento do IMEI são 15bytes, o que pode não ser adequado para todos os casos. O IMEI ou o IMEI hashed é então usado como identidade do usuário no passo 3 e 14 na Fig. 1.

O benefício de usar o IMEI hashed neste passo é que ele pode evitar embuste. O UE pode usar o IMEI hashed no passo 3 e usar o IMEI original completo no passo 14. Assim, até mesmo um agressor pode espiar o IMEI hashed e usá-lo para iniciar outra chamada de emergência, ele poderá usar o próprio IMEI para ser usado no passo 14. O IMEI hashed correto não será gerado no PDG, se o PDG receber um IMEI errado de um atacante no passo 14. Isto é, quando um IMEI hashed é incluído na resposta/identidade EAP no passo 3, um atacante pode conseguir possivelmente esse IMEI hashed, ouvindo pelo link sem fio e pode usá-lo para atacar o PDG no passo 14. Por conseguinte, no caso de um IMEI não-hashed completo ser usado no pedido AUTH_no passo 14, aí, mesmo se o agressor tiver sido capaz de conseguir o IMEI hashed (no passo 3), ele/ela não poderá usá-lo para atacar o PDG, uma vez que ele/ela não conhece o IMEI completo.

Como alternativa, no caso de 3GPP permitir outro WLAN UE tal como o PDA ou notebook para fazer uma chamada de emergência IMS, o endereço MAC pode ser usado da seguinte maneira, nos passos 3 e 14:

1) Endereço MAC. Cada WLAN EU deve ter um endereço MAC único.
Cada WLAN EU deve ter um endereço MAC único. O comprimento da ID é o mais curto.
2) Endereço MAC + WLAN AN ID (SE).
Isto pode fornecer o local da chamada de emergência para chegar-se a conhecer o local da emergência, ou rastrear as chamadas falsas. Se o agressor usar outro endereço MAC no mesmo WLAN NA, ele será detectado. Como alternativa, é possível usar um (endereço MAC + WLAN AN ID (SSID) hashed).
3) Endereço Local IP (designado pelo WLAN AN) + WLAN AN ID (SSID).
Isto pode fornecer o local da chamada de emergência, de modo que é possível rastrear chamadas falsas. Se o agressor usar outro endereço IP no mesmo WLAN AN, ele será detectado. Como alternativa, pode ser usada também uma combinação hashed do endereço local IP + WLAN AN ID.

Quando um UE conecta-se ao WLAN AN para obter uma conexão de cenário 2, ele pode usar um identificador de usuário no passo 3, e.g., userlD@sos.w-apn.mnc012.mcc34 5.pub.3gppnetwork.org. Isto é, numa mensagem inicial (passo 3, o terminal do assinante usa o identificador do usuário. Em resposta a isso, o servidor AAA pode conseguir o endereço UE's MAC/IP e informações WLAN AN de WLAN AN. Assim, em resposta, no passo 5, o servidor AAA pode formar a ID do usuário a partir do MAC/IP (e informações WLAN AN) recebidas do WLAN AN.

Quando UE estabelece conexão do cenário 3 com PDG, uma vez que o reino no seu NAI pode indicar ao PDG que o pedido e de conexão é de chamada emergência e que deseja usar EAP através de IKEv2 e que já compartilhou a chave (MSK) entre WLAN UE e o servidor AAA, o WLAN UE pode gerar o parâmetro AUTH e mandar para o PDG. O PDG pode conseguir o MSK do servidor AAA para verificar o AUTH. Desta maneira não é necessário mais passos como no cenário 3 normal.

Assim, de acordo com a presente materialização, um método de autenticação como o método de autenticação EAP-TLS, que pode evitar uma autenticação de cliente, é usado em l-WLAN para usuários sem UICC no caso de chamada de emergência.

Desta maneira, uma autenticação do servidor continua sendo fornecida. A autenticação do servidor permite a geração de uma MSK compartilhada entre o WLAN UE e o servidor AAA para uso de EAP sobre IKE2.

Assim, a autenticação é apenas para o servidor, não para o cliente. Portanto a rede não irá rejeitar a chamada de emergência (EM-call). Existem duas finalidades para esta autenticação. Uma é manter a WLAN AN inalterada. Caso contrário a WLAN AN irá verificar o NAI do UE para identificar se ele é para EM-call. A outra é gerar a MSK que será usada no procedimento do Cenário 3.

Mais que isso, é possível configurar um túnel criptografado para PDG se o Servidor AAA não tiver vetores de autenticação para este terminal (= caso sem UICC). Ou seja, como descrito acima, a MSK pode ser gerada a partir do segredo máster TLS como especificado no RFC 4346 em UE e servidor AAA. O PDG pode obter a MSK do servidor 3GPP AAA. De modo que o túnel criptografado pode ser estabelecido entre UE e PDG.

Não há mudança necessária na WLAN AN. O servidor AAA precisa formar a identidade do usuário a partir do MAC/IP (e da identidade WLAN AN).

Assim, uma conexão autenticada e confiável pode ser estabelecida em um caso sem UICC.

A seguir, uma segunda materialização da invenção é descrita, neste caso é considerado que um atacante pode iniciar chamadas de emergência duplas.

Em detalhes, de acordo com TS33.234, sessões simultâneas são permitidas em ambos os cenário, 2 e 3 (isto é, via acesso IP e acesso 3GPP), e os números das sessões simultâneas são baseados na política da operadora. A solicitação de ter sessões simultâneas é válida especialmente no caso de uma divisão de WLAN EU. Por exemplo, um usuário pode usar seu terminal móvel para visitar um website da operadora e usar seu notebook para acessar a VPN desta empresa ao mesmo tempo.

Entretanto, quando um usuário faz uma chamada de emergência IMS através de um terminal sem 10 UICC (como descrito na primeira materialização, por exemplo), não é razoável da parte dele fazer chamadas IMS de emergência simultâneas. Se ocorrer, a segunda pode ser uma fraude ou pode ser vandalismo contra os serviços de emergência. Portanto, chamadas IMS de emergência simultâneas através de um terminal sem UICC devem ser proibidas.

De acordo com a presente materialização, um controle correspondente é feito no PDG, isto é, o W-APN da chamada de emergência, ao invés do servidor AAA porque a WLAN UE pode não receber a mensagem de sucesso EAP (na etapa 12 da fig. 1) e não iniciar os procedimentos do cenário 3.Quando o PDG recebe a solicitação da WLAN UE (na etapa 14), ele deve verificar se já existe uma sessão do usuário. Se sim, ele deve rejeitar a nova solicitação ao invés de aceitá-la. O raciocínio é que é difícil para um atacante saber a identidade da vítima com antecedência, mas pode interceptá-la enquanto a UE estabelece a conexão do cenário 2. emergência IMS sem UICC.

A partir da identidade UE, o PDG pode saber se é uma chamada de emergência IMS sem UICC.

Assim, de acordo com a presente materialização, chamadas de emergência duplas são detectadas com confiança e evitadas.

A seguir, os elementos da rede envolvidos nas materializações descritas acima são descritas através de referências às figuras. 2A a 2D. Pode ser observado que nas figs. 2A a 2D somente os elementos básicos são exibidos de modo a simplificar os esquemas.

A fig. 2A mostra a configuração básica de um terminal de assinante A. O terminal de assinante A contém um controlador A1 e um transceptor A2. O controlador A2 pode incluir uma CPU e diferentes tipos de unidades de memória como RAM, ROM ou similares. Um programa de computador pode ser armazenado na memória e pode englobar porções de códigos de software para executar o método de acordo com as materializações. Este programa de computador pode ser armazenado em mídia de gravação como um CD ROM, por exemplo, e pode ser carregada diretamente na memória de trabalho do controlador. Ou como alternativa, o programa de computador pode ser carregado através da rede na memória do controlador.

A fig. 2B mostra a configuração básica do servidor AAA B, que contém um controlador B1 e um transceptor B2. O controlador B1 pode ser configurado de maneira semelhante à do controlador. Ou seja, o controlado B2 também pode incluir uma CPU e tipos diferentes de unidades de memória como RAM, ROM, um disco rígido, um leitor de CD ou DVD ROM ou similar. Um programa de computador pode ser fornecido ao servidor AAA de maneira semelhante à descrita acima. O transceptor B2 pode conter uma ou mais interfaces, pelas quais a conexão através da rede com outros elementos da rede pode ser providenciada.

A fig. 2C mostra a configuração básica do PGD C, que é similar à configuração do servidor AAA B, de modo que a sua descrição não é repetida.

A fig. 2D mostra a configuração básica da WLAN AN, que também é similar à configuração do servidor AAA B, de modo que a sua descrição detalhada não é repetida. modificações são possíveis.

A invenção não se limita às materializações descritas acima, e várias modificações são possíveis.

Em particular, o método de autenticação (ou procedimento de autenticação) não é limitado ao EAP-TLS. Em particular, qualquer outro método adequado pode ser usado se a autenticação do cliente puder ser omitida.

Além disso, o identificador do terminal do assinante não é limitado ao IMEI. Ou seja, qualquer outro identificador que identifique um terminal de maneira única pode ser usado.

Além disso, a sequência de autenticação e os elementos da rede envolvidos não são limitados aos detalhes mostrados na fig. 1 e descritos acima. Ou então as diferentes etapas podem ser executadas em ordem diferente ou envolvendo menos ou mais elementos da rede como apropriado.

Além disso, a chamada de emergência IMS mencionada acima é apenas um exemplo de uma chamada sem UICC. Em particular, pode haver outras situações nas quais uma chamada sem UICC pode ser permitida. Por exemplo, uma chamada sem UICC pode ser permitida por uma rede de modo a entrar em contato com uma operadora da provedora.

Claims

Método, caracterizado por compreender:
iniciação de uma sessão de um terminal de assinante, onde o terminal de assinante não engloba um módulo de identificação de usuário específico;

formação de uma identificação temporária do terminal de assinante;

baseado pelo menos em parte na identificação temporária, executar uma autenticação de servidor sem fazer a autenticação do cliente;

onde a identificação temporária compreende um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante;

onde o identificador de usuário baseado em pelo menos um de um identificador de terminal; um endereço de controle de acesso à mídia do terminal de assinante; e um endereço de protocolo de internet designado por um elemento de acesso à rede para o terminal do assinante.
Método de acordo com a reivindicação 1, caracterizado por a autenticação do servidor envolve o uso de um protocolo do tipo protocolo de autenticação extensível segurança de nível de transporte (EAP/TLS) ou protocolo de troca de chave (IKE).
Método de acordo com a reivindicação 1, caracterizado por a identificação temporária envolve um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante.
Método de acordo com a reivindicação 3, caracterizado por a indicação específica indica uma emergência.
Método de acordo com a reivindicação 3, caracterizado por o identificador do usuário é criado baseado em pelo menos um de:
um identificador de terminal;

um endereço de controle de acesso à mídia do terminal de assinante; e

um endereço de protocolo de internet designado por um elemento de acesso à rede para o terminal do assinante.
Método caracterizado por compreender:
iniciação de uma sessão de um terminal de assinante, onde o terminal de assinante não engloba um módulo de identificação de usuário específico;

formação de uma identificação temporária do terminal de assinante;

baseado pelo menos em parte na identificação temporária, executar uma autenticação de servidor sem fazer a autenticação do cliente;

onde a identificação temporária compreende um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante;

onde o identificador de usuário é criado baseado em pelo menos em parte de uma combinação de pelo menos um de:

um endereço de controle de acesso à mídia do terminal de assinante e um identificador de rede; e

uma combinação hashed do endereço de controle de acesso à mídia e identificador de rede.
Método caracterizado por compreender:
o envio de uma solicitação de autenticação para um terminal de assinante para a autenticação de uma sessão iniciada do terminal do assinante;

receber uma resposta de autenticação/mensagem de identidade do terminal do assinante, onde a resposta de identificação/mensagem de identidade engloba uma identificação temporária do terminal do assinante; e

autenticação da sessão baseado pelo menos em parte na identificação temporária do terminal do assinante, onde uma autenticação do servidor é feita mas a autenticação do cliente é omitida,

onde a identificação temporária compreende um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante, onde o terminal do assinante não engloba um módulo de identificação de usuário específico;

onde o identificador do usuário é criado baseado pelo menos em parte de uma da identidade de equipamento móvel internacional, um endereço de controle de acesso à mídia do terminal de assinante; e um endereço de protocolo de internet designado por um elemento de acesso à rede para o terminal do assinante.
Método de acordo com a reivindicação 7, caracterizado por englobar ainda a geração de uma chave de sessão máster compartilhada que pode ser usada para a codificação dos dados do usuário.
Método de acordo com a reivindicação 7, caracterizado por a identificação temporária envolve um identificador de usuário e um reino, o reino englobando uma indicação específica para a sessão iniciada por um terminal de assinante, onde o terminal do assinante não envolve um módulo de identificação de usuário específico.
Método de acordo com a reivindicação 7, caracterizado por compreender: verificação se já existe uma sessão para o terminal do assinante, e rejeição de uma nova sessão no caso de já existir uma sessão.
Aparelho, caracterizado por compreender:
pelo menos um processador; e

pelo menos uma memória incluindo o código do programa do computador no mínimo a memória e o código do programa do computador configurado para, com pelo menos um processador, fazer que o aparelho execute pelo menos o seguinte:

iniciar uma sessão, onde o aparelho não engloba um módulo de identificação de usuário específico;

formar uma identificação temporária; e

baseado, pelo menos em parte, na identificação temporária, executar uma autenticação de servidor sem fazer a autenticação do cliente;

onde a identificação temporária compreende um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante,

onde o identificador de usuário é criado baseado em pelo menos em parte de uma identidade de equipamento móvel internacional, um endereço de controle de acesso à mídia do terminal de assinante; e um endereço de protocolo de internet designado por um elemento de acesso à rede para o terminal do assinante.
Aparelho de acordo com a reivindicação 11, caracterizado por a autenticação envolve o uso de protocolo do tipo protocolo de autenticação extensível segurança de nível de transporte (EAP/TLS) ou protocolo de troca de
Aparelho de acordo com a reivindicação 11, caracterizado por uma chave de sessão máster é gerada, podendo ser usada para a codificação dos dados do usuário.
Aparelho de acordo com a reivindicação 11, caracterizado por a identificação temporária envolve um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada pelo aparelho.
Aparelho de acordo com a reivindicação 14, caracterizado por a indicação específica indica uma emergência.
Aparelho caracterizado por envolver:
pelo menos um processador; e

pelo menos uma memória incluindo o código do programa do computador assinante;

no mínimo a memória e o código do programa do computador configurado para, com pelo menos um processador, fazer que o aparelho execute pelo menos o seguinte:

envio de uma solicitação de autenticação para um terminal de assinante;

receber uma resposta de autenticação/mensagem de identidade do terminal do assinante, onde a resposta de identificação/mensagem de identidade engloba uma identificação temporária do terminal do assinante; e

realizar uma autenticação baseada pelo menos em parte na identificação temporária,

onde uma identificação de servidor é feita mas a identificação do cliente é omitida,

onde a identificação temporária compreende um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante, onde o terminal de assinante não compreende um módulo de identificação de usuário específico,

onde o identificador de usuário é baseado em pelo menos um de uma identidade do equipamento móvel internacional; um endereço de controle de acesso à mídia do terminal de assinante; e um endereço de protocolo de internet designado por um elemento de acesso à rede para o terminal do assinante.
Aparelho de acordo com a reivindicação 16, caracterizado por o processador recebe configuração adicional para gerar uma chave de sessão máster, onde a chave de sessão máster é gerada para codificação dos dados do usuário.
Aparelho de acordo com a reivindicação 16, caracterizado por a identificação temporária envolve um identificador de usuário e um reino, o reino englobando uma indicação específica para uma sessão iniciada por um terminal de assinante, onde o terminal do assinante não envolve um módulo de identificação de usuário específico.
Aparelho de acordo com a reivindicação 18, caracterizado por a indicação específica indica uma emergência.
Aparelho de acordo com a reivindicação 16, caracterizado por o processador é configurado para verificar se já existe uma sessão para o terminal do assinante, e para rejeitar uma nova sessão no caso de já existir uma sessão.