JP2022541760A - コアネットワークドメインにおける証明書ハンドリングのための技法 - Google Patents

Abstract

移動体通信ネットワークのコアネットワークドメインにおいて、ネットワークリポジトリ機能（ＮＲＦ）が提供され、ＮＲＦは、ネットワーク機能（ＮＦ）ディスカバリのためにＮＦプロファイルを登録するように設定され、ＮＦ証明書はＮＦに向けて発行されており、各ＮＦ証明書はそれぞれのＮＦの公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含む。ＮＲＦは、ＮＦ証明書を有する登録ＮＦから、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および登録ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を含むプロファイル情報を受信するように設定される。ＮＲＦは、受信したプロファイル情報をリポジトリに記憶するようにさらに設定される。【選択図】図４

Description

本開示は、一般的に移動体通信システムに関し、詳細には移動体通信ネットワークのコアネットワークドメインに関する。より詳細には、本開示は、コアネットワークドメインにおいてネットワークリポジトリ機能およびネットワーク機能を提供する装置、コアネットワークドメインシステム、対応する方法、ならびにコンピュータプログラム製品に関する。

第３世代パートナーシッププロジェクト（３ＧＰＰ）は、第５世代（５Ｇ）通信システムに向けて開発中の技術仕様（ＴＳ：ｔｅｃｈｎｉｃａｌ ｓｐｅｃｉｆｉｃａｔｉｏｎ）である。３ＧＰＰ ＴＳ ２３．５０１ Ｖ１５．４．０（２０１８－１２）は、５Ｇのサービスベースアーキクテチャ（ＳＢＡ：Ｓｅｒｖｉｃｅ Ｂａｓｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）のアーキクテチャ上の態様を規定している。このＳＢＡによると、ネットワーク機能（ＮＦ：ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）は、他のＮＦからのサービスを消費するためにサービスベースの対話を使用する。サービスのディスカバリおよびそれらをプロデュースするＮＦのディスカバリは、ネットワークリポジトリ機能（ＮＲＦ：ｎｅｔｗｏｒｋ ｒｅｐｏｓｉｔｏｒｙ ｆｕｎｃｔｉｏｎ）によって提供される。

サービスをプロデュースするＮＦは、ＮＲＦにおいてＮＦのプロファイルを登録、更新、または登録抹消する。サービスを消費するＮＦは、所与のタイプのサービスを提供するＮＦインスタンスについてＮＲＦに問い合わせることによって、ＮＦプロデューサーインスタンスによって提供されるサービスを発見する。ＮＦは、ＮＲＦに登録されたＮＦのステータスの変更を、サブスクライブおよびサブスクライブ解除してもよい。そのようなサブスクリプションに基づいて、ＮＲＦは、ＮＦに他のＮＦのステータス変更を通知する。

ＳＢＡのセキュリティメカニズムは、３ＧＰＰ ＴＳ ３３．５０１ Ｖ１５．３．１で指定されている。例えば、この文書のセクション１３．１は、ＮＦは、サーバ側とクライアント側の両方の証明書によりトランスポートレイヤセキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）をサポートするものと規定している。このＴＬＳモードは、通常相互ＴＬＳ（ｍＴＬＳ）と称される。

ＴＬＳは、公開鍵を含み、認証局（ＣＡ：ｃｅｒｔｉｆｉｃａｔｉｏｎ ａｕｔｈｏｒｉｔｙ）によりデジタル署名されたＸ．５０９証明書を使用する。ＣＡは、他のＣＡによって署名される場合がある証明書を有している。ルートＣＡは、その証明書が、他のどのＣＡによっても署名されていないＣＡである。証明書チェーンは、ルートＣＡで始まり、すべての（ルートＣＡ以外の）中間的なＣＡを含み、クライアント証明書またはサーバ証明書で終わり、それぞれの証明書は、それ以前の証明書において符号化された公開鍵に対して署名される。

Ｘ．５０９証明書を受信するパーティは、それを有効性確認（ｖａｌｉｄａｔｅ）しなければならない。有効性確認とは、証明書チェーンを横断し、すべての証明書署名を有効性確認することを意味する。すべての署名が有効である場合、証明書は、有効であると考えられる。

サービスコンシューマーＮＦの証明書が、サービスプロデューサーＮＦによって正常に有効性確認された場合、サービスプロデューサーＮＦは、このサービスコンシューマーＮＦを認証（ａｕｔｈｅｎｔｉｃａｔｅ）する。次いで、サービスプロデューサーＮＦは、サービスコンシューマーＮＦを認可（ａｕｔｈｏｒｉｚｅ）する必要がある、つまり、サービスコンシューマーＮＦが、サービスプロデューサーＮＦによって提供されるサービスを消費するよう権限付けられているかチェックする必要がある。

ＴＳ ３３．５０１によると、任意選択的にトークンベースの認可を使用することが可能である。使用されない場合、サービスプロデューサーＮＦは、ローカルポリシに基づいてサービスコンシューマーＮＦの認可をチェックすることになる。

ｍＴＬＳを使用する場合、ＣＡ証明書のライフサイクル管理が必須となる。そのような管理を大規模に行うことは、複雑なタスクであり、高額な統合を必要として複雑性を招くものである。その一方で、トークンベースの認可が使用されず、認可がローカルポリシに基づいている場合、アクセス制御リスト（ＡＣＬ：ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ）または等価なメカニズムを、サービスプロデューサーＮＦにおいて設定する必要があり、ネットワーク内に新しいＮＦインスタンスをインスタンス化する際、すべてのサービスプロデューサーＮＦのＡＣＬを更新しなければならず、これもまた複雑かつ高額である。

コアネットワークドメインにおいてＣＡ証明書の効率的なハンドリングを提供する技法が必要である。

第１の態様によると、移動体通信ネットワークのコアネットワークドメインにおいて、ネットワークリポジトリ機能（ＮＲＦ）を提供するように設定された装置が提供され、ＮＲＦは、ネットワーク機能（ＮＦ）ディスカバリのためにＮＦプロファイルを登録するように設定され、ＮＦ証明書はＮＦに向けて発行されており、各ＮＦ証明書はそれぞれのＮＦの公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含む。装置は、ＮＦ証明書を有する登録ＮＦから、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および登録ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を含むプロファイル情報を受信するように設定される。装置は、受信したプロファイル情報をリポジトリに記憶するようにさらに設定される。

例として、一部またはすべてのＮＦのＮＦプロファイルは、対応するＮＦプロファイルに関連付けられるＮＦの証明書を有効性確認するために必要とされる１つもしくは複数またはすべてのＣＡ証明書を含む属性により、それぞれ拡張されてもよい。有効性確認は、特にサービスコンシューマーＮＦとサービスプロデューサーＮＦとの間の相互ハンドシェイク手順の間に行われる場合がある。ハンドシェイク手順は、ＴＬＳプロトコルに従ってもよい。

１つの変形では、登録ＮＦに向けて発行されたＮＦ証明書は、登録ＮＦのＮＦ識別情報とは異なるＮＦ識別子をさらに含む。この変形では、受信したプロファイル情報は、ＮＦ識別子をさらに含んでもよい。例として、一部またはすべてのＮＦのＮＦプロファイルは、対応するＮＦプロファイルに関連付けられるＮＦのＮＦ識別子を含むさらなる属性により、それぞれ拡張されてもよい。ＮＦ識別子は、サービスコンシューマーＮＦとサービスプロデューサーＮＦとの間の相互ハンドシェイク手順の間の、有効性確認目的に使用されてもよい。

例として、ＮＦ識別子は、ＮＦ証明書のサブジェクトフィールドに含まれる特定の識別子であってもよい。場合によっては、ＮＦ識別子は、完全修飾ドメイン名（ＦＱＤＮ：ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ ｄｏｍａｉｎ ｎａｍｅ）、およびｓｅｃｕｒｅ ｐｒｏｄｕｃｔｉｏｎ ｉｄｅｎｔｉｔｙ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｅｖｅｒｙｏｎｅ（ＳＰＩＦＦＥ）識別子のうちの１つの形態を取ってもよい。

ＮＦ識別子とは反対に、「レギュラー」ＮＦ識別情報は、コアネットワークドメインにおいて、（このＮＦ識別情報を含むＮＦプロファイルに関連付けられる）ＮＦを発見可能または区別可能にしてもよい。

装置は、少なくとも１つのＮＦタイプを示すディスカバリ要求を受信するように設定されてもよい。そのような実装形態では、装置は、リポジトリにアクセスして、少なくとも示されたＮＦタイプに一致する１つまたは複数のＮＦプロファイルを識別することと、１つまたは複数の一致するＮＦプロファイルからのディスカバリ情報を含むディスカバリ応答を送信することとを行うようにさらに設定されてもよい。場合によっては、ディスカバリ情報は、それぞれのＮＦプロファイルごとに記憶された少なくとも１つまたは複数のＣＡ証明書を含む。

装置は、第１のＮＦから、更新されたＣＡ証明書情報を含む更新要求を受信するようにさらに設定されてもよい。次いで、装置は、第１のＮＦのプロファイル情報を、更新されたＣＡ証明書情報に基づいて更新してもよい。特に、装置は、第１のＮＦに関連付けられる１つまたは複数の第２のＮＦを、通知のサブスクリプションを通じて、識別することと、更新されたＣＡ証明書情報の少なくとも一部を、１つまたは複数の識別された第２のＮＦに送信することとを行うように設定されてもよい。

装置は、第１のＮＦから、更新されたＮＦ識別子情報を含む更新要求を受信するようにさらに設定されてもよい。次いで、装置は、第１のＮＦのプロファイル情報を、更新されたＮＦ識別子情報に基づいて更新してもよい。特に、装置は、第１のＮＦに関連付けられる１つまたは複数の第２のＮＦを、通知のサブスクリプションを通じて、識別することと、更新されたＮＦ識別子情報の少なくとも一部を、１つまたは複数の識別された第２のＮＦに送信することとを行うように設定されてもよい。

第２の態様によると、移動体通信ネットワークのコアネットワークドメインにおいて、ネットワーク機能（ＮＦ）を提供するように設定される装置が提供され、ＮＦ証明書はＮＦに向けて発行されており、ＮＦ証明書は、ＮＦの公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含む。第２の態様の装置は、ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を取得することと、コアネットワークドメインにおいて、ＮＦディスカバリのためにＮＦプロファイルを登録するように設定される、ネットワークリポジトリ機能（ＮＲＦ）にプロファイル情報を送信することを行うように設定され、プロファイル情報は、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および少なくとも１つのＣＡ証明書を含む。

登録ＮＦに向けて発行されたＮＦ証明書は、登録ＮＦのＮＦ識別情報とは異なるＮＦ識別子をさらに含んでもよい。受信したプロファイル情報は、例えば属性の形態で（例えば、少なくとも１つのＣＡ証明書を規定する属性に加えて）ＮＦ識別子をさらに含んでもよい。

第２の態様の装置は、他のＮＦとのハンドシェイク手順において、他のＮＦに、ＮＦ証明書を送信するように設定されてもよい。ハンドシェイク手順は、ＴＬＳ（例えば、ｍＴＬＳ）に従ってもよい。

第２の態様の装置は、少なくとも１つのＮＦタイプを示すディスカバリ要求をＮＲＦに送信するように設定されてもよい。装置は、ＮＲＦから、少なくともＮＦタイプに一致する１つまたは複数のＮＦプロファイルからのディスカバリ情報を含むディスカバリ応答を受信するようにさらに設定されてもよく、ディスカバリ情報は、それぞれのＮＦプロファイル（また、任意選択的に、関連するＮＦ識別子）ごとに記憶された少なくとも１つのＣＡ証明書を含んでもよい。装置は、ディスカバリ情報を記憶装置に記憶してもよい。

特に、装置は、ディスカバリ情報が以前にＮＲＦから受信されている、他のＮＦから、他のＮＦに対して発行されたＮＦ証明書を受信することと、記憶装置からディスカバリ情報に含まれる少なくとも１つのＣＡ証明書を読み取ることと、ＮＦ証明書を記憶装置から読み取ったＣＡ証明書を使用して有効性確認することとを行うようにさらに設定されてもよい。ＮＦ証明書は、（例えば、ＴＬＳに従う）他のＮＦとのハンドシェイク手順のコンテキストにおいて受信されてもよい。

第２の態様の装置は、受信したＮＦ証明書から第１のＮＦ識別子を抽出することと、プロファイル情報から第２のＮＦ識別子を抽出することと、第２のＮＦ識別子に基づいて第１のＮＦ識別子を有効性確認することとを行うように設定されてもよい。例として、第１のＮＦ識別子および第２のＮＦ識別子が同一であることが有効性確認されてもよい。

第２の態様の装置は、ＮＲＦから、通知のサブスクリプションを通じて受信側ＮＦに関連付けられ、ディスカバリ情報が以前に受信されて記憶されているＮＦについての更新されたＣＡ証明書情報の少なくとも一部を受信するように設定されてもよい。この場合、装置は、記憶されたディスカバリ情報を、受信した更新されたＣＡ証明書情報に基づいて更新するようにさらに設定されてもよい。同一の手順が更新されたＮＦ識別子情報について実施されてもよい。

第２の態様の装置は、ＮＦについての更新されたＣＡ証明書情報を決定することと、ＮＲＦに、ＮＦについての更新されたＣＡ証明書情報を含む更新メッセージを送信することとを行うように設定されてもよい。同一の手順が更新されたＮＦ識別子情報について実施されてもよい。

いくつかの実装形態では、第２のものの装置は、サービスコンシューマーＮＦとして設定される。他の実装形態では、装置はサービスプロデューサーＮＦとして設定される。

第１の態様の装置（つまり、ＮＲＦ）および第２の態様の装置（つまり、ＮＦ）を備えるコアネットワークシステムもまた、提供される。

移動体通信ネットワークのコアネットワークドメインにおいて、ネットワークリポジトリ機能（ＮＲＦ）を提供する方法がさらに提示され、ＮＲＦは、ネットワーク機能（ＮＦ）ディスカバリのためにＮＦプロファイルを登録するように設定され、ＮＦ証明書はＮＦに向けて発行されており、各ＮＦ証明書はそれぞれのＮＦの公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含む。方法は、ＮＦ証明書を有する登録ＮＦから、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および登録ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を含むプロファイル情報を受信することを含む。方法はまた、受信したプロファイル情報をリポジトリに記憶することを含む。

上記方法は、第１の態様の装置（つまり、ＮＲＦ）によって実施されてもよい。

なおさらには、移動体通信ネットワークのコアネットワークドメインにおいて、ネットワーク機能（ＮＦ）を提供する方法が提示され、ＮＦ証明書はＮＦに向けて発行されており、ＮＦ証明書は、ＮＦの公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含む。方法は、ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を取得することと、コアネットワークドメインにおいて、ネットワーク機能（ＮＦ）ディスカバリのためにＮＦプロファイルを登録するように設定される、ネットワークリポジトリ機能（ＮＲＦ）にプロファイル情報を送信することとを含み、プロファイル情報は、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および少なくとも１つのＣＡ証明書を含む。

上記方法は、第２の態様の装置（つまり、ＮＦ）によって実施されてもよい。

コンピュータプログラム製品が１つまたは複数のプロセッサによって実行されると、本明細書で提示される方法を実行するように設定されたプログラムコード部分を含む、コンピュータプログラム製品もまた提供される。コンピュータプログラム製品は、コンピュータ可読記録媒体に記憶されてもよく、またはネットワーク接続を介してダウンロード用に提供されてもよい。

本開示のさらなる態様、詳細、および利点は、次の例示の実施形態の詳細な説明から、および図面から、明らかとなろう。

本開示のネットワークシステム実施形態の図である。 Ａ～Ｂは、本開示の２つのＮＲＦ装置実施形態を図示するブロック図である。 Ａ～Ｂは、本開示による、２つのＮＦ装置の実施形態を図示するブロック図である。 本開示の方法実施形態のフロー図である。 本開示のさらなる実施形態を図示する概略図シグナリング図である。 本開示のさらなる実施形態を図示する概略図シグナリング図である。 本開示のさらなる実施形態を図示する概略図シグナリング図である。 本開示のさらなる実施形態を図示する概略図シグナリング図である。

以下の説明では、限定ではなく説明目的として、本開示の十分な理解を与えるために具体的な詳細が説明される。本開示は、このような具体的な詳細から逸脱する他の実施形態において実践されてもよいことが当業者には明らかとなろう。

例えば、以下の説明は、５Ｇ仕様に従う例示的なコアネットワーク設定にフォーカスを当てるが、本開示はその点に限定されない。本開示はまた、コアネットワークドメインを有する他のセルラまたは非セルラの無線通信ネットワークに実装することもできる。

したがって、実施形態は具体的に５Ｇコアネットワークエンティティを参照して説明されるが、本開示は、他のネットワークタイプにおいて、および類似の機能性を有する他のネットワークエンティティによって、実装可能であることを了解されたい。その上、証明書関連の情報は、ＴＬＳのような例示的なタイプのセキュリティプロトコルおよびハンドシェイク手順のコンテキストにおいて説明されるが、本開示は、その点に限定されないことが容易に明らかとなろう。

当業者であれば、本明細書で説明されるステップ、サービス、および機能は、個々のハードウェア回路を用いて、プログラムされたマイクロプロセッサもしくは汎用コンピュータと併せてソフトウェア機能性を用いて、１つもしくは複数の特定用途向け集積回路（ＡＳＩＣ）を用いて、および／または１つもしくは複数のデジタル信号プロセッサ（ＤＳＰ）を用いて、実装され得ることがさらに了解されよう。本開示が、方法の観点で説明される場合、方法は、１つまたは複数のプロセッサ、および１つまたは複数のプロセッサに結合された１つまたは複数のメモリに具体化されてもよく、この場合、１つまたは複数のメモリは、１つまたは複数のプロセッサによって実行されると、本明細書で開示されるステップ、サービス、および機能を実施する、１つまたは複数のコンピュータプログラムを記憶することも了解されたい。

例示の実施形態の以下の説明では、同じ符号は、同一または類似のコンポーネントを指す。

図１は、本開示を実装することができるネットワークシステム１００の実施形態を図示している。図１に示されるように、ネットワークシステム１００は、モバイルネットワークオペレータによって運用されるコアネットワークドメイン１０２を含む。ＵＥタイプの端末デバイス１０４Ａ（例えば、スマートフォン）および２つのＩｏＴタイプの端末デバイス１０４Ｂ、１０４Ｃ（例えば、車用およびウェアラブルのデバイス）などの、様々な端末デバイス１０４が、アクセスネットワークドメインを通じてコアネットワークドメイン１０２によってサービスされている。アクセスネットワークドメインは、図１には示されていない。

以下では、コアネットワークドメイン１０２は、５Ｇ仕様に準拠しているものと仮定する。この理由のため、コアネットワークドメイン１０２の以下の説明は、典型的な５Ｇコアネットワーク要素を参照するが、本開示はそれに限定されない。アクセスネットワークドメインもまた、５Ｇ仕様に準拠していてもよく、任意選択的に、４Ｇおよび３Ｇ端末デバイスに対するコンパチビリティを追加的に提供してもよい。

コアネットワークドメイン１０２は、複数のネットワークエンティティを含む。図１では、ＮＲＦ関連の手順に関与するネットワークエンティティが主に図示されている。このようなネットワークエンティティは、様々なＮＦ１０７、ならびにＮＦサービスディスカバリおよびそれらを提供するＮＦ１０７のディスカバリの点で、ＮＦ１０７にサービスするように設定される中央的なＮＲＦ１０６を含む。

以下の実施形態のコンテキストにおいて、ＮＦ１０７は、規定された機能的な挙動および規定されたインタフェースを有する処理機能である。ＮＦ１０７は、専用ハードウェア上のネットワーク要素として、専用ハードウェア上で実行するソフトウェアインスタンスとして、または適当なプラットフォーム、例えば、クラウドインフラストラクチャにインスタンス化された仮想化された機能としてのいずれかで実装することができる。以下では、用語「ＮＦ」は、通常、専用のＮＦ識別情報を有する（また、専用のＮＦタイプである）識別可能なＮＦインスタンスを指す。

図１に図示されるＮＦ１０７は、ユーザプレーン機能（ＵＰＦ）１０７Ａ、１０７Ｂ、１０７Ｃなど、様々な形態を取ることが可能である。ＵＰＦタイプの各ＮＦ１０７Ａ、１０７Ｂ、１０７Ｃは、端末デバイス１０４Ａ、１０４Ｂ、１０４Ｃのうちの１つにそれぞれ関連付けられ、関連するデータトラフィックをハンドリングする。各ＵＰＦ１０７Ａ、１０７Ｂ、１０７Ｃは、原理的にはネットワーク設定に応じて端末デバイス１０４Ａ、１０４Ｂ、１０４Ｃのうちの複数のデバイスについてのデータトラフィックをハンドリングすることを了解されたい。

ＮＦ１０７Ａ、１０７Ｂ、１０７Ｃおよび他のＮＦ１０７Ｄ、１０７Ｅは、その個々のＮＲプロファイルをＮＲＦ１０６に登録、更新、または登録解除してもよく、ＮＲＦ１０６に登録されたＮＦ１０７のステータス変更についてＮＲＦ１０６が通知されるようＮＲＦ１０６においてサブスクライブおよびサブスクライブ解除してもよい。これらの（および他の）手順では、ＮＲＦ１０６は、例示的な５Ｇ実装形態において、いわゆるＮｎｒｆ＿ＮＦＭａｎａｇｅｍｅｎｔサービスを提供する（３ＧＰＰ ＴＳ ２９．５１０ Ｖ．１５．２．０（２０１８－１２）のセクション５．２参照）。その上、ＮＦ１０７はまた、ＮＲＦ１０６に、他のＮＦ１０７によって提供されるサービスを発見するため、およびそれらをどのように消費するかを問い合わせることができる。これらの手順では、ＮＲＦ１０６は、例示的な５Ｇ実装形態において、いわゆるＮｎｒｆ＿ＮＦＤｉｓｃｏｖｅｒｙサービスを提供する（ＴＳ ２９．５１０のセクション５．３参照）。

ＮＦ１０７のそれぞれは、ＮＦプロファイルに関連付けられる。特定のＮＦのＮＦプロファイルは、特定のＮＦ１０７の一意な識別情報ならびにそのタイプ（例えば、そのＮＦによって提供されるサービスのタイプによって示される）など、複数のＮＦ属性を規定する。ＮＲＦ１０６は、ＮＦ１０７から受信したプロファイル関連情報を記憶するためのデータリポジトリ１０６Ａを含む。各ＮＦ１０７もまた、ローカルのデータ記憶装置を含む。

ＴＳ ３３．５０１のセクション１３．１によると、ＮＦ１０７は、サーバ側およびクライアント側両方のＮＦ証明書を用いてＴＬＳをサポートする。本明細書で理解されるように、サービスプロデューサーＮＦ１０７は、サーバ側に置かれ、その一方でサービスコンシューマーＮＦ１０７は、クライアント側に置かれる。各ＮＦ証明書は、個々のＮＦの公開鍵および少なくとも１つのＣＡの少なくとも１つの署名を含む。

図２Ａおよび図２Ｂは、図１のＮＲＦ１０６の２つの実施形態を図示している。図２Ａに図示される実施形態では、ＮＲＦ１０６は、プロセッサ２０２およびプロセッサ２０２に結合されるメモリ２０４を含む。ＮＲＦ１０６は、任意選択的な入力インタフェース２０６および任意選択的な出力インタフェース２０８をさらに含む。メモリ２０４は、プロセッサ２０２の動作を制御するプログラムコードを記憶する。メモリ２０４、または様々な記憶装置はまた、データリポジトリ１０６Ｂを記憶する。

プロセッサ２０２は、例えば、入力インタフェース２０６を通じて、およびＮＦ証明書を有する登録ＮＦから、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および登録ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を含むプロファイル情報を受信するように適合される。プロセッサ２０２は、図１に図示されるように、受信したプロファイル情報をデータリポジトリ１０６Ａに記憶するようにさらに設定される。

図２Ｂは、ＮＲＦ１０６がモジュール的な設定で実装される実施形態を示している。図２Ｂに示されるように、ＮＲＦ１０６は、登録ＮＦから、登録ＮＦのＮＦ識別情報、登録ＮＦのＮＦタイプ、および登録ＮＦに向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を含むプロファイル情報を受信するように設定される受信モジュール２１０を含む。ＮＲＦ１０６は、受信したプロファイル情報をデータリポジトリに記憶するように設定される記憶モジュール２１２をさらに含む。

図３Ａおよび図３Ｂは、ＮＦ１０７のＮＦプロファイルをＮＲＦ１０６に登録するように設定される図１のＮＦ１０７の２つの実施形態を図示する。図３Ａに図示される実施形態では、ＮＦ１０７は、プロセッサ３０２およびプロセッサ３０２に結合されるメモリ３０４を含む。ＮＦ１０７は、任意選択的な入力インタフェース３０６および任意選択的な出力インタフェース３０８をさらに含む。メモリ３０４は、プロセッサ３０２の動作を制御するプログラムコードを記憶する。メモリ３０４、または様々な記憶装置はまた、ＮＦ１０７自身についての、または他のＮＦ１０７から取得したＣＡ証明書関連情報を記憶してもよい。

ＮＦ１０７のプロセッサ３０２は、例えば、入力インタフェース３０６を通じて、ＮＦ１０７に向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を取得するように適合される。プロセッサ３０２は、例えば、出力インタフェース３０８を通じて、コアネットワークドメイン１０２において、ＮＦディスカバリのためにＮＦプロファイルを登録するように設定されるＮＲＦ１０６に、プロファイル情報を送信するようにさらに適合される。送信されるプロファイル情報は、登録ＮＦ１０７のＮＦ識別情報、登録ＮＦ１０７のＮＦタイプ、および少なくとも１つのＣＡ証明書を含む。

図３Ｂは、ＮＦ１０７がモジュール的な設定で実装される実施形態を示している。図３Ｂに示されるように、ＮＦ１０７は、ＮＦ１０７に向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を取得するように設定される取得モジュール３１０を含む。ＮＦ１０７は、コアネットワークドメイン１０２において、ＮＦディスカバリのためにＮＦプロファイルを登録するように設定されるＮＲＦ１０６に、プロファイル情報を送信するように設定される送信モジュール３１２をさらに含む。プロファイル情報は、登録ＮＦ１０７のＮＦ識別情報、登録ＮＦ１０７のＮＦタイプ、および少なくとも１つのＣＡ証明書を含む。

図４は、２つのフロー図４００、４１０において、本開示の方法実施形態を図示している。フロー図４００の方法実施形態は、図３Ａおよび図３ＢのＮＦ実施形態のいずれかによって実施されてもよい。フロー図４１０の方法実施形態は、図２Ａおよび図２ＢのＮＲＦ実施形態のいずれかによって実施されてもよい。

フロー図４００に図示される方法は、登録ＮＦ１０７によって、登録ＮＦ１０７に向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を取得するステップ４０２を含む。少なくとも１つのＣＡ証明書は、ＮＦ設定の一部として登録ＮＦ１０７によって取得されている。この設定はベンダー特有であるが、典型的にはＮＥＴＣＯＮＦなどの汎用のＣｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ（ＣＭ）インタフェースが、この目的のために使用される。

ステップ４０４では、登録ＮＦ１０７は、そのＮＦプロファイルを、コアネットワークドメイン１０２において、ＮＦディスカバリのためにＮＲＦ１０６に登録することができるように、プロファイル情報をＮＲＦ１０６に送信する。プロファイル情報は、（少なくとも）登録ＮＦ１０７のＮＦ識別情報、登録ＮＦ１０７のＮＦタイプ、およびステップ４０２で取得した少なくとも１つのＣＡ証明書を含む。

次にフロー図４１０を見ると、ＮＲＦ１０６は、ステップ４０４で送信されたプロファイル情報を、ステップ４０６において登録ＮＦ１０７から受信する。上で説明したように、プロファイル情報は、（少なくとも）登録ＮＦ１０７のＮＦ識別情報、登録ＮＦ１０７のＮＦタイプ、および登録ＮＦ１０７に向けて発行されたＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書を含む。そして、ステップ４０８では、ＮＲＦ１０６は、受信したプロファイル情報を、そのデータリポジトリ１０６Ａに記憶する。

以下では、上の一般的な実施形態を、図５ａ～図５Ｄで図示されるシグナリング実施形態を参照してさらに詳細に説明する。これらのシグナリング図は、とりわけＴＳ ２９．５１０で規定されるような例示的な５Ｇシグナリング実装形態に基づいている。例示的なレガシーなＮＦプロファイルのコンテンツは、ＴＳ ２９．５１０のセクション６．１．６．２．２および６．１．６．２．３に規定されており、以下の実施形態では次の２つの属性のうちの一方または両方によって拡張される：

ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性は、ＮＦ１０７によって使用される証明書を検証（ｖｅｒｉｆｙ）するために使用される最大ＮのＣＡ証明書の一覧を含む任意選択的な属性である。この属性の形式は、文字列型の配列である。各文字列は、１つのＣＡ証明書のコンテンツを含んでもよい。

１つの変形では、各文字列は、ＰＥＭ（Ｐｒｉｖａｃｙ－ｅｎｈａｎｃｅｄ Ｅｌｅｃｔｒｏｎｉｃ Ｍａｉｌ）Ｂａｓｅ６４符号化ＤＥＲ（Ｄｉｓｔｉｎｇｕｉｓｈｉｎｇ Ｅｎｃｏｄｉｎｇ Ｒｕｌｅ）証明書を、「－－－－－ＢＥＧＩＮ ＣＥＲＴＩＦＩＣＡＴＥ－－－－－」と「－－－－－ＥＮＤ ＣＥＲＴＩＦＩＣＡＴＥ－－－－－」とで囲んで、表現する。ＮＦプロファイルに通常使用されるＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）エンコーディングとコンパチビリティがある限り、ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性には、他のエンコーディング形式が可能である。

ｉｄｅｎｔｉｆｉｅｒ属性は、ＮＦインスタンスを、そのＣＡ証明書において識別するために使用される識別子を含む任意選択的な属性である。形式は、文字列型である。このｉｄｅｎｔｉｆｉｅｒ属性は、レガシーなＮＦプロファイルにおけるｎｆＩｎｓｔａｎｃｅＩＤ属性またはｓｅｒｖｉｃｅＩｎｓｔａｎｃｅＩＤ属性とは異なっており、それらに加えて提供されることに留意されたい。

１つの変形では、ｉｄｅｎｔｉｆｉｅｒ属性は、ＦＱＤＮである。ＦＱＤＮは、３ＧＰＰ ＴＳ ２３．００３ Ｖ１５．６．０（２０１８－１２）のセクション２８．２に従って構築されてもよい。ＦＱＤＮの一例は、以下の通り：
＜ｎｆ－ｉｎｓｔａｎｃｅ－ｉｄ＞．＜ｎｆ－ｉｎｓｔａｎｃｅ－ｔｙｐｅ＞．５ｇｃ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ
ここで、
－ ＜ｎｆ－ｉｎｓｔａｎｃｅ－ｉｄ＞は、ＮＦインスタンスに一意な識別子である。公衆陸上移動体通信網（ＰＬＭＮ）でのＮＦタイプには、２つの等しい識別子が存在してはならない。
－ ＜ｎｆ－ｉｎｓｔａｎｃｅ－ｔｙｐｅ＞は、ＮＦタイプ、例えばＵｎｉｆｉｅｄ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ（ＵＤＭ）である。
－ ＜ＭＮＣ＞および＜ＭＣＣ＞は、オペレータのＰＬＭＮのモバイルネットワークコード（ＭＮＣ）およびモバイル国コード（ＭＣＣ）に対応する。

別の変形では、ｉｄｅｎｔｉｆｉｅｒ属性は、ＳＰＩＦＦＥ識別子である。例示的なＳＰＩＦＦＥ識別子を、次に示す：
ｓｐｉｆｆｅ：／／５ｇｃ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ／＜ｎｆ－ｉｎｓｔａｎｃｅ－ｔｙｐｅ＞／＜ｎｆ－ｉｎｓｔａｎｃｅ－ｉｄ＞
ここで、
－ ＜ｎｆ－ｉｎｓｔａｎｃｅ－ｉｄ＞は、ＮＦインスタンスに一意な識別子である。ＰＬＭＮでのＮＦタイプには、２つの等しい識別子が存在してはならない。
－ ＜ｎｆ－ｉｎｓｔａｎｃｅ－ｔｙｐｅ＞は、ＮＦタイプ、例えばＵＤＭである。
－ ＜ＭＮＣ＞および＜ＭＣＣ＞は、オペレータのＰＬＭＮのＭＮＣおよびＭＣＣに対応する。

なおさらなる変形では、ｉｄｅｎｔｉｆｉｅｒ属性は、不透明な値である。不透明なｉｄｅｎｔｉｆｉｅｒ属性の例を、次に示す：
３６ｆ０１０２７－４ｄ６ｆ－４５ｅ６－８ｅ６０－１ｅ１４ｄ４６４３４４ｅ

図５Ａは、図１に図示されるＮＦ１０７のいずれかをＮＲＦ１０６に登録するコンテキストにおけるシグナリング実施形態を描いている。図５Ａに描かれるＮＦ１０７は、サービスプロデューサーもしくはサービスコンシューマーであってもよく、または優勢な要求に応じて両方の役割を果たすこともできる。

事前条件として、ＮＦ１０７が、例えば設定中に、ルートＣＡ証明書、および任意選択的にはＮＦ１０７の証明書に署名するために使用された１つまたは複数の中間的なＣＡ証明書を用いてプロビジョニングされていることが仮定される。このプロビジョニングは、図４に図示されるステップＳ４０２のコンテキストで生じてもよい。

図５Ａのシグナリング実施形態は、以下のステップを含む：

最初のステップ１１００では、ＮＦ１０７は、自身のＮＦプロファイルを作成する。ＮＦプロファイルは、とりわけそのＮＦタイプ（例えば、ＵＤＲ）、その一意なＮＦ識別情報（例えば、ｎｆＩｎｓｔａｎｃｅＩＤまたはｓｅｒｖｉｃｅＩｎｓｔａｎｃｅＩＤ）、および以下の属性のうちの少なくとも１つを含む：
－ ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性：（例えば、上で説明したように符号化された）ＮＦ１０７の証明書を有効性確認するために必要となるルートおよび／または中間的なＣＡ証明書を含む。
－ ｉｄｅｎｔｉｆｉｅｒ属性：（例えば、上で説明したような）ＮＦ識別子を含む。いくつかの変形では、ＮＦ識別子は、ＮＦ１０７の証明書のＳｕｂｊｅｃｔ ＮａｍｅまたはＳｕｂｊｅｃｔ Ａｌｔｅｒｎａｔｉｖｅ Ｎａｍｅフィールドの値と一致する。

いくつかの実装形態では、ｉｄｅｎｔｉｆｉｅｒ属性は省略されてもよい。他の実装形態では、ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性は省略されてもよい。このような属性のうちの１つが省略される場合では、一定のセキュリティプロセスを実施することができない（図５Ｃを参照して以下で議論する通り）。そのため、最大のセキュリティとして、両方の属性が、デフォルトで使用される場合がある。

ステップ１１０１では、ＮＦ１０７は、Ｎｎｒｆ＿ＮＦＭａｎａｇｅｍｅｎｔ＿ＮＦＲｅｇｉｓｔｅｒ要求を送信することによって自身をＮＲＦ１０６に登録する（図４におけるステップＳ４０４参照）。要求は、ステップ１１００で既に作成されたＮＦプロファイルを含む。

ＮＲＦ１０６は、ＮＦプロファイルを受信し（図４におけるステップＳ４０６参照）、受信したＮＦプロファイルをそのデータリポジトリ１０６Ａに記憶する（図４におけるステップＳ４０８参照）。

次いで、ステップ１１０２では、ＮＲＦ１０６、およびＮｎｒｆ＿ＮＦＭａｎａｇｅｍｅｎｔ＿ＮＦＲｅｇｉｓｔｅｒ応答をＮＦ１０７に返す。この応答は、ＮＦ１０７に、ＮＦプロファイルがＮＦ１０７によって適切に受信され、記憶されたことを知らせる。

図５Ｂは、サービスコンシューマーの役割を仮定したＮＦ１０７によるＮＦディスカバリのコンテキストにおけるシグナリング実施形態を描いている。以下では、例示的に、図１のＮＦ１０７Ｄがサービスコンシューマーとして振る舞い、ＮＦ１０７Ｅはサービスプロデューサーとして振る舞うと仮定する。図５Ａを参照して上で説明したように、ＮＲＦ１０６は、そのデータリポジトリ１０６Ａに、他のＮＦ１０７に対してサービスプロデューサーとして振る舞うことができるＮＦ１０７すべてのＮＦプロファイル（関連するＮＦタイプおよびＣＡ証明書とともに）を記憶する。

ステップ１２００では、サービスコンシューマーＮＦ１０７Ｄは、対話する必要がある１つまたは複数のＮＦタイプ（つまり、サービスタイプ）を決定し、それらのそれぞれに対して、ステップ１２０１～１２０５を繰り返す。

ステップ１２０１では、サービスコンシューマーＮＦ１０７Ｄは、Ｎｎｒｆ＿ＮＦＤｉｓｃｏｖｅｒｙ要求をＮＲＦ１０７に送信する。この要求は、選択基準として少なくとも１つの特定のＮＦタイプを示す。場合によっては、要求は１つもしくは複数のさらなる選択基準、または他の情報を含んでもよい。

次いで、ステップ１２０２では、ＮＲＦ１０６は、１つまたは複数のサービスプロデューサーＮＦ１０７ＥのＮＦプロファイルをマッチングするためにそのデータリポジトリ１０６Ａを調べ、Ｎｎｒｆ＿ＮＦＤｉｓｃｏｖｅｒｙ応答を返す。この応答には、ステップ１２０１で示された１つまたは複数の基準に一致するＮＦプロファイルが含まれる。ステップ１２０２で返されたＮＦプロファイルは、とりわけ個々のｃａＣｅｒｔｉｆｉｃａｔｅｓ属性およびｉｄｅｎｔｉｆｉｅｒ属性を含んでもよい。この方法では、サービスコンシューマーＮＦ１０７Ｄは、将来的な使用のために、ＮＲＦ１０６のデータリポジトリ１０６ＡにサービスプロデューサーＮＦ１０７Ｅごとに記憶された１つまたは複数のＣＡ証明書を受信する。

ステップ１２０３では、サービスコンシューマーＮＦ１０７Ｄは、受信したＮＦプロファイルを処理する。ＮＦプロファイルごとに、サービスコンシューマーＮＦ１０７Ｄは、：
－ ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性のコンテンツを抽出し、ＣＡ証明書ごとに、抽出したコンテンツをＴＬＳ実装形態のセキュアなレジストリに記憶する；
－ ｉｄｅｎｔｉｆｉｅｒ属性のコンテンツを抽出し、それを内部的に（そして、通常はｃａＣｅｒｔｉｆｉｃａｔｅｓ属性から抽出されたコンテンツとは別個に）記憶する。

さらなるステップ１２０４では、サービスコンシューマーＮＦ１０７Ｄは、（任意選択的な）Ｎｎｒｆ＿ＮＦＭａｎａｇｅｍｅｎｔ＿ＮＦＳｔａｔｕｓＳｕｂｓｃｒｉｂｅ要求をＮＲＦ１０６に送信する。このサブスクリプション要求では、ステップ１２０２においてＮＦプロファイルが取得されたサービスプロデューサーＮＦ１０７Ｅのステータスの変更を受信し、示されるＮＦタイプに一致する新しいＮＦプロファイルを知るために、サービスコンシューマーＮＦ１０７ＤはＮＦタイプを示す。

ステップ１２０５では、ＮＲＦ１０６は、サブスクリプション要求を処理し、Ｎｎｒｆ＿ＮＦＭａｎａｇｅｍｅｎｔ＿ＮＦＳｔａｔｕｓＳｕｂｓｃｒｉｂｅ応答を返す。サブスクリプション応答は、サービスコンシューマーＮＦ１０７Ｄにサブスクリプション要求が適切に受信されて処理されたことを通知する。

図５Ｂに図示されるシグナリング手順の終わりには、サービスコンシューマーＮＦ１０７Ｄは、潜在的にサービスを消費する必要があるすべてのサービスプロデューサーＮＦ１０７Ｅの、ＮＦ識別情報、ＣＡ証明書、およびＮＦ識別子すべてを有する。同じシグナリング手順が、サービスプロデューサーＮＦ１０７Ｅによって実行される可能性があるが、この場合は、サービスプロデューサー１０７Ｅが、そのサービスを提供するＮＦタイプを示している。対応するシグナリング手順の終わりには、サービスプロデューサーＮＦ１０７Ｅは、そのサービスを消費するすべてのサービスコンシューマーＮＦ１０７Ｄの、ＮＦ識別情報、ＣＡ証明書、およびＮＦ識別子すべてを有する。

一部のＮＦ１０７は、サービスコンシューマーとサービスプロデューサーの両方の役割を同時的に有することが可能であり、例えば、ＵＤＭは認証サーバ機能（ＡＵＳＦ）に対してはサービスプロデュースとして振る舞い、ｕｎｉｆｉｅｄ ｄａｔａ ｒｅｐｏｓｉｔｏｒｙ（ＵＤＲ）に対してはコンシューマーとして振る舞う。そのような事例では、図５Ｂに図示されるシグナリング手順は、所与のＮＦ１０７によって２回実行されてもよい（サービスコンシューマーとして１回、サービスプロデューサーとして１回）。

図５Ｃは、サービスコンシューマーＮＦ１０７Ｄによる、サービスプロデューサーＮＦ１０７Ｅに対する、ＮＦサービス呼び出しのコンテキストにおけるシグナリング実施形態を描いている。サービスプロデュースＮＦ１０７Ｅは、図５Ｂに図示されるように、以前にディスカバリ／サブスクリプションのシグナリングを使用してサービスコンシューマーＮＦ１０７Ｄによって発見されている。

ステップ１３００では、サービスコンシューマーＮＦ１０７Ｄは、ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ ２（ＨＴＴＰ／２）接続をサービスプロデューサーＮＦ１０７Ｅに向けて開始する。接続はｍＴＬＳでセキュアにされているため、ＴＬＳハンドシェイク手順が始まる（破線枠を参照）。

ステップ１３０１では、サービスコンシューマーＮＦ１０７Ｄは、Ｃｌｉｅｎｔ ＨｅｌｌｏメッセージをサービスプロデューサーＮＦ１０７Ｅに送信し、ステップ１３０２では、サービスプロデューサーＮＦ１０７Ｅは、Ｓｅｒｖｅｒ Ｈｅｌｌｏメッセージを、（他のパラメータの中でも）サービスプロデューサーＮＦ１０７Ｅの証明書（図５Ｃの「サーバ証明書」）を含めて、サービスコンシューマーＮＦ１０７Ｅに送信する。

次いで、ステップ１３０３では、サービスコンシューマーＮＦ１０７Ｄは、サービスをプロデュースするＮＦ１０７Ｅによって提供されたサーバ証明書を有効性確認する。このコンテキストでは、ＴＬＳ実装形態は、セキュアなレジストリにアクセスして、図５Ｂのステップ１２０３においてサービスプロデューサーＮＦ１０７Ｅについて記憶された１つまたは複数のＣＡ証明書をフェッチする。そのような検証は、通常はルートＣＡ証明書から中間的なＣＡ証明書を経由してＮＦ証明書までの証明書チェーンを横断すること、および証明書署名のすべてを有効性確認することによって、Ｘ．５０９プロトコルに従って実施され、本明細書ではあまり詳細には説明しない。以下では、証明書チェーンのすべての署名が正常に有効性確認することができたため、有効性確認がすべて正常であったと仮定する。

正常な有効性確認の後、ステップ１３０４において、サービスコンシューマーＮＦ１０７Ｄは、メッセージをサービスプロデューサーＮＦ１０７Ｅに送信する。このメッセージは、他のパラメータの中でも、サービスコンシューマーＮＦ１０７Ｄの証明書を含む（図５Ｃにおける「クライアント証明書」）。

ステップ１３０５では、サービスプロデューサーＮＦ１０７Ｅは、サービスコンシューマーＮＦ１０７Ｄによって提供されたクライアント証明書を（正常に）有効性確認する。この目的のため、ＴＬＳ実装形態は、セキュアなレジストリにアクセスして、図５Ｂのステップ１２０３においてサービスコンシューマーＮＦ１０７Ｄについて記憶された１つまたは複数のＣＡ証明書をフェッチする。サービスプロデューサーＮＦ１０７Ｅは、クライアント証明書の詳細を後の使用のために記憶する。

ステップ１３０６では、サービスプロデューサーＮＦ１０７Ｅは、Ｓｅｒｖｅｒ ＦｉｎｉｓｈｅｄメッセージをサービスコンシューマーＮＦ１０７Ｄに送信し、ＴＬＳハンドシェイクフェーズを終了する。この時点から、ＨＴＴＰ／２接続はセキュアにされ、ｍＴＬＳ認証は、正常に完了する。

ステップ１３０７では、サービスコンシューマーＮＦ１０７Ｄは、ＮＦ Ｓｅｒｖｉｃｅ要求をサービスプロデュースＮＦ１０７Ｅに送信し、そのサービスのうちの１つを消費する。

ステップ１３０８では、サービスプロデューサーＮＦ１０７Ｅは、そのサービスの消費を可能にすることに先立って、サービスコンシューマーＮＦ１０７Ｄを認可する。このために、サービスプロデューサーＮＦ１０７Ｅは、：
－ ステップ１３０４および１３０５でそれぞれ受信して記憶したクライアント証明書から、Ｓｕｂｊｅｃｔ ＮａｍｅおよびＳｕｂｊｅｃｔ Ａｌｔｅｒｎａｔｉｖｅ Ｎａｍｅフィールドを抽出する；
－ そのサービスを消費するＮＦタイプのＮＦプロファイルを反復処理し（例えば、図５Ｂに図示されるディスカバリシグナリングの間に、ＮＲＦ１０６から既に受信した通りに）、各ＮＦプロファイル中のｉｄｅｎｔｉｆｉｅｒ属性を、クライアント証明書からのＳｕｂｊｅｃｔ ＮａｍｅまたはＳｕｂｊｅｃｔ Ａｌｔｅｒｎａｔｉｖｅ Ｎａｍｅフィールドとマッチングする。

一致が見つかった場合、サービスコンシューマーＮＦ１０７Ｄは、正常に認可されており、ステップ１３０９において、サービスプロデューサーＮＦ１０７Ｅはサービス呼び出し応答を返す。一方で、一致が見つからない場合、サービスコンシューマーＮＦ１０７Ｄは、認可されておらず、ステップ１３１０において、サービスプロデューサーＮＦ１０７Ｅはエラー応答を返す。エラーメッセージは、ステップ１３０７におけるサービス要求受信が認可されなかったことを示す。

ステップ１３０１～１３０６ならびにステップ１３０７～１３０９は、それぞれ新しいｃａＣｅｒｔｉｆｉｃａｔｅｓ属性および新しいｉｄｅｎｔｉｆｉｅｒ属性に基づいていることを了解されたい。これらの属性のうちの１つしか実装されていない場合でも、レガシーな実装形態と比較して、なお実装形態またはセキュリティ上の恩恵がある。

図５Ｄは、ライフサイクル管理（ＬＣＭ）に係るＣＡ証明書の更新（例えば、その失効による）のコンテキストにおけるシグナリング実施形態を描いている。更新する必要があるＣＡ証明書は、図５Ａおよび図５Ｂを参照して上で議論したように、コアネットワークドメイン１０２内で既に通信されたことがある。同一のシグナリング手順が、各ＮＦ１０７によって、そのサービスコンシューマーかサービスプロデューサーかの役割とは無関係に、適用される。図５Ｄに図示されるシグナリング手順の事前条件として、ＮＦ１０７には、少なくとも１つの更新された、または新しい、ルートおよび／または中間的なＣＡ証明書がプロビジョニングされている。

以下では、ＬＣＭ運用のため、ＣＡ証明書は、例として、サービスプロデューサーＮＦ１０７Ｅ用に更新されなければならないと仮定する。故にサービスプロデューサーＮＦ１０７Ｅは、そのＮＦプロファイルを、ステップ１４００においてｃａＣｅｒｔｉｆｉｃａｔｅｓ属性についての新しい値で更新する。

ステップ１４０１では、サービスプロデューサーＮＦ１０７Ｅは、ＮＦＵｐｄａｔｅ要求をＮＲＦ１０６に送信する。要求は、ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性についての新しい値を示しており、潜在的には追加的な変わってしまったＮＦプロファイル属性を伴う。いくつかの実装形態では、完全なＮＦプロファイルが送信され、他の実装形態では、変わってしまった属性の値だけが送信される。

ステップ１４０２では、ＮＲＦ１０６は、更新されたＮＦプロファイルをデータリポジトリ１０６Ａに記憶し、ＮＦＵｐｄａｔｅ応答をサービスプロデュースＮＦ１０７Ｅに返す。

ステップ１４０３では、ＮＲＦ１０６は、ステップ１４０２において要求メッセージを送信した特定のサービスプロデューサーＮＦ１０７Ｅ中の変更に対して、または一般的には、ステップ１４０２において要求メッセージを送信した特定のサービスプロデューサーＮＦ１０７Ｅが属するサービスプロデューサーＮＦタイプ中の変更に対して、アクティブなサブスクリプションを有するすべてのサービスコンシューマーＮＦ１０７Ｄを決定する。

次いで、ステップ１４０４において、ステップ１４０３で決定されたサービスコンシューマーＮＦ１０７Ｄごとに、ＮＲＦ１０６はＮＦＳｔａｔｕｓＮｏｔｉｆｙ要求を送信する。要求には、ステップ１４０１で受信した修正ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性が含まれ、それに関連するサービスプロデューサーＮＦ１０７Ｅのｉｄｅｎｔｉｆｉｅｒ属性を示す。

ステップ１４０５では、特定のサービスコンシューマーＮＦ１０７Ｄは、要求を受信し、ＮＦＳｔａｔｕｓＮｏｔｉｆｙ応答をＮＲＦ１０６に返す。応答は、要求の適当な受信を肯定応答する。

さらには、ステップ１４０６では、サービスコンシューマーＮＦ１０７Ｄは、ステップ１４０５で受信したメッセージからｃａＣｅｒｔｉｆｉｃａｔｅｓ属性のコンテンツを抽出し、それらをＴＬＳ実装形態のセキュアなレジストリに記憶する。

図５Ｄにおけるシグナリング手順の終わりには、それぞれ考慮されるサービスコンシューマーＮＦ１０７Ｄは、更新されたそのＣＡ証明書を、手順を開始したサービスプロデューサーＮＦ１０７Ｅについて記憶されたものとして有する。他の方向では、また、サービスコンシューマーＮＦ１０７Ｄは、自身のそれぞれのｃａＣｅｒｔｉｆｉｃａｔｅｓ属性を更新し、サービスプロデューサーＮＦ１０７Ｅは、対応する更新通知をＮＲＦ１０６から受信し、それに応じてＴＬＳ実装形態の自身のそれぞれのセキュアなレジストリを更新する。同一のシグナリング手順が、サービスコンシューマーＮＦ１０７ＤのＮＦプロファイルのｉｄｅｎｔｉｆｉｅｒ属性における変更に対して適用可能である。

図５Ａ～図５Ｄから明らかなように、ＮＦプロファイルをｃａＣｅｒｔｉｆｉｃａｔｅｓ属性およびｉｄｅｎｔｉｆｉｅｒ属性の一方または両方で拡張すると、レガシーなシグナリング手順の様々な修正形態となる。このような修正形態としては、ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性および／またはｉｄｅｎｔｉｆｉｅｒ属性を有するＮＦ１０７用のＮＦプロファイルの作成（図５Ａのステップ１１００、および図５Ｄのステップ１４００）、ｃａＣｅｒｔｉｆｉｃａｔｅｓ属性に含まれるＣＡ証明書のＴＬＳ実装形態のセキュアなレジストリへの記憶、およびｉｄｅｎｔｉｆｉｅｒ属性の内部的な記憶（図５Ｂのステップ１２０３および図５Ｄのステップ１４０６）、ＮＦプロファイル中のｉｄｅｎｔｉｆｉｅｒ属性の、クライアント証明書のＳｕｂｊｅｃｔ Ｎａｍｅおよび／またはＳｕｂｊｅｃｔ Ａｌｔｅｒｎａｔｉｖｅ Ｎａｍｅフィールドに対するルックアップとマッチング（図５Ｃのステップ１３０８）、ならびにその他が挙げられる。

了解されるように、上記実施形態のコンテキストにおいて証明書およびＮＦ識別子を送信することは、注意深く行わなければセキュリティ上の問題を露呈させる可能性がある。しかしながら、ＮＦ１０７とＮＲＦ１０６との間の接続は、ｍＴＬＳを使用して保護されているため、登録、ディスカバリ、および通知シグナリングの間に交換されるＣＡ証明書およびＮＦ識別子は、潜在的な攻撃者による盗聴または改竄から保護される。その上、ＮＲＦ１０６は、信頼できると考えられるため、中に含まれるＮＦプロファイルが潜在的な攻撃者によって公開、または改竄することができない方法で実装される。

本明細書で提示される技法は、例えばｍＴＬＳを用いてセキュアにされる接続で使用される証明書を有効性確認するために必要な、暗号法的な文書（ＣＡ証明書）の配布を容易にする。本明細書で提示される技法はまた、（トークンベースの認可を使用していない場合）ローカルポリシに基づく単純な認可方法を提供し、異なるＮＦでの設定を通常は必要としない。結果として、５Ｇまたは類似のシステムの運用が容易になり、簡単なスケーリングを可能とし、手作業による介入および設定エラーに起因するエラーの確率を低減させる。

本開示は、多くの態様で変わる可能性がある例示の実施形態を参照して説明されたことを了解されたい。そのため、本発明は、以降の特許請求項によってのみ限定される。

Claims (27)

1. 移動体通信ネットワークのコアネットワークドメイン（１０２）において、ネットワークリポジトリ機能（ＮＲＦ）を提供するように設定される装置（１０６）であって、前記ＮＲＦは、ネットワーク機能（ＮＦ）ディスカバリのためにＮＦプロファイルを登録するように設定され、ＮＦ証明書はＮＦ（１０７）に向けて発行されており、各ＮＦ証明書はそれぞれの前記ＮＦの公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含み、前記装置（１０６）は、
   ＮＦ証明書を有する登録ＮＦ（１０７）から、
   前記登録ＮＦ（１０７）のＮＦ識別情報、
   前記登録ＮＦ（１０７）のＮＦタイプ、および
   前記登録ＮＦ（１０７）に向けて発行された前記ＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書
   を含むプロファイル情報を受信することと（２１０）、
   受信した前記プロファイル情報をリポジトリ（１０６Ａ）に記憶することと（２１２）
   を行うように設定される、装置（１０６）。
2. 前記登録ＮＦ（１０７）に向けて発行された前記ＮＦ証明書が、前記登録ＮＦ（１０７）の前記ＮＦ識別情報とは異なるＮＦ識別子をさらに含み、受信した前記プロファイル情報が前記ＮＦ識別子をさらに含む、請求項１に記載の装置。
3. 前記ＮＦ識別子が、前記ＮＦ証明書のサブジェクトフィールドに含まれる、請求項２に記載の装置。
4. 前記ＮＦ識別子が、完全修飾ドメイン名（ＦＱＤＮ）、およびｓｅｃｕｒｅ ｐｒｏｄｕｃｔｉｏｎ ｉｄｅｎｔｉｔｙ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｅｖｅｒｙｏｎｅ（ＳＰＩＦＦＥ）識別子のうちの１つの形態を取る、請求項２または３に記載の装置。
5. 前記ＮＦ識別情報が、前記コアネットワークドメイン（１０２）において、前記登録ＮＦ（１０７）を発見可能または区別可能にする、請求項１から４のいずれか一項に記載の装置。
6. 少なくとも１つのＮＦタイプを示すディスカバリ要求を受信することと、
   前記リポジトリ（１０６Ａ）にアクセスして、少なくとも示された前記ＮＦタイプに一致する１つまたは複数のＮＦプロファイルを識別することと、
   前記１つまたは複数の一致するＮＦプロファイルからのディスカバリ情報を含むディスカバリ応答を送信することであって、前記ディスカバリ情報がそれぞれの前記ＮＦプロファイルごとに記憶された少なくとも前記１つまたは複数のＣＡ証明書を含む、ディスカバリ応答を送信することと
   を行うように設定される、請求項１から５のいずれか一項に記載の装置。
7. 第１のＮＦ（１０７Ｅ）から、更新されたＣＡ証明書情報を含む更新要求を受信することと、
   前記第１のＮＦ（１０７Ｅ）の前記プロファイル情報を、前記更新されたＣＡ証明書情報に基づいて更新することと
   を行うように設定される、請求項１から６のいずれか一項に記載の装置。
8. 前記第１のＮＦ（１０７Ｅ）に関連付けられる１つまたは複数の第２のＮＦ（１０７Ｄ）を、通知のサブスクリプションを通じて、識別することと、
   前記更新されたＣＡ証明書情報の少なくとも一部を、前記１つまたは複数の識別された第２のＮＦ（１０７Ｄ）に送信することと
   を行うように設定される、請求項７に記載の装置。
9. 移動体通信ネットワークのコアネットワークドメイン（１０２）において、ネットワーク機能（ＮＦ）を提供するように設定される装置（１０７）であって、ＮＦ証明書は前記ＮＦ（１０７）に向けて発行されており、前記ＮＦ証明書は、前記ＮＦ（１０７）の公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含み、前記装置は、
   前記ＮＦ（１０７）に向けて発行された前記ＮＦ証明書に署名した前記少なくとも１つのＣＡの前記少なくとも１つのＣＡ証明書を取得することと（３１０）、
   前記コアネットワークドメインにおいて、ＮＦディスカバリのためにＮＦプロファイルを登録するように設定される、ネットワークリポジトリ機能（ＮＲＦ）（１０６）にプロファイル情報を送信すること（３１２）であって、前記プロファイル情報が
   登録ＮＦ（１０７）のＮＦ識別情報、
   前記登録ＮＦ（１０７）のＮＦタイプ、および
   前記少なくとも１つのＣＡ証明書
   を含む、プロファイル情報を送信することと（３１２）
   を行うように設定される、装置（１０７）。
10. 前記登録ＮＦ（１０７）に向けて発行された前記ＮＦ証明書が、前記登録ＮＦ（１０７）の前記ＮＦ識別情報とは異なるＮＦ識別子をさらに含み、受信した前記プロファイル情報が前記ＮＦ識別子をさらに含む、請求項９に記載の装置。
11. 他のＮＦ（１０７Ｄ／Ｅ）とのハンドシェイク手順において、前記他のＮＦ（１０７Ｄ／Ｅ）に、前記ＮＦ証明書を送信するように設定される、請求項９または１０に記載の装置。
12. 少なくとも１つのＮＦタイプを示すディスカバリ要求を、前記ＮＲＦ（１０６）に送信することと、
    前記ＮＲＦ（１０６）から、少なくとも前記ＮＦタイプに一致する１つまたは複数のＮＦプロファイルからのディスカバリ情報を含むディスカバリ応答を受信することであって、前記ディスカバリ情報が、それぞれの前記ＮＦプロファイルごと記憶された前記少なくとも１つのＣＡ証明書を含む、ディスカバリ応答を受信することと、
    前記ディスカバリ情報を記憶装置に記憶することと
    を行うように設定される、請求項９から１１のいずれか一項に記載の装置。
13. ディスカバリ情報が以前に前記ＮＲＦ（１０６）から受信されている、他のＮＦ（１０７Ｄ／Ｅ）から、前記他のＮＦ（１０７Ｄ／Ｅ）に対して発行された前記ＮＦ証明書を受信することと、
    前記記憶装置から前記ディスカバリ情報に含まれる前記少なくとも１つのＣＡ証明書を読み取ることと、
    前記ＮＦ証明書を前記記憶装置から読み取った前記ＣＡ証明書を使用して有効性確認することと
    を行うように設定される、請求項１２に記載の装置。
14. 受信した前記ＮＦ証明書から第１のＮＦ識別子を抽出することと、
    前記プロファイル情報から第２のＮＦ識別子を抽出することと、
    前記第２のＮＦ識別子に基づいて前記第１のＮＦ識別子を有効性確認することと
    を行うように設定される、請求項１３に記載の装置。
15. 前記ＮＦ証明書が、他のＮＦ（１０７Ｄ／Ｅ）とのハンドシェイク手順のコンテキストにおいて受信される、請求項１３または１４に記載の装置。
16. 前記ハンドシェイク手順がトランスポートレイヤセキュリティ（ＴＬＳ）プロトコルに基づくものである、請求項１１または１５に記載の装置。
17. 前記ＮＲＦ（１０６）から、通知のサブスクリプションを通じて受信側の前記ＮＦに関連付けられ、ディスカバリ情報が以前に受信されて記憶されているＮＦ（１０７）についての更新されたＣＡ証明書情報の少なくとも一部を受信することと、
    記憶された前記ディスカバリ情報を、受信した前記更新されたＣＡ証明書情報に基づいて更新することと
    を行うように設定される、請求項１２から１６のいずれか一項に記載の装置。
18. 前記ＮＦ（１０７）についての更新されたＣＡ証明書情報を決定することと、
    前記ＮＲＦ（１０６）に、前記ＮＦ（１０７）についての前記更新されたＣＡ証明書情報を含む更新メッセージを送信することと
    を行うように設定される、請求項１０から１７のいずれか一項に記載の装置。
19. サービスを消費するＮＦ（１０７Ｄ）として設定される、請求項１０から１８のいずれか一項に記載の装置。
20. サービスをプロデュースするＮＦ（１０７Ｅ）として設定される、請求項１０から１８のいずれか一項に記載の装置。
21. 請求項１から８のいずれか一項に記載の前記装置（１０６）、および請求項９から２０のいずれか一項に記載の前記装置（１０７）を備える、コアネットワークシステム。
22. 移動体通信ネットワークのコアネットワークドメイン（１０６）において、ネットワークリポジトリ機能（ＮＲＦ）（１０６）を提供する方法であって、前記ＮＲＦは、ネットワーク機能（ＮＦ）ディスカバリのためにＮＦプロファイルを登録するように設定され、ＮＦ証明書はＮＦ（１０７）に向けて発行されており、各ＮＦ証明書はそれぞれの前記ＮＦ（１０７）の公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含み、前記方法は、
    ＮＦ証明書を有する登録ＮＦ（１０７）から、
    前記登録ＮＦ（１０７）のＮＦ識別情報、
    前記登録ＮＦ（１０７）のＮＦタイプ、および
    前記登録ＮＦ（１０７）に向けて発行された前記ＮＦ証明書に署名した少なくとも１つのＣＡの少なくとも１つのＣＡ証明書
    を含むプロファイル情報を受信することと（４０６）、
    受信した前記プロファイル情報をリポジトリ（１０６Ａ）に記憶することと（４０８）
    を含む、方法。
23. 請求項１から８のいずれか一項に記載の前記装置によって実施される、請求項２２に記載の方法。
24. 移動体通信ネットワークのコアネットワークドメイン（１０２）において、ネットワーク機能（ＮＦ）（１０７）を提供する方法であって、ＮＦ証明書は前記ＮＦ（１０７）に向けて発行されており、前記ＮＦ証明書は、前記ＮＦ（１０７）の公開鍵および少なくとも１つの認証局（ＣＡ）の少なくとも１つの署名を含み、前記方法は、
    前記ＮＦ（１０７）に向けて発行された前記ＮＦ証明書に署名した前記少なくとも１つのＣＡの前記少なくとも１つのＣＡ証明書を取得することと（４０２）、
    前記コアネットワークドメイン（１０２）においてＮＦディスカバリのためにＮＦプロファイルを登録するように設定される、ネットワークリポジトリ機能（ＮＲＦ）（１０６）にプロファイル情報を送信すること（４０４）であって、前記プロファイル情報が
    登録ＮＦ（１０７）のＮＦ識別情報、
    前記登録ＮＦ（１０７）のＮＦタイプ、および
    前記少なくとも１つのＣＡ証明書
    を含む、プロファイル情報を送信することと（４０４）
    を含む、方法。
25. 請求項９から２０のいずれか一項に記載の前記装置によって実施される、請求項２４に記載の方法。
26. プログラムコード部分が１つまたは複数のプロセッサ（２０２、３０２）によって実施されると、請求項２２から２５のいずれか一項に記載の前記方法を実施するための前記プログラムコード部分を含む、コンピュータプログラム製品。
27. コンピュータ可読媒体に記憶される、請求項２６に記載のコンピュータプログラム製品。
    

Images