RFC 3779: IPアドレスとAS識別子のためのX.509拡張
本文書の位置付け
本文書は、インターネット・コミュニティのためのインターネット標準トラック・プロトコルを規定し、改善のための議論と提案を求める。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1)を参照のこと。このメモの配布は無制限である。
著作権表示
著作権 (C) The Internet Society (2004)。
要旨
本文書は、2つのX.509 v3証明書拡張を定義する。1つ目は、IPアドレス・ブロックまたはプレフィックスのリストを証明書のサブジェクトに結び付ける(bind)もの。2つ目は、自律システム識別子のリストを証明書のサブジェクトにバインドするものである。これらの拡張は、拡張に含まれるIPアドレスおよび自律システム識別子を使用するサブジェクトの認可を伝達するために使用される。
1. はじめに
本文書は、IANAから地域インターネット・レジストリ(RIR)を通じて、インターネット・サービス・プロバイダ(ISP)およびユーザ組織に、IPアドレスと自律システム識別子の使用権を譲渡する(transfer)ことを認可する2つのX.509 v3証明書拡張を定義する。1つ目は、IPアドレス・ブロックのリスト(多くの場合、IPアドレス・プレフィックスとして表される)を証明書のサブジェクト(秘密鍵の保有者)に結び付ける。2つ目は、自律システム (AS)識別子のリストを証明書のサブジェクト(秘密鍵の保有者)に結び付ける。証明書の発行者は、IPアドレス・ブロックとAS識別子のセットの管理権(custodianship)を証明書のサブジェクトに譲渡する(「割り当てる」)権限を持つエンティティ(IANA、地域インターネット・レジストリ、ISPなど)である。これらの証明書は、IPアドレス・プレフィックスとAS識別子のセットの使用権を検証するスケーラブルな手段を提供する。これらは、セキュアBGP[S-BGP]のようなルーティング・プロトコルがルーティング情報の正統性(legitimacy)と正当性(correctness)を検証するために、あるいはインターネット・ルーティング・レジストリが受信したデータを検証するために使用される。
セクション2と3では、この仕様で定義されている拡張の符号化について、従わなければならない(MUST)いくつかの規則を規定している。これらの符号化規則は以下の目的を果たす。まず、拡張の値が一意に符号化され、2つの拡張のインスタンスは、オクテットごとに等しいかどうか比較できる。第2に、最小サイズの符号化を実現する。第3に、証明書パスの検証を行う際に、リライング・パーティーがワンパス・アルゴリズムを使用できるようにする。特に、リライング・パーティーは、情報を並べ替えたり、いくつかの境界値(隣接、重複、または包含される範囲)を処理するために、部分チェック・アルゴリズムに追加のコードを実装する必要がない。
1.1. 用語
読者は、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile」[RFC3280]、「INTERNET PROTOCOL」[RFC791]、「Internet Protocol Version 6 (IPv6) Addressing Architecture」、「"INTERNET REGISTRY IP ALLOCATION GUIDELINES」[RFC2050]に記載されている用語と概念に精通していることを前提とする。関連する用語には以下のようなものがある。
割り振り(allocate) - リソースの管理権を中間組織に譲渡すること([RFC2050]を参照)。
割り当て(assign) - リソースの管理権を最終組織に譲渡すること ([RFC2050]を参照)。
自律システム(AS) - 統一されたポリシーを持つ単一の技術管理下にあるルータの集合で、1つ以上の内部ゲートウェイ・プロトコルとメトリックを使用して自律システム内のパケットをルーティングする方法を決定し、外部ゲートウェイ・プロトコルを使用して他の自律システムへのパケットをどのようにルーティングするかを決定する。
自律システム番号 - 自律システムを識別する32ビットの番号。
委任(delegate) - エンティティへの証明書の発行を通じて、IPアドレス・ブロックまたはAS識別子の管理権(つまり、使用権)を移転すること。
第1オクテット - DERで符号化されたBIT STRING(ビット列型)[X.690]の値の最初のオクテット。
IP v4アドレス - 「.」で区切られた0～255の範囲の4つの10進数で記述される32ビットの識別子。10.5.0.5はIPv4アドレスの例である。
IP v6アドレス - 「:」で区切られた0～ffffの範囲の8つの16進数値で記述される128ビットの識別子。2001:0:200:3:0:0:0:1はIPv6アドレスの例である。:0:フィールドの1つの文字列を「::」に置き換えることができるため、2001:0:200:3::1は直前の例と同じアドレスを表す。([RFC3513]を参照)。
プレフィックス - アドレスのいくつかの先頭ビットで構成されるビット列で、アドレスの後に「/」を付けて記述する。10.5.0.0/16や2001:0:200:3:0:0:0:0/64(または 2001:0:200:3::/64)はプレフィックスの例である。プレフィックスは、重要度の低いゼロフィールドを省略して短縮されることが多いが、指定された数の初期ビットを含むのに十分なフィールドが必要である。10.5/16と2001:0:200:3::/64は省略されたプレフィックスの例である。
地域インターネット・レジストリ(RIR) - IPアドレスとAS識別子の管理を行う地域当局としてIANAによって認められた組織。執筆時点では、AfriNIC、APNIC、ARIN、LACNIC、RIPE NCCが含まれる。
使用権(right-to-use) - IPアドレス・プレフィックスに対して、インターネット全体でそのプレフィックスの広告を発信するASを指定する権限を持つこと。自律システム識別子の場合、その自律システム識別子を用いて他のネットワーク・オペレータに自らを識別させるネットワークを運用することを認可されること。
後続オクテット - DERで符号化されたBIT STRING[X.690]の値の2番目から最後までのオクテット。
トラストアンカー - 証明書パスの検証を行う際に信頼される証明書([RFC3280]を参照)。
本文書に「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」というキーワードがあらわれる場合、[RFC2119]の記述に従って解釈されるものとする。
2. IPアドレス委任拡張
この拡張は、IPアドレスをエンティティに属する公開鍵に結び付けることで、IPアドレスの割り当てをエンティティに伝えるものである。
2.1. コンテクスト
IPアドレス空間は現在、名目上はIANAを頂点とする階層によって管理されているが、実際はRIRによって管理されている。IANAはIPアドレス空間をRIRに割り当て、RIRは次にIPアドレス空間をインターネット・サービス・プロバイダ(ISP)に割り当て、ISPはIPアドレス空間をダウンストリーム・プロバイダやカスタマなどに割り当てることができる。RIRはまた、エンド・エンティティである組織にもIPアドレス空間を割り当てることができる。つまり、その空間を他の組織に再割り当てしない組織のことである。(割り当てと割り当てプロセスのガイドラインは、[RFC2050]および関連するRIRポリシー文書を参照のこと)。
IPアドレス委任拡張は、IPアドレス・ブロックの適切な委任、つまりIPアドレス空間を使用または部分割り当てするエンティティの認可の検証を可能にすることを目的としている。したがって、IPアドレス空間を割り当てるための既存の管理フレームワークが持つ固有の権威性(authoritativeness)を利用することは理にかなっている。上記セクション1で説明したように、本セクションで説明する拡張を持つ証明書を発行することで、これを実現する。この拡張の情報の1つの使用例は、特定のIPアドレス・ブロックへのパスを広告するBGP UPDATEを発信する組織の認可を検証するために、あるエンティティがこの拡張を使用する。例えば、[RFC1771]、[S-BGP]を参照のこと。
2.1.1. IPアドレスまたはプレフィックスの符号化
IP アドレスには、IPv4とIPv6の2つのファミリーがある。
IPv4アドレスは、0～255の範囲の4つの10進数をドット(「.」)で区切って記述した32ビットの数値である。10.5.0.5はIPv4アドレスの例である。
IPv6 アドレスは、0～ffffの範囲の8つの16進数をセミコロン(「:」)で区切って記述した128ビットの数値である。2001:0:200:3:0:0:0:1はIPv6アドレスの例である。IPv6 アドレスは、値が0の隣接フィールドが存在することが多い。このような0フィールドのグループの1つは、2つのセミコロン(「::」)で省略することができる。したがって、前の例は 2001:0:200:3::1で表すことができる。
アドレス・プレフィックスとは、最上位ビットが同じである2^k個の連続したアドレスの集合のことである。例えば、10.5.0.0から10.5.1.255までの512個のIPv4アドレスの集合はすべて、最上位ビットがすべて同じ23個である。アドレスの集合は、集合内の最下位アドレスにスラッシュ (「/」)と定数ビット数を付加して記述する。例のプレフィックス集合は10.5.0.0/23で、2^(32-23) = 2^9のアドレスが含む。IPv6アドレス2001:0:200:0:0:0:0:0から2001:0:3ff:ffff:ffff:ffff:ffff:ffff(2^89アドレス)の集合は、2001:0:200:0:0:0:0:0/39または等価的に2001:0:200::/39で表される。プレフィックスは、最下位のゼロフィールドを省略することで省くことができるが、指定された数の定数ビットを含むのに十分なフィールドが必要である。IPv4プレフィックスの例の短縮形は10.5.0/23で、IPv6プレフィックスの例の短縮形は2001:0:200::/39である。
IPアドレスまたはプレフィックスは、IPアドレス委任拡張で定数の最上位ビットを含むDERで符号化されたASN.1 BIT STRINGとして符号化される。BIT STRINGのDERの符号化は、BIT STRING型(0x03)、値のオクテット数(の符号化)、値の順で構成されることを思い出してほしい[X.690]。値は、最後の値オクテットの未使用ビット数を指定する「第1オクテット」と、それに続くビット列のオクテットを含む「後続オクテット」で構成される。(IPアドレスの場合、長さの符号化は長さだけになる。)
単一アドレスの場合、すべてのビットは定数なので、IPv4アドレスのビット列は32ビットを含む。アドレス10.5.0.4のDER符号化における後続オクテットは、0x0a 0x05 0x00 0x04である。最後のオクテットのすべてのビットが使用されるため、第1オクテットは0x00となる。したがって、DERで符号化されたBIT STRINGのオクテットは以下のようになる。
Type Len Unused Bits ...
0x03 0x05 0x00 0x0a 0x05 0x00 0x04
同様に、プレフィックス10.5.0/23のDER符号化は以下のようになる。
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
この場合、後続の3つのオクテットには24ビットが含まれるが、プレフィックスは23ビットしか使用しないため、最後のオクテットには未使用のビットが1つあり、第1オクテットは1となる(DERは、未使用ビットをすべて0に設定しなければならない(MUST))。
IPv6アドレス2001:0:200:3:0:0:0:1のDER符号化は以下のようになる。
Type Len Unused Bits ...
0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
そして、最後のオクテットに未使用ビットが1つあるプレフィックス2001:0:200/39の DER符号化は以下のようになる。
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
2.1.2. IPアドレス範囲の符号化
IPアドレスの連続する範囲は、連続したプレフィックスの集合で表すことができるが、より簡潔な表現は、範囲を最小アドレスと最大アドレスを含むSEQUENCE(順序列型)として符号化することで得られ、各アドレスはBIT STRINGとして符号化される。SEQUENCEの中で、範囲の最下位アドレスを表すビット列は、アドレスから最下位ゼロビットをすべて取り除くことで形成され、範囲の最上位アドレスを表すビット列は、最下位1ビットをすべて取り除くことで形成される。DER BIT STRINGの符号化は、最後のオクテットの未使用ビットはすべてゼロビットに設定しなければならない(MUST)。プレフィックスは常に範囲として表現できるが、範囲は常にプレフィックスとして表現できるわけではないことに留意すること。
プレフィックス10.5.0/23で表されるアドレスの範囲は、10.5.0.0～10.5.1.255である。最下位アドレスは、削除される16個のゼロビットで終わる。結果の16ビット列のDER符号化は以下のようになる。
Type Len Unused Bits ...
0x03 0x03 0x00 0x0a 0x05
最上位アドレスは、削除される9つの1ビットで終わる。結果の23ビット列のDER符号化は以下のようになる。
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00
プレフィックス2001:0:200/39は、最下位アドレス(2001:0:200)をDER符号化した範囲として符号化できる。
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
最大アドレス(2001:0:3ff:ffff:ffff:ffff:ffff:ffff)は、90個の最下位1ビットを削除すると38ビット列が残り、以下のように符号化できる。
Type Len Unused Bits ...
0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
すべてのIPアドレス・ブロックの特殊なケース、つまりすべてゼロビットのプレフィックス -- 「0/0」は、長さオクテットを1、最初のオクテットを0、後続のオクテットなしでDERごとに符号化しなければならない(MUST)。
Type Len Unused Bits ...
0x03 0x01 0x00
IPアドレスの場合、末尾のゼロビットの数が重要であることに留意すること。例えば、以下の10.64/12のDER符号化:
Type Len Unused Bits ...
0x03 0x03 0x04 0x0a 0x40
は、10.64.0/20のDER符号化とは異なる。
Type Len Unused Bits ...
0x03 0x04 0x04 0x0a 0x40 0x00
2.2. 仕様
2.2.1. OID
この拡張のOIDは、id-pe-ipAddrBlocksである。
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
[RFC3280]は以下のように定義している。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
2.2.2. 重要度
この拡張は、CRITICALとすべきである(SHOULD)。この拡張の使用目的は、その拡張で識別されるIPアドレスのブロックの使用する管理を示すことである。CAは、リライング・パーティーが証明書を発行された目的で使用するために、この拡張のセマンティクスを理解しなければならないという概念を伝えるために、この拡張をCRITICALとしてマークする。この拡張を含む証明書を使用する新しく作成されたアプリケーションは、この拡張を認識することが期待される。
2.2.3. 構文
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
2.2.3.1. IPAddrBlocks型
IPAddrBlocks型は、SEQUENCE OF IPAddressFamily型である。
2.2.3.2. IPAddressFamily型
IPAddressFamily型は、addressFamily要素とipAddressChoice要素を含む SEQUENCEである。
2.2.3.3. addressFamily要素
addressFamily要素は、2オクテットのアドレスファミリー識別子(AFI)をネットワーク・バイトオーダーを含むOCTET STRING(オクテット列型)であり、オプションでその後に1オクテットの後続アドレスファミリー識別子(SAFI)が続く。AFIとSAFIはそれぞれ[IANA-AF]と[IANA-SAFI]で規定されている。
特定のAFIとオプションのSAFIに対して認可が与えられない場合、IPAddrBlocks SEQUENCEにそのAFI/SAFIのIPAddressFamilyメンバーがあってはならない(MUST NOT)。
AFIとSAFIの一意の組み合わせごとに、IPAddressFamily SEQUENCEは1つだけ存在しなければならない(MUST)。各SEQUENCEは、(オクテットを符号なしの量として扱う)addressFamily値の昇順で並べなければならない(MUST)。SAFIを含まないaddressFamilyは、SAFIを含むaddressFamilyよりも前に置かなければならない(MUST)。IPv4アドレスとIPv6アドレスの両方を指定された場合、IPv4アドレスはIPv6アドレスに先行しなければならない(MUST)(IPv4 AFIの0001がIPv6 AFIの0002より小さいため)。
2.2.3.4. ipAddressChoice要素とIPAddressChoice型
ipAddressChoice要素の型はIPAddressChoiceである。IPAddressChoice型は、inherit要素またはaddressOrRanges要素のいずれかのCHOICE(選択型)である。
2.2.3.5. inherit要素
IPAddressChoice CHOICEにinherit要素が含まれる場合、指定されたAFIおよびオプションのSAFIに対する認可されたIPアドレスの集合は、addressOrRanges要素を含む IPAddressChoiceを含む証明書が取得されるまで、発行者の証明書、または発行者の発行者の証明書から再帰的に取得される。
2.2.3.6. addressesOrRanges要素
addressOrRanges要素は、SEQUENCE OF IPAddressOrRange型である。addressPrefix要素とaddressRange要素は、以下のバイナリ表現でソートしなければならない(MUST)。
<lowest IP address in range> | <prefix length>
ここで「|」 連結を表す。この表現のオクテット(a.b.c.d | IPv4では長さ、あるいは s:t:u:v:w:x:y:z | IPv6では長さ)は、DERで符号化されたBIT STRING値のオクテットではないことに留意すること。例えば、2つのaddressPrefixが与えられたとする。
| IP addr | length | DER encoding |
|---|---|---|
| 10.32.0.0 | 12 | Type Len Unused Bits... 03 03 04 0a 20 |
| 10.64.0.0 | 16 | 03 03 00 0a 40 |
プレフィックス10.32.0.0/12は、プレフィックス10.64.0.0/16より前に来なければならない(MUST)。一方、DERビット列でソートする場合、未使用ビットのオクテットは逆の順序でソートされるため、順序が逆になる。拡張内のIPAddressOrRangeの選択肢のペアは、互いに重複してはならない(MUST NOT)。連続するアドレス・プレフィックスまたは範囲は、単一の範囲または可能な限り単一のプレフィックスにまとめなければならない(MUST)。
2.2.3.7. IPAddressOrRange型
IPAddressOrRange型は、addressPrefix(IPプレフィックスまたはアドレス)要素またはaddressRange(IPアドレス範囲)要素のいずれかのCHOICEである。
この仕様では、プレフィックスとして符号化できるアドレス範囲はIPAddress要素(BIT STRING)を使用して符号化しなければならず(MUST)、プレフィックスとしてエンコードできないアドレス範囲はIPAddressRange(2つのBIT STRINGを含むSEQUENCE)を使用して符号化しなければならない(MUST)。以下の疑似コードは、指定されたアドレス範囲の符号化を選択する方法を示している。
LET N = 範囲の最下位アドレスと最上位アドレスの一致する最上位ビットの数
IF 最下位アドレスの残りのビットがすべてゼロビット
AND かつ、最上位アドレスの残りのビットがすべて1ビット
THEN その範囲はNビットのIPAddresとして符号化しなければならない(MUST)
ELSE その範囲をIPAddressRangeとして符号化しなければならない(MUST)
2.2.3.8. addressPrefix要素とIPAddress型
addressPrefix要素はIPAddress型である。IPAddress型は、アドレスの最上位(左端)N ビットが一定のままであり、残りのビット(IPv4の場合は32 - Nビット、IPv6の場合は128 - Nビット)が、0か1のどちらか変更されるIPアドレスの範囲を定義する。例えば、IPv4プレフィックス10.64/12は、アドレス10.64.0.0～10.79.255.255に対応し、10.64/11は10.64.0.0～10.95.255.255に対応する。IPv6プレフィックス2001:0:2/48は、アドレス2001:0:2～2001:0:2:ffff:ffff:ffff:ffff:ffffを表す。
IPアドレス・プレフィックスはBIT STRINGとして符号化される。BIT STRINGのDER符号化は、文字列の最初のオクテットを使用して、後続の最後のオクテットの最下位ビットのうちいくつが未使用かを指定する。DER符号化は、これらの未使用ビットをゼロビットに設定しなければならない(MUST)ことを規定する。
例:
128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000
to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
bit string to encode = 1000
Type Len Unused Bits ...
Encoding = 0x03 0x02 0x04 0x80
2.2.3.9. addressRange要素とIPAddressRange型
addressRange要素のIPAddressRange型である。IPAddressRange型は、最小(要素 min)と最大(要素max)のIPアドレスを含むSEQUENCEで構成される。各IPアドレスはBIT STRINGとして符号化される。IPAddressRangeの最小アドレスの意味的解釈は、(IPアドレスの全長に対して)指定されていないすべてのビットが0ビットであるということである。最大アドレスの意味的解釈は、指定されていないすべてのビットが1ビットであるということである。最小アドレスのBIT STRINGは、最下位ゼロビットをすべて取り除いた結果である。最大アドレスのBIT STRINGは、最大アドレスから最下位1ビットをすべて取り除いたものである。
Example:
129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000
to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111
minimum bit string = 1000 0001.01
maximum bit string = 1000
Encoding = SEQUENCE {
Type Len Unused Bits ...
min 0x03 0x03 0x06 0x81 0x40
max 0x03 0x02 0x04 0x80
}
認証パスの検証を実行する際のIPアドレス・ブロックの比較を簡素化するために、最大IPアドレスは、値が1であるビットを少なくとも1つ含まれなければならない(MUST)。つまり、後続のオクテットを省略したり、すべて0にすることはできない。
2.3. IPアドレス委任拡張の証明パスの検証
IPアドレス委任拡張を含む証明書の証明パスの検証には、追加の処理が必要である。パス内の各証明書が検証される際、その証明書のIPアドレス委任拡張に含まれるIPアドレスは、発行者の証明書のIPアドレス委任拡張のIPアドレスに包含されなければならない(MUST)。そうでなければ、検証は失敗しなければならない(MUST)。IPアドレス委任拡張を含む証明書の証明パス検証のためのトラストアンカーとなる証明書、およびパス上のすべての証明書は、それぞれIPアドレス委任拡張が含まれなければならない(MUST)。許可されるアドレス範囲の初期セットは、トラストアンカー証明書から取得される。
3. 自律システム識別子委任拡張
この拡張は、自律システム(AS)識別子をエンティティに属する公開鍵に結び付けることで、AS識別子をエンティティに割り当てたことを伝える。
3.1. コンテクスト
AS識別子委任は現在、名目上はIANAを頂点とする階層によって管理されているが、RIRによって管理されている。IANAはRIRにAS識別子を割り当て、RIRはエンド・エンティティである組織、つまり、他の組織にAS 識別子を再割り当てしない組織にAS 識別子を割り当てる。AS識別子委任拡張は、AS識別子の適切な委任の検証、つまりこれらのAS識別子を使用するエンティティの認可の検証を可能にすることを目的としている。したがって、AS識別子を管理するための既存の管理フレームワークに固有の権威を利用することが理にかなっている。上記セクション1で説明したように、このセクションで説明する拡張を持つ証明書を発行することで実現する。この拡張の情報の使用例としては、拡張内のAS識別子によって識別されるASを管理する組織の認可を検証するためにエンティティがその情報を使用する。AS識別子の割り当てを表すためにこの拡張を使用することは、AS識別子が管理される手順、またはASがいつ使用されるべきかを変更することを意図したものではない([RFC1930]参照)。
3.2. 仕様
3.2.1. OID
この拡張のOIDは id-pe-autonomousSysIdsである。
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
ここで、[RFC3280]は次のように定義している。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
3.2.2. 重要度
この拡張はCRITICALとすべきである(SHOULD)。この拡張の意図する用途は、拡張内のAS識別子の使用権を示すことである。CAは、リライング・パーティーが証明書を発行された目的に使用するためには、拡張のセマンティクスを理解しなければならないという概念を伝えるために、拡張をCRITICALとマークする。この拡張を含む証明書を使用する新しく作成されたアプリケーションは、この拡張を認識することが期待される。
3.2.3. 構文
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
3.2.3.1. ASIdentifiers型
ASIdentifiers型は、1つ以上の自律システム識別子を含むSEQUENCEである、つまりAS番号(asnum要素内)またはルーティング・ドメイン識別子(rdi要素内)である。ASIdentifiers型に複数の形式の識別子を含む場合、asnumエントリはrdiエントリの前になければならない(MUST)。AS番号はBGPで使用され、ルーティング・ドメイン識別子はIDRP[RFC1142]で規定されている。
3.2.3.2. asnum要素、rdi要素、およびASIdentifierChoice型
asnum要素とrdi要素は両方ともASIdentifierChoice型である。ASIdentifierChoice 型は、inherit要素またはasIdsOrRanges要素のいずれかのCHOICE(選択型)である。
3.2.3.3. inherit要素
ASIdentifierChoiceの選択肢にinherit要素が含まれている場合、asIdsOrRanges要素を含むASIdentifierChoiceを含む証明書が見つかるまで、認可されたAS識別子は、発行者の証明書、または発行者の発行者の証明書から再帰的に取得される。特定の形式のAS識別子に認可が付与されていない場合、ASIdentifiers順序列に対応するasnum/rdiメンバーが存在してはならない(MUST NOT)。
3.2.3.4. IdsOrRanges要素
asIdsOrRanges要素は、ASIdOrRange型のSEQUENCEである。asIdsOrRanges SEQUENCEに含まれる項目のペアは重複してはならない(MUST NOT)。連続する一連のAS識別子は、可能な限り1つの範囲にまとめなければならない(MUST)。 asIdsOrRanges要素のAS識別子は、数値の昇順にソートしなければならない(MUST)。
3.2.3.5. ASIDOrRange型
ASIdOrRange型は、1つの整数(ASId)または1つの順序列(ASRange)のいずれかの CHOICE(選択型)である。
3.2.3.6. id要素
id要素はASId型である。
3.2.3.7. range要素
range要素はASRange型である。
3.2.3.8. ASRange型
ASRange型は、min要素とmax要素で構成されるSEQUENCEで、AS識別子の値の範囲を指定するために使われる。
3.2.3.9. min要素とmax要素
min要素とmax要素はASId型である。min要素は範囲内の最小AS 識別子の値を指定するために使われ、max要素は範囲内の最大AS 識別子の値を指定する。
3.2.3.10. ASId型
ASId型はINTEGERである。
3.3. 自律システム識別子委任拡張の認証パスの検証
自律システム識別子委任拡張を含む証明書の証明パスの検証には、追加の処理が必要である。パス内の各証明書が検証される際、その証明書の自律システム識別子委任拡張の AS識別子は、発行者の証明書の自律システム識別子委任拡張のAS識別子に包含されなければならない(MUST)。そうでない場合、検証は失敗しなければならない。自律システム識別子委任拡張を含む証明書の証明パス検証のためのトラストアンカーとなる証明書、およびパスに沿ったすべての証明書は、それぞれ自律システム識別子委任拡張を含まれなければならない(MUST)。許可されるAS識別子の初期集合は、トラストアンカー証明書から取得する。
4. セキュリティに関する考慮事項
本仕様は、2つのX.509拡張について説明する。 X.509証明書はデジタル署名されているため、追加の完全性サービスは必要ない。これらの拡張を持つ証明書は秘密にしておく必要はなく、これらの証明書への無制限かつ匿名のアクセスはセキュリティ上の意味を持たない。
ただし、本仕様の範囲外のセキュリティ要因は、証明書ユーザに提供される保証に影響を与える。本セクションでは、実装者、管理者、ユーザが考慮すべき重要な問題を取り上げる。
これらの拡張は、認可情報、つまりIPアドレスやAS識別子の使用権を表す。これらは、BGPのセキュア・バージョン[S-BGP]をサポートするために開発されたが、他のコンテキストで使用される場合もある。セキュアBGPのコンテキストでは、これらの拡張を含む証明書はケイパビリティとして機能する。証明書は、秘密鍵の保有者(サブジェクト)が拡張で表されるIPアドレスまたはAS識別子を使用する認可を持つことをアサートする。このケイパビリティ・モデルの結果、一般的なPKI規則とは異なり、Subjectフィールドはセキュリティ目的とはほとんど無関係となる。
5. 謝辞
著者らは、チャールズ・ガーディナー、ラス・ハウスリー、ジェームス・マンガー、ジム・シャードの本仕様への貢献に感謝の意を表する。
付録 A -- ASN.1モジュール
この規範となる付録では、準拠するPKIコンポーネントが、ASN.1構文で使用するIPアドレスとAS識別子の拡張について記述する。
IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident(30) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- Copyright (C) The Internet Society (2004). This --
-- version of this ASN.1 module is part of RFC 3779; --
-- see the RFC itself for full legal notices. --
-- EXPORTS ALL --
IMPORTS
-- PKIX specific OIDs and arcs --
id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
-- IP Address Delegation Extension OID --
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
-- IP Address Delegation Extension Syntax --
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
-- Autonomous System Identifier Delegation Extension OID --
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
-- Autonomous System Identifier Delegation Extension Syntax --
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
END
付録 B -- IP アドレス委任拡張の例
重要なX.509 v3証明書拡張:
IPv4ユニキャスト・アドレス・プレフィックス
- 10.0.32/20、つまり10.0.32.0～10.0.47.255
- 10.0.64/24、つまり10.0.64.0～10.0.64.255
- 10.1/16、つまり10.1.0.0～10.1.255.255
- 10.2.48/20、つまり10.2.48.0～10.2.63.255
- 10.2.64/24、つまり10.2.64.0～10.2.64.255
- 10.3/16、つまり10.3.0.0～10.3.255.255、および
- 発行者の証明書からすべてのIPv6アドレスを継承する
(16進数):
30 46 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 37 extnValue {
30 35 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 24 addressesOrRanges {
IPAddressOrRange
03 04 04 0a0020 addressPrefix 10.0.32/20
IPAddressOrRange
03 04 00 0a0040 addressPrefix 10.0.64/24
IPAddressOrRange
03 03 00 0a01 addressPrefix 10.1/16
IPAddressOrRange
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
IPAddressOrRange
03 03 00 0a03 addressPrefix 10.3/16
} -- addressesOrRanges
} -- IPAddressFamily
30 06 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
この例は、プレフィックスと範囲がどのようにソートされるかを示している。
-
プレフィックス1の未使用ビット数(4)がプレフィックス2の未使用ビット数(0) より大きい場合でも、プレフィックス1はプレフィックス2より前に先行しなければならない(MUST)。
-
プレフィックス2のBIT STRING符号化のオクテット数(4)がプレフィックス3のBIT STRING符号化のオクテット数(3)より大きい場合でも、プレフィックス2はプレフィックス3より前に先行しなければならない(MUST)。
-
プレフィックス4と5は隣接している(10.2.48.0から10.2.64.255までのアドレス範囲を表す)ため、(範囲を1つのプレフィックスで符号化できないため)範囲をまとめなければならない(MUST)。
-
範囲のmax要素の末尾の6つのゼロビットは、値の意味解釈にとって重要であることに留意すること(未使用ビットはすべて0ではなく1として解釈されるため)。 min要素の末尾の4つのゼロビットは重要ではないため、削除しなければならない(MUST)(したがって、min要素の符号化では未使用の(4)ビットがある)。(DER符号化では、後続の最後のオクテットの未使用ビットをゼロに設定しなければならない(MUST)。)
-
プレフィックス4と5で形成される範囲(30)は、範囲のSEQUENCEタグがプレフィックス6の符号化に使用されるBIT STRING(03)のタグより大きい場合でも、プレフィックス6より前に先行しなければならない(MUST)。
-
IPv4のアドレスファミリ識別子(0001)はIPv6の識別子(0002)より小さいため、IPv4情報はIPv6情報の前に先行しなければならない(MUST)。
IPv6プレフィックス2001:0:2/48とIPv4プレフィックス10/8および172.16/12を指定し、発行者の証明書からすべてのIPv4マルチキャスト・アドレスを継承する拡張は以下のようになる(16進数)。
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 ac10 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/48
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
付録 C -- AS識別子委任拡張の例
AS番号135、3000～3999、5001を指定し、すべてのルーティング・ドメイン識別子を発行者の証明書から継承する拡張は、以下のようになる(16進数)。
30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
付録D -- X.509属性証明書の使用
この付録では、地域インターネット・レジストリ(RIR)からエンドユーザ組織にIP アドレス・ブロックまたはAS識別子の「使用権」を伝達するために属性証明書([RFC3281] で指定されているAC)を使用する提案から生じる問題について説明する。
AS識別子とIPアドレス・ブロックという2つのリソースは、現在、別の方法で管理されている。AS識別子の使用権を持つすべての組織は、RIRから直接認可を受ける。IPアドレス・ブロックの使用権を持つ組織は、RIRから直接または間接的に認可を受ける。例えば、ダウンストリーム・サービス・プロバイダから認可を受け、そのサービス・プロバイダがインターネット・サービス・プロバイダから認可を受け、その後、そのインターネット・サービス・プロバイダがRIRから認可を受ける。AS識別子は将来的にサブ割り当てされる可能性があるため、使用されるメカニズムは3レベルの階層に依存すべきではないことに留意すること。
RFC 3281のセクション1では、ACの使用が、認可情報を伝える拡張を持つ公開鍵証明書(PKC)を使用するよりも望ましい理由について、以下の2つの理由を挙げている。
「認可情報は、PKC拡張に配置してもいいし、別個の属性証明書(AC)に配置してもいい。PKC内に認可情報を配置することは、通常、以下の2つの理由から望ましくない。第1に、認可情報は多くの場合、IDと公開鍵のバインディングと同じ有効期間を持たないことが多い。認可情報をPKC拡張に配置すると、一般にPKCの有効期限が短くなる。第2に、PKC発行者は通常、認可情報に対して権限を持たない。これにより、PKC 発行者は、権威ある情報源から認可情報を取得するために、追加の手順が必要になる。
「これらの理由により、多くの場合、認可情報をPKCから分離した方がよい場合が多い。しかし、認可情報もアイデンティティに結び付ける必要がある。ACはこのバインディングを提供する。ACは単にデジタル署名された(または認証された)アイデンティティと属性のセットである。」
IPアドレスおよびAS識別子の認可の場合、これらの理由は当てはまらない。第1に、公開鍵証明書は認可のためだけに発行されるため、証明書の有効期間は認可の有効期間と正確に一致し、多くの場合、発行者と認可を受けるエンティティとの間の契約関係と結び付けられる。サブジェクト名と発行者名は、証明パスの検証時にチェーニングのために使用され、物理的なエンティティに対応する必要はない。PKCのサブジェクト名は、実際には発行CAがランダムに割り当てる場合があり、リソース保有者の匿名性を限定的に保つことができる。第2に、証明書発行者が認証情報に対して権威を持つように、証明書の階層が構築される。
したがって、上記で最初に引用した段落の2つの点は、AS番号とIPアドレス・ブロックの割り当ての場合には当てはまらない。また、リソースはIDではなく、PKCの公開鍵に対応する秘密鍵の保有者に結び付けられるため、引用した2番目の段落の指摘も当てはまらない。
RFC 3281は、準拠する属性証明書が満たさなければならないいくつかの要件を規定している。S-BGPに関連して、より重要な要件は以下のとおりである。
-
セクション1より、「本仕様はACチェーンの使用を推奨しない。他の(将来の)仕様がACチェーンの使用が対応するかもしれない。」
IANAからRIR、ISP、DSPへの割り当て、およびエンド組織への割り当ては、少なくともIPアドレス・ブロックについてはチェーンの使用を必要とする。上位のACがどのように配置され、どのように処理されるかについての説明を提供する必要がある。この文書の読者には、チェーンを回避する方法を提案することを推奨する。
-
セクション4.2.9より、「セクション4.3は、このプロファイルで使用できる拡張と、その拡張がクリティカルとマークされるかどうかを定義している。他のクリティカルな拡張が使用された場合、ACはこのプロファイルに準拠しない。しかし、 他の重要ではない拡張が使用されている場合、ACはこのプロファイルに準拠する。」
これは、この仕様で定義されているクリティカルな委任拡張を単純にACに配置できないことを意味する。これらは、クリティカルとマークされていない場合は使用できるが、意図された用途では、拡張がクリティカルである必要があるため、拡張を含む証明書を疑い余地のないアプリケーションがID証明書として使用することはできない。
-
セクション4.5より、「AC発行者は、PKC発行者であってはならない(MUST NOT)。つまり、AC発行者はCAになることはできない。」
つまり、AC発行者ごとに、AC保有者の公開鍵を含むPKCを発行する別のCAが必要になる。AC発行者は保有者のPKCを発行できず、PKC発行者はACに署名できない。したがって、PKI内の各エンティティは、CAに加えてAC発行者を運用する必要がある。属性証明書をサポートするために処理すべき証明書発行者とCRLの数は、PKCを使用する場合に必要とされる数の2倍となる。1つの目的のために証明書を発行する発行者が2つ存在する場合、不整合が発生する可能性もある。
RFC 3281のACモデルは、AC保有者が属性または認可を実証したい場合に、AC保有者がAC検証者にACを提示することを意味する。ここで定義される拡張の使用目的には、AC検証者(NOC)とAC発行者(すべてのRIRとNOC)間の直接的なやり取りはない。使用権が主張されたオブジェクトに署名があれば、「AC検証者」は AC保有者のPKCを特定できるが、サブジェクトのACを直接特定する方法はない。
-
セクション5より、「4. AC発行者は、(設定などによって)AC発行者として直接信頼されなければならない(MUST)。」
これは、階層を通じて割り当てられるIPアドレス・ブロックの使用権の場合には当てはまらない。ACの認証パスの検証は、委任階層を介してチェーンアップする必要がある。各リライング・パーティー(NOC)が他のすべてのNOCを「信頼」するように構成するkとは、拡張性に繋がらないし、そのような「信頼」は、提案されているセキュリティ・メカニズムが防止するように設計されている障害を引き起こす。信頼されたルートを持つ単一のPKIが使用され、ISPごとに個別に信頼された何千ものAC発行者が使用されるわけではない。
ACを適切に検証するために必要となる作業量は、本文書で定義される証明書拡張をPKCに配置するメカニズムよりも多い。ACに加えて、検証すべき証明書の数が2倍になる。ACをサポートするために必要な管理負担が大幅に増加する可能性がある。
参考文献
引用規約
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)".
参考規約
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program Protocol Specification", RFC 791, September 1981.
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway Protocol (S-BGP)," IEEE JSAC Special Issue on Network Security, April 2000.
著者のアドレス
チャールズ・リン
BBNテクノロジーズ
10 モールトン ストリート
マサチューセッツ州ケンブリッジ 02138
アメリカ合衆国
電話: +1 (617) 873-3367
メール: CLynn@BBN.Com
スティーブン・ケント
BBNテクノロジーズ
10 モールトン ストリート
マサチューセッツ州ケンブリッジ 02138
アメリカ合衆国
電話: +1 (617) 873-3988
メール: Kent@BBN.Com
カレン・セオ
BBNテクノロジーズ
10 モールトン ストリート
マサチューセッツ州ケンブリッジ 02138
アメリカ合衆国
電話: +1 (617) 873-3152
メール: KSeo@BBN.Com
完全な著作権に関する声明
著作権 (C) The Internet Society (2004)。本文書は、BCP 78に含まれる権利、ライセンス、制限に従うものであり、そこに規定されている場合を除き、著者はすべての権利を保持する。
本文書およびここに含まれる情報は「現状のまま」で提供されるものであり、寄稿者、寄稿者が代表または後援する組織(存在する場合)、インターネット協会およびインターネット・エンジニアリング・タスク・フォースは、すべての保証を否認する。これは、明示または黙示を問わず、ここに記載された情報の使用がいかなる権利も侵害しないという保証、または商品性や特定の目的への適合性の黙示的な保証を含むが、これに限定されない。
知的財産
IETFは、本文書に記載されたテクノロジーの実装または使用に関連すると主張されうる知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスがどの程度利用可能か不可能かに関して、いかなる立場も取らない。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを表明するものでもない。RFC文書の権利に関する手続きに関する情報は、BCP 78およびBCP 79に記載されている。
IETF事務局に対して行われたIPR開示の写し、および利用可能になるライセンスの保証、または本仕様の実装者や利用者がそのような保有権の使用するための一般ライセンスや許可を取得しようとする試みの結果は、IETFのオンラインIPRリポジトリ(http://www.ietf.org/ipr) から入手できる。
IETFは、本規格の実装に必要とされる技術をカバーする著作権、特許、特許出願、その他の保有権について、利害関係者に対して注意を喚起するよう求める。情報はIETF(ietf-ipr@ietf.org)に送っていただきたい。
謝辞
RFCエディター機能の資金は現在、インターネットソサエティから提供されている。
変更履歴
- 2024.2.9
Discussion