RFC 7255 - Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7255
タイトル : RFC 7255 - International Mobile Station Equipment Identity（IMEI）Uniform Resource Name（URN）をインスタンスIDとして使用する
翻訳編集 : 自動生成

[要約] RFC 7255は、IMEIを使用したURNをインスタンスIDとして使用する方法についての標準化ドキュメントです。目的は、IMEIを一意の識別子として使用することで、モバイルデバイスの管理や追跡を容易にすることです。

Internet Engineering Task Force (IETF)                     A. Allen, Ed.
Request for Comments: 7255                                    Blackberry
Category: Informational                                         May 2014
ISSN: 2070-1721

Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID

International Mobile Station Equipment Identity（IMEI）Uniform Resource Name（URN）をインスタンスIDとして使用する

Abstract

概要

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.

この仕様は、グローバルシステムフォーモバイルコミュニケーションアソシエーション（GSMA）のID用に予約されたUniform Resource Name（URN）と、国際移動局機器ID（IMEI）のサブネームスペースをインスタンスIDとして使用する方法を定義します。その目的は、特定のURNを作成して、アウトバウンド動作の「+ sip.instance」Contactヘッダーフィールドパラメータで使用する方法を定義するための要件を満たすことです。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7255.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7255で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Background ......................................................3
   4. 3GPP Use Cases ..................................................5
   5. User Agent Client Procedures ....................................5
   6. User Agent Server Procedures ....................................6
   7. 3GPP SIP Registrar Procedures ...................................6
   8. Security Considerations .........................................7
   9. Acknowledgements ................................................7
   10. References .....................................................8
      10.1. Normative References ......................................8
      10.2. Informative References ....................................8

1. Introduction

1. はじめに

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) as specified in RFC 7254 [1] can be used as an instance-id as specified in RFC 5626 [2] and also as used by RFC 5627 [3].

この仕様は、RFC 7254 [1]で指定されている、グローバルシステムフォーモバイルコミュニケーションアソシエーション（GSMA）のID用に予約されたUniform Resource Name（URN）と、国際移動局機器ID（IMEI）のサブネームスペースをどのように使用できるかを定義RFC 5626 [2]で指定され、RFC 5627 [3]でも使用されるインスタンスIDとして。

RFC 5626 [2] specifies the '+sip.instance' Contact header field parameter that contains a URN as specified in RFC 2141 [4]. The instance-id uniquely identifies a specific User Agent (UA) instance. This instance-id is used as specified in RFC 5626 [2] so that the Session Initiation Protocol (SIP) registrar (as specified in RFC 3261 [9]) can recognize that the contacts from multiple registrations correspond to the same UA. The instance-id is also used as specified by RFC 5627 [3] to create Globally Routable User Agent URIs (GRUUs) that can be used to uniquely address a UA when multiple UAs are registered with the same Address of Record (AoR).

RFC 5626 [2]は、RFC 2141 [4]で指定されているURNを含む '+ sip.instance' Contactヘッダーフィールドパラメータを指定しています。 instance-idは、特定のユーザーエージェント（UA）インスタンスを一意に識別します。このインスタンスIDは、RFC 5626 [2]で指定されているように使用されるため、セッション開始プロトコル（SIP）レジストラー（RFC 3261 [9]で指定）は、複数の登録からの連絡先が同じUAに対応していることを認識できます。 instance-idは、RFC 5627 [3]で指定されているように使用され、同じレコードアドレス（AoR）で複数のUAが登録されている場合に、UAを一意にアドレス指定するために使用できるグローバルにルーティング可能なユーザーエージェントURI（GRUU）を作成します。

RFC 5626 [2] requires that a UA SHOULD create a Universally Unique Identifier (UUID) URN as specified in RFC 4122 [6] as its instance-id but allows for the possibility to use other URN schemes. Per RFC 5626, "If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior". This specification meets this requirement by specifying how the GSMA IMEI URN is used in the '+sip.instance' Contact header field parameter for outbound behavior, and RFC 7254 [1] specifies how the GSMA IMEI URN is constructed.

RFC 5626 [2]は、UAがそのインスタンスIDとしてRFC 4122 [6]で指定されているユニバーサルユニークID（UUID）URNを作成する必要があるが、他のURNスキームを使用できるようにする必要があります。 RFC 5626に従って、「UUID以外のURNスキームが使用されている場合、UAは、RFC（IETFストリームから）が特定のURNを構築して "+ sip.instance"で使用する方法を定義するURNのみを使用する必要があります（MUST）。アウトバウンド動作の連絡先ヘッダーフィールドパラメータ」。この仕様は、アウトバウンド動作の「+ sip.instance」コンタクトヘッダーフィールドパラメータでGSMA IMEI URNを使用する方法を指定することでこの要件を満たし、RFC 7254 [1]はGSMA IMEI URNの構築方法を指定します。

The GSMA IMEI is a URN for the IMEI -- a globally unique identifier that identifies mobile devices used in the GSM, Universal Mobile Telecommunications System (UMTS), and 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) networks. The IMEI allocation is managed by the GSMA to ensure that the IMEI values are globally unique. Details of the formatting of the IMEI as a URN are specified in RFC 7254 [1], and the definition of the IMEI is contained in 3GPP TS 23.003 [10]. Further details about the GSMA's role in allocating the IMEI, and the IMEI allocation guidelines, can be found in GSMA PRD TS.06 [11].

GSMA IMEIは、IMEIのURNです。これは、GSM、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）、および第3世代パートナーシッププロジェクト（3GPP）ロングタームエボリューション（LTE）ネットワークで使用されるモバイルデバイスを識別するグローバルに一意の識別子です。 IMEIの割り当てはGSMAによって管理され、IMEI値がグローバルに一意になるようにします。 URNとしてのIMEIのフォーマットの詳細はRFC 7254 [1]で指定されており、IMEIの定義は3GPP TS 23.003 [10]に含まれています。 IMEIの割り当てにおけるGSMAの役割とIMEI割り当てガイドラインの詳細については、GSMA PRD TS.06 [11]を参照してください。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [7]で説明されているように解釈されます。

3. Background

3. バックグラウンド

GSM, UMTS, and LTE capable mobile devices represent 90% of the mobile devices in use worldwide. Every manufactured GSM, UMTS, or LTE mobile device has an allocated IMEI that uniquely identifies this specific mobile device. Among other things, in some regulatory jurisdictions the IMEI is used to identify that a stolen mobile device is being used, to help to identify the subscription that is using it, and to prevent use of the mobile device. While GSM was originally a circuit switched system, enhancements such as the General Packet Radio Service (GPRS) and UMTS have added IP data capabilities that, along with the definition of the IP Multimedia Subsystem (IMS), have made SIP-based calls and IP multimedia sessions from mobile devices possible.

GSM、UMTS、およびLTE対応のモバイルデバイスは、世界中で使用されているモバイルデバイスの90％を占めています。製造されたすべてのGSM、UMTS、またはLTEモバイルデバイスには、この特定のモバイルデバイスを一意に識別する割り当てられたIMEIがあります。特に、一部の規制管轄では、IMEIは、盗まれたモバイルデバイスが使用されていることを識別し、それを使用しているサブスクリプションを識別し、モバイルデバイスの使用を防止するために使用されます。 GSMはもともと回線交換システムでしたが、General Packet Radio Service（GPRS）やUMTSなどの拡張機能によりIPデータ機能が追加され、IPマルチメディアサブシステム（IMS）の定義とともに、SIPベースのコールとIP可能なモバイルデバイスからのマルチメディアセッション。

The latest enhancement, known as LTE, introduces even higher data rates and dispenses with the circuit switched infrastructure completely. This means that with LTE networks, voice calls will need to be conducted using IP and IMS. However, the transition to all IP SIP-based IMS networks worldwide will take a great many years, and mobile devices, being mobile, will need to operate in both IP/SIP/IMS mode and circuit switched mode. This means that calls and sessions will need to be handed over between IP/SIP/IMS mode and circuit switched mode mid-call or mid-session. Also, since many existing GSM and UMTS radio access networks are unable to support IP/SIP/IMS-based voice services in a commercially acceptable manner, some sessions could have some media types delivered via IP/IMS simultaneously with voice media delivered via the circuit switched domain to the same mobile device. To achieve this, the mobile device needs to be simultaneously attached via both the IP/SIP/IMS domain and the circuit switched domain.

LTEとして知られる最新の拡張機能により、さらに高いデータレートが導入され、回線交換インフラストラクチャが完全に不要になります。つまり、LTEネットワークでは、IPとIMSを使用して音声通話を行う必要があります。ただし、世界中のすべてのIP SIPベースのIMSネットワークへの移行には非常に長い年月がかかり、モバイルデバイスはモバイルであるため、IP / SIP / IMSモードと回線交換モードの両方で動作する必要があります。これは、通話とセッションがIP / SIP / IMSモードと回線交換モードの通話中またはセッション間でハンドオーバーされる必要があることを意味します。また、多くの既存のGSMおよびUMTS無線アクセスネットワークはIP / SIP / IMSベースの音声サービスを商業的に受け入れられる方法でサポートできないため、一部のセッションでは、IP / IMSを介して配信されるメディアタイプと同時に、回路を介して配信される音声メディアを使用できますドメインを同じモバイルデバイスに切り替えました。これを実現するには、モバイルデバイスをIP / SIP / IMSドメインと回線交換ドメインの両方を介して同時に接続する必要があります。

To meet this need, the 3GPP has specified how to maintain session continuity between the IP/SIP/IMS domain and the circuit switched domain in 3GPP TS 24.237 [12], and in 3GPP TS 24.292 [13] has specified how to access IMS hosted services via both the IP/SIP/IMS domain and the circuit switched domain.

このニーズを満たすために、3GPPは3GPP TS 24.237 [12]でIP / SIP / IMSドメインと回線交換ドメイン間のセッション継続性を維持する方法を指定し、3GPP TS 24.292 [13]ではホストされたIMSにアクセスする方法を指定していますIP / SIP / IMSドメインと回線交換ドメインの両方を介したサービス。

In order for the mobile device to access SIP/IMS services via the circuit switched domain, the 3GPP has specified a Mobile Switching Center (MSC) server enhanced for IMS Centralized Services (ICS) and a MSC server enhanced for Single Radio Voice Call Continuity (SR-VCC) that control mobile voice call setup over the circuit switched radio access while establishing the corresponding voice session in the core network using SIP/IMS. To enable this, the MSC server enhanced for ICS or the MSC server enhanced for SR-VCC performs SIP registration on behalf of the mobile device, which is also simultaneously directly registered with the IP/SIP/IMS domain. The only mobile device identifier that is transportable using GSM/UMTS/LTE signaling is the IMEI; therefore, the instance-id included by the MSC server enhanced for ICS or the MSC server enhanced for SR-VCC when acting on behalf of the mobile device, and the instance-id directly included by the mobile device, both need to be based on the IMEI.

モバイルデバイスが回線交換ドメインを介してSIP / IMSサービスにアクセスするために、3GPPは、IMS Centralized Services（ICS）用に拡張されたMobile Switching Center（MSC）サーバーと、単一の無線音声通話継続用に拡張されたMSCサーバーを指定しています（ SR-VCC）は、SIP / IMSを使用してコアネットワークで対応する音声セッションを確立しながら、回線交換無線アクセスを介してモバイル音声コールのセットアップを制御します。これを可能にするために、ICS用に拡張されたMSCサーバーまたはSR-VCC用に拡張されたMSCサーバーは、モバイルデバイスに代わってSIP登録を実行します。これも同時にIP / SIP / IMSドメインに直接登録されます。 GSM / UMTS / LTEシグナリングを使用して転送可能な唯一のモバイルデバイス識別子は、IMEIです。したがって、モバイルデバイスに代わって動作する場合に、ICS用に拡張されたMSCサーバーまたはSR-VCC用に拡張されたMSCサーバーによって含まれるインスタンスID、およびモバイルデバイスによって直接含まれるインスタンスIDは、どちらにも基づく必要があります。 IMEI。

Additionally, in order to meet the above requirements, the same IMEI that is obtained from the circuit switched signaling by the MSC server needs to be obtainable from SIP signaling so that it can be determined that both the SIP signaling and circuit switched signaling originate from the same mobile device.

さらに、上記の要件を満たすために、MSCサーバーによって回線交換シグナリングから取得される同じIMEIがSIPシグナリングから取得可能である必要があります。これにより、SIPシグナリングと回線交換シグナリングの両方が同じモバイルデバイス。

For these reasons, 3GPP TS 24.237 [12] and 3GPP TS 24.292 [13] already specify the use of the URN namespace for the GSMA IMEI URN as specified in RFC 7254 [1] as the instance-id used by GSM/UMTS/LTE

これらの理由により、3GPP TS 24.237 [12]および3GPP TS 24.292 [13]は、GSM / UMTS / LTEで使用されるインスタンスIDとして、RFC 7254 [1]で指定されているGSMA IMEI URNのURN名前空間の使用をすでに指定しています。

mobile devices, the MSC server enhanced for SR-VCC, and the MSC server enhanced for ICS, for SIP/IMS registrations and emergency-related SIP requests.

SIP / IMS登録および緊急関連のSIPリクエストのために、モバイルデバイス、SR-VCC用に拡張されたMSCサーバー、およびICS用に拡張されたMSCサーバー。

4. 3GPP Use Cases

4. 3GPPの使用例

1. The mobile device includes its IMEI in the SIP REGISTER request so that the SIP registrar can perform a check of the Equipment Identity Register (EIR) to verify whether this mobile device is allowed to access the network for non-emergency services or is barred from doing so (e.g., because the device has been stolen). If the mobile device is not allowed to access the network for non-emergency services, the SIP registrar can reject the registration and thus prevent a barred mobile device from accessing the network for non-emergency services.

1. モバイルデバイスは、IMEIをSIP REGISTER要求に含めます。これにより、SIPレジストラーは、Equipment Identity Register（EIR）のチェックを実行して、このモバイルデバイスが非緊急サービスのためにネットワークへのアクセスを許可されているか、または禁止されているかを確認できますそうです（たとえば、デバイスが盗まれたため）。モバイルデバイスが非緊急サービスのためにネットワークにアクセスすることを許可されていない場合、SIPレジストラは登録を拒否し、それにより禁止されたモバイルデバイスが非緊急サービスのためにネットワークにアクセスするのを防ぐことができます。

2. The mobile device includes its IMEI in SIP INVITE requests used to establish emergency sessions. This is so that the Public Safety Answering Point (PSAP) can obtain the IMEI of the mobile device for identification purposes if required by regulations.

2. モバイルデバイスには、緊急セッションの確立に使用されるSIP INVITE要求にIMEIが含まれています。これは、Public Safety Answering Point（PSAP）が規制によって要求された場合に識別目的でモバイルデバイスのIMEIを取得できるようにするためです。

3. The IMEI that is included in SIP INVITE requests by the mobile device and used to establish emergency sessions is also used in cases of unauthenticated emergency sessions to enable the network to identify the mobile device. This is especially important if the unauthenticated emergency session is handed over from the packet switched domain to the circuit switched domain. In this scenario, the IMEI is the only identifier that is common to both domains, so the Emergency Access Transfer Function (EATF) in the network, which in such cases coordinates the transfer between domains, can use the IMEI to determine that the circuit switched call is from the same mobile device that was in the emergency session in the packet switched domain.

3. モバイルデバイスによるSIP INVITE要求に含まれ、緊急セッションの確立に使用されるIMEIは、認証されていない緊急セッションの場合にも使用され、ネットワークがモバイルデバイスを識別できるようにします。これは、認証されていない緊急セッションがパケット交換ドメインから回線交換ドメインにハンドオーバーされる場合に特に重要です。このシナリオでは、IMEIが両方のドメインに共通の唯一の識別子であるため、そのような場合にドメイン間の転送を調整するネットワークの緊急アクセス転送機能（EATF）は、IMEIを使用して回線が切り替えられたことを判断できます。コールは、パケット交換ドメインで緊急セッションにあった同じモバイルデバイスからのものです。

5. User Agent Client Procedures

5. ユーザーエージェントクライアントの手順

A User Agent Client (UAC) that has an IMEI as specified in 3GPP TS 23.003 [10] and that is registering with a 3GPP IMS network MUST include in the "sip.instance" media feature tag the GSMA IMEI URN according to the syntax specified in RFC 7254 [1] when performing the registration procedures specified in RFC 5626 [2] or RFC 5627 [3], or any other procedure requiring the inclusion of the "sip.instance" media feature tag. The UAC SHOULD NOT include the optional 'svn' parameter in the GSMA IMEI URN in the "sip.instance" media feature tag, since the software version can change as a result of upgrades to the device firmware that would create a new instance-id. Any future non-zero values of the 'vers' parameter, or the future definition of additional parameters for the GSMA IMEI URN that are intended to be used as part of an instance-id, will require that an update be made to this RFC. The UAC MUST provide character-by-character identical URNs in each registration according to RFC 5626 [2]. Hence, any optional or variable components of the URN (e.g., the 'vers' parameter) MUST be presented with the same values and in the same order in every registration as in the first registration.

3GPP TS 23.003 [10]で指定されているIMEIを持ち、3GPP IMSネットワークに登録しているユーザーエージェントクライアント（UAC）は、指定された構文に従って「sip.instance」メディア機能タグにGSMA IMEI URNを含める必要がありますRFC 5254 [1]またはRFC 5626 [2]またはRFC 5627 [3]で指定された登録手順、または「sip.instance」メディア機能タグを含める必要があるその他の手順を実行する場合。 UACは、「sip.instance」メディア機能タグのGSMA IMEI URNにオプションの「svn」パラメータを含めないでください。新しいインスタンスIDを作成するデバイスファームウェアへのアップグレードの結果、ソフトウェアバージョンが変更される可能性があるためです。「vers」パラメーターの将来のゼロ以外の値、またはインスタンスIDの一部として使用することを目的としたGSMA IMEI URNの追加パラメーターの将来の定義では、このRFCを更新する必要があります。 UACは、RFC 5626 [2]に従って、各登録で文字ごとに同一のURNを提供する必要があります。したがって、URNのオプションコンポーネントまたは可変コンポーネント（「vers」パラメーターなど）は、最初の登録と同じ値で、すべての登録で同じ順序で提示する必要があります。

A UAC MUST NOT use the GSMA IMEI URN as an instance-id, except when registering with a 3GPP IMS network. When a UAC is operating in IMS mode, it will obtain from the Universal Integrated Circuit Card (UICC) (commonly known as the SIM card) the domain of the network with which to register. This is a carrier's IMS network domain. The UAC will also obtain the address of the IMS edge proxy to send the REGISTER request containing the IMEI using information elements in the Attach response when it attempts to connect to the carrier's packet data network. When registering with a non-3GPP IMS network, a UAC SHOULD use a UUID as an instance-id as specified in RFC 5626 [2].

UACは、3GPP IMSネットワークに登録する場合を除き、インスタンスIDとしてGSMA IMEI URNを使用してはなりません（MUST NOT）。 UACは、IMSモードで動作している場合、登録するネットワークのドメインをUniversal Integrated Circuit Card（UICC）（通称SIMカード）から取得します。これは、キャリアのIMSネットワークドメインです。 UACはまた、IMSエッジプロキシのアドレスを取得して、キャリアのパケットデータネットワークに接続しようとしたときに、アタッチ応答の情報要素を使用して、IMEIを含むREGISTER要求を送信します。非3GPP IMSネットワークに登録する場合、UACはRFC 5626 [2]で指定されているように、インスタンスIDとしてUUIDを使用する必要があります（SHOULD）。

A UAC MUST NOT include the "sip.instance" media feature tag containing the GSMA IMEI URN in the Contact header field of non-REGISTER requests, except when the request is related to an emergency session. Regulatory requirements can require that the IMEI be provided to the PSAP. Any future exceptions to this prohibition will require the publication of an RFC that addresses how privacy is not violated by such usage.

UACは、リクエストが緊急セッションに関連している場合を除き、非REGISTERリクエストのContactヘッダーフィールドにGSMA IMEI URNを含む「sip.instance」メディア機能タグを含めてはなりません（MUST NOT）。規制要件により、IMEIをPSAPに提供することが要求される場合があります。この禁止に対する将来の例外は、プライバシーがそのような使用によってどのように違反されないかを扱うRFCの公開を必要とします。

6. User Agent Server Procedures

6. ユーザーエージェントサーバーの手順

A User Agent Server (UAS) MUST NOT include its "sip.instance" media feature tag containing the GSMA IMEI URN in the Contact header field of responses, except when the response is related to an emergency session. Regulatory requirements can require that the IMEI be provided to the PSAP. Any future exceptions to this prohibition will require the publication of an RFC that addresses how privacy is not violated by such usage.

ユーザーエージェントサーバー（UAS）は、応答が緊急セッションに関連している場合を除いて、GSMA IMEI URNを含む「sip.instance」メディア機能タグを応答のContactヘッダーフィールドに含めてはなりません（MUST NOT）。規制要件により、IMEIをPSAPに提供することが要求される場合があります。この禁止に対する将来の例外は、プライバシーがそのような使用によってどのように違反されないかを扱うRFCの公開を必要とします。

7. 3GPP SIP Registrar Procedures

7. 3GPP SIPレジストラの手順

In 3GPP IMS, when the SIP registrar receives in the Contact header field a "sip.instance" media feature tag containing the GSMA IMEI URN according to the syntax specified in RFC 7254 [1] the SIP registrar follows the procedures specified in RFC 5626 [2]. The IMEI URN MAY be validated as described in RFC 7254 [1]. If the UA indicates that it supports the extension in RFC 5627 [3] and the SIP registrar allocates a public GRUU according to the procedures specified in RFC 5627 [3], the instance-id MUST be obfuscated when creating the 'gr' parameter in order not to reveal the IMEI to other UAs when the public GRUU is included in non-REGISTER requests and responses. 3GPP TS 24.229 [8] subclause 5.4.7A.2 specifies the mechanism for obfuscating the IMEI when creating the 'gr' parameter.

3GPP IMSでは、SIPレジストラがRFC 7254 [1]で指定された構文に従ってGSMA IMEI URNを含む「sip.instance」メディア機能タグをContactヘッダーフィールドで受信すると、RFC 5626で指定された手順に従います[ 2]。 IMEI URNは、RFC 7254 [1]で説明されているように検証できます。 UAがRFC 5627 [3]の拡張をサポートしていることを示し、SIPレジストラがRFC 5627 [3]で指定された手順に従ってパブリックGRUUを割り当てる場合、instance-idは、 'gr'パラメータを作成するときに難読化する必要があります。パブリックGRUUが非REGISTERリクエストおよびレスポンスに含まれている場合、IMEIを他のUAに公開しないように指示します。 3GPP TS 24.229 [8] 5.4.7A.2節では、「gr」パラメーターの作成時にIMEIを難読化するメカニズムを指定しています。

8. Security Considerations

8. セキュリティに関する考慮事項

Because IMEIs, like other formats of instance-ids, can be correlated to a user, they are personally identifiable information and therefore MUST be treated in the same way as any other personally identifiable information. In particular, the "sip.instance" media feature tag containing the GSMA IMEI URN MUST NOT be included in requests or responses intended to convey any level of anonymity, as this could violate the user's privacy. RFC 5626 [2] states that "One case where a UA could prefer to omit the "sip.instance" media feature tag is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity". The same concerns apply when using the GSMA IMEI URN as an instance-id. Publication of the GSMA IMEI URN to networks to which the UA is not attached, or with which the UA does not have a service relationship, is a security breach, and the "sip.instance" media feature tag MUST NOT be forwarded by the service provider's network elements when forwarding requests or responses towards the destination UA. Additionally, an instance-id containing the GSMA IMEI URN identifies a mobile device and not a user. The instance-id containing the GSMA IMEI URN MUST NOT be used alone as an address for a user or as an identification credential for a user. The GRUU mechanism specified in RFC 5627 [3] provides a means to create URIs that address the user at a specific device or User Agent.

他のインスタンスIDの形式と同様に、IMEIはユーザーに関連付けることができるため、個人を特定できる情報であり、したがって、他の個人を特定できる情報と同じ方法で処理する必要があります。特に、GSMA IMEI URNを含む「sip.instance」メディア機能タグは、ユーザーのプライバシーを侵害する可能性があるため、あらゆるレベルの匿名性を伝えることを目的としたリクエストまたはレスポンスに含めることはできません。 RFC 5626 [2]は、「UAが "sip.instance"メディア機能タグを省略したほうがよいケースの1つは、匿名リクエストを行っているとき、または他のプライバシーの懸念から、UAがその身元を明かさないことを要求しているときです」と述べています。 GSMA IMEI URNをインスタンスIDとして使用する場合も同じ懸念が当てはまります。 UAが接続されていない、またはUAがサービス関係を持たないネットワークへのGSMA IMEI URNの公開はセキュリティ違反であり、「sip.instance」メディア機能タグはサービスによって転送されてはなりません宛先UAに向けて要求または応答を転送するときのプロバイダーのネットワーク要素。さらに、GSMA IMEI URNを含むインスタンスIDは、ユーザーではなくモバイルデバイスを識別します。 GSMA IMEI URNを含むインスタンスIDを、ユーザーのアドレスとして、またはユーザーの識別資格情報として単独で使用してはなりません。 RFC 5627 [3]で指定されているGRUUメカニズムは、特定のデバイスまたはユーザーエージェントでユーザーをアドレス指定するURIを作成する手段を提供します。

Entities that log the instance-id need to protect them as personally identifiable information. Regulatory requirements can require that carriers log SIP IMEIs.

instance-idをログに記録するエンティティは、それらを個人を特定できる情報として保護する必要があります。規制要件により、通信事業者はSIP IMEIを記録する必要があります。

In order to protect the "sip.instance" media feature tag containing the GSMA IMEI URN from being tampered with, those REGISTER requests containing the GSMA IMEI URN MUST be sent using a security mechanism such as Transport Layer Security (TLS) (RFC 5246 [5]) or another security mechanism that provides equivalent levels of protection such as hop-by-hop security based upon IPsec.

GSMA IMEI URNを含む「sip.instance」メディア機能タグが改ざんされないように保護するために、GSMA IMEI URNを含むREGISTERリクエストは、トランスポート層セキュリティ（TLS）（RFC 5246 [ 5]）または、IPsecに基づくホップバイホップのセキュリティなど、同等レベルの保護を提供する別のセキュリティメカニズム。

9. Acknowledgements

9. 謝辞

The author would like to thank Paul Kyzivat, Dale Worley, Cullen Jennings, Adam Roach, Keith Drage, Mary Barnes, Peter Leis, James Yu, S. Moonesamy, Roni Even, and Tim Bray for reviewing this document and providing their comments.

著者は、このドキュメントのレビューとコメントの提供に対して、Paul Kyzivat、Dale Worley、Cullen Jennings、Adam Roach、Keith Drage、Mary Barnes、Peter Leis、James Yu、S。Moonesamy、Roni Even、およびTim Brayに感謝します。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[1] Montemurro, M., Ed., Allen, A., McDonald, D., and P. Gosden, "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", RFC 7254, May 2014.

[1] Montemurro、M.、Ed。、Allen、A.、McDonald、D.、and P. Gosden、 "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association（GSMA）and the International Mobile Station Equipment Identity（IMEI） "、RFC 7254、2014年5月。

[2] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.

[2] Jennings、C.、Mahy、R。、およびF. Audet、「Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）」、RFC 5626、2009年10月。

[3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.

[3] Rosenberg、J。、「セッション開始プロトコル（SIP）でのグローバルにルーティング可能なユーザーエージェントURI（GRUU）の取得と使用」、RFC 5627、2009年10月。

[4] Moats, R., "URN Syntax", RFC 2141, May 1997.

[4] Moats、R。、「URN構文」、RFC 2141、1997年5月。

[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[5] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。

[6] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

[6] Leach、P.、Mealling、M。、およびR. Salz、「A Universally Unique Identifier（UUID）URN Namespace」、RFC 4122、2005年7月。

[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[7] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。

[8] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 (Release 8), March 2014, <ftp://ftp.3gpp.org/Specs/archive/24_series/ 24.229/>.

[8] 3GPP、「セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）に基づくIPマルチメディアコール制御プロトコル、ステージ3」、3GPP TS 24.229（リリース8）、2014年3月、<ftp://ftp.3gpp.org/ Specs / archive / 24_series / 24.229 />。

[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[9] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261 、2002年6月。

10.2. Informative References

10.2. 参考引用

[10] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 (Release 8), March 2014, <ftp://ftp.3gpp.org/Specs/ archive/23_series/23.003/>.

[10] 3GPP、「番号付け、アドレス指定、および識別」、3GPP TS 23.003（リリース8）、2014年3月、<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>。

[11] GSM Association, "IMEI Allocation and Approval Guidelines", PRD TS.06 (DG06) Version 6.0, July 2011, <http://www.gsma.com/newsroom/wp-content/uploads/2012/06/ ts0660tacallocationprocessapproved.pdf>.

[11] GSM Association、「IMEI Allocation and Approval Guidelines」、PRD TS.06（DG06）Version 6.0、2011年7月、<http://www.gsma.com/newsroom/wp-content/uploads/2012/06/ts0660tacallocationprocessapproved.pdf >。

[12] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.237 (Release 8), September 2013, <ftp://ftp.3gpp.org/Specs/archive/ 24_series/24.237/>.

[12] 3GPP、「モバイルラジオインターフェースレイヤー3仕様、コアネットワークプロトコル、ステージ3」、3GPP TS 24.237（リリース8）、2013年9月、<ftp://ftp.3gpp.org/Specs/archive/ 24_series / 24.237 />。

[13] 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS); Stage 3", 3GPP TS 24.292 (Release 8), December 2013, <ftp://ftp.3gpp.org/Specs/ archive/24_series/24.292/>.

[13] 3GPP、「IPマルチメディア（IM）コアネットワーク（CN）サブシステム集中サービス（ICS）;ステージ3」、3GPP TS 24.292（リリース8）、2013年12月、<ftp://ftp.3gpp.org/Specs/ archive / 24_series / 24.292 />。

Author's Address

著者のアドレス

Andrew Allen (editor) Blackberry 1200 Sawgrass Corporate Parkway Sunrise, Florida 33323 USA

アンドリューアレン（編集者）Blackberry 1200 Sawgrass Corporate Parkway Sunrise、Florida 33323 USA

   EMail: aallen@blackberry.com