KR100966516B1

KR100966516B1 - 세션 개시 프로토콜을 통해 트러스티드 네트워크 지원형 액세스 네트워크 정보를 전달하는 시스템 및 방법

Info

Publication number: KR100966516B1
Application number: KR1020087023346A
Authority: KR
Inventors: 손 판-안
Original assignee: 노키아 코포레이션
Priority date: 2006-03-28
Filing date: 2007-03-27
Publication date: 2010-06-29
Also published as: US20080039085A1; JP2009531921A; WO2007110743A3; US9419955B2; CN101444062B; EP1999929A2; EP1999929A4; WO2007110743A2; CN101444062A; KR20080096849A; US20160373444A1

Abstract

트러스티드 네트워크로 액세스하는 사용자 기기를 인증하기 위한 방법, 컴퓨터 코드 제품 및 시스템은 사용자 기기를 유일하게 식별하는 사용자 아이디를 수신하는 단계를 포함할 수 있다. 트러스티드 네트워크 내 프록시 엔티티가 사용자 아이디를 포함한 네트워크 트러스티드 헤더를 생성하고, 그것을 네트워크 내 서빙 엔티티로 전송한다. 서빙 엔티티는 수신된 캐리어 헤더에 대한 검증을 수행하고, 사용자 아이디와, 승인된 사용자 ID들의 리스트를 비교하고, 매치가 이뤄지면 사용자 기기의 네트워크로의 액세스가 인증된다. 홈 IMS 네트워크를 향한 프록시 엔티티에 대해 선택적 하이딩을 수행하는 IBCF는 암호화된 토큰으로부터 프록시 엔티티가 생성한 파라미터를 추출하여, 그것이 캐리어 헤더 안에서 암호화된 것일 때 서빙 엔티티에서 읽혀질 수 있게 만든다. 프록시 엔티티는 또한 사용자 기기로부터의 등록 요청을 처리할 때, 사용되는 헤더의 검증을 지원할 수 있다. 이와 달리 서빙 엔티티에, 다양한 프록시 엔티티들이나 프록시 엔티티들이 위치하는 도메인들에서의 NBA 지원 관련 데이터가 제공되어, 서빙 엔티티가 NBA 절차를 통한 처리를 결정하거나, 소정 프록시 엔티티들이나 방문 네트워크들을 통해 수신된 등록에 대해서는 처리하지 않을 것을 결정할 수 있다.

Description

세션 개시 프로토콜을 통해 트러스티드 네트워크 지원형 액세스 네트워크 정보를 전달하는 시스템 및 방법 {System and method for carrying trusted network provided access network information in session initiation protocol}

본 발명은 일반적으로 통신 네트워크에서의 인증에 관한 것이다. 더 상세히 말해, 본 발명은 인증 목적으로 액세스-네트워크 정보를 전송하는 것에 대한 것이다.

이 섹션은 청구항들에서 언급된 발명의 배경기술 또는 맥락을 제공하기 위한 것이다. 여기서의 내용은, 추구될 수 있는 개념들을 포함할 수 있지만, 반드시 앞서 인지되었거나 추구되었던 것들은 아니다. 따라서, 여기서 달리 지시되지 않는다면, 이 섹션에 기술되는 것들은 본 출원의 상세 설명 및 청구항들의 선행 기술이 아니며, 이 섹션에 포함됨으로써 선행 기술이라고 인정되는 것이 아니다.

TISPAN (Telecom and Internet Converged services and Protocols for Advanced Networks, 진일보한 네트워크를 위한 전화 및 인터넷 수렴형 서비스 및 프로토콜)이 IMS (IP Multimedia Subsystem, IP 멀티미디어 서브시스템) 기반 서비스들을 위한 사용자 인증 개념들을 제공하고 있다. TISPAN은 네트워크 인식형 액세스 정보 (network-recognized access information), 특히 인증 목적의 line-id (라인-아이디)를 이용하는 NASS (Network Attachment Subsystem) 번들형 인증 (NASS bundled authentication) (NBA)을 도입해 왔다. line-id는 액세스 네트워크로부터 P-CSCF (Proxy Call Session Control Function)에 의해 얻어져서, P-CSCF에 의해 P-Access-Network-Info (P-액세스-네트워크-정보) 헤더를 통해 S-CSCF (Serving Call Session Control Function)로 전송되어, 인증 목적의 베이스로 사용된다. 그러나, 이러한 접근법은 이상적인 것과는 거리가 멀다.

먼저, 현재 RFC3455에 규정된 것과 같은 P-Access-Network-Info 헤더는 일반적으로 사용자 기기 (UE)에서 네트워크 (NW)로 정보를 전달하기 위한 것으로 정해져 있다. 이 헤더는 한 네트워크 요소에서 다른 요소로 액세스-정보를 전달하기 위한 것으로 설정되어 있지 않다. 사실상, 그런 종류의 용도는 RFC3455에 의해 명시적으로 금지되어 있다.

게다가, P-Access-Network-Info (P-A-N-I)를 다룸에 있어 이러한 일탈사항을 P-CSCF에 도입시키는 것은, (이미 배치된 3GPP R5/R6 시스템들에 존재하는 것들과 같은) "NBA-aware" 및 레거시 (legacy) "non-NBA-aware" P-CSCF들 모두가 존재할 때, 호환성 문제, 심지어는 시스템의 보안 허점들이 생겨나게 할 수도 있다. 도 1에 도시된 바와 같이, 레거시 P-CSCF에 연결되는 UE는 거짓 line-id를 P-A-N-I 안에 넣을 수 있다. 이 경우, 그 레거시 P-CSCF는 이 P-A-N-I를 건드리지 않을 것이고, 그러면 그 거짓 line-id 정보는 S-CSCF로 갈 수 있다. S-CSCF가 그 거짓 정보를 NBA의 베이스로서 사용하면, 문제의 UE는 이 거짓 정보에 기초해 인증을 받을 수가 있다. 문제의 UE가 "NBA-aware" P-CSCF에 연결되었더라도, 그 P-CSCF는 연결 을 막기 위해 모든 P-A-N-I의 콘텐츠를 검색할 필요가 있게 될 것이다. 이러한 것은 시스템 성능에 부정적 효과를 미칠 수 있을 것이다.

따라서, 현재의 해법들에 있어서의 호환성, 보안 및 성능 문제들에 대처할 개선된 인증 시스템 및 방법들이 필요로 된다.

본 발명의 실시예들은 트러스티드 (trusted) 네트워크에 액세스하기 위해 사용자 기기를 인증하는 방법, 컴퓨터 코드 제품 및 시스템을 포함할 수 있다. 사용자 기기는 고유한 사용자 아이디로 인증될 수 있고 트러스티드 네트워크는 P-CSCF (Proxy Call Session Control Function) 및 S-CSCF (Serving Call Session Control Function)를 포함할 수 있다. 상기 방법, 컴퓨터 코드 제품 및 시스템은 P-CSCF에서 사용자 기기로부터 등록 요청을 수신하는 단계; P-CSCF에서 사용자 기기의 line-id (라인-아이디) 같은 사용자 고유 위치 정보를 수신하는 단계; P-CSCF에서, 상기 수신된 사용자 고유 위치 정보를 포함하는 네트워크 트러스티드 헤더를 생성하는 단계; 인증을 위해 상기 네트워크 트러스티드 헤더를 S-CSCF로 보내는 단계; 상기 사용자 고유 위치 정보를 S-CSCF 내 승인된 사용자 고유 위치 정보의 리스트와 비교하는 단계; 및 매치가 이뤄지면, 상기 트러스티드 IMS 네트워크 액세스를 위해 사용자 기기를 인증하는 단계를 포함한다. 네트워크 트러스티드 헤더는, 통신 시스템의 네트워크 엔티티들이 신뢰할 수 있는 콘텐츠를 포함하는 헤더일 수 있는데, 이는 네트워크 엔티티들이 그 헤더의 콘텐츠가 다른 트러스티드 네트워크 엔티티, 및 이를테면 악의적 사용자 기기가 아닌 것으로부터 나온 것이라고 인지하기 때문이다.

네트워크 트러스티드 헤더는 사용자 고유 위치 정보가 삽입될 파라미터를 포함할 수 있다. 이 파라미터는 어떤 이름을 가지지만 여기서는 pani-np라고 부를 것이며, 다음과 같은 전형적 신택스를 가질 수 있다:

여기서 n은 파라미터에 포함된 정보 필드들의 개수이다.

pani-np를 통해 전달되는 가장 주목할만한 사용자 고유 위치 정보는 line-id이지만, 다른 정보 역시 전달될 수 있다. 일반적으로 말해, NBA-aware P-CSCF들 및 non-NBA-aware P-CSCF들 둘 모두에서 REGISTER (등록)를 다룰 때, P-CSCF에 의해 생성된 한 헤더는 pani-np 헤더를 전달하기 위한 네트워크 트러스티드 헤더들로서 사용될 수 있다. 예들로는 P-Visited-Network-ID (P-방문-네트워크-아이디), Via, Path (경로), P-Charging-Vector (P-비용청구-벡터) 헤더들 등등이 포함될 수 있다.

본 발명의 실시예들은, 전달된 pani-np 파라미터가 어떤 다른 개체가 아닌 P-CSCF에 의해 삽입되었다는 것을 보장하도록, S-CSCF에 의한 사용 네트워크 트러스티드 헤더의 추가 검증을 포함할 수 있다. 이 검증은, 거짓 pani-np 정보를 헤더에 넣고 그 정보가 P-CSCF에 의해 삽입된 것처럼 보이도록 시도하는 악의적 사용자 기기에 의해 야기될 수 있는, 사용되는 캐리어 헤더 내 비정상적 사항들을 식별하는데 사용될 수 있는, S-CSCF에서 이용가능한 정보에 기반할 수 있다.

REGISTER를 다룰 때 P-CSCF 및 사용자 기기의 표준 동향으로부터 도출되는 규칙들과 제약사항들이 그러한 검증을 수행하는데 사용될 수 있다. S-CSCF의 다른 "로컬 지식 (local knowledge)" 또한 이용될 수 있다. 예를 들어, 사용되는 네트워크 트러스티드 헤더가 P-Visited-Network-ID (P-V-N-I) 헤더일 때, S-CSCF에서 수신되는 REGISTER의 헤더들의 수는 IMS 아키텍처를 통해 잘 알려져 있다. 이러한 지식이 검증을 수행하기 위한 기준으로 사용될 수 있다. 예를 들어, 악의적 사용자 기기가 추가적 P-V-N-I 헤더들을 리스트에 넣는다면, S-CSCF에 의해 수신된 P-V-N-I 헤더 리스트의 아이템들 수가 예상한 것보다 많을 것이다. 이것은 일어날 수 있는 문제를 시그날링 하는데 사용될 수 있고, 이 경우 검증은 실패할 수도 있을 것이다. 유사한 규칙들이 P-Charging-Vector 헤더들에 적용된다 (가령, S-CSCF에 의해 수신되는 REGISTER의 상기 헤더들의 개수는 잘 알려져 있다).

본 발명의 실시예들은 또한 P-CSCF에 의한, 사용되는 네트워크 트러스티드 헤더에 대한 추가 검증을 포함한다. 이것 역시, 한 사용자 기기에 의해 있을 수 있는 악의적 헤더 정보 삽입을 인지하는데 사용될 수 있다. IMS 아키텍처에 따르면, P-CSCF에 의해 사용자 기기로부터 수신된 REGISTER는 어떠한 Path 헤더나, P-Visited-Network-ID나 P-Charging-Vector 헤더도 없이 오직 한 Via 헤더만을 포함한다. P-CSCF가 하나를 넘는 Via 헤더를 인식하거나, 위에서 나열한 다른 세 가지 헤더들 중 어느 하나를 인식했다면, 사용자 기기 측으로부터의 잠정적 속임수가 인지될 수 있으므로 P-CSCF는 그 요청을 거부할 수 있다.

본 발명의 실시예들은 P-CSCF에 의해, 수신한 사용자 아이디를 디지털 서명하는 단계, 및 S-CSCF에서 그 디지털 서명을 검증하는 단계를 더 포함할 수 있다. 트러스티드 네트워크는 IP 멀티미디어 서브시스템 (IP Multimedia Subsystem)일 수 있다.

Interconnect Border Control Function (상호연결 경계 제어 기능)은 서로 다른 서비스 제공자 네트워크들간 경계에 대한 전반적 제어를 지원한다. 그것은 THIG (Topology Hiding Inter-network Gateway, 토폴로지 하이딩 네트워크 간 게이트웨이) 서브 기능을 구현함으로써 시그날링 정보에 관련한 IMS 코어 네트워크의 보안을 지원할 수 있다. 그 서브 기능은 시그날링 기반 토폴로지 하이딩, IPv4-IPv6 인터워킹 (inter-working) 및, 소스 및 목적지 시그날링 어드레스들에 기초한 세션 스크리닝을 수행할 수 있다. 어떤 상황에서는, 토폴로지 하이딩이 Home (홈) IMS 네트워크 및 Visited (방문) IMS 네트워크 사이에 존재할 수 있다.

토폴로지 하이딩이 Visited IMS 네트워크 내 P-CSCF에 인가되고, 사용되는 캐리어 헤더의 암호화가 적용되면, 그 하이딩을 수행하는 IBCF (Interconnection Border Control Function)가 상술한 pani-np 파라미터를 암호화된 한 토큰으로부터 제거하므로 그것이 S-CSCF에 대해 판독가능한 상태로 남을 수 있다.

본 발명의 다른 실시예에서, 사용자 고유 위치 정보는 P-A-N-I를 통해 계속해서 보내질 수 있고, S-CSCF는 어느 P-CSCF들이 NBA-aware이고 어느 것들이 아닌지를 보이는 데이터를 갖출 수 있다. 이런 식으로, S-CSCF는 P-CSCF가 정보를 전송하는데 기반하는 등록에 NBA 절차가 적용가능한지 아닌지 여부를 판단할 수 있다. 리스트는 P-CSCF 고유한 것이거나, 도메인 고유 (그 도메인 내 모든 P-CSCF에 적용가능함)한 것일 수 있고, 아니면 IP 어드레스 범위에 따라 설정될 수 있다. 화이트 리스트 (P-CSCF들이 NBA-awar 인 것) 또는 블랙 리스트 (NBA-aware가 아닌 것들)가 있을 수 있다. S-CSCF는, 자신의 리스트 대비 P-CSCF 네임들/IP 어드레스 또는 P-CSCF가 위치한 도메인을 체크하여, NBA 절차가 특정 P-CSCF를 통해 도달한 등록에 적용 가능할지 여부를 결정할 수 있다.

본 발명의 실시예들은 트러스티드 네트워크로 액세스할 사용자 기기를 인증하는 방법, 컴퓨터 코드 제품들 및 시스템들을 포함할 수 있다. 사용자 기기는 고유한 사용자 아이디에 의해 식별될 수 있고, 트러스티드 네트워크는 P-CSCF (Proxy Call session Control Function) 및 S-CSCF (Serving Call Session Control Function)을 포함할 수 있다. 상기 방법, 컴퓨터 코드 제품, 및 시스템은 P-CSCF에서 사용자 기기로부터 등록 요청을 수신하고, P-CSCF에서 사용자 기기의 line-id 같은 사용자 고유 위치 정보를 수신하고, P-CSCF에서 사용자 고유 위치 정보를 P-Access-Network-Info에 삽입하고, 인증을 위해 그 P-A-N-I 헤더를 S-CSCF로 전달하고, S-CSCF에서 그 전송 P-CSCF가 NBA aware인지 여부를 판단하고, 그렇다고 판단한 경우 사용자 고유 위치 정보를 S-CSCF 내 승인된 사용자 고유 위치 정보의 리스트와 비교하는 동작들을 포함한다. 비교 동작시 매치가 이뤄지면, 사용자 기기는 트러스티드 IMS 네트워크로의 액세스에 대해 인증될 수 있다. 상술한 바와 같이, 본 발명의 이러한 실시예들에서 S-CSCF는 어떤 P-CSCF들이 NBA-aware이고 어느 것들이 아닌지를 보이는 데이터를 갖출 수 있다.

본 발명의 상기, 그리고 다른 목적들, 이점들 및 특징들과, 그 동작 체계 및 방식은 첨부된 도면들과 함께 파악되는 이하의 상세 설명으로부터 명확해지게 될 것이며, 아래에 기술된 전체 도면들에 걸쳐 동일한 구성요소들은 동일한 첨부부호를 가진다.

도 1은 기존 시스템의 잠정적 문제점들을 예시한 TISPAN 인증 시스템의 개략도이다.

도 2는 본 발명이 구현될 수 있는 TISPAN 릴리스 1 아키텍처 시스템의 개략도이다.

도 3은 본 발명의 일 실시예의 구현에 사용될 수 있는 시그날링 흐름도이다.

도 4는 본 발명의 일 실시예에 따른 TISPAN 인증 시스템의 개략도이다.

도 5는 본 발명의 일 실시예에 따른, NASS 번들형 인증의 형식적 매핑을 도시한 개략도이다.

도 6 및 7은 본 발명의 일 실시예의 구현에 사용될 수 있는 시그날링 흐름도들이다.

본 발명의 실시예들은 코어 (core) IMS 서브시스템으로의 액세스를 인증하는 것에 관한 것으로, 보다 상세히는, 코어 IMS 서브시스템으로의 ITSPAN 액세스에 관한 것이다. 도 2를 보면, 참조 부호 100으로 일반 지칭한 TISPAN 릴리스 1 아키텍처는 여러 서브 시스템들을 구비한다. NASS 번들형 (bundled) 인증 (NBA) 관점에서 특히 관련된 것이 NASS 서브 시스템(102) 및 IMS 서브시스템(104)이다. NASS 서브시스템(102)은 CLF (Connectivity session Location and repository Function, 연결 세션 위치 및 저장 기능)(106)을 포함한다. CLF(106)는 할당된 IP 어드레스 및 line_id (라인_아이디)의 결합을 다루도록 설정될 수 있다. IMS 서브시스템(104)은 P-CSCF(108), I-CSCF (Interrogating Call Session Control Function)(110), S-CSCF(112), 및 HSS (Home Subscriber Server)(114)를 포함한다. 사용자 기기 (UE)(116)는 NASS 서브시스템(102)를 통해 IMS 서브시스템(104)으로의 액세스를 허락받을 수 있다.

P-CSCF(108)는 IM CN (IP Multimedia Core Network) 안에서 UE의 최초 접촉 포인트로서 식별될 수 있는 IMS 엘리먼트이다. P-CSCF(108)의 기능들에는, UE(116)로부터 수신된 SIP 메시지들을 전달하는 것이 포함될 수 있다. 메시지들은 I-CSCF(110)나 S-CSCF(112)로 전송될 수 있는데, 이는 메시지 타입 및 수행되는 절차에 따라 좌우된다. P-CSCF(108)는 CDR (Call Detail Record, 통화 세부내역 레코드) 생성을 담당할 수도 있다. P-CSCF 어드레스는 IP 연결을 설정하는 데 수반되는 세션 관리 절차의 일부로서 찾아질 수 있다. 즉, P-CSCF 어드레스는 PDP (Packet Data Protocol) 컨텍스트 활성화 프로세스 중에 제공될 수 있다. 이와 다른 방안으로서, 이 어드레스는 다이내믹 호스트 설정 프로토콜 질의 (Dynamic Host Configuration Protocol Query)/응답 (Response) 프로세스를 통한 PDP 콘텍스트 작동 프로세스 뒤에 정해질 수도 있다. 이 경우, UE(116)는 IP 세션을 설정하기 위해 IP 어드레스에 더해 다른 변수들을 요청할 수 있다.

I-CSCF(110)는 운영자 네트워크 안에서, 네트워크의 가입자들 또는 로밍하는 가입자들의 등록을 허용하게 하는 접촉 포인트를 제공할 수 있는 IMS 엘리먼트이다. 일반적으로 말해, I-CSCF(110)는 등록, SIP 메시지들의 라우팅 및 전달과 비용청구를 다룬다.

S-CSCF(112)는 UE(116)를 위한 세션 제어 서비스들을 제공하는 IMS 엘리먼트이다. 이것은 네트워크 운영자로 하여금 다양한 서비스들을 지원할 수 있게 한다. S-CSCF 기능들에는 모바일 등록 관리, 세션 유지, 다른 서비스들과의 인터랙션 (interaction), 비용청구 및 보안이 포함될 수 있다. 일 실시예에서, S-CSCF(112)는 SIP 서버이다. 그 역할은, 이동중 HSS(114) 같은 네트워크 데이터베이스 그리고 보안을 위한 액세스, 인증 및 회계 서버들과의 상호동작을 포함할 수 있다. SIP 등록 프로세스의 일부로서, 사용자에게는 일반적으로 가입자의 Home Public Land Mobile Network (홈 퍼블릭 육상 모바일 네트워크) 안에 상주하는 한 S-CSCF(112)가 할당될 것이다. 이 S-CSCF(112)는 그 가입자에 대한 세션 제어의 모든 양상들을 담당할 것이다.

HSS(114)는 일반적으로 퍼블릭 육상 모바일 네트워크 (Public Land Mobile Network)에 대한 마스터 데이터베이스이다. 그것은 사용자 이동성 서버 (User Mobility Server), 홈 로케이션 레지스터 (Home Location Register), 도메인 네임 서버들 (Domain Name Servers), 및 보안 및 네트워크 액세스 데이터베이스들과 같은 다양한 기능들을 담당할 수 있다. 그것은 논리적으로 하나의 엔티티로 보여지지만, 실제로는 가입자 수 및 지원되어야 할 서비스의 정도에 따라 여러 개의 물리적 데이터베이스들로 이뤄질 수 있다. HSS(114)는 가입자들에 의해 이뤄지는 콜 (통화) 및 세션들의 지원, 설정 및 유지를 위한 변수들과 아이디들을 보유할 수 있다. 여기에는 가입자의 국제 모바일 가입자 아이디 (International Mobile Subscriber Identity), 보안 변수들 및 위치 정보가 포함될 수 있다. 기본적 홈 로케이션 레지스터/인증 센터 (Home Location Register/Authentication Center) 기능들을 제공하는 것 외에, HSS(114)는 추가 데이터베이스들 및 참조 포인트들의 이용을 통해 더 강화될 수 있다. 이것은 네트워크로 하여금, CAMEL (Customized Application for Mobile network Enhanced Logic), OSA (Open Service Access) 및 SIP에 기초해 서비스 어플리케이션 서버들과 상호동작함으로써 가입자에게 고급 서비스 및 사양들을 제공할 수 있게 한다.

본 발명의 실시예들은 IMS 서브시스템(104)으로의 UE(116) 액세스를 인증하는 것에 관한 것이다. 본 발명의 여러 실시예들에서, 이러한 것은 P-A-N-I를 통해서가 아닌, P-CSCF(108)에서의 의무적 캐리어 SIP 헤더의 파라미터 내 line-id 같은 네트워크 인지형 액세스 정보를 전송함으로써 수행될 수 있다. 네트워크 트러스티드 헤더는 통신 시스템의 네트워크 엔티티들이 신뢰할 수 있는 콘텐츠의 헤더로서, 네트워크 엔티티들이 그 헤더의 콘텐츠가 가령 악의적 UE로부터가 아닌 다른 신뢰할 수 있는 네트워크 엔티티로부터 나온 것이라는 것을 알 수 있도록 한다. 일 실시예에서, 파라미터는 pani-np (P-A-N-I-network-provided)로 명명되고, P-CSCF(108)에 의해 S-CSCF(112)로 리포트 될 line-id를 포함하는 인용 (quoted) 스트링을 포함한다. access-type (액세스 타입) 같은 다른 관련 액세스 정보 역시 포함될 수 있다.

일 실시예에서, pani-np 파라미터는 아래와 같은 포맷으로 정렬될 수 있다.

pani-np="<parameter name 1> -eq- <parameter value 1> ... <parameter name n> -eq- <parameter value n>"

이때 1부터 n까지의 파라미터들이 pani-ip 파라미터에 포함될 수 있다. 예를 들어, Via 헤더가 네트워크 트러스티드 캐리어 헤더로서 사용될 때, line-id=1234567890이고 access-type이 dsl이면, P-CSCF(108)에 의해 부가되는 최우선 Via 헤더는

로부터

로 바뀔 수 있다.

동일한 예가 P-V-N-I에 적용되는 경우, 다음과 같은 변화가 일어날 것이다:

이

로 바뀐다.

이 예에서, NW (P-CSCF(108))는 S-CSCF(112)에, 액세스 타입이 DSL이고 line-id가 1234567890임을 알릴 것이다.

본 발명의 실시예들을 구현함으로써, P-CSCF(108)는 P-A-N-I를 사용하는 대신, line-id 정보를 전송하도록 P-CSCF에 의해 생성된 의무적 네트워크 트러스티드 헤더 내에 파라미터 pani-np를 사용함으로써 NBA를 구현할 것이다. 이러한 P-A-N-I의 비 부합 (non-compliant) 용도의 대체가, SIP에서 NBA를 구현하기 위해 P-CSCF(108)로부터 S-CSCF(112)로, line-id 같은 필수 액세스 정보를 전송하는 SIP-부합 방식을 제공한다. 본 발명의 실시예들은 새로운 SIP 헤더를 필요로 하지 않으므로, 레거시, non-NBA-aware P-CSCF 문제를 해결할 수 있다. line-id 정보가 새 SIP 헤더 또는 심지어 어떤 기존 헤더들을 통해 전송되면, 그 헤더들은 레거시 P-CSCF에 의해 체크되지 않을 수도 있어, 부정한 정보가 S-CSCF에 도달되게 만들 수 있다. 네트워크 트러스티드 헤더는 항상 P-CSCF(108)에 의해 구축되지만, NBA-aware P-CSCF만이 pani-np 파라미터를 그 헤더 안에 넣는다. 이와 같이, 레거시 P-CSCF는 항상 그러한 헤더를 생성할 것이나, pani-np 파라미터를 자신의 캐리어 헤더 안에 삽입하지는 않을 것이므로, UE가 레거시 시스템들 내 S-CSCF로 거짓 line-id 정보를 보낼 수는 없을 것이다.

본 발명의 일 실시예에서, S-CSCF는 가령 P-CSCF 및 UE의 표준 양태로부터 도출된 규칙들 및 제약사항들에 기초해, 수신된 캐리어 헤더에 대한 검증을 수행한다. 예를 들어, 사용되는 캐리어 헤더가 P-V-N-I이면, 한 가지 가능한 검증 체크는, S-CSCF에서 수신된 P-V-N-I 헤더 리스트 내 아이템들의 개수를, 표준 IMS SIP 시그날링 플로로부터 도출된 잘 알려진 결과에 대해 비교함으로써 행해질 수 있다. 비슷한 검증 기준이 P-Charging-Vector에 대해서도 적용될 수 있다. 다른 실시예에서, P-CSCF는 사용되는 네트워크 트러스티드 헤더와 관련된 REGISTER 메시지에 대한 검증 역시 지원하여, UE에 의한 악의적 헤더 삽입을 걸러낼 수 있다. 예를 들어, P-CSCF는, 그 안에 한 개를 넘는 Via 헤더가 있거나 어떤 P-Visited-Network-ID, Path (패스) 혹은 P-Charging-Vector 헤더들을 포함하는 경우 REGISTER (등록) 요청을 거부할 수 있다.

본 발명의 일 실시예에서, 인증 프로세스에 추가 보안을 제공하기 위해, pani-np 정보가 P-CSCF(108)에 의해 디지털 서명될 수 있다. 이 경우, S-CSCF(112)는 인증을 통한 처리 전에 그 pani-np에 대한 디지털 서명을 검증할 수 있다.

본 발명의 실시예들은 한 SIP 노드로부터 다른 노드로 임의의 신뢰가능한 (트러스티드) 정보를 전달한다고 일반화할 수 있다. 그러한 트러스티드 정보는 해당 노드에 의해 생성된 어떤 선택된 의무적 캐리어 헤더 내 확장 파라미터 (extension parameter)로서 전송될 수 있을 것이다. 소스 노드 (이 경우 P-CSCF)에서 수신 노드 (이 경우 S-CSCF)까지 홉-바이-홉 (hop-by-hop) 트러스트 (trust)가 존재하면, 소스 노드 앞의 노드들 (이 경우 UE)은 레거시 네트워크 노드들에 대해 "이해할 수 없으면 건드리지 말라 (don't touch it if I don't understand it"라는 SIP 디폴트 양태를 이용하여 수신 노드로 거짓 정보를 밀지 못할 것이다.

도 3은 본 발명의 일 실시예에 따른, NBA를 이용한 성공적 등록 시도의 시그날링 흐름도(200)를 도시한 것이고, 도 4는 본 발명의 일 실시예에 따른 TISPAN 인 증 시스템의 개괄을 보인 것이다. 이 실시예에서, UE(116)는 NASS 서브시스템(102)으로의 액세스-레벨 연결을 수행하여 IP 어드레스를 배정받아 IP 연결이 이행되게 된다 (201 단계). 그런 다음, 202 단계에서, UE(116)는 P-CSCF(108)로 IMS 서브시스템(104)에의 등록을 개시하라는 REGISTER 메시지를 전송한다. REGISTER 메시지는 Authorization (인가) 헤더를 포함할 수도, 포함하지 않을 수도 있다.

REGISTER 메시지를 수신할 때, P-CSCF(108)는 위치 정보를 전송하기 위해 선택된 네트워크 트러스티드 헤더에 대한 검증을 수행할 수 있는데, 가령 Register에 오직 하나의 Via 헤더만이 존재하고 P-Visited-Network-ID, Path, P-Charging-Vector는 존재하지 않는다는 것을 확인하기 위해 체크를 행한다. P-CSCF(108)는 그런 다음 204 단계에서 CLF(106)로의 위치 정보 질의를 수행할 수 있다. 예를 들어, P-CSCF(108)는 다른 액세스 네트워크들에 연결된 여러 네트워크 인터페이스들을 가질 수 있다. 이 경우, P-CSCF(108)는 네트워크 인터페이스마다 NBA-관련 기능을 수행하도록 설정될 수 있다. CLF 어드레스 또한 네트워크 인터페이스마다 있는 설정 수단에 의해 정해질 수 있다. IP 헤더를 통해 알 수 있는 소스 IP 어드레스는 위치 정보 질의를 위한 키로서 사용될 수 있다. P-CSCF에서 CLF로의 인터페이스는 TISPAN 아키텍처에서 e2 인터페이스로 명명된다. 이것이 DIAMETER-기반 인터페이스이다. 또한, 가입 시점에, NBA가 UE(116)에 대한 인증 스킴 (authentication scheme)으로서 제공되고, 한 개 혹은 일련의 참조 line-id-ref가 가입자를 위해 HSS(114)에 저장된다.

206 단계에서, CLF(106)는 할당된 IP 어드레스와 연결된 line-id를, LocationInformationResponse (위치 정보 응답) 메시지를 이용해 다시 P-CSCF(108)로 전송한다. 종래의 시스템들에서 P-CSCF(108)는 I-CSCF(110)로 전송된 SIP 메시지 내 P-A-N-I 헤더의 "dsl-location" 파라미터 안에, 수신한 line-id를 인코딩해 넣었다. 그 line-id가 네트워크에 의해 제공된다는 것을 가리키기 위해, "network-provided (네트워크 제공)" 파라미터가 P-A-N-I 헤더 안에 부가될 수도 있다. 그러나, 상술한 바와 같이, 이것은 호환성 및 보안 문제들을 야기하는 P-A-N-I의 금지된 용법이다. 본 발명의 실시예들에 따르면, line-id (및 기타 정보)가 P-CSCF(108)에 의해 생성된 네트워크 트러스티드 헤더 내 새 파라미터인 pani-np 파라미터에 추가될 수 있다. 본 발명의 실시예들에 따르면, 이 정보는 208 단계에서 네트워크 트러스티드 헤더를 통해 I-CSCF(110) 및 계속해서 S-CSCF(112)로 전송된다. 이에 더해, P-CSCF(108)는 추가 보안을 위해 pani-np 파라미터를 디지털 서명할 수 있다.

210 단계에서, I-CSCF(110)는 HSS(114)와 함께 UAR/UAA Cx 동작을 수행하여, S-CSCF(112)의 위치를 확인할 수 있다. line-id가 네트워크 트러스티드 헤더를 통해 건네지므로, 그것은 S-CSCF(112)에 의해 추출될 수 있다. pani-np 파라미터가 P-CSCF(108)에 의해 디지털 서명되었으면, S-CSCF(112)가 그 디지털 서명을 검증할 수 있다. 212 및 212 단계에서, S-CSCF(112)는 HSS(114)와 MAR 및 MAA 동작들을 각각 수행할 수 있다. HSS(114)는 하나 이상의 참조 line-id-ref 파라미터를 전송할 수 있고, 또한 인증 스킴이 NBA임을 확인 또는 지시할 수도 있다.

HSS(114)로부터 수신된 인증 스킴이, NBA가 UE(116)에 적용된다는 것을 확인 하면, S-CSCF(112)는 우선 그 수신된 네트워크 트러스티드 헤더에 대해 표준 IMS 등록 절차로부터 파생된 규칙 및 제한사항들, 로컬 지식 또는 그 둘 모두의 조합에 기초해 검증을 수행할 수 있다. 검증이 성공적이면, S-CSCF(112)는 Via 헤더의 pani-np 파라미터 (이것이 존재하고 또한 그것이 "network-provided" 파라미터를 포함한 경우)에 포함된 line-id를, 참조 line-id-ref (line-id-refset)과 비교할 수 있다 (216 단계). 적어도 하나가 매치하면, 사용자는 인증된 것으로 간주 되어 200 OK가 UE(116)로 다시 보내져서 (218, 220 및 222 단계들) 등록이 성공하였음을 가리키도록 한다.

NASS 번들형 인증 (NBA, NASS bundled authentication)은 NASS 계층 내 성공적 인증을 서비스 계층까지 확장함으로써 유효하게 된다. 네트워크 연결 도중, NASS가 UE를 인증하고 IP 어드레스를 할당한다. 그것은 계층-2 및 계층-3 아이디들을 NASS 프로파일 안에 저장한다. UE가 P-CSCF에 등록될 때, P-CSCF는 NASS (실제로 CLF 기능의 엔티티)에게 물어, 그것의 위치 정보를 얻는다. P-CSCF는 그 위치 정보를 SIP 메시지 안에, P-CSCF에 의해 생성된 Via 헤더 속 파라미터의 형식으로 내장시키고, 검증을 위해 그것을 S-CSCF로 전송한다. S-CSCF는 UPSF로부터 얻은 위치 정보와 함께 이 위치 정보를 검증한다. 성공적 검증시, 사용자는 IMS 계층에서 인증된다.

토폴로지 하이딩 (topology hiding)이 홈 네트워크를 향한 P-CSCF에 적용되는 경우, 그 하이딩을 수행하는 IBCF가 암호화된 토큰으로부터 이 Via 파라미터를 꺼낼 것이므로, 그것은 S-CSCF에 의해 여전히 판독가능하다는 것을 알아야 한다. 또한 토폴로지 하이딩이 NBA에 대해 적용될 수 없거나, 요구되지 않을 수도 있다.

아키텍처 레벨에서, 다음의 두 인터페이스들이 영향을 받는다:

NASS로부터의 위치 정보가 전송되는 'e2' 인터페이스.

UPSF에 저장된 사용자 프로파일이 전송되는 'Cx' 인터페이스.

네트워크 플로의 시각화와 함께 이러한 것이 도 5, 6 및 7에 도시된다.

본 발명은 일 실시예를 통해, 네트워킹 환경하의 컴퓨터들에 의해 실행되는 프로그램 코드 같은 컴퓨터 실행가능 명령들을 포함하는 프로그램 제품에 의해 구현될 수 있는 일반적인 맥락의 방법의 단계들로서 기술되었다. 일반적으로, 프로그램 모듈에는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등등과 같이 특정 작업들을 수행하거나 특정한 추상 데이터 타입들을 구현하는 것들이 포함된다. 데이터 구조들과 결부된 컴퓨터 실행가능 명령들, 및 프로그램 모듈들은 여기 개시된 방법의 단계들을 실행하는 프로그램 코드의 예들을 나타낸다. 그러한 실행가능 명령들 또는 관련 데이터 구조들의 특정 시퀀스는, 상기 단계들로 기술된 기능들을 구현하기 위한 상응하는 동작들의 예들을 나타낸다.

본 발명의 소프트웨어 및 웹 구현예들은 규칙 기반 로직 및 기타 로직과 함께 표준 프로그래밍 테크닉들을 통해 이행됨으로써, 다양한 데이터베이스 서치 단계들, 상관 단계들, 비교 단계들 및 결정 단계들을 수행하도록 한다. 명세서 및 청구범위에 사용된 "컴포넌트", 및 "모듈"이라는 말들은 한 줄 이상의 소프트웨어 코드, 및/또는 하드웨어 구성, 및/또는 수동 입력을 수취하기 위한 장치를 이용하는 구현예들을 포괄하도록 되어 있다는 것을 알아야 한다.

본 발명의 실시예에 대한 상술한 내용은 예시와 설명의 목적으로 제시되었다. 그것이 완전한 것이라거나, 본 발명을 개시된 정확한 그 형식으로 제한하고자 하려는 의도는 없으며, 상기 가르침에 비춰 본 발명의 실시로부터 그 변형 및 치환이 가능하거나 취득될 수 있다. 본 발명의 원리들 및 그 실질적 응용을 설명하여, 이 분야의 당업자로 하여금 본 발명을 다양한 실시예들 및, 특정한 용도에 적합하고 신중히 고려된 그 변형을 통해 활용할 수 있게 하기 위해 실시예가 선택되었다.

Claims

사용자 기기를 인증하기 위한 방법에 있어서,

트러스티드 네트워크 (trusted network)의 프록시 엔티티 (proxying entity)에서, 사용자 기기로부터의 등록 요청을 수신하는 단계;

상기 트러스티드 네트워크의 프록시 엔티티에서 상기 사용자 기기의 사용자 고유 위치 정보를 수신하는 단계;

상기 프록시 엔티티에서, 상기 수신된 사용자 고유 위치 정보가 포함된 네트워크 트러스티드 헤더를 생성하는 단계;

인증을 위해, 상기 네트워크 트러스티드 헤더를 서빙 엔티티 (serving entity)로 전송하는 단계;

상기 사용자 고유 정보를, 서빙 엔티티 내 승인된 참조사항들의 리스트와 비교하는 단계; 및

상기 사용자 고유 정보가, 상기 승인된 참조사항들의 리스트 중 한 엔트리와 매치하면, 상기 트러스티드 네트워크로 액세스하는 사용자 기기를 인증하는 단계를 포함하고,

IBCF (Interconnection Border Control Function)가 상기 서빙 엔티티를 향해 상기 프록시 엔티티의 선택적 토폴로지 하이딩 (topology hiding)을 수행하고, 상기 IBCF는 암호화된 한 토큰으로부터 상기 사용자 고유 위치 정보를 추출하도록 설정되어, 그것이 서빙 엔티티에 의해 판독가능하게 되도록 함을 특징으로 하는 방법.
제1항에 있어서, 상기 네트워크 트러스티드 헤더는, 상기 사용자 고유 위치 정보가 삽입될 수 있는 파라미터를 포함함을 특징으로 하는 방법.
제1항 또는 제2항에 있어서, 상기 사용자 고유 위치 정보는 상기 프록시 엔티티에 의해 얻어진 line-id (라인-아이디)를 포함함을 특징으로 하는 방법.
제1항에 있어서,

상기 프록시 엔티티에 의해, 수신된 사용자 아이디를 디지털 서명하는 단계; 및

상기 서빙 엔티티에서, 상기 디지털 서명을 검증하는 단계를 더 포함함을 특징으로 하는 방법.
삭제
제1항에 있어서, 상기 서빙 엔티티는, 상기 프록시 엔티티에 기반하여 상기 사용자 기기를 인증함에 있어 NASS 번들형 인증 (NBA, NASS Bundled Authentication)이 적용가능한지 여부를 체크함을 특징으로 하는 방법.
제1항에 있어서, 상기 서빙 엔티티에는, 상기 프록시 엔티티 네임과 IP 어드레스, 상기 프록시 엔티티의 도메인 네임, 및 프록시 엔티티와 관련된 IP 어드레스 범위 중 적어도 하나를 포함하는 데이터가 제공되고,

상기 서빙 엔티티는 상기 제공된 데이터 대해, 상기 프록시 엔티티 네임과 IP 어드레스, 상기 프록시 엔티티의 도메인 네임, 및 프록시 엔티티와 관련된 IP 어드레스 범위 중 상기 적어도 하나를 체크함을 특징으로 하는 방법.
제1항에 있어서, 상기 트러스티드 네트워크는 IP Multimedia Subsystem (IP 멀티미디어 서브시스템)임을 특징으로 하는 방법.
제1항에 있어서, 상기 서빙 엔티티는 상기 수신된 네트워크 트러스티드 헤더에 대한 건전성 체크를 수행함을 특징으로 하는 방법.
제1항에 있어서, 상기 서빙 엔티티는, 표준 IP Multimedia Subsystem Session Initiation Protocol (IP 멀티미디어 서브시스템 세션 개시 프로토콜) 시그날링 플로로부터 도출되는 알려진 결과 대비, 캐리어 헤더들의 리스트 내 아이템 수를 체크하여, 건전성 체크를 수행함을 특징으로 하는 방법.
제1항에 있어서, 상기 프록시 서버는, 표준 IP Multimedia Subsystem Session Initiation Protocol (IP 멀티미디어 서브시스템 세션 개시 프로토콜) 시그날링 플로들 및 로컬 지식 (local knowledge) 중 한가지로부터 도출된 규칙들 및 제약사항들을 이용해, 상기 선택된 네트워크 트러스티드 헤더와 관련하여 수신된 등록 메시지에 대한 건전성 체크를 수행함을 특징으로 하는 방법.
제1항에 있어서, 상기 프록시 엔티티는 상기 사용자 기기로부터 수신된 등록 메시지를 체크하여, 그 등록 메시지가 둘 이상의 네트워크 트러스티드 헤더를 포함하거나, 어떤 P-Visited-network-ID, Path 또는 P-Charging-Vector를 포함하는 경우 그 등록 메시지를 거부할 수 있음을 특징으로 하는 방법.
제1항에 있어서, 상기 프록시 엔티티는 P-CSCF (Proxy Call Session Control Function)를 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 서빙 엔티티는 S-CSCF (Serving Call Session Control Function)를 포함함을 특징으로 하는 방법.
제1항의 방법을 수행하기 위한 컴퓨터 코드를 포함하는 컴퓨터 프로그램 제품을 저장한 컴퓨터에 의해 판독가능한 저장매체.
사용자 기기를 인증하기 위한 시스템에 있어서,

서빙 엔티티 (serving entity); 및

사용자 기기로부터의 등록 요청을 수신하고, 상기 사용자 기기를 식별하는 사용자 고유 위치 정보를 수신하고, 상기 사용자 고유 위치 정보가 포함된 네트워크 트러스티드 헤더를 생성하고, 인증을 위해, 상기 네트워크 트러스티드 헤더를 상기 서빙 엔티티로 전송하도록 구성된 프록시 엔티티 (proxying entity)를 포함하고,

상기 서빙 엔티티는, 상기 사용자 고유 위치 정보와, 승인된 위치 정보의 리스트를 비교하고, 상기 사용자 고유 정보가, 상기 승인된 참조사항들의 리스트 중 한 엔트리와 매치하면 상기 트러스티드 네트워크로 액세스하는 상기 사용자 기기를 인증하도록 구성되고,

IBCF (Interconnection Border Control Function)가 상기 서빙 엔티티를 향해 상기 프록시 엔티티의 선택적 토폴로지 하이딩 (topology hiding)을 수행하고, 상기 IBCF는 암호화된 한 토큰으로부터 상기 사용자 고유 위치 정보를 추출하도록 설정되어, 그것이 서빙 엔티티에 의해 판독가능하게 되도록 함을 특징으로 하는 시스템.
제16항에 있어서, 상기 네트워크 트러스티드 헤더는, 상기 사용자 고유 위치 정보가 삽입될 수 있는 파라미터를 포함함을 특징으로 하는 시스템.
제16항 또는 제17항에 있어서, 상기 프록시 엔티티는 상기 수신된 사용자 아이디를 디지털 서명하도록 추가 구성되고, 상기 서빙 엔티티는 상기 디지털 서명을 검증하도록 추가 구성됨을 특징으로 하는 시스템.
삭제
제16항에 있어서, 상기 서빙 엔티티는, 상기 프록시 엔티티에 기반하여 상기 사용자 기기를 인증함에 있어 NASS 번들형 인증 (NBA, NASS Bundled Authentication)이 적용가능한지 여부를 체크함을 특징으로 하는 시스템.
제16항에 있어서, 상기 서빙 엔티티에는, 상기 프록시 엔티티 네임과 IP 어드레스, 상기 프록시 엔티티의 도메인 네임, 및 프록시 엔티티와 관련된 IP 어드레스 범위 중 적어도 하나를 포함하는 데이터가 제공되고,

상기 서빙 엔티티는 상기 제공된 데이터 대해, 상기 프록시 엔티티 네임과 IP 어드레스, 상기 프록시 엔티티의 도메인 네임, 및 프록시 엔티티와 관련된 IP 어드레스 범위 중 상기 적어도 하나를 체크함을 특징으로 하는 시스템.
제16항에 있어서, 상기 트러스티드 네트워크는 IP Multimedia Subsystem (IP 멀티미디어 서브시스템)임을 특징으로 하는 시스템.
서비스 계층에서 사용자 기기를 인증하기 위한 방법에 있어서,

네트워크 연결 계층에서 사용자 기기를 인증하는 단계;

아이디 저장 엔티티에서, 상기 사용자 기기의 네트워크 연결 계층 인증에 반응해 상기 네트워크 연결 계층 아이디와 상기 사용자 기기의 서비스 계층 아이디 사이의 바인딩을 저장하는 단계;

프록시 엔티티에서, 서비스 계층 등록 절차 도중, 상기 사용자 기기의 상기 네트워크 연결 계층 아이디에 기반하여 상기 아이디 저장 엔티티로부터 사용자 기기의 상기 서비스 계층 아이디를 질의하는 단계;

상기 사용자 기기의 서비스 계층 아이디를 등록 메시지의 네트워크 트러스티드 헤더 안에 삽입하는 단계,

상기 등록 메시지를 서빙 엔티티로 전송하는 단계,

상기 서빙 엔티티에서, 사용자 프로파일 엔티티로부터 상기 사용자 기기의 서비스 계층 아이디를 검색하는 단계,

상기 등록 메시지의 네트워크 트러스티드 헤더를 통해 전송된 상기 사용자 기기의 서비스 계층 아이디가, 상기 사용자 프로파일 엔티티로부터 검색된 상기 사용자 기기의 서비스 계층 아이디와 매치하면, 상기 서비스 계층에서 상기 사용자 기기를 인증하는 단계를 포함하고,

상기 서비스 엔티티를 향해 상기 프록시 엔티티에 대한 토폴로지 하이딩이 수행됨으로써, 상기 네트워크 트러스티드 헤더가 암호화되게 함을 특징으로 하는 방법.
제23항에 있어서, 상기 네트워크 트러스티드 헤더는 Session Initiation Protocol의 네트워크 트러스티드 헤더를 포함함을 특징으로 하는 방법.
제23항 또는 제24항에 있어서, 상기 네트워크 트러스티드 헤더는, P-Visited-Network-ID 헤더, Path 헤더, 및 P-Charging-Vector 헤더 중 하나를 포함함을 특징으로 하는 방법.
제23항에 있어서, 상기 네트워크 트러스티드 헤더는 사용자 고유 위치 정보가 삽입될 수 있는 파라미터를 포함함을 특징으로 하는 방법.
제23항에 있어서,

상기 프록시 엔티티에 의해, 수신된 사용자 아이디를 디지털 서명하는 단계; 및

상기 서비스 엔티티에서, 상기 디지털 서명을 검증하는 단계를 더 포함함을 특징으로 하는 방법.
삭제
제23항에 있어서, 상기 서빙 엔티티는 상기 수신된 네트워크 트러스티드 헤더에 대한 건전성 체크를 수행함을 특징으로 하는 방법.
제23항에 있어서, 상기 서빙 엔티티는, 캐리어 헤더들의 리스트 내 아이템 개수를, 표준 IP Multimedia Subsystem Session Initiation Protocol 시그날링 플로로부터 도출된 알려진 결과에 대비해 체크함으로써 건전성 체크를 수행함을 특징으로 하는 방법.
제23항에 있어서, 상기 프록시 엔티티는 표준 IP Multimedia Subsystem Session Initiation Protocol 시그날링 플로 및 로컬 지식 가운데 하나에서 도출된 규칙들 및 제약사항들을 이용해, 선택된 네트워크 트러스티드 헤더와 관련해 수신된 등록 메시지에 대한 건전성 체크를 수행함을 특징으로 하는 방법.
제23항에 있어서, 상기 프록시 엔티티는 상기 사용자 기기로부터 수신된 등록 메시지를 체크하여, 그 등록 메시지가 둘 이상의 네트워크 트러스티드 헤더를 포함하거나, 어떤 P-Visited-network-ID, Path 또는 P-Charging-Vector를 포함하는 경우 그 등록 메시지를 거부할 수 있음을 특징으로 하는 방법.
제23항에 있어서, 상기 프록시 엔티티는 P-CSCF (Proxy Call Session Control Function)를 포함함을 특징으로 하는 방법.
제23항에 있어서, 상기 서빙 엔티티는 S-CSCF (Serving Call Session Control Function)를 포함함을 특징으로 하는 방법.
액세스 네트워크를 인터페이스하기 위한 제어 엔티티에 있어서,

사용자를 등록시키기 위한 등록 요청을 수신하고;

상기 사용자와 결부된 유일한 사용자 고유 위치 정보를 얻기 위해 아이디 저장 엔티티에 질의하고;

상기 유일한 사용자 고유 위치 정보를 상기 등록 요청의 네트워크 트러스티드 헤더 안에 삽입하고;

상기 등록 요청을 서빙 제어 엔티티를 향해 전송하도록 구성되고,

서비스 엔티티를 향해 프록시 엔티티에 대한 토폴로지 하이딩이 수행됨으로써, 상기 네트워크 트러스티드 헤더가 암호화되게 함을 특징으로 하는 제어 엔티티.
제35항에 있어서, 상기 제어 엔티티는 상기 유일한 사용자 고유 위치 정보를 네트워크 트러스티드 헤더 안에 삽입하도록 추가 구성됨을 특징으로 하는 제어 엔티티.
제35항 또는 제36항에 있어서, 상기 제어 엔티티는 상기 유일한 사용자 고유 위치 정보를 P-Visited-Network-ID 헤더, Path 헤더, 및 P-Charging-Vector 헤더 중 하나 안에 내장시키도록 추가 구성됨을 특징으로 하는 제어 엔티티.
고유한 위치 정보로 식별되는 사용자 기기의 트러스티드 네트워크로의 액세스를 인증하기 위한 시스템에 있어서,

서빙 엔티티; 및

사용자 기기로부터 수신된 등록 요청을 건전성 체크하고, 상기 사용자 기기의 상기 위치 정보를 수신하고, 상기 수신된 사용자 고유 위치 정보가 포함된 네트워크 트러스티드 헤더를 생성하고, 인증을 위해 캐리어 헤더를 상기 서빙 엔티티로 전송하도록 구성된 프록시 엔티티를 포함하고,

상기 서빙 엔티티는, 상기 등록 요청시 상기 수신된 네트워크 트러스티드 헤더를 건전성 체크하고, 상기 서빙 엔티티의 건전성 체크가 성공적이면, 상기 위치 정보를 승인된 위치 정보 리스트와 비교하고, 상기 위치 정보가 상기 승인된 참조사항들의 리스트 내 한 엔트리와 매치하면, 상기 트러스티드 네트워크로 액세스하는 사용자 기기를 인증하도록 구성되고,

IBCF (Interconnection Border Control Function)가 상기 서빙 엔티티를 향해 상기 프록시 엔티티의 선택적 토폴로지 하이딩 (topology hiding)을 수행하고, 상기 IBCF는 암호화된 한 토큰으로부터 상기 사용자 고유 위치 정보를 추출하도록 설정되어, 그것이 서빙 엔티티에 의해 판독가능하게 되도록 함을 특징으로 하는 시스템.
제38항에 있어서, 상기 선택된 네트워크 트러스티드 헤더는, 상기 사용자 고유 위치 정보가 삽입될 파라미터를 포함함을 특징으로 하는 시스템.
제38항 또는 제39항에 있어서, 상기 프록시 엔티티는 상기 수신된 사용자 아이디를 디지털 서명하도록 추가 구성되고, 상기 서빙 엔티티는 상기 디지털 서명을 검증하도록 추가 구성됨을 특징으로 하는 시스템.