RFC4945 日本語訳
4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, andPKIX. B. Korver. August 2007. (Format: TXT=101495 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Korver Request for Comments: 4945 Network Resonance, Inc. Category: Standards Track August 2007
Korverがコメントのために要求するワーキンググループB.をネットワークでつないでください: 4945年のネットワーク共鳴Inc.カテゴリ: 標準化過程2007年8月
The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
IKEv1/ISAKMP、IKEv2、およびPKIXのインターネットIPセキュリティPKIプロフィール
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec.
X.509(PKIX)証明書プロフィールのためのインターネット・キー・エクスチェンジ(IKE)と公開鍵基盤はともに、与えられたアプリケーションにおける使用のために輪郭を描かなければならないフレームワークを提供します。 このドキュメントはIKE/IPsecの文脈でPKI技術を使用するための要件を定義するIKEとPKIXのプロフィールを提供します。 ドキュメントはIKEv1やIKEv2などのプロトコル仕様の補足となります。(公開鍵証明書と関連する合わせることの材料の存在を仮定しますが、IKEv2は明らかにPKIに問題を扱いません)。 このドキュメントはそれらの問題を扱います。 対象とする訪問者はIPsecのためのPKIのimplementersです。
Korver Standards Track [Page 1] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[1ページ]
Table of Contents
目次
1. Introduction ....................................................4
2. Terms and Definitions ...........................................4
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP ................5
3.1. Identification Payload .....................................5
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR .......................7
3.1.2. ID_FQDN .............................................9
3.1.3. ID_USER_FQDN .......................................10
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET,
ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE .............11
3.1.5. ID_DER_ASN1_DN .....................................11
3.1.6. ID_DER_ASN1_GN .....................................12
3.1.7. ID_KEY_ID ..........................................12
3.1.8. Selecting an Identity from a Certificate ...........12
3.1.9. Subject for DN Only ................................12
3.1.10. Binding Identity to Policy ........................13
3.2. Certificate Request Payload ...............................13
3.2.1. Certificate Type ...................................14
3.2.2. X.509 Certificate - Signature ......................14
3.2.3. Revocation Lists (CRL and ARL) .....................14
3.2.4. PKCS #7 wrapped X.509 certificate ..................15
3.2.5. Location of Certificate Request Payloads ...........15
3.2.6. Presence or Absence of Certificate Request
Payloads ...........................................15
3.2.7. Certificate Requests ...............................15
3.2.8. Robustness .........................................18
3.2.9. Optimizations ......................................18
3.3. Certificate Payload .......................................19
3.3.1. Certificate Type ...................................20
3.3.2. X.509 Certificate - Signature ......................20
3.3.3. Revocation Lists (CRL and ARL) .....................20
3.3.4. PKCS #7 Wrapped X.509 Certificate ..................20
3.3.5. Location of Certificate Payloads ...................21
3.3.6. Certificate Payloads Not Mandatory .................21
3.3.7. Response to Multiple Certification
Authority Proposals ................................21
3.3.8. Using Local Keying Materials .......................21
3.3.9. Multiple End-Entity Certificates ...................22
3.3.10. Robustness ........................................22
3.3.11. Optimizations .....................................23
4. Use of Certificates in RFC 4301 and IKEv2 ......................24
4.1. Identification Payload ....................................24
4.2. Certificate Request Payload ...............................24
4.2.1. Revocation Lists (CRL and ARL) .....................24
4.3. Certificate Payload .......................................25
4.3.1. IKEv2's Hash and URL of X.509 Certificate ..........25
4.3.2. Location of Certificate Payloads ...................25
1. 序論…4 2. 用語と定義…4 3. RFC2401とIKEv1/ISAKMPにおける証明書の使用…5 3.1. 識別有効搭載量…5 3.1.1. _ID IPV4_ADDRと_ID IPV6_ADDR…7 3.1.2. _ID FQDN…9 3.1.3. _IDユーザ_FQDN…10 3.1.4. ID_IPV4_ADDR_サブネット、ID_IPV6_ADDR_サブネット、ID_IPV4_ADDR_範囲、ID_IPV6_ADDR_範囲…11 3.1.5. ID_DER_ASN1_DN…11 3.1.6. ID_DER_ASN1_GN…12 3.1.7. IDの_の主要な_ID…12 3.1.8. 証明書からアイデンティティを選択します…12 3.1.9. DNだけのために、かけます。12 3.1.10. 方針への拘束力があるアイデンティティ…13 3.2. 要求有効搭載量を証明してください…13 3.2.1. タイプを証明してください…14 3.2.2. X.509証明書--、署名…14 3.2.3. 取消しは(CRLとARL)を記載します…14 3.2.4. PKCS#7はX.509証明書を包装しました…15 3.2.5. 証明書要求有効搭載量の位置…15 3.2.6. 証明書要求有効搭載量の存在か欠如…15 3.2.7. 要求を証明してください…15 3.2.8. 丈夫さ…18 3.2.9. 最適化…18 3.3. 有効搭載量を証明してください…19 3.3.1. タイプを証明してください…20 3.3.2. X.509証明書--、署名…20 3.3.3. 取消しは(CRLとARL)を記載します…20 3.3.4. PKCS#7はX.509証明書を包装しました…20 3.3.5. 証明書有効搭載量の位置…21 3.3.6. 義務的でない状態で有効搭載量を証明してください…21 3.3.7. 複数の認証局の提案への応答…21 3.3.8. 地方の合わせることの材料を使用します…21 3.3.9. 複数の終わり実体証明書…22 3.3.10. 丈夫さ…22 3.3.11. 最適化…23 4. RFC4301とIKEv2における証明書の使用…24 4.1. 識別有効搭載量…24 4.2. 要求有効搭載量を証明してください…24 4.2.1. 取消しは(CRLとARL)を記載します…24 4.3. 有効搭載量を証明してください…25 4.3.1. IKEv2のX.509証明書のハッシュとURL…25 4.3.2. 証明書有効搭載量の位置…25
Korver Standards Track [Page 2] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[2ページ]
4.3.3. Ordering of Certificate Payloads ...................25
5. Certificate Profile for IKEv1/ISAKMP and IKEv2 .................26
5.1. X.509 Certificates ........................................26
5.1.1. Versions ...........................................26
5.1.2. Subject ............................................26
5.1.3. X.509 Certificate Extensions .......................27
5.2. X.509 Certificate Revocation Lists ........................33
5.2.1. Multiple Sources of Certificate Revocation
Information ........................................34
5.2.2. X.509 Certificate Revocation List Extensions .......34
5.3. Strength of Signature Hashing Algorithms ..................35
6. Configuration Data Exchange Conventions ........................36
6.1. Certificates ..............................................36
6.2. CRLs and ARLs .............................................37
6.3. Public Keys ...............................................37
6.4. PKCS#10 Certificate Signing Requests ......................37
7. Security Considerations ........................................37
7.1. Certificate Request Payload ...............................37
7.2. IKEv1 Main Mode ...........................................37
7.3. Disabling Certificate Checks ..............................38
8. Acknowledgements ...............................................38
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................39
Appendix A. The Possible Dangers of Delta CRLs ....................40
Appendix B. More on Empty CERTREQs ................................40
4.3.3. 証明書有効搭載量を注文します…25 5. IKEv1/ISAKMPとIKEv2のためにプロフィールを証明してください…26 5.1. X.509証明書…26 5.1.1. バージョン…26 5.1.2. かけます。26 5.1.3. X.509は拡大を証明します…27 5.2. X.509証明書取消しは記載します…33 5.2.1. 証明書取消し情報の複数の源…34 5.2.2. X.509は取消しリスト拡張子を証明します…34 5.3. アルゴリズムを論じ尽くす署名の強さ…35 6. コンフィギュレーション・データはコンベンションを交換します…36 6.1. 証明書…36 6.2. CRLsとARLs…37 6.3. 公開鍵…37 6.4. PKCS#10は署名要求を証明します…37 7. セキュリティ問題…37 7.1. 要求有効搭載量を証明してください…37 7.2. IKEv1の主なモード…37 7.3. 証明書を無効にするのはチェックします…38 8. 承認…38 9. 参照…38 9.1. 標準の参照…38 9.2. 有益な参照…39付録、A. デルタCRLsの可能な危険…40 さらに空のCERTREQsの上の付録B.…40
Korver Standards Track [Page 3] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[3ページ]
1. Introduction
1. 序論
IKE [1], ISAKMP [2], and IKEv2 [3] provide a secure key exchange mechanism for use with IPsec [4] [14]. In many cases, the peers authenticate using digital certificates as specified in PKIX [5]. Unfortunately, the combination of these standards leads to an underspecified set of requirements for the use of certificates in the context of IPsec.
イケ[1]、ISAKMP[2]、およびIKEv2[3]はIPsec[4][14]と共に安全な主要な交換メカニズムを使用に提供します。 多くの場合、同輩はPKIX[5]で指定されるように使用のデジタル証明書を認証します。 残念ながら、これらの規格の組み合わせはIPsecの文脈における証明書の使用のためのunderspecifiedセットの要件につながります。
ISAKMP references the PKIX certificate profile but, in many cases, merely specifies the contents of various messages without specifying their syntax or semantics. Meanwhile, the PKIX certificate profile provides a large set of certificate mechanisms that are generally applicable for Internet protocols, but little specific guidance for IPsec. Given the numerous underspecified choices, interoperability is hampered if all implementers do not make similar choices, or at least fail to account for implementations that have chosen differently.
多くの場合では、輪郭を描きますが、PKIXが証明するISAKMP参照は単にそれらの構文か意味論を指定することのない様々なメッセージのコンテンツを指定します。 その間、PKIX証明書プロフィールはほとんど大きいセットのインターネットプロトコルには、一般に、適切な証明書メカニズム、しかし、特定の指導をIPsecに供給しません。 頻繁なunderspecified選択を考えて、すべてのimplementersが同様の選択をするか、または必ず異なって選ばれた実装を少なくとも説明するなら、相互運用性は妨げられます。
This profile of the IKE and PKIX frameworks is intended to provide an agreed-upon standard for using PKI technology in the context of IPsec by profiling the PKIX framework for use with IKE and IPsec, and by documenting the contents of the relevant IKE payloads and further specifying their semantics.
それらの意味論を指定しながら、IKEとPKIXフレームワークのこのプロフィールがIKEとIPsecとの使用のためにPKIXフレームワークの輪郭を描いて、関連IKEペイロードのコンテンツを記録するのによるIPsecの文脈にさらにPKI技術を使用する同意している規格を提供することを意図します。
In addition to providing a profile of IKE and PKIX, this document attempts to incorporate lessons learned from recent experience with both implementation and deployment, as well as the current state of related protocols and technologies.
IKEとPKIXのプロフィールを提供することに加えて、このドキュメントは、実装と展開と関連するプロトコルと技術の現状の両方の最近の経験から学習されたレッスンを取り入れるのを試みます。
Material from ISAKMP, IKEv1, IKEv2, or PKIX is not repeated here, and readers of this document are assumed to have read and understood those documents. The requirements and security aspects of those documents are fully relevant to this document as well.
ISAKMP、IKEv1、IKEv2、またはPKIXからの材料はここで繰り返されないで、それらのドキュメントを読んで、このドキュメントの読者が理解していたと思われます。 それらのドキュメントの要件とセキュリティ局面はまた、このドキュメントに完全に関連しています。
This document is organized as follows. Section 2 defines special terminology used in the rest of this document, Section 3 provides the profile of IKEv1/ISAKMP, Section 4 provides a profile of IKEv2, and Section 5 provides the profile of PKIX. Section 6 covers conventions for the out-of-band exchange of keying materials for configuration purposes.
このドキュメントは以下の通りまとめられます。 セクション2はこのドキュメントの残りに使用される特別な用語を定義します、そして、セクション3はIKEv1/ISAKMPのプロフィールを提供します、そして、セクション4はIKEv2のプロフィールを提供します、そして、セクション5はPKIXのプロフィールを提供します。 セクション6は構成目的のための合わせることの材料のバンドで出ている交換のためにコンベンションをカバーします。
2. Terms and Definitions
2. 用語と定義
Except for those terms that are defined immediately below, all terms used in this document are defined in either the PKIX [5], ISAKMP [2], IKEv1 [1], IKEv2 [3], or Domain of Interpretation (DOI) [6] documents.
すぐに以下で定義されるそれらの用語を除いて、本書では使用されるすべての用語がInterpretation(DOI)[6]のPKIX[5]、ISAKMP[2]、IKEv1[1]、IKEv2[3]、またはDomainが記録するどちらかで定義されます。
Korver Standards Track [Page 4] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[4ページ]
o Peer source address: The source address in packets from a peer.
This address may be different from any addresses asserted as the
"identity" of the peer.
o 同輩ソースアドレス: 同輩からのパケットのソースアドレス。 このアドレスは同輩の「アイデンティティ」として断言されたどんなアドレスとも異なっているかもしれません。
o FQDN: Fully qualified domain name.
o FQDN: 完全修飾ドメイン名。
o ID_USER_FQDN: IKEv2 renamed ID_USER_FQDN to ID_RFC822_ADDR. Both
are referred to as ID_USER_FQDN in this document.
o _IDユーザ_FQDN: IKEv2は_ID RFC822_ADDRへのUSER_FQDNにID_を改名しました。両方が本書では_ID USER_FQDNと呼ばれます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[7]で説明されるように本書では解釈されることであるべきですか?
3. Use of Certificates in RFC 2401 and IKEv1/ISAKMP
3. RFC2401とIKEv1/ISAKMPにおける証明書の使用
3.1. Identification Payload
3.1. 識別有効搭載量
The Identification (ID) Payload indicates the identity claimed by the sender. The recipient can then use the ID as a lookup key for policy and for certificate lookup in whatever certificate store or directory that it has available. Our primary concern in this section is to profile the ID payload so that it can be safely used to generate or lookup policy. IKE mandates the use of the ID payload in Phase 1.
Identification(ID)有効搭載量は送付者によって要求されたアイデンティティを示します。 そして、受取人は方針と証明書ルックアップに、主要なルックアップとしてそれが利用可能にするどんな証明書店かディレクトリでもIDを使用できます。 このセクションの私たちのプライマリ関心は安全に生成するのにおいて使用されるかルックアップ方針になるようにIDペイロードの輪郭を描くことです。 IKEはPhase1におけるIDペイロードの使用を強制します。
The DOI [6] defines the 11 types of Identification Data that can be used and specifies the syntax for these types. These are discussed below in detail.
DOI[6]は使用できるIdentification Dataの11のタイプを定義して、これらのタイプに構文を指定します。 以下で詳細にこれらについて議論します。
The ID payload requirements in this document cover only the portion of the explicit policy checks that deal with the Identification Payload specifically. For instance, in the case where ID does not contain an IP address, checks such as verifying that the peer source address is permitted by the relevant policy are not addressed here, as they are out of the scope of this document.
IDペイロード要件は本書では明確にIdentification有効搭載量に対処する明白な方針チェックの部分だけをカバーしています。 例えば、IDがIPアドレスを含まない場合では、同輩ソースアドレスが関連方針で受入れられることを確かめなどなどのチェックはここで扱われません、このドキュメントの範囲の外にそれらがあるとき。
Implementations SHOULD populate ID with identity information that is contained within the end-entity certificate. Populating ID with identity information from the end-entity certificate enables recipients to use ID as a lookup key to find the peer end-entity certificate. The only case where implementations may populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range).
実装SHOULDは終わり実体証明書の中に含まれているアイデンティティ情報でIDに居住します。 終わり実体証明書からのアイデンティティ情報でIDに居住するのは、受取人が同輩終わり実体証明書を見つけるために主要なルックアップとしてIDを使用するのを可能にします。 実装が終わり実体証明書に含まれていない情報でIDに居住するかもしれない唯一のケースがIDが同輩ソースアドレス(サブネットか範囲ではなく、ただ一つのアドレス)を含む時です。
Because implementations may use ID as a lookup key to determine which policy to use, all implementations MUST be especially careful to verify the truthfulness of the contents by verifying that they correspond to some keying material demonstrably held by the peer.
実装がどの方針を使用したらよいかを決定するために主要なルックアップとしてIDを使用するかもしれないので、すべての実装が同輩によって論証できて保たれた材料を合わせながらいくつかに対応することを確かめることによってコンテンツの正直さについて確かめるのに特に慎重でなければなりません。
Korver Standards Track [Page 5] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[5ページ]
Failure to do so may result in the use of an inappropriate or insecure policy. The following sections describe the methods for performing this binding.
そうしない場合、不適当であるか不安定な方針の使用をもたらすかもしれません。 以下のセクションはこの結合を実行するためのメソッドを説明します。
The following table summarizes the binding of the Identification Payload to the contents of end-entity certificates and of identity information to policy. Each ID type is covered more thoroughly in the following sections.
以下のテーブルは終わり実体証明書と方針へのアイデンティティ情報のコンテンツへIdentification有効搭載量の結合をまとめます。 それぞれのIDタイプは以下のセクションで、より徹底的にカバーされています。
ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules
-------------------------------------------------------------------
| | | |
IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | |
| | | |
FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | |
| | | |
USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | |
| | | |
IP range | MUST NOT | n/a | n/a | n/a
| | | |
DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU
| | compare | |
| | | |
GN | MUST NOT | n/a | n/a | n/a
| | | |
KEY_ID | MUST NOT | n/a | n/a | n/a
| | | |
IDタイプ| サポート| 対応してください。| 本命| SPDルックアップ| 発信| PKIX Attrib| マッチング| 規則------------------------------------------------------------------- | | | | IP*_ADDR | 必須[a]| SubjAltName| 必須[b]| [c]、[d]| | iPAddress| | | | | | FQDN| 必須[a]| SubjAltName| 必須[b]| [c]、[d]| | dNSName| | | | | | ユーザ_FQDN| 必須[a]| SubjAltName| 必須[b]| [c]、[d]| | rfc822Name| | | | | | IP範囲| 必須NOT| なし| なし| なし| | | | DN| 必須[a]| 全体| 必須[b]| ルックアップをサポートしなければなりません。| | 受けることがある| | どんな組み合わせに関しても| | bitwiseします。| | C、CN、O、またはOUについて| | 比較してください。| | | | | | GN| 必須NOT| なし| なし| なし| | | | キー_ID| 必須NOT| なし| なし| なし| | | |
[a] = Implementation MUST have the configuration option to send this
ID type in the ID payload. Whether or not the ID type is used
is a matter of local configuration.
[a] = 実装には、IDペイロードでこのIDタイプを送る設定オプションがなければなりません。 IDタイプが使用されているかどうかが、地方の構成の問題です。
[b] = The ID in the ID payload MUST match the contents of the
corresponding field (listed) in the certificate exactly, with
no other lookup. The matched ID MAY be used for Security
Policy Database (SPD) lookup, but is not required to be used
for this.
[b] = IDペイロードのIDはまさに証明書の対応する分野(記載されている)のコンテンツに合わなければなりません、他のルックアップなしで。 取り組んでいるIDは、Security Policy Database(SPD)ルックアップに使用されるかもしれませんが、これに使用されるのに必要ではありません。
[c] = At a minimum, Implementation MUST be capable of being
configured to perform exact matching of the ID payload contents
to an entry in the local SPD.
[c] = 最小限では、Implementationは、地方のSPDでIDペイロードコンテンツの正確なマッチングをエントリーに実行するために構成できなければなりません。
Korver Standards Track [Page 6] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[6ページ]
[d] = In addition, the implementation MAY also be configurable to
perform substring or wildcard matches of ID payload contents to
entries in the local SPD. (More on this in Section 3.1.5.)
[d] = また、さらに、実装も地方のSPDでIDペイロードコンテンツのサブストリングかワイルドカードマッチをエントリーに実行するのにおいて構成可能であるかもしれません。 (さらにセクション3.1.5におけるこれの。)
When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, implementations MUST be able to be configured to send the same string as it appears in the corresponding SubjectAltName extension. This document RECOMMENDS that deployers use this configuration option. All these ID types are treated the same: as strings that can be compared easily and quickly to a corresponding string in an explicit value in the certificate. Of these types, FQDN and USER_FQDN are RECOMMENDED over IP addresses (see discussion in Section 3.1.1).
IPV4_ADDRを送るとき、ADDR、FQDN、またはUSER_FQDN、実装が同じストリングを送るためにそれのように構成できなければならないIPV6_は対応するSubjectAltName拡張子に現れます。 これはRECOMMENDSを記録します。デプロイヤはこの設定オプションを使用します。 これらのすべてのIDタイプが同じように扱われます: ストリングとして、証明書の明白な値で対応するストリングと簡単にすぐにそれを比較できます。 これらのタイプでは、FQDNとUSER_FQDNはIPアドレスの上のRECOMMENDED(セクション3.1.1における議論を見る)です。
When sending a Distinguished Name (DN) as ID, implementations MUST send the entire DN in ID. Also, implementations MUST support at least the C, CN, O, and OU attributes for SPD matching. See Section 3.1.5 for more details about DN, including SPD matching.
IDとしてDistinguished Name(DN)を送るとき、実装はIDで全体のDNを送らなければなりません。 また、実装はSPDマッチングのために少なくともC、CN、O、およびOUに属性をサポートしなければなりません。 SPDマッチングを含むDNに関するその他の詳細に関してセクション3.1.5を見てください。
Recipients MUST be able to perform SPD matching on the exact contents of the ID, and this SHOULD be the default setting. In addition, implementations MAY use substrings or wildcards in local policy configuration to do the SPD matching against the ID contents. In other words, implementations MUST be able to do exact matches of ID to SPD, but MAY also be configurable to do substring or wildcard matches of ID to SPD.
受取人はIDの正確なコンテンツで合っているSPD、およびこのSHOULDを実行できるのが、既定の設定であるということであるに違いありません。 さらに、実装は、IDコンテンツに対して合っているSPDをするのに地方の方針構成にサブストリングかワイルドカードを使用するかもしれません。 言い換えれば、実装も、IDの完全な一致がSPDにできなければなりませんが、また、IDのサブストリングかワイルドカードマッチをSPDにするのにおいて構成可能であるかもしれません。
3.1.1. ID_IPV4_ADDR and ID_IPV6_ADDR
3.1.1. _ID IPV4_ADDRと_ID IPV6_ADDR
Implementations MUST support at least the ID_IPV4_ADDR or ID_IPV6_ADDR ID type, depending on whether the implementation supports IPv4, IPv6, or both. These addresses MUST be encoded in "network byte order", as specified in IP [8]: The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For the ID_IPV4_ADDR type, the payload MUST contain exactly four octets [8]. For the ID_IPV6_ADDR type, the payload MUST contain exactly sixteen octets [10].
実装は、少なくともIDの_IPV4_ADDRか_ID IPV6_ADDR IDがタイプであるとサポートしなければなりません、実装がIPv4、IPv6、または両方をサポートするかどうかによって。 指定されるとして「ネットワークバイトオーダー」でこれらのアドレスをIP[8]でコード化しなければなりません: それぞれの八重奏の最下位ビット(LSB)はネットワーク・アドレスの対応するバイトのLSBです。 ID_IPV4_ADDRタイプのために、ペイロードはまさに4つの八重奏[8]を含まなければなりません。 ID_IPV6_ADDRタイプのために、ペイロードはまさに16の八重奏[10]を含まなければなりません。
Implementations SHOULD NOT populate ID payload with IP addresses due to interoperability issues such as problems with Network Address Translator (NAT) traversal, and problems with IP verification behavior.
実装SHOULD NOTはNetwork Address Translator(NAT)縦断に関する問題などの相互運用性問題によるIPアドレスでIDペイロードに居住して、IP検証の振舞いで問題に居住します。
Deployments may only want to consider using the IP address as ID if all of the following are true:
以下のすべてが本当である場合にだけ、展開は、IPアドレスを使用するのが、IDであるとみなしたがっているかもしれません:
o the peer's IP address is static, not dynamically changing
o 同輩のIPアドレスはダイナミックに変化するのではなく、静的です。
o the peer is NOT behind a NAT'ing device
o 同輩はNAT'ingデバイスの後ろのそうではありません。
Korver Standards Track [Page 7] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[7ページ]
o the administrator intends the implementation to verify that the
peer source address matches the IP address in the ID received, and
that in the iPAddress field in the peer certificate's
SubjectAltName extension.
o 実装は、管理者が、同輩ソースアドレスがiPAddress分野で同輩証明書のSubjectAltName拡張子でIDのアドレスが受けたIP、およびそれに合っていることを確かめるつもりです。
Implementations MUST be capable of verifying that the IP address presented in ID matches via bitwise comparison the IP address present in the certificate's iPAddress field of the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the iPAddress field in the SubjectAltName extension for equality, binary comparison MUST be performed. Note that certificates may contain multiple address identity types -- in which case, at least one must match the source IP. If the default is enabled, then a mismatch between the two addresses MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip- validation" in order to permit better interoperability as current implementations vary greatly in how they behave on this topic.
を通して実装が、IPアドレスがIDでマッチを贈ったことを確かめることができなければならない、bitwiseする、証明書のSubjectAltName拡張子のiPAddress分野のアドレス現在の比較IP。 実装はデフォルトでこの検証を実行しなければなりません。 平等のためのSubjectAltName拡張子でiPAddress分野とIDのコンテンツを比べるとき、2進の比較を実行しなければなりません。 証明書が複数のアドレスアイデンティティタイプを含むかもしれないことに注意してください--その場合、少なくともソースIPに合わなければなりません。 デフォルトが可能にされるなら、2つのアドレスの間のミスマッチを誤りとして扱わなければなりません、そして、セキュリティ協会セットアップを中止しなければなりません。 このイベントSHOULD、監査可能であってください。 実装はその検証ステップをサボる(すなわち、構成が可能にすることができるローカルの方針)ために設定オプションを提供するかもしれませんが、そのオプションはデフォルトで取り止めになっていなければなりません。 私たちは、現在の実装が大いに異なるときそれらがこの話題に関してどう振る舞うかで、より良い相互運用性を可能にするために「オプションからスキップ合法化」を入れます。
In addition, implementations MUST be capable of verifying that the address contained in the ID is the same as the address contained in the IP header. Implementations SHOULD be able to check the address in either the outermost or innermost IP header and MAY provide a configuration option for specifying which is to be checked. If there is no configuration option provided, an implementation SHOULD check the peer source address contained in the outermost header (as is the practice of most of today's implementations). If ID is one of the IP address types, then implementations MUST perform this verification by default. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e. local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on the topic of verification of source IP.
さらに、実装は、IDに保管されていたアドレスがIPヘッダーに含まれたアドレスと同じであることを確かめることができなければなりません。 実装SHOULDは一番はずれの、または、最も奥深いIPヘッダーでアドレスをチェックできて、どれがチェックされることになっていたらよいかを指定するための設定オプションを提供するかもしれません。 構成が全くなければ、オプションは提供されました、同輩ソースアドレスが一番はずれのヘッダー(今日の実装の大部分の習慣のような)に含んだ実装SHOULDチェック。 IDがIPアドレスタイプのひとりであるなら、実装はデフォルトでこの検証を実行しなければなりません。 このデフォルトが可能にされるなら、誤りとしてミスマッチを扱わなければなりません、そして、セキュリティ協会セットアップを中止しなければなりません。 このイベントSHOULD、監査可能であってください。 実装はその検証ステップをサボる(すなわち、構成が可能にすることができるローカルの方針)ために設定オプションを提供するかもしれませんが、そのオプションはデフォルトで取り止めになっていなければなりません。 私たちは、より良い相互運用性を可能にするために「オプションからスキップ合法化」を入れます、それらがソースIPの検証の話題に関してどう振る舞うかで現在の実装が大いに異なるとき。
If the default for both the verifications above are enabled, then, by transitive property, the implementation will also be verifying that the peer source IP address matches via a bitwise comparison the contents of the iPAddress field in the SubjectAltName extension in the certificate. In addition, implementations MAY allow administrators to configure a local policy that explicitly requires that the peer source IP address match via a bitwise comparison the contents of the iPAddress field in the SubjectAltName extension in
両方のためのデフォルトであるなら、上の検証は可能にされます、次に、遷移的な特性で、また、実装がaを通した同輩ソースIPアドレス一致がiPAddressの内容が証明書におけるSubjectAltName拡張子でさばく比較をbitwiseすることを確かめるでしょう。 さらに、実装で、管理者はaを通した同輩ソースIPアドレス一致がiPAddressの内容が中でSubjectAltName拡張子でさばく比較をbitwiseするのを明らかに必要とするローカルの方針を構成できるかもしれません。
Korver Standards Track [Page 8] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[8ページ]
the certificate. Implementations SHOULD allow administrators to configure a local policy that skips this validation check.
証明書。 実装SHOULDは管理者にこの合法化チェックをサボるローカルの方針を構成させます。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration.
実装はSPDの方針を調べるためにサブストリング、ワイルドカード、または正規表現にIDのコンテンツのマッチングをサポートするかもしれません、そして、地方の安全保障政策構成の問題はそのようなものでしょう。
Implementations MAY use the IP address found in the header of packets received from the peer to look up the policy, but such implementations MUST still perform verification of the ID payload. Although packet IP addresses are inherently untrustworthy and must therefore be independently verified, it is often useful to use the apparent IP address of the peer to locate a general class of policies that will be used until the mandatory identity-based policy lookup can be performed.
実装は方針を調べるために同輩から受け取られたパケットのヘッダーで見つけられたIPアドレスを使用するかもしれませんが、そのような実装はまだIDペイロードの検証を実行しなければなりません。 パケットIPアドレスについて本来信頼できなく、したがって、独自に確かめなければなりませんが、同輩は、見かけのIPアドレスを使用するために義務的なアイデンティティベースの方針ルックアップを実行できるまで使用される一般的なクラスの方針の場所を見つけるとはしばしば役に立ちます。
For instance, if the IP address of the peer is unrecognized, a VPN gateway device might load a general "road warrior" policy that specifies a particular Certification Authority (CA) that is trusted to issue certificates that contain a valid rfc822Name, which can be used by that implementation to perform authorization based on access control lists (ACLs) after the peer's certificate has been validated. The rfc822Name can then be used to determine the policy that provides specific authorization to access resources (such as IP addresses, ports, and so forth).
例えば、同輩のIPアドレスが認識されていないなら、VPNゲートウェイデバイスはその実装によって使用される、同輩の証明書が有効にされた後にアクセスコントロールリスト(ACLs)に基づく承認を実行できる有効なrfc822Nameを含む問題証明書に任せられる特定の認証局(カリフォルニア)を指定する一般的な「道行く戦士」方針をロードするかもしれません。 そして、特定の承認を提供する方針がリソース(IPアドレス、ポートなどなどの)にアクセスすることを決定するのにrfc822Nameを使用できます。
As another example, if the IP address of the peer is recognized to be a known peer VPN endpoint, policy may be determined using that address, but until the identity (address) is validated by validating the peer certificate, the policy MUST NOT be used to authorize any IPsec traffic.
別の例として、同輩のIPアドレスが知られている同輩VPN終点になるように認識されるなら、方針はそのアドレスを使用することで決定しているかもしれませんが、アイデンティティ(アドレス)が同輩証明書を有効にすることによって有効にされるまで、どんなIPsecトラフィックも認可するのに方針を使用してはいけません。
3.1.2. ID_FQDN
3.1.2. ID_FQDN
Implementations MUST support the ID_FQDN ID type, generally to support host-based access control lists for hosts without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
実装は、IDが一般に、FQDN IDがホストのために固定IPアドレスなしでホストベースのアクセスコントロールリストをサポートするためにタイプする_であるとサポートしなければなりません。 しかしながら、実装SHOULD NOTはどんな政策決定への入力のためのIPアドレスにもFQDNを写像するのにDNSを使用します、DNSSEC[11]がそのFQDNに使われたなら例えば、そのマッピングが安全であることが知られない場合。
If ID contains an ID_FQDN, implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the dNSName field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the dNSName field in the SubjectAltName extension
IDがID_FQDNを含んでいるなら、実装は、アイデンティティがIDペイロードマッチに同輩終わり実体証明書に含まれたアイデンティティ情報を含んだことを確かめることができなければなりません、SubjectAltName拡張子におけるdNSName分野で。 実装はデフォルトでこの検証を実行しなければなりません。 SubjectAltName拡張子におけるdNSName分野があるIDのコンテンツを突き合わせたいつ
Korver Standards Track [Page 9] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[9ページ]
for equality, case-insensitive string comparison MUST be performed. Note that case-insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip- validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
平等において、大文字と小文字を区別しないストリング比較を実行しなければなりません。 大文字と小文字を区別しないストリング比較がまた、国際化ドメイン名(IDNs)に働くことに注意してください。(IDN[12])を見てください。 この比較のためにサブストリング、ワイルドカード、または正規表現マッチングを実行してはいけません。 このデフォルトが可能にされるなら、誤りとしてミスマッチを扱わなければなりません、そして、セキュリティ協会セットアップを中止しなければなりません。 このイベントSHOULD、監査可能であってください。 実装はその検証ステップをサボる(すなわち、構成が可能にすることができるローカルの方針)ために設定オプションを提供するかもしれませんが、そのオプションはデフォルトで取り止めになっていなければなりません。 私たちは、より良い相互運用性を可能にするために「オプションからスキップ合法化」を入れます、それらがこの話題に関してどう振る舞うかで現在の実装が大いに異なるとき。
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up the policy in the SPD, and such would be a matter of local security policy configuration.
実装はSPDの方針を調べるためにサブストリング、ワイルドカード、または正規表現にIDのコンテンツのマッチングをサポートするかもしれません、そして、地方の安全保障政策構成の問題はそのようなものでしょう。
3.1.3. ID_USER_FQDN
3.1.3. _IDユーザ_FQDN
Implementations MUST support the ID_USER_FQDN ID type, generally to support user-based access control lists for users without fixed IP addresses. However, implementations SHOULD NOT use the DNS to map the FQDN portion to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example, if DNSSEC [11] were employed for that FQDN.
実装は、IDが一般に、USER_FQDN IDがユーザのために固定IPアドレスなしでユーザベースのアクセスコントロールリストをサポートするためにタイプする_であるとサポートしなければなりません。 しかしながら、実装SHOULD NOTはどんな政策決定への入力のためのIPアドレスにもFQDN部分を写像するのにDNSを使用します、DNSSEC[11]がそのFQDNに使われたなら例えば、そのマッピングが安全であることが知られない場合。
Implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the rfc822Name field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the rfc822Name field in the SubjectAltName extension for equality, case- insensitive string comparison MUST be performed. Note that case- insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
Implementations MUST be capable of verifying that the identity contained in the ID payload matches identity information contained in the peer end-entity certificate, in the rfc822Name field in the SubjectAltName extension. Implementations MUST perform this verification by default. When comparing the contents of ID with the rfc822Name field in the SubjectAltName extension for equality, case- insensitive string comparison MUST be performed. Note that case- insensitive string comparison works on internationalized domain names (IDNs) as well (See IDN [12]). Substring, wildcard, or regular expression matching MUST NOT be performed for this comparison. If this default is enabled, then a mismatch MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable. Implementations MAY provide a configuration option to (i.e., local policy configuration can enable) skip that verification step, but that option MUST be off by default. We include the "option-to-skip-validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.
Korver Standards Track [Page 10] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 10] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up policy in the SPD, and such would be a matter of local security policy configuration.
Implementations MAY support substring, wildcard, or regular expression matching of the contents of ID to look up policy in the SPD, and such would be a matter of local security policy configuration.
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE,
ID_IPV6_ADDR_RANGE
3.1.4. ID_IPV4_ADDR_SUBNET, ID_IPV6_ADDR_SUBNET, ID_IPV4_ADDR_RANGE, ID_IPV6_ADDR_RANGE
Note that RFC 3779 [13] defines blocks of addresses using the certificate extension identified by:
Note that RFC 3779 [13] defines blocks of addresses using the certificate extension identified by:
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
id-pe-ipAddrBlock OBJECT IDENTIFIER ::= { id-pe 7 }
although use of this extension in IKE is considered experimental at this time.
although use of this extension in IKE is considered experimental at this time.
3.1.5. ID_DER_ASN1_DN
3.1.5. ID_DER_ASN1_DN
Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MUST be capable of generating this type, and the decision to do so will be a matter of local security policy configuration. When generating this type, implementations MUST populate the contents of ID with the Subject field from the end- entity certificate, and MUST do so such that a binary comparison of the two will succeed. If there is not a match, this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
Implementations MUST support receiving the ID_DER_ASN1_DN ID type. Implementations MUST be capable of generating this type, and the decision to do so will be a matter of local security policy configuration. When generating this type, implementations MUST populate the contents of ID with the Subject field from the end- entity certificate, and MUST do so such that a binary comparison of the two will succeed. If there is not a match, this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
Implementations MUST NOT populate ID with the Subject from the end- entity certificate if it is empty, even though an empty certificate Subject is explicitly allowed in the "Subject" section of the PKIX certificate profile.
Implementations MUST NOT populate ID with the Subject from the end- entity certificate if it is empty, even though an empty certificate Subject is explicitly allowed in the "Subject" section of the PKIX certificate profile.
Regarding SPD matching, implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experience has shown that using the entire DN in local configuration is difficult, especially in large-scale deployments. Therefore, implementations also MUST be able to perform SPD matches of any combination of one or more of the C, CN, O, OU attributes within Subject DN in the ID to the same in the SPD. Implementations MAY support matching using additional DN attributes in any combination, although interoperability is far from certain and is dubious. Implementations MAY also support performing substring, wildcard, or regular expression matches for any of its supported DN attributes from ID, in any combination, to the SPD. Such flexibility allows deployers to create one SPD entry on the gateway for an entire department of a company (e.g., O=Foobar Inc., OU=Engineering) while still allowing them to draw out other details
Regarding SPD matching, implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experience has shown that using the entire DN in local configuration is difficult, especially in large-scale deployments. Therefore, implementations also MUST be able to perform SPD matches of any combination of one or more of the C, CN, O, OU attributes within Subject DN in the ID to the same in the SPD. Implementations MAY support matching using additional DN attributes in any combination, although interoperability is far from certain and is dubious. Implementations MAY also support performing substring, wildcard, or regular expression matches for any of its supported DN attributes from ID, in any combination, to the SPD. Such flexibility allows deployers to create one SPD entry on the gateway for an entire department of a company (e.g., O=Foobar Inc., OU=Engineering) while still allowing them to draw out other details
Korver Standards Track [Page 11] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 11] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
from the DN (e.g., CN=John Doe) for auditing purposes. All the above is a matter of local implementation and local policy definition and enforcement capability, not bits on the wire, but will have a great impact on interoperability.
from the DN (e.g., CN=John Doe) for auditing purposes. All the above is a matter of local implementation and local policy definition and enforcement capability, not bits on the wire, but will have a great impact on interoperability.
3.1.6. ID_DER_ASN1_GN
3.1.6. ID_DER_ASN1_GN
Implementations MUST NOT generate this type, because the recipient will be unlikely to know how to use it.
Implementations MUST NOT generate this type, because the recipient will be unlikely to know how to use it.
3.1.7. ID_KEY_ID
3.1.7. ID_KEY_ID
The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope.
The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope.
3.1.8. Selecting an Identity from a Certificate
3.1.8. Selecting an Identity from a Certificate
Implementations MUST support certificates that contain more than a single identity, such as when the Subject field and the SubjectAltName extension are both populated, or the SubjectAltName extension contains multiple identities irrespective of whether or not the Subject is empty. In many cases, a certificate will contain an identity, such as an IP address, in the SubjectAltName extension in addition to a non-empty Subject.
Implementations MUST support certificates that contain more than a single identity, such as when the Subject field and the SubjectAltName extension are both populated, or the SubjectAltName extension contains multiple identities irrespective of whether or not the Subject is empty. In many cases, a certificate will contain an identity, such as an IP address, in the SubjectAltName extension in addition to a non-empty Subject.
Implementations should populate ID with whichever identity is likely to be named in the peer's policy. In practice, this generally means FQDN, or USER_FQDN, but this information may also be available to the administrator through some out-of-band means. In the absence of such out-of-band configuration information, the identity with which an implementation chooses to populate the ID payload is a local matter.
Implementations should populate ID with whichever identity is likely to be named in the peer's policy. In practice, this generally means FQDN, or USER_FQDN, but this information may also be available to the administrator through some out-of-band means. In the absence of such out-of-band configuration information, the identity with which an implementation chooses to populate the ID payload is a local matter.
3.1.9. Subject for DN Only
3.1.9. Subject for DN Only
If an FQDN is intended to be processed as an identity for the purposes of ID matching, it MUST be placed in the dNSName field of the SubjectAltName extension. Implementations MUST NOT populate the Subject with an FQDN in place of populating the dNSName field of the SubjectAltName extension.
If an FQDN is intended to be processed as an identity for the purposes of ID matching, it MUST be placed in the dNSName field of the SubjectAltName extension. Implementations MUST NOT populate the Subject with an FQDN in place of populating the dNSName field of the SubjectAltName extension.
While nothing prevents an FQDN, USER_FQDN, or IP address information from appearing somewhere in the Subject contents, such entries MUST NOT be interpreted as identity information for the purposes of matching with ID or for policy lookup.
While nothing prevents an FQDN, USER_FQDN, or IP address information from appearing somewhere in the Subject contents, such entries MUST NOT be interpreted as identity information for the purposes of matching with ID or for policy lookup.
Korver Standards Track [Page 12] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 12] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
3.1.10. Binding Identity to Policy
3.1.10. Binding Identity to Policy
In the presence of certificates that contain multiple identities, implementations should select the most appropriate identity from the certificate and populate the ID with that. The recipient MUST use the identity sent as a first key when selecting the policy. The recipient MUST also use the most specific policy from that database if there are overlapping policies caused by wildcards (or the implementation can de-correlate the policy database so there will not be overlapping entries, or it can also forbid creation of overlapping policies and leave the de-correlation process to the administrator, but, as this moves the problem to the administrator, it is NOT RECOMMENDED).
In the presence of certificates that contain multiple identities, implementations should select the most appropriate identity from the certificate and populate the ID with that. The recipient MUST use the identity sent as a first key when selecting the policy. The recipient MUST also use the most specific policy from that database if there are overlapping policies caused by wildcards (or the implementation can de-correlate the policy database so there will not be overlapping entries, or it can also forbid creation of overlapping policies and leave the de-correlation process to the administrator, but, as this moves the problem to the administrator, it is NOT RECOMMENDED).
For example, imagine that an implementation is configured with a certificate that contains both a non-empty Subject and a dNSName. The sender's policy may specify which of those to use, and it indicates the policy to the other end by sending that ID. If the recipient has both a specific policy for the dNSName for this host and generic wildcard rule for some attributes present in the Subject field, it will match a different policy depending on which ID is sent. As the sender knows why it wanted to connect the peer, it also knows what identity it should use to match the policy it needs to the operation it tries to perform; it is the only party who can select the ID adequately.
For example, imagine that an implementation is configured with a certificate that contains both a non-empty Subject and a dNSName. The sender's policy may specify which of those to use, and it indicates the policy to the other end by sending that ID. If the recipient has both a specific policy for the dNSName for this host and generic wildcard rule for some attributes present in the Subject field, it will match a different policy depending on which ID is sent. As the sender knows why it wanted to connect the peer, it also knows what identity it should use to match the policy it needs to the operation it tries to perform; it is the only party who can select the ID adequately.
In the event that the policy cannot be found in the recipient's SPD using the ID sent, then the recipient MAY use the other identities in the certificate when attempting to match a suitable policy. For example, say the certificate contains a non-empty Subject field, a dNSName and an iPAddress. If an iPAddress is sent in ID but no specific entry exists for the address in the policy database, the recipient MAY search in the policy database based on the Subject or the dNSName contained in the certificate.
In the event that the policy cannot be found in the recipient's SPD using the ID sent, then the recipient MAY use the other identities in the certificate when attempting to match a suitable policy. For example, say the certificate contains a non-empty Subject field, a dNSName and an iPAddress. If an iPAddress is sent in ID but no specific entry exists for the address in the policy database, the recipient MAY search in the policy database based on the Subject or the dNSName contained in the certificate.
3.2. Certificate Request Payload
3.2. Certificate Request Payload
The Certificate Request (CERTREQ) Payload allows an implementation to request that a peer provide some set of certificates or certificate revocation lists (CRLs). It is not clear from ISAKMP exactly how that set should be specified or how the peer should respond. We describe the semantics on both sides.
The Certificate Request (CERTREQ) Payload allows an implementation to request that a peer provide some set of certificates or certificate revocation lists (CRLs). It is not clear from ISAKMP exactly how that set should be specified or how the peer should respond. We describe the semantics on both sides.
Korver Standards Track [Page 13] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 13] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
3.2.1. Certificate Type
3.2.1. Certificate Type
The Certificate Type field identifies to the peer the type of certificate keying materials that are desired. ISAKMP defines 10 types of Certificate Data that can be requested and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
The Certificate Type field identifies to the peer the type of certificate keying materials that are desired. ISAKMP defines 10 types of Certificate Data that can be requested and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
o X.509 Certificate - Signature
o Revocation Lists (CRL and ARL)
o PKCS #7 wrapped X.509 certificate
o X.509 Certificate - Signature o Revocation Lists (CRL and ARL) o PKCS #7 wrapped X.509 certificate
The use of the other types are out of the scope of this document:
The use of the other types are out of the scope of this document:
o X.509 Certificate - Key Exchange
o PGP (Pretty Good Privacy) Certificate
o DNS Signed Key
o Kerberos Tokens
o SPKI (Simple Public Key Infrastructure) Certificate
o X.509 Certificate Attribute
o X.509 Certificate - Key Exchange o PGP (Pretty Good Privacy) Certificate o DNS Signed Key o Kerberos Tokens o SPKI (Simple Public Key Infrastructure) Certificate o X.509 Certificate Attribute
3.2.2. X.509 Certificate - Signature
3.2.2. X.509 Certificate - Signature
This type requests that the end-entity certificate be a certificate used for signing.
This type requests that the end-entity certificate be a certificate used for signing.
3.2.3. Revocation Lists (CRL and ARL)
3.2.3. Revocation Lists (CRL and ARL)
ISAKMP does not support Certificate Payload sizes over approximately 64K, which is too small for many CRLs, and UDP fragmentation is likely to occur at sizes much smaller than that. Therefore, the acquisition of revocation material is to be dealt with out-of-band of IKE. For this and other reasons, implementations SHOULD NOT generate CERTREQs where the Certificate Type is "Certificate Revocation List (CRL)" or "Authority Revocation List (ARL)". Implementations that do generate such CERTREQs MUST NOT require the recipient to respond with a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt of such a CERTREQ, implementations MAY ignore the request.
ISAKMP does not support Certificate Payload sizes over approximately 64K, which is too small for many CRLs, and UDP fragmentation is likely to occur at sizes much smaller than that. Therefore, the acquisition of revocation material is to be dealt with out-of-band of IKE. For this and other reasons, implementations SHOULD NOT generate CERTREQs where the Certificate Type is "Certificate Revocation List (CRL)" or "Authority Revocation List (ARL)". Implementations that do generate such CERTREQs MUST NOT require the recipient to respond with a CRL or ARL, and MUST NOT fail when not receiving any. Upon receipt of such a CERTREQ, implementations MAY ignore the request.
In lieu of exchanging revocation lists in-band, a pointer to revocation checking SHOULD be listed in either the CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) certificate extensions (see Section 5 for details). Unless other methods for obtaining revocation information are available, implementations SHOULD be able to process these attributes, and from them be able to identify cached revocation material, or retrieve the relevant revocation material from a URL, for validation processing. In addition, implementations MUST have the ability to configure
In lieu of exchanging revocation lists in-band, a pointer to revocation checking SHOULD be listed in either the CRLDistributionPoints (CDP) or the AuthorityInfoAccess (AIA) certificate extensions (see Section 5 for details). Unless other methods for obtaining revocation information are available, implementations SHOULD be able to process these attributes, and from them be able to identify cached revocation material, or retrieve the relevant revocation material from a URL, for validation processing. In addition, implementations MUST have the ability to configure
Korver Standards Track [Page 14] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 14] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
validation checking information for each certification authority. Regardless of the method (CDP, AIA, or static configuration), the acquisition of revocation material SHOULD occur out-of-band of IKE. Note, however, that an inability to access revocation status data through out-of-band means provides a potential security vulnerability that could potentially be exploited by an attacker.
validation checking information for each certification authority. Regardless of the method (CDP, AIA, or static configuration), the acquisition of revocation material SHOULD occur out-of-band of IKE. Note, however, that an inability to access revocation status data through out-of-band means provides a potential security vulnerability that could potentially be exploited by an attacker.
3.2.4. PKCS #7 wrapped X.509 certificate
3.2.4. PKCS #7 wrapped X.509 certificate
This ID type defines a particular encoding (not a particular certificate type); some current implementations may ignore CERTREQs they receive that contain this ID type, and the editors are unaware of any implementations that generate such CERTREQ messages. Therefore, the use of this type is deprecated. Implementations SHOULD NOT require CERTREQs that contain this Certificate Type. Implementations that receive CERTREQs that contain this ID type MAY treat such payloads as synonymous with "X.509 Certificate - Signature".
This ID type defines a particular encoding (not a particular certificate type); some current implementations may ignore CERTREQs they receive that contain this ID type, and the editors are unaware of any implementations that generate such CERTREQ messages. Therefore, the use of this type is deprecated. Implementations SHOULD NOT require CERTREQs that contain this Certificate Type. Implementations that receive CERTREQs that contain this ID type MAY treat such payloads as synonymous with "X.509 Certificate - Signature".
3.2.5. Location of Certificate Request Payloads
3.2.5. Location of Certificate Request Payloads
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5.
In IKEv1 Main Mode, the CERTREQ payload MUST be in messages 4 and 5.
3.2.6. Presence or Absence of Certificate Request Payloads
3.2.6. Presence or Absence of Certificate Request Payloads
When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. In other words, an implementation that does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads.
When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. In other words, an implementation that does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads.
3.2.7. Certificate Requests
3.2.7. Certificate Requests
3.2.7.1. Specifying Certification Authorities
3.2.7.1. Specifying Certification Authorities
When requesting in-band exchange of keying materials, implementations SHOULD generate CERTREQs for every peer trust anchor that local policy explicitly deems trusted during a given exchange. Implementations SHOULD populate the Certification Authority field with the Subject field of the trust anchor, populated such that binary comparison of the Subject and the Certification Authority will succeed.
When requesting in-band exchange of keying materials, implementations SHOULD generate CERTREQs for every peer trust anchor that local policy explicitly deems trusted during a given exchange. Implementations SHOULD populate the Certification Authority field with the Subject field of the trust anchor, populated such that binary comparison of the Subject and the Certification Authority will succeed.
Korver Standards Track [Page 15] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 15] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Upon receipt of a CERTREQ, implementations MUST respond by sending at least the end-entity certificate corresponding to the Certification Authority listed in the CERTREQ unless local security policy configuration specifies that keying materials must be exchanged out- of-band. Implementations MAY send certificates other than the end- entity certificate (see Section 3.3 for discussion).
Upon receipt of a CERTREQ, implementations MUST respond by sending at least the end-entity certificate corresponding to the Certification Authority listed in the CERTREQ unless local security policy configuration specifies that keying materials must be exchanged out- of-band. Implementations MAY send certificates other than the end- entity certificate (see Section 3.3 for discussion).
Note that, in the case where multiple end-entity certificates may be available that chain to different trust anchors, implementations SHOULD resort to local heuristics to determine which trust anchor is most appropriate to use for generating the CERTREQ. Such heuristics are out of the scope of this document.
Note that, in the case where multiple end-entity certificates may be available that chain to different trust anchors, implementations SHOULD resort to local heuristics to determine which trust anchor is most appropriate to use for generating the CERTREQ. Such heuristics are out of the scope of this document.
3.2.7.2. Empty Certification Authority Field
3.2.7.2. Empty Certification Authority Field
Implementations SHOULD generate CERTREQs where the Certificate Type is "X.509 Certificate - Signature" and where the Certification Authority field is not empty. However, implementations MAY generate CERTREQs with an empty Certification Authority field under special conditions. Although PKIX prohibits certificates with an empty Issuer field, there does exist a use case where doing so is appropriate, and carries special meaning in the IKE context. This has become a convention within the IKE interoperability tests and usage space, and so its use is specified, explained here for the sake of interoperability.
Implementations SHOULD generate CERTREQs where the Certificate Type is "X.509 Certificate - Signature" and where the Certification Authority field is not empty. However, implementations MAY generate CERTREQs with an empty Certification Authority field under special conditions. Although PKIX prohibits certificates with an empty Issuer field, there does exist a use case where doing so is appropriate, and carries special meaning in the IKE context. This has become a convention within the IKE interoperability tests and usage space, and so its use is specified, explained here for the sake of interoperability.
USE CASE: Consider the rare case where you have a gateway with multiple policies for a large number of IKE peers: some of these peers are business partners, some are remote-access employees, some are teleworkers, some are branch offices, and/or the gateway may be simultaneously serving many customers (e.g., Virtual Routers). The total number of certificates, and corresponding trust anchors, is very high -- say, hundreds. Each of these policies is configured with one or more acceptable trust anchors, so that in total, the gateway has one hundred (100) trust anchors that could possibly used to authenticate an incoming connection. Assume that many of those connections originate from hosts/gateways with dynamically assigned IP addresses, so that the source IP of the IKE initiator is not known to the gateway, nor is the identity of the initiator (until it is revealed in Main Mode message 5). In IKE main mode message 4, the responder gateway will need to send a CERTREQ to the initiator. Given this example, the gateway will have no idea which of the hundred possible Certification Authorities to send in the CERTREQ. Sending all possible Certification Authorities will cause significant processing delays, bandwidth consumption, and UDP fragmentation, so this tactic is ruled out.
USE CASE: Consider the rare case where you have a gateway with multiple policies for a large number of IKE peers: some of these peers are business partners, some are remote-access employees, some are teleworkers, some are branch offices, and/or the gateway may be simultaneously serving many customers (e.g., Virtual Routers). The total number of certificates, and corresponding trust anchors, is very high -- say, hundreds. Each of these policies is configured with one or more acceptable trust anchors, so that in total, the gateway has one hundred (100) trust anchors that could possibly used to authenticate an incoming connection. Assume that many of those connections originate from hosts/gateways with dynamically assigned IP addresses, so that the source IP of the IKE initiator is not known to the gateway, nor is the identity of the initiator (until it is revealed in Main Mode message 5). In IKE main mode message 4, the responder gateway will need to send a CERTREQ to the initiator. Given this example, the gateway will have no idea which of the hundred possible Certification Authorities to send in the CERTREQ. Sending all possible Certification Authorities will cause significant processing delays, bandwidth consumption, and UDP fragmentation, so this tactic is ruled out.
Korver Standards Track [Page 16] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 16] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
In such a deployment, the responder gateway implementation should be able to do all it can to indicate a Certification Authority in the CERTREQ. This means the responder SHOULD first check SPD to see if it can match the source IP, and find some indication of which CA is associated with that IP. If this fails (because the source IP is not familiar, as in the case above), then the responder SHOULD have a configuration option specifying which CAs are the default CAs to indicate in CERTREQ during such ambiguous connections (e.g., send CERTREQ with these N CAs if there is an unknown source IP). If such a fall-back is not configured or impractical in a certain deployment scenario, then the responder implementation SHOULD have both of the following configuration options:
In such a deployment, the responder gateway implementation should be able to do all it can to indicate a Certification Authority in the CERTREQ. This means the responder SHOULD first check SPD to see if it can match the source IP, and find some indication of which CA is associated with that IP. If this fails (because the source IP is not familiar, as in the case above), then the responder SHOULD have a configuration option specifying which CAs are the default CAs to indicate in CERTREQ during such ambiguous connections (e.g., send CERTREQ with these N CAs if there is an unknown source IP). If such a fall-back is not configured or impractical in a certain deployment scenario, then the responder implementation SHOULD have both of the following configuration options:
o send a CERTREQ payload with an empty Certification Authority
field, or
o send a CERTREQ payload with an empty Certification Authority field, or
o terminate the negotiation with an appropriate error message and
audit log entry.
o terminate the negotiation with an appropriate error message and audit log entry.
Receiving a CERTREQ payload with an empty Certification Authority field indicates that the recipient should send all/any end-entity certificates it has, regardless of the trust anchor. The initiator should be aware of what policy and which identity it will use, as it initiated the connection on a matched policy to begin with, and can thus respond with the appropriate certificate.
Receiving a CERTREQ payload with an empty Certification Authority field indicates that the recipient should send all/any end-entity certificates it has, regardless of the trust anchor. The initiator should be aware of what policy and which identity it will use, as it initiated the connection on a matched policy to begin with, and can thus respond with the appropriate certificate.
If, after sending an empty CERTREQ in Main Mode message 4, a responder receives a certificate in message 5 that chains to a trust anchor that the responder either (a) does NOT support, or (b) was not configured for the policy (that policy was now able to be matched due to having the initiator's certificate present), this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
If, after sending an empty CERTREQ in Main Mode message 4, a responder receives a certificate in message 5 that chains to a trust anchor that the responder either (a) does NOT support, or (b) was not configured for the policy (that policy was now able to be matched due to having the initiator's certificate present), this MUST be treated as an error, and security association setup MUST be aborted. This event SHOULD be auditable.
Instead of sending an empty CERTREQ, the responder implementation MAY be configured to terminate the negotiation on the grounds of a conflict with locally configured security policy.
Instead of sending an empty CERTREQ, the responder implementation MAY be configured to terminate the negotiation on the grounds of a conflict with locally configured security policy.
The decision of which to configure is a matter of local security policy; this document RECOMMENDS that both options be presented to administrators.
The decision of which to configure is a matter of local security policy; this document RECOMMENDS that both options be presented to administrators.
More examples and explanation of this issue are included in "More on Empty CERTREQs" (Appendix B).
More examples and explanation of this issue are included in "More on Empty CERTREQs" (Appendix B).
Korver Standards Track [Page 17] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 17] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
3.2.8. Robustness
3.2.8. Robustness
3.2.8.1. Unrecognized or Unsupported Certificate Types
3.2.8.1. Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTREQs with unsupported Certificate Types. Absent any recognized and supported CERTREQ types, implementations MAY treat them as if they are of a supported type with the Certification Authority field left empty, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
Implementations MUST be able to deal with receiving CERTREQs with unsupported Certificate Types. Absent any recognized and supported CERTREQ types, implementations MAY treat them as if they are of a supported type with the Certification Authority field left empty, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
3.2.8.2. Undecodable Certification Authority Fields
3.2.8.2. Undecodable Certification Authority Fields
Implementations MUST be able to deal with receiving CERTREQs with undecodable Certification Authority fields. Implementations MAY ignore such payloads, depending on local policy. ISAKMP specifies other actions which may be taken.
Implementations MUST be able to deal with receiving CERTREQs with undecodable Certification Authority fields. Implementations MAY ignore such payloads, depending on local policy. ISAKMP specifies other actions which may be taken.
3.2.8.3. Ordering of Certificate Request Payloads
3.2.8.3. Ordering of Certificate Request Payloads
Implementations MUST NOT assume that CERTREQs are ordered in any way.
Implementations MUST NOT assume that CERTREQs are ordered in any way.
3.2.9. Optimizations
3.2.9. Optimizations
3.2.9.1. Duplicate Certificate Request Payloads
3.2.9.1. Duplicate Certificate Request Payloads
Implementations SHOULD NOT send duplicate CERTREQs during an exchange.
Implementations SHOULD NOT send duplicate CERTREQs during an exchange.
3.2.9.2. Name Lowest 'Common' Certification Authorities
3.2.9.2. Name Lowest 'Common' Certification Authorities
When a peer's certificate keying material has been cached, an implementation can send a hint to the peer to elide some of the certificates the peer would normally include in the response. In addition to the normal set of CERTREQs that are sent specifying the trust anchors, an implementation MAY send CERTREQs specifying the relevant cached end-entity certificates. When sending these hints, it is still necessary to send the normal set of trust anchor CERTREQs because the hints do not sufficiently convey all of the information required by the peer. Specifically, either the peer may not support this optimization or there may be additional chains that could be used in this context but will not be if only the end-entity certificate is specified.
When a peer's certificate keying material has been cached, an implementation can send a hint to the peer to elide some of the certificates the peer would normally include in the response. In addition to the normal set of CERTREQs that are sent specifying the trust anchors, an implementation MAY send CERTREQs specifying the relevant cached end-entity certificates. When sending these hints, it is still necessary to send the normal set of trust anchor CERTREQs because the hints do not sufficiently convey all of the information required by the peer. Specifically, either the peer may not support this optimization or there may be additional chains that could be used in this context but will not be if only the end-entity certificate is specified.
No special processing is required on the part of the recipient of such a CERTREQ, and the end-entity certificates will still be sent. On the other hand, the recipient MAY elect to elide certificates based on receipt of such hints.
No special processing is required on the part of the recipient of such a CERTREQ, and the end-entity certificates will still be sent. On the other hand, the recipient MAY elect to elide certificates based on receipt of such hints.
Korver Standards Track [Page 18] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 18] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
CERTREQs must contain information that identifies a Certification Authority certificate, which results in the peer always sending at least the end-entity certificate. Always sending the end-entity certificate allows implementations to determine unambiguously when a new certificate is being used by a peer (perhaps because the previous certificate has just expired), which may result in a failure because a new intermediate CA certificate might not be available to validate the new end-entity certificate). Implementations that implement this optimization MUST recognize when the end-entity certificate has changed and respond to it by not performing this optimization if the exchange must be retried so that any missing keying materials will be sent during retry.
CERTREQs must contain information that identifies a Certification Authority certificate, which results in the peer always sending at least the end-entity certificate. Always sending the end-entity certificate allows implementations to determine unambiguously when a new certificate is being used by a peer (perhaps because the previous certificate has just expired), which may result in a failure because a new intermediate CA certificate might not be available to validate the new end-entity certificate). Implementations that implement this optimization MUST recognize when the end-entity certificate has changed and respond to it by not performing this optimization if the exchange must be retried so that any missing keying materials will be sent during retry.
3.2.9.3. Example
3.2.9.3. Example
Imagine that an IKEv1 implementation has previously received and cached the peer certificate chain TA->CA1->CA2->EE. If, during a subsequent exchange, this implementation sends a CERTREQ containing the Subject field in certificate TA, this implementation is requesting that the peer send at least three certificates: CA1, CA2, and EE. On the other hand, if this implementation also sends a CERTREQ containing the Subject field of CA2, the implementation is providing a hint that only one certificate needs to be sent: EE. Note that in this example, the fact that TA is a trust anchor should not be construed to imply that TA is a self-signed certificate.
Imagine that an IKEv1 implementation has previously received and cached the peer certificate chain TA->CA1->CA2->EE. If, during a subsequent exchange, this implementation sends a CERTREQ containing the Subject field in certificate TA, this implementation is requesting that the peer send at least three certificates: CA1, CA2, and EE. On the other hand, if this implementation also sends a CERTREQ containing the Subject field of CA2, the implementation is providing a hint that only one certificate needs to be sent: EE. Note that in this example, the fact that TA is a trust anchor should not be construed to imply that TA is a self-signed certificate.
3.3. Certificate Payload
3.3. Certificate Payload
The Certificate (CERT) Payload allows the peer to transmit a single certificate or CRL. Multiple certificates should be transmitted in multiple payloads. For backwards-compatibility reasons, implementations MAY send intermediate CA certificates in addition to the appropriate end-entity certificate(s), but SHOULD NOT send any CRLs, ARLs, or trust anchors. Exchanging trust anchors and especially CRLs and ARLs in IKE would increase the likelihood of UDP fragmentation, make the IKE exchange more complex, and consume additional network bandwidth.
The Certificate (CERT) Payload allows the peer to transmit a single certificate or CRL. Multiple certificates should be transmitted in multiple payloads. For backwards-compatibility reasons, implementations MAY send intermediate CA certificates in addition to the appropriate end-entity certificate(s), but SHOULD NOT send any CRLs, ARLs, or trust anchors. Exchanging trust anchors and especially CRLs and ARLs in IKE would increase the likelihood of UDP fragmentation, make the IKE exchange more complex, and consume additional network bandwidth.
Note, however, that while the sender of the CERT payloads SHOULD NOT send any certificates it considers trust anchors, it's possible that the recipient may consider any given intermediate CA certificate to be a trust anchor. For instance, imagine the sender has the certificate chain TA1->CA1->EE1 while the recipient has the certificate chain TA2->EE2 where TA2=CA1. The sender is merely including an intermediate CA certificate, while the recipient receives a trust anchor.
Note, however, that while the sender of the CERT payloads SHOULD NOT send any certificates it considers trust anchors, it's possible that the recipient may consider any given intermediate CA certificate to be a trust anchor. For instance, imagine the sender has the certificate chain TA1->CA1->EE1 while the recipient has the certificate chain TA2->EE2 where TA2=CA1. The sender is merely including an intermediate CA certificate, while the recipient receives a trust anchor.
Korver Standards Track [Page 19] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 19] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
However, not all certificate forms that are legal in the PKIX certificate profile make sense in the context of IPsec. The issue of how to represent IKE-meaningful name-forms in a certificate is especially problematic. This document provides a profile for a subset of the PKIX certificate profile that makes sense for IKEv1/ ISAKMP.
However, not all certificate forms that are legal in the PKIX certificate profile make sense in the context of IPsec. The issue of how to represent IKE-meaningful name-forms in a certificate is especially problematic. This document provides a profile for a subset of the PKIX certificate profile that makes sense for IKEv1/ ISAKMP.
3.3.1. Certificate Type
3.3.1. Certificate Type
The Certificate Type field identifies to the peer the type of certificate keying materials that are included. ISAKMP defines 10 types of Certificate Data that can be sent and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
The Certificate Type field identifies to the peer the type of certificate keying materials that are included. ISAKMP defines 10 types of Certificate Data that can be sent and specifies the syntax for these types. For the purposes of this document, only the following types are relevant:
o X.509 Certificate - Signature
o Revocation Lists (CRL and ARL)
o PKCS #7 wrapped X.509 certificate
o X.509 Certificate - Signature o Revocation Lists (CRL and ARL) o PKCS #7 wrapped X.509 certificate
The use of the other types are out of the scope of this document:
The use of the other types are out of the scope of this document:
o X.509 Certificate - Key Exchange
o PGP Certificate
o DNS Signed Key
o Kerberos Tokens
o SPKI Certificate
o X.509 Certificate Attribute
o X.509 Certificate - Key Exchange o PGP Certificate o DNS Signed Key o Kerberos Tokens o SPKI Certificate o X.509 Certificate Attribute
3.3.2. X.509 Certificate - Signature
3.3.2. X.509 Certificate - Signature
This type specifies that Certificate Data contains a certificate used for signing.
This type specifies that Certificate Data contains a certificate used for signing.
3.3.3. Revocation Lists (CRL and ARL)
3.3.3. Revocation Lists (CRL and ARL)
These types specify that Certificate Data contains an X.509 CRL or ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for discussion.
These types specify that Certificate Data contains an X.509 CRL or ARL. These types SHOULD NOT be sent in IKE. See Section 3.2.3 for discussion.
3.3.4. PKCS #7 Wrapped X.509 Certificate
3.3.4. PKCS #7 Wrapped X.509 Certificate
This type defines a particular encoding, not a particular certificate type. Implementations SHOULD NOT generate CERTs that contain this Certificate Type. Implementations SHOULD accept CERTs that contain this Certificate Type because several implementations are known to generate them. Note that those implementations sometimes include
This type defines a particular encoding, not a particular certificate type. Implementations SHOULD NOT generate CERTs that contain this Certificate Type. Implementations SHOULD accept CERTs that contain this Certificate Type because several implementations are known to generate them. Note that those implementations sometimes include
Korver Standards Track [Page 20] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 20] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
entire certificate hierarchies inside a single CERT PKCS #7 payload, which violates the requirement specified in ISAKMP that this payload contain a single certificate.
entire certificate hierarchies inside a single CERT PKCS #7 payload, which violates the requirement specified in ISAKMP that this payload contain a single certificate.
3.3.5. Location of Certificate Payloads
3.3.5. Location of Certificate Payloads
In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6.
In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6.
3.3.6. Certificate Payloads Not Mandatory
3.3.6. Certificate Payloads Not Mandatory
An implementation that does not receive any CERTREQs during an exchange SHOULD NOT send any CERT payloads, except when explicitly configured to proactively send CERT payloads in order to interoperate with non-compliant implementations that fail to send CERTREQs even when certificates are desired. In this case, an implementation MAY send the certificate chain (not including the trust anchor) associated with the end-entity certificate. This MUST NOT be the default behavior of implementations.
An implementation that does not receive any CERTREQs during an exchange SHOULD NOT send any CERT payloads, except when explicitly configured to proactively send CERT payloads in order to interoperate with non-compliant implementations that fail to send CERTREQs even when certificates are desired. In this case, an implementation MAY send the certificate chain (not including the trust anchor) associated with the end-entity certificate. This MUST NOT be the default behavior of implementations.
Implementations whose local security policy configuration expects that a peer must receive certificates through out-of-band means SHOULD ignore any CERTREQ messages that are received. Such a condition has been known to occur due to non-compliant or buggy implementations.
Implementations whose local security policy configuration expects that a peer must receive certificates through out-of-band means SHOULD ignore any CERTREQ messages that are received. Such a condition has been known to occur due to non-compliant or buggy implementations.
Implementations that receive CERTREQs from a peer that contain only unrecognized Certification Authorities MAY elect to terminate the exchange, in order to avoid unnecessary and potentially expensive cryptographic processing, denial-of-service (resource starvation) attacks.
Implementations that receive CERTREQs from a peer that contain only unrecognized Certification Authorities MAY elect to terminate the exchange, in order to avoid unnecessary and potentially expensive cryptographic processing, denial-of-service (resource starvation) attacks.
3.3.7. Response to Multiple Certification Authority Proposals
3.3.7. Response to Multiple Certification Authority Proposals
In response to multiple CERTREQs that contain different Certification Authority identities, implementations MAY respond using an end-entity certificate which chains to a CA that matches any of the identities provided by the peer.
In response to multiple CERTREQs that contain different Certification Authority identities, implementations MAY respond using an end-entity certificate which chains to a CA that matches any of the identities provided by the peer.
3.3.8. Using Local Keying Materials
3.3.8. Using Local Keying Materials
Implementations MAY elect to skip parsing or otherwise decoding a given set of CERTs if those same keying materials are available via some preferable means, such as the case where certificates from a previous exchange have been cached.
Implementations MAY elect to skip parsing or otherwise decoding a given set of CERTs if those same keying materials are available via some preferable means, such as the case where certificates from a previous exchange have been cached.
Korver Standards Track [Page 21] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 21] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
3.3.9. Multiple End-Entity Certificates
3.3.9. Multiple End-Entity Certificates
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
If multiple end-entity certificates are sent, they MUST have the same public key; otherwise, the responder does not know which key was used in the Main Mode message 5.
If multiple end-entity certificates are sent, they MUST have the same public key; otherwise, the responder does not know which key was used in the Main Mode message 5.
3.3.10. Robustness
3.3.10. Robustness
3.3.10.1. Unrecognized or Unsupported Certificate Types
3.3.10.1. Unrecognized or Unsupported Certificate Types
Implementations MUST be able to deal with receiving CERTs with unrecognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
Implementations MUST be able to deal with receiving CERTs with unrecognized or unsupported Certificate Types. Implementations MAY discard such payloads, depending on local policy. ISAKMP [2] Section 5.10, "Certificate Request Payload Processing", specifies additional processing.
3.3.10.2. Undecodable Certificate Data Fields
3.3.10.2. Undecodable Certificate Data Fields
Implementations MUST be able to deal with receiving CERTs with undecodable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions that may be taken.
Implementations MUST be able to deal with receiving CERTs with undecodable Certificate Data fields. Implementations MAY discard such payloads, depending on local policy. ISAKMP specifies other actions that may be taken.
3.3.10.3. Ordering of Certificate Payloads
3.3.10.3. Ordering of Certificate Payloads
Implementations MUST NOT assume that CERTs are ordered in any way.
Implementations MUST NOT assume that CERTs are ordered in any way.
3.3.10.4. Duplicate Certificate Payloads
3.3.10.4. Duplicate Certificate Payloads
Implementations MUST support receiving multiple identical CERTs during an exchange.
Implementations MUST support receiving multiple identical CERTs during an exchange.
3.3.10.5. Irrelevant Certificates
3.3.10.5. Irrelevant Certificates
Implementations MUST be prepared to receive certificates and CRLs that are not relevant to the current exchange. Implementations MAY discard such extraneous certificates and CRLs.
Implementations MUST be prepared to receive certificates and CRLs that are not relevant to the current exchange. Implementations MAY discard such extraneous certificates and CRLs.
Implementations MAY send certificates that are irrelevant to an exchange. One reason for including certificates that are irrelevant to an exchange is to minimize the threat of leaking identifying information in exchanges where CERT is not encrypted in IKEv1. It should be noted, however, that this probably provides rather poor protection against leaking the identity.
Implementations MAY send certificates that are irrelevant to an exchange. One reason for including certificates that are irrelevant to an exchange is to minimize the threat of leaking identifying information in exchanges where CERT is not encrypted in IKEv1. It should be noted, however, that this probably provides rather poor protection against leaking the identity.
Korver Standards Track [Page 22] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 22] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Another reason for including certificates that seem irrelevant to an exchange is that there may be two chains from the Certification Authority to the end entity, each of which is only valid with certain validation parameters (such as acceptable policies). Since the end- entity doesn't know which parameters the relying party is using, it should send the certificates needed for both chains (even if there's only one CERTREQ).
Another reason for including certificates that seem irrelevant to an exchange is that there may be two chains from the Certification Authority to the end entity, each of which is only valid with certain validation parameters (such as acceptable policies). Since the end- entity doesn't know which parameters the relying party is using, it should send the certificates needed for both chains (even if there's only one CERTREQ).
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
Implementations SHOULD NOT send multiple end-entity certificates and recipients SHOULD NOT be expected to iterate over multiple end-entity certificates.
3.3.11. Optimizations
3.3.11. Optimizations
3.3.11.1. Duplicate Certificate Payloads
3.3.11.1. Duplicate Certificate Payloads
Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed.
Implementations SHOULD NOT send duplicate CERTs during an exchange. Such payloads should be suppressed.
3.3.11.2. Send Lowest 'Common' Certificates
3.3.11.2. Send Lowest 'Common' Certificates
When multiple CERTREQs are received that specify certification authorities within the end-entity certificate chain, implementations MAY send the shortest chain possible. However, implementations SHOULD always send the end-entity certificate. See Section 3.2.9.2 for more discussion of this optimization.
When multiple CERTREQs are received that specify certification authorities within the end-entity certificate chain, implementations MAY send the shortest chain possible. However, implementations SHOULD always send the end-entity certificate. See Section 3.2.9.2 for more discussion of this optimization.
3.3.11.3. Ignore Duplicate Certificate Payloads
3.3.11.3. Ignore Duplicate Certificate Payloads
Implementations MAY employ local means to recognize CERTs that have already been received and SHOULD discard these duplicate CERTs.
Implementations MAY employ local means to recognize CERTs that have already been received and SHOULD discard these duplicate CERTs.
3.3.11.4. Hash Payload
3.3.11.4. Hash Payload
IKEv1 specifies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes. This pointer is used by an implementation to locate the end-entity certificate that contains the public key that a peer should use for encrypting payloads during the exchange.
IKEv1 specifies the optional use of the Hash Payload to carry a pointer to a certificate in either of the Phase 1 public key encryption modes. This pointer is used by an implementation to locate the end-entity certificate that contains the public key that a peer should use for encrypting payloads during the exchange.
Implementations SHOULD include this payload whenever the public portion of the keypair has been placed in a certificate.
Implementations SHOULD include this payload whenever the public portion of the keypair has been placed in a certificate.
Korver Standards Track [Page 23] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 23] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
4. Use of Certificates in RFC 4301 and IKEv2
4. Use of Certificates in RFC 4301 and IKEv2
4.1. Identification Payload
4.1. Identification Payload
The Peer Authorization Database (PAD) as described in RFC 4301 [14] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement, which are generally out of scope of this document. The PAD is intended to provide a link between the SPD and the security association management in protocols such as IKE. See RFC 4301 [14], Section 4.4.3 for more details.
The Peer Authorization Database (PAD) as described in RFC 4301 [14] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement, which are generally out of scope of this document. The PAD is intended to provide a link between the SPD and the security association management in protocols such as IKE. See RFC 4301 [14], Section 4.4.3 for more details.
Note that IKEv2 adds an optional IDr payload in the second exchange that the initiator may send to the responder in order to specify which of the responder's multiple identities should be used. The responder MAY choose to send an IDr in the third exchange that differs in type or content from the initiator-generated IDr. The initiator MUST be able to receive a responder-generated IDr that is a different type from the one the initiator generated.
Note that IKEv2 adds an optional IDr payload in the second exchange that the initiator may send to the responder in order to specify which of the responder's multiple identities should be used. The responder MAY choose to send an IDr in the third exchange that differs in type or content from the initiator-generated IDr. The initiator MUST be able to receive a responder-generated IDr that is a different type from the one the initiator generated.
4.2. Certificate Request Payload
4.2. Certificate Request Payload
4.2.1. Revocation Lists (CRL and ARL)
4.2.1. Revocation Lists (CRL and ARL)
IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause.
IKEv2 does not support Certificate Payload sizes over approximately 64K. See Section 3.2.3 for the problems this can cause.
4.2.1.1. IKEv2's Hash and URL of X.509 certificate
4.2.1.1. IKEv2's Hash and URL of X.509 certificate
This ID type defines a request for the peer to send a hash and URL of its X.509 certificate, instead of the actual certificate itself. This is a particularly useful mechanism when the peer is a device with little memory and lower bandwidth, e.g., a mobile handset or consumer electronics device.
This ID type defines a request for the peer to send a hash and URL of its X.509 certificate, instead of the actual certificate itself. This is a particularly useful mechanism when the peer is a device with little memory and lower bandwidth, e.g., a mobile handset or consumer electronics device.
If the IKEv2 implementation supports URL lookups, and prefers such a URL to receiving actual certificates, then the implementation will want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 [3], Section 3.10.1, "This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format)". If an HTTP_CERT_LOOKUP_SUPPORTED notification is sent, the sender MUST support the http scheme. See Section 4.3.1 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED.
If the IKEv2 implementation supports URL lookups, and prefers such a URL to receiving actual certificates, then the implementation will want to send a notify of type HTTP_CERT_LOOKUP_SUPPORTED. From IKEv2 [3], Section 3.10.1, "This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format)". If an HTTP_CERT_LOOKUP_SUPPORTED notification is sent, the sender MUST support the http scheme. See Section 4.3.1 for more discussion of HTTP_CERT_LOOKUP_SUPPORTED.
Korver Standards Track [Page 24] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 24] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
4.2.1.2. Location of Certificate Request Payloads
4.2.1.2. Location of Certificate Request Payloads
In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
In IKEv2, the CERTREQ payload must be in messages 2 and 3. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
4.3. Certificate Payload
4.3. Certificate Payload
4.3.1. IKEv2's Hash and URL of X.509 Certificate
4.3.1. IKEv2's Hash and URL of X.509 Certificate
This type specifies that Certificate Data contains a hash and the URL to a repository where an X.509 certificate can be retrieved.
This type specifies that Certificate Data contains a hash and the URL to a repository where an X.509 certificate can be retrieved.
An implementation that sends an HTTP_CERT_LOOKUP_SUPPORTED notification MUST support the http scheme and MAY support the ftp scheme, and MUST NOT require any specific form of the url-path, and it SHOULD support having user-name, password, and port parts in the URL. The following are examples of mandatory forms:
An implementation that sends an HTTP_CERT_LOOKUP_SUPPORTED notification MUST support the http scheme and MAY support the ftp scheme, and MUST NOT require any specific form of the url-path, and it SHOULD support having user-name, password, and port parts in the URL. The following are examples of mandatory forms:
o http://certs.example.com/certificate.cer o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 o http://certs.example.com/%0a/../foo/bar/zappa
o http://certs.example.com/certificate.cer o http://certs.example.com/certs/cert.pl?u=foo;a=pw;valid-to=+86400 o http://certs.example.com/%0a/../foo/bar/zappa
while the following is an example of a form that SHOULD be supported:
while the following is an example of a form that SHOULD be supported:
o http://user:password@certs.example.com:8888/certificate.cer
o http://user:password@certs.example.com:8888/certificate.cer
FTP MAY be supported, and if it is, the following is an example of the ftp scheme that MUST be supported:
FTP MAY be supported, and if it is, the following is an example of the ftp scheme that MUST be supported:
o ftp://ftp.example.com/pub/certificate.cer
o ftp://ftp.example.com/pub/certificate.cer
4.3.2. Location of Certificate Payloads
4.3.2. Location of Certificate Payloads
In IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
In IKEv2, the CERT payload MUST be in messages 3 and 4. Note that in IKEv2, it is possible to have one side authenticating with certificates while the other side authenticates with pre-shared keys.
4.3.3. Ordering of Certificate Payloads
4.3.3. Ordering of Certificate Payloads
For IKEv2, implementations MUST NOT assume that any but the first CERT is ordered in any way. IKEv2 specifies that the first CERT contain an end-entity certificate that can be used to authenticate the peer.
For IKEv2, implementations MUST NOT assume that any but the first CERT is ordered in any way. IKEv2 specifies that the first CERT contain an end-entity certificate that can be used to authenticate the peer.
Korver Standards Track [Page 25] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 25] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
5. Certificate Profile for IKEv1/ISAKMP and IKEv2
5. Certificate Profile for IKEv1/ISAKMP and IKEv2
Except where specifically stated in this document, implementations MUST conform to the requirements of the PKIX [5] certificate profile.
Except where specifically stated in this document, implementations MUST conform to the requirements of the PKIX [5] certificate profile.
5.1. X.509 Certificates
5.1. X.509 Certificates
Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check.
Users deploying IKE and IPsec with certificates have often had little control over the capabilities of CAs available to them. Implementations of this specification may include configuration knobs to disable checks required by this specification in order to permit use with inflexible and/or noncompliant CAs. However, all checks on certificates exist for a specific reason involving the security of the entire system. Therefore, all checks MUST be enabled by default. Administrators and users ought to understand the security purpose for the various checks, and be clear on what security will be lost by disabling the check.
5.1.1. Versions
5.1.1. Versions
Although PKIX states that "implementations SHOULD be prepared to accept any version certificate", in practice, this profile requires certain extensions that necessitate the use of Version 3 certificates for all but self-signed certificates used as trust anchors. Implementations that conform to this document MAY therefore reject Version 1 and Version 2 certificates in all other cases.
Although PKIX states that "implementations SHOULD be prepared to accept any version certificate", in practice, this profile requires certain extensions that necessitate the use of Version 3 certificates for all but self-signed certificates used as trust anchors. Implementations that conform to this document MAY therefore reject Version 1 and Version 2 certificates in all other cases.
5.1.2. Subject
5.1.2. Subject
Certification Authority implementations MUST be able to create certificates with Subject fields with at least the following four attributes: CN, C, O, and OU. Implementations MAY support other Subject attributes as well. The contents of these attributes SHOULD be configurable on a certificate-by-certificate basis, as these fields will likely be used by IKE implementations to match SPD policy.
Certification Authority implementations MUST be able to create certificates with Subject fields with at least the following four attributes: CN, C, O, and OU. Implementations MAY support other Subject attributes as well. The contents of these attributes SHOULD be configurable on a certificate-by-certificate basis, as these fields will likely be used by IKE implementations to match SPD policy.
See Section 3.1.5 for details on how IKE implementations need to be able to process Subject field attributes for SPD policy lookup.
See Section 3.1.5 for details on how IKE implementations need to be able to process Subject field attributes for SPD policy lookup.
5.1.2.1. Empty Subject Name
5.1.2.1. Empty Subject Name
IKE Implementations MUST accept certificates that contain an empty Subject field, as specified in the PKIX certificate profile. Identity information in such certificates will be contained entirely in the SubjectAltName extension.
IKE Implementations MUST accept certificates that contain an empty Subject field, as specified in the PKIX certificate profile. Identity information in such certificates will be contained entirely in the SubjectAltName extension.
Korver Standards Track [Page 26] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 26] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
5.1.2.2. Specifying Hosts and not FQDN in the Subject Name
5.1.2.2. Specifying Hosts and not FQDN in the Subject Name
Implementations that desire to place host names that are not intended to be processed by recipients as FQDNs (for instance "Gateway Router") in the Subject MUST use the commonName attribute.
Implementations that desire to place host names that are not intended to be processed by recipients as FQDNs (for instance "Gateway Router") in the Subject MUST use the commonName attribute.
5.1.2.3. EmailAddress
5.1.2.3. EmailAddress
As specified in the PKIX certificate profile, implementations MUST NOT populate X.500 distinguished names with the emailAddress attribute.
As specified in the PKIX certificate profile, implementations MUST NOT populate X.500 distinguished names with the emailAddress attribute.
5.1.3. X.509 Certificate Extensions
5.1.3. X.509 Certificate Extensions
Conforming IKE implementations MUST recognize extensions that must or may be marked critical according to this specification. These extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
Conforming IKE implementations MUST recognize extensions that must or may be marked critical according to this specification. These extensions are: KeyUsage, SubjectAltName, and BasicConstraints.
Certification Authority implementations SHOULD generate certificates such that the extension criticality bits are set in accordance with the PKIX certificate profile and this document. With respect to compliance with the PKIX certificate profile, IKE implementations processing certificates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the criticality bit for extensions that are not supported by that implementation. That is, a relying party SHOULD processes all the extensions it is aware of whether the bit is true or false -- the bit says what happens when a relying party cannot process an extension.
Certification Authority implementations SHOULD generate certificates such that the extension criticality bits are set in accordance with the PKIX certificate profile and this document. With respect to compliance with the PKIX certificate profile, IKE implementations processing certificates MAY ignore the value of the criticality bit for extensions that are supported by that implementation, but MUST support the criticality bit for extensions that are not supported by that implementation. That is, a relying party SHOULD processes all the extensions it is aware of whether the bit is true or false -- the bit says what happens when a relying party cannot process an extension.
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok
implements bit in cert PKIX mandate behavior ------------------------------------------------------ yes true true ok yes true false ok or reject yes false true ok or reject yes false false ok no true true reject no true false reject no false true reject no false false ok
5.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier
5.1.3.1. AuthorityKeyIdentifier and SubjectKeyIdentifier
Implementations SHOULD NOT assume support for the AuthorityKeyIdentifier or SubjectKeyIdentifier extensions. Thus, Certification Authority implementations should not generate certificate hierarchies that are overly complex to process in the absence of these extensions, such as those that require possibly
Implementations SHOULD NOT assume support for the AuthorityKeyIdentifier or SubjectKeyIdentifier extensions. Thus, Certification Authority implementations should not generate certificate hierarchies that are overly complex to process in the absence of these extensions, such as those that require possibly
Korver Standards Track [Page 27] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 27] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate that contains the key that was used to generate the signature.
verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate that contains the key that was used to generate the signature.
5.1.3.2. KeyUsage
5.1.3.2. KeyUsage
IKE uses an end-entity certificate in the authentication process. The end-entity certificate may be used for multiple applications. As such, the CA can impose some constraints on the manner that a public key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) extensions apply in this situation.
IKE uses an end-entity certificate in the authentication process. The end-entity certificate may be used for multiple applications. As such, the CA can impose some constraints on the manner that a public key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU) extensions apply in this situation.
Since we are talking about using the public key to validate a signature, if the KeyUsage extension is present, then at least one of the digitalSignature or the nonRepudiation bits in the KeyUsage extension MUST be set (both can be set as well). It is also fine if other KeyUsage bits are set.
Since we are talking about using the public key to validate a signature, if the KeyUsage extension is present, then at least one of the digitalSignature or the nonRepudiation bits in the KeyUsage extension MUST be set (both can be set as well). It is also fine if other KeyUsage bits are set.
A summary of the logic flow for peer cert validation follows:
A summary of the logic flow for peer cert validation follows:
o If no KU extension, continue.
o If no KU extension, continue.
o If KU present and doesn't mention digitalSignature or
nonRepudiation (both, in addition to other KUs, is also fine),
reject cert.
o If KU present and doesn't mention digitalSignature or nonRepudiation (both, in addition to other KUs, is also fine), reject cert.
o If none of the above, continue.
o If none of the above, continue.
5.1.3.3. PrivateKeyUsagePeriod
5.1.3.3. PrivateKeyUsagePeriod
The PKIX certificate profile recommends against the use of this extension. The PrivateKeyUsageExtension is intended to be used when signatures will need to be verified long past the time when signatures using the private keypair may be generated. Since IKE security associations (SAs) are short-lived relative to the intended use of this extension in addition to the fact that each signature is validated only a single time, the usefulness of this extension in the context of IKE is unclear. Therefore, Certification Authority implementations MUST NOT generate certificates that contain the PrivateKeyUsagePeriod extension. If an IKE implementation receives a certificate with this set, it SHOULD ignore it.
The PKIX certificate profile recommends against the use of this extension. The PrivateKeyUsageExtension is intended to be used when signatures will need to be verified long past the time when signatures using the private keypair may be generated. Since IKE security associations (SAs) are short-lived relative to the intended use of this extension in addition to the fact that each signature is validated only a single time, the usefulness of this extension in the context of IKE is unclear. Therefore, Certification Authority implementations MUST NOT generate certificates that contain the PrivateKeyUsagePeriod extension. If an IKE implementation receives a certificate with this set, it SHOULD ignore it.
Korver Standards Track [Page 28] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 28] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
5.1.3.4. CertificatePolicies
5.1.3.4. CertificatePolicies
Many IKE implementations do not currently provide support for the CertificatePolicies extension. Therefore, Certification Authority implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical. As is the case with all certificate extensions, a relying party receiving this extension but who can process the extension SHOULD NOT reject the certificate because it contains the extension.
Many IKE implementations do not currently provide support for the CertificatePolicies extension. Therefore, Certification Authority implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical. As is the case with all certificate extensions, a relying party receiving this extension but who can process the extension SHOULD NOT reject the certificate because it contains the extension.
5.1.3.5. PolicyMappings
5.1.3.5. PolicyMappings
Many IKE implementations do not support the PolicyMappings extension. Therefore, implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical.
Many IKE implementations do not support the PolicyMappings extension. Therefore, implementations that generate certificates that contain this extension SHOULD NOT mark the extension as critical.
5.1.3.6. SubjectAltName
5.1.3.6. SubjectAltName
Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, or IPV6_ADDR MUST issue certificates with the corresponding SubjectAltName fields populated with the same data. Implementations SHOULD generate only the following GeneralName choices in the SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/ IKEv2 Identification Payload types: rfc822Name, dNSName, or iPAddress. Although it is possible to specify any GeneralName choice in the Identification Payload by using the ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume support for such functionality, and SHOULD NOT generate certificates that do so.
Deployments that intend to use an ID of FQDN, USER_FQDN, IPV4_ADDR, or IPV6_ADDR MUST issue certificates with the corresponding SubjectAltName fields populated with the same data. Implementations SHOULD generate only the following GeneralName choices in the SubjectAltName extension, as these choices map to legal IKEv1/ISAKMP/ IKEv2 Identification Payload types: rfc822Name, dNSName, or iPAddress. Although it is possible to specify any GeneralName choice in the Identification Payload by using the ID_DER_ASN1_GN ID type, implementations SHOULD NOT assume support for such functionality, and SHOULD NOT generate certificates that do so.
5.1.3.6.1. dNSName
5.1.3.6.1. dNSName
If the IKE ID type is FQDN, then this field MUST contain a fully qualified domain name. If the IKE ID type is FQDN, then the dNSName field MUST match its contents. Implementations MUST NOT generate names that contain wildcards. Implementations MAY treat certificates that contain wildcards in this field as syntactically invalid.
If the IKE ID type is FQDN, then this field MUST contain a fully qualified domain name. If the IKE ID type is FQDN, then the dNSName field MUST match its contents. Implementations MUST NOT generate names that contain wildcards. Implementations MAY treat certificates that contain wildcards in this field as syntactically invalid.
Although this field is in the form of an FQDN, IKE implementations SHOULD NOT assume that this field contains an FQDN that will resolve via the DNS, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document. Implementations SHOULD NOT treat the failure to resolve as an error.
Although this field is in the form of an FQDN, IKE implementations SHOULD NOT assume that this field contains an FQDN that will resolve via the DNS, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document. Implementations SHOULD NOT treat the failure to resolve as an error.
Korver Standards Track [Page 29] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 29] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
5.1.3.6.2. iPAddress
5.1.3.6.2. iPAddress
If the IKE ID type is IPV4_ADDR or IPV6_ADDR, then the iPAddress field MUST match its contents. Note that although PKIX permits CIDR [15] notation in the "Name Constraints" extension, the PKIX certificate profile explicitly prohibits using CIDR notation for conveying identity information. In other words, the CIDR notation MUST NOT be used in the SubjectAltName extension.
If the IKE ID type is IPV4_ADDR or IPV6_ADDR, then the iPAddress field MUST match its contents. Note that although PKIX permits CIDR [15] notation in the "Name Constraints" extension, the PKIX certificate profile explicitly prohibits using CIDR notation for conveying identity information. In other words, the CIDR notation MUST NOT be used in the SubjectAltName extension.
5.1.3.6.3. rfc822Name
5.1.3.6.3. rfc822Name
If the IKE ID type is USER_FQDN, then the rfc822Name field MUST match its contents. Although this field is in the form of an Internet mail address, IKE implementations SHOULD NOT assume that this field contains a valid email address, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document.
If the IKE ID type is USER_FQDN, then the rfc822Name field MUST match its contents. Although this field is in the form of an Internet mail address, IKE implementations SHOULD NOT assume that this field contains a valid email address, unless this is known by way of some out-of-band mechanism. Such a mechanism is out of the scope of this document.
5.1.3.7. IssuerAltName
5.1.3.7. IssuerAltName
Certification Authority implementations SHOULD NOT assume that other implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
Certification Authority implementations SHOULD NOT assume that other implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
5.1.3.8. SubjectDirectoryAttributes
5.1.3.8. SubjectDirectoryAttributes
The SubjectDirectoryAttributes extension is intended to convey identification attributes of the subject. IKE implementations MAY ignore this extension when it is marked non-critical, as the PKIX certificate profile mandates.
The SubjectDirectoryAttributes extension is intended to convey identification attributes of the subject. IKE implementations MAY ignore this extension when it is marked non-critical, as the PKIX certificate profile mandates.
5.1.3.9. BasicConstraints
5.1.3.9. BasicConstraints
The PKIX certificate profile mandates that CA certificates contain this extension and that it be marked critical. IKE implementations SHOULD reject CA certificates that do not contain this extension. For backwards compatibility, implementations may accept such certificates if explicitly configured to do so, but the default for this setting MUST be to reject such certificates.
The PKIX certificate profile mandates that CA certificates contain this extension and that it be marked critical. IKE implementations SHOULD reject CA certificates that do not contain this extension. For backwards compatibility, implementations may accept such certificates if explicitly configured to do so, but the default for this setting MUST be to reject such certificates.
5.1.3.10. NameConstraints
5.1.3.10. NameConstraints
Many IKE implementations do not support the NameConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
Many IKE implementations do not support the NameConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
Korver Standards Track [Page 30] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
Korver Standards Track [Page 30] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
5.1.3.11. PolicyConstraints
5.1.3.11. PolicyConstraints
Many IKE implementations do not support the PolicyConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
Many IKE implementations do not support the PolicyConstraints extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
5.1.3.12. ExtendedKeyUsage
5.1.3.12. ExtendedKeyUsage
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates for use with IKE. Note that there were three IPsec- related object identifiers in EKU that were assigned in 1999. The semantics of these values were never clearly defined. The use of these three EKU values in IKE/IPsec is obsolete and explicitly deprecated by this specification. CAs SHOULD NOT issue certificates for use in IKE with them. (For historical reference only, those values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- ipsecUser.)
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates for use with IKE. Note that there were three IPsec- related object identifiers in EKU that were assigned in 1999. The semantics of these values were never clearly defined. The use of these three EKU values in IKE/IPsec is obsolete and explicitly deprecated by this specification. CAs SHOULD NOT issue certificates for use in IKE with them. (For historical reference only, those values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- ipsecUser.)
The CA SHOULD NOT mark the EKU extension in certificates for use with IKE and one or more other applications. Nevertheless, this document defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a certificate's use:
The CA SHOULD NOT mark the EKU extension in certificates for use with IKE and one or more other applications. Nevertheless, this document defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a certificate's use:
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
where id-kp is defined in RFC 3280 [5]. If a certificate is intended to be used with both IKE and other applications, and one of the other applications requires use of an EKU value, then such certificates MUST contain either the keyPurposeID id-kp-ipsecIKE or anyExtendedKeyUsage [5], as well as the keyPurposeID values associated with the other applications. Similarly, if a CA issues multiple otherwise-similar certificates for multiple applications including IKE, and it is intended that the IKE certificate NOT be used with another application, the IKE certificate MAY contain an EKU extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with the other application. Recall, however, that EKU extensions in certificates meant for use in IKE are NOT RECOMMENDED.
イド-kpがRFC3280[5]で定義されるところ。 IKEと他のアプリケーションの両方と共に証明書が使用されることを意図して、他のアプリケーションのひとりがEKU価値の使用を必要とするなら、そのような証明書はkeyPurposeIDイド-kp-ipsecIKEかanyExtendedKeyUsage[5]のどちらかを含まなければなりません、他のアプリケーションに関連しているkeyPurposeID値と同様に。 同様に、カリフォルニアがIKEを含む複数のアプリケーションのための複数のそうでなければ、同様の証明書を発行して、IKE証明書が別のアプリケーションと共に使用されないことを意図するなら、IKE証明書はもう片方のアプリケーションによる使用に水をさしているためにイド-kp-ipsecIKEのkeyPurposeIDを記載するEKU拡張子を含むかもしれません。 しかしながら、IKEにおける使用のために意味された証明書におけるEKU拡張子がNOT RECOMMENDEDであると思い出してください。
Conforming IKE implementations are not required to support EKU. If a critical EKU extension appears in a certificate and EKU is not supported by the implementation, then RFC 3280 requires that the certificate be rejected. Implementations that do support EKU MUST support the following logic for certificate validation:
従っているIKE実装は、EKUをサポートするのに必要ではありません。 重要なEKU拡張子が証明書に現れて、EKUが実装によってサポートされないなら、RFC3280は、証明書が拒絶されるのを必要とします。 EKU MUSTをサポートする実装は証明書合法化のために以下の論理をサポートします:
Korver Standards Track [Page 31] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[31ページ]
o If no EKU extension, continue.
o EKU拡張子でないなら、続いてください。
o If EKU present AND contains either id-kp-ipsecIKE or
anyExtendedKeyUsage, continue.
o EKUの現在のANDがイド-kp-ipsecIKEかanyExtendedKeyUsageのどちらかを含むなら、続いてください。
o Otherwise, reject cert.
o さもなければ、本命を拒絶してください。
5.1.3.13. CRLDistributionPoints
5.1.3.13. CRLDistributionPoints
Because this document deprecates the sending of CRLs in-band, the use of CRLDistributionPoints (CDP) becomes very important if CRLs are used for revocation checking (as opposed to, say, Online Certificate Status Protocol - OCSP [16]). The IPsec peer either needs to have a URL for a CRL written into its local configuration, or it needs to learn it from CDP. Therefore, Certification Authority implementations SHOULD issue certificates with a populated CDP.
と対照的に、CRLsが取消しの照合に使用されるならこのドキュメントが中で組になった状態でCRLsの発信を非難するのでCRLDistributionPoints(CDP)の使用が非常に重要になる、(たとえば、Online Certificate Statusプロトコル--OCSP[16])。 IPsec同輩が地方の構成に書かれたCRLのためのURLを必要とするか、またはそれは、CDPからそれを学ぶ必要があります。 したがって、認証局実装SHOULDは居住されたCDPと共に証明書を発行します。
Failure to validate the CRLDistributionPoints/ IssuingDistributionPoint pair can result in CRL substitution where an entity knowingly substitutes a known good CRL from a different distribution point for the CRL that is supposed to be used, which would show the entity as revoked. IKE implementations MUST support validating that the contents of CRLDistributionPoints match those of the IssuingDistributionPoint to prevent CRL substitution when the issuing CA is using them. At least one CA is known to default to this type of CRL use. See Section 5.2.2.5 for more information.
CRLDistributionPoints/ IssuingDistributionPoint組を有効にしない場合、実体が故意に使用されるべきであるCRLのための異なった分配ポイント(取り消されるように実体を示している)から知られている良いCRLを代入するところでCRL代替をもたらすことができます。 IKE実装は、発行カリフォルニアが彼らを使用しているとき、CRL代替を防ぐためにCRLDistributionPointsの内容が合っている有効にするのにIssuingDistributionPointのものをサポートしなければなりません。 少なくとも1カリフォルニアがこのタイプのCRL使用をデフォルトとするのが知られています。 セクション5.2を見てください。.2 .5 詳しい情報のために。
CDPs SHOULD be "resolvable". Several non-compliant Certification Authority implementations are well known for including unresolvable CDPs like http://localhost/path_to_CRL and http:///path_to_CRL that are equivalent to failing to include the CDP extension in the certificate.
CDPs SHOULD、「溶解性」はそうです。 証明書にCDP拡張子を含んでいないのに同等な http://localhost/path_to_CRL と http:///path_to_CRL のようなunresolvable CDPsを含んでいるのにおいて、いくつかの不従順な認証局実装がよく知られています。
See the IETF IPR Web page for CRLDistributionPoints intellectual property rights (IPR) information. Note that both the CRLDistributionPoints and IssuingDistributionPoint extensions are RECOMMENDED but not REQUIRED by the PKIX certificate profile, so there is no requirement to license any IPR.
CRLDistributionPoints知的所有権(IPR)情報に関してIETF IPRウェブページを見てください。 どんなIPRも認可するという要件が全くないようにCRLDistributionPointsとIssuingDistributionPoint拡張子の両方がREQUIREDではなく、PKIX証明書プロフィールによるRECOMMENDEDであることに注意してください。
5.1.3.14. InhibitAnyPolicy
5.1.3.14. InhibitAnyPolicy
Many IKE implementations do not support the InhibitAnyPolicy extension. Since the PKIX certificate profile mandates that this extension be marked critical when present, Certification Authority implementations that are interested in maximal interoperability for IKE SHOULD NOT generate certificates that contain this extension.
多くのIKE実装は、InhibitAnyPolicyが拡大であるとサポートしません。 以来、存在しているとき、この拡大があるPKIX証明書プロフィール命令が重要であるとマークされて、IKE SHOULD NOTのための最大限度の相互運用性に興味を持っている認証局実装はこの拡大を含む証明書を作ります。
Korver Standards Track [Page 32] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[32ページ]
5.1.3.15. FreshestCRL
5.1.3.15. FreshestCRL
IKE implementations MUST NOT assume that the FreshestCRL extension will exist in peer certificates. Note that most IKE implementations do not support delta CRLs.
IKE実装は、FreshestCRL拡張子が同輩証明書に存在すると仮定してはいけません。 ほとんどのIKE実装が、デルタがCRLsであるとサポートしないことに注意してください。
5.1.3.16. AuthorityInfoAccess
5.1.3.16. AuthorityInfoAccess
The PKIX certificate profile defines the AuthorityInfoAccess extension, which is used to indicate "how to access CA information and services for the issuer of the certificate in which the extension appears". Because this document deprecates the sending of CRLs in- band, the use of AuthorityInfoAccess (AIA) becomes very important if OCSP [16] is to be used for revocation checking (as opposed to CRLs). The IPsec peer either needs to have a URI for the OCSP query written into its local configuration, or it needs to learn it from AIA. Therefore, implementations SHOULD support this extension, especially if OCSP will be used.
PKIX証明書プロフィールはAuthorityInfoAccess拡張子を定義します。(それは、「拡大が現れる証明書の発行人のためにどのようにカリフォルニア情報とサービスにアクセスしますか」と示すのに使用されます)。 このドキュメントがコネが括るCRLsの発信を非難するので、OCSP[16]が取消しの照合(CRLsと対照的に)に使用されるつもりであるなら、AuthorityInfoAccess(AIA)の使用は非常に重要になります。 IPsec同輩が地方の構成に書かれたOCSP質問のためのURIを必要とするか、またはそれは、AIAからそれを学ぶ必要があります。 したがって、特にOCSPが使用されるなら、実装SHOULDはこの拡大をサポートします。
5.1.3.17. SubjectInfoAccess
5.1.3.17. SubjectInfoAccess
The PKIX certificate profile defines the SubjectInfoAccess certificate extension, which is used to indicate "how to access information and services for the subject of the certificate in which the extension appears". This extension has no known use in the context of IPsec. Conformant IKE implementations SHOULD ignore this extension when present.
PKIX証明書プロフィールはSubjectInfoAccess証明書拡張子を定義します。(それは、「どのように拡大が現れる証明書の対象のための情報とサービスにアクセスしますか」と示すのに使用されます)。 この拡大には、IPsecの文脈における知られている使用が全くありません。 存在しているとき、Conformant IKE実装SHOULDはこの拡大を無視します。
5.2. X.509 Certificate Revocation Lists
5.2. X.509証明書失効リスト
When validating certificates, IKE implementations MUST make use of certificate revocation information, and SHOULD support such revocation information in the form of CRLs, unless non-CRL revocation information is known to be the only method for transmitting this information. Deployments that intend to use CRLs for revocation SHOULD populate the CRLDistributionPoints extension. Therefore, Certification Authority implementations MUST support issuing certificates with this field populated. IKE implementations MAY provide a configuration option to disable use of certain types of revocation information, but that option MUST be off by default. Such an option is often valuable in lab testing environments.
証明書を有効にするとき、IKE実装は証明書取消し情報を利用しなければなりません、そして、SHOULDはCRLsの形でそのような取消しが情報であるとサポートします、非CRL取消し情報がこの情報を伝えるための唯一のメソッドであることは知られない場合。 取消しSHOULDにCRLsを使用するつもりである展開がCRLDistributionPoints拡張子に居住します。 したがって、この分野が居住されている状態で、認証局実装は、発行が証明書であるとサポートしなければなりません。 IKE実装はあるタイプの取消し情報の使用を無効にするために設定オプションを提供するかもしれませんが、そのオプションはデフォルトで取り止めになっていなければなりません。 そのようなオプションは研究室テスト環境でしばしば貴重です。
Korver Standards Track [Page 33] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[33ページ]
5.2.1. Multiple Sources of Certificate Revocation Information
5.2.1. 証明書取消し情報の複数の源
IKE implementations that support multiple sources of obtaining certificate revocation information MUST act conservatively when the information provided by these sources is inconsistent: when a certificate is reported as revoked by one trusted source, the certificate MUST be considered revoked.
これらのソースによって提供された情報が矛盾しているとき、入手の複数の源を支えるIKE実装が情報が保守的に機能させなければならない取消しを証明します: 1人の信頼できるソースによって取り消されるように証明書が報告されるとき、取り消されると証明書を考えなければなりません。
5.2.2. X.509 Certificate Revocation List Extensions
5.2.2. X.509証明書失効リスト拡張子
5.2.2.1. AuthorityKeyIdentifier
5.2.2.1. AuthorityKeyIdentifier
Certification Authority implementations SHOULD NOT assume that IKE implementations support the AuthorityKeyIdentifier extension, and thus should not generate certificate hierarchies which are overly complex to process in the absence of this extension, such as those that require possibly verifying a signature against a large number of similarly named CA certificates in order to find the CA certificate which contains the key that was used to generate the signature.
認証局実装SHOULD NOTは、IKE実装がAuthorityKeyIdentifier拡張子をサポートして、その結果、この拡大がないとき処理するためにひどく複雑な証明書階層構造を生成するべきでないと仮定します、署名を生成するのに使用されたキーを含むカリフォルニア証明書を見つけるためにことによると多くの同様に命名されたカリフォルニア証明書に対して署名について確かめるのを必要とするものなどのように。
5.2.2.2. IssuerAltName
5.2.2.2. IssuerAltName
Certification Authority implementations SHOULD NOT assume that IKE implementations support the IssuerAltName extension, and especially should not assume that information contained in this extension will be displayed to end users.
認証局実装SHOULD NOTは、IKE実装が、IssuerAltName拡張子をサポートして、この拡大に含まれた情報がエンドユーザに表示されると特に仮定するべきでないと仮定します。
5.2.2.3. CRLNumber
5.2.2.3. CRLNumber
As stated in the PKIX certificate profile, all issuers MUST include this extension in all CRLs.
PKIX証明書プロフィールに述べられているように、すべての発行人がすべてのCRLsにこの拡大を含まなければなりません。
5.2.2.4. DeltaCRLIndicator
5.2.2.4. DeltaCRLIndicator
5.2.2.4.1. If Delta CRLs Are Unsupported
5.2.2.4.1. デルタCRLsがサポートされないなら
IKE implementations that do not support delta CRLs MUST reject CRLs that contain the DeltaCRLIndicator (which MUST be marked critical according to the PKIX certificate profile) and MUST make use of a base CRL if it is available. Such implementations MUST ensure that a delta CRL does not "overwrite" a base CRL, for instance, in the keying material database.
デルタがCRLsであるとサポートしないIKE実装は、DeltaCRLIndicator(PKIX証明書プロフィールによると、重要であるとマークしなければならない)を含むCRLsを拒絶しなければならなくて、それが利用可能であるなら、ベースCRLを利用しなければなりません。 そのような実装は、例えば、CRLデルタが合わせることの物質的なデータベースでベースCRLを「上書きしないこと」を確実にしなければなりません。
Korver Standards Track [Page 34] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[34ページ]
5.2.2.4.2. Delta CRL Recommendations
5.2.2.4.2. デルタCRL推薦
Since some IKE implementations that do not support delta CRLs may behave incorrectly or insecurely when presented with delta CRLs, administrators and deployers should consider whether issuing delta CRLs increases security before issuing such CRLs. And, if all the elements in the VPN and PKI systems do not adequately support Delta CRLs, then their use should be questioned.
デルタCRLsを与えるとき、デルタがCRLsであるとサポートしないいくつかのIKE実装が不当か不安定に振る舞うかもしれないので、そのようなCRLsを発行する前にデルタCRLs増加にセキュリティを発行するか否かに関係なく、管理者とデプロイヤは考えるべきです。 そして、VPNとPKIシステムのすべての要素が適切にデルタCRLsをサポートしないなら、彼らの使用は質問されるべきです。
The editors are aware of several implementations that behave in an incorrect or insecure manner when presented with delta CRLs. See Appendix A for a description of the issue. Therefore, this specification RECOMMENDS NOT issuing delta CRLs at this time. On the other hand, failure to issue delta CRLs may expose a larger window of vulnerability if a full CRL is not issued as often as delta CRLs would be. See the Security Considerations section of the PKIX [5] certificate profile for additional discussion. Implementers as well as administrators are encouraged to consider these issues.
エディタはデルタCRLsを与えるとき不正確であるか不安定な態度で振る舞ういくつかの実装を意識しています。 問題の記述に関してAppendix Aを見てください。 したがって、このときデルタCRLsを発行するこの仕様RECOMMENDS NOT。 他方では、完全なCRLがデルタCRLsであるだろうというのと同じくらい頻繁に発行されないで、またデルタCRLsを発行しない場合、脆弱性の、より大きいウィンドウを出すかもしれません。 追加議論のためのPKIX[5]証明書プロフィールのSecurity Considerations部を見てください。 管理者と同様にImplementersがこれらの問題を考えるよう奨励されます。
5.2.2.5. IssuingDistributionPoint
5.2.2.5. IssuingDistributionPoint
A CA that is using CRLDistributionPoints may do so to provide many "small" CRLs, each only valid for a particular set of certificates issued by that CA. To associate a CRL with a certificate, the CA places the CRLDistributionPoints extension in the certificate, and places the IssuingDistributionPoint in the CRL. The distributionPointName field in the CRLDistributionPoints extension MUST be identical to the distributionPoint field in the IssuingDistributionPoint extension. At least one CA is known to default to this type of CRL use. See Section 5.1.3.13 for more information.
CRLDistributionPointsを使用しているカリフォルニアは多くの「小さい」CRLsを提供するためにするかもしれません、そのカリフォルニアによって発行された特定のセットの証明書だけにはそれぞれ有効です。 カリフォルニアは、CRLを証明書に関連づけるために、CRLDistributionPoints拡張子を証明書に置いて、IssuingDistributionPointをCRLに置きます。 CRLDistributionPoints拡張子におけるdistributionPointName分野はIssuingDistributionPoint拡張子がdistributionPoint分野と同じであるに違いありません。 少なくとも1カリフォルニアがこのタイプのCRL使用をデフォルトとするのが知られています。 セクション5.1を見てください。.3 .13 詳しい情報のために。
5.2.2.6. FreshestCRL
5.2.2.6. FreshestCRL
Given the recommendations against Certification Authority implementations generating delta CRLs, this specification RECOMMENDS that implementations do not populate CRLs with the FreshestCRL extension, which is used to obtain delta CRLs.
デルタがCRLsであると生成する認証局実装に対する推薦を考えて、実装がするこの仕様RECOMMENDSはFreshestCRL拡張子があるCRLsに居住しません。(拡張子は、デルタCRLsを入手するのに使用されます)。
5.3. Strength of Signature Hashing Algorithms
5.3. アルゴリズムを論じ尽くす署名の強さ
At the time that this document is being written, popular certification authorities and CA software issue certificates using the RSA-with-SHA1 and RSA-with-MD5 signature algorithms. Implementations MUST be able to validate certificates with either of those algorithms.
このドキュメントが書かれている時に、ポピュラーな証明当局とカリフォルニアソフトウェアは、SHA1とRSAとMD5とRSA署名アルゴリズムを使用することで証明書を発行します。実装はそれらのアルゴリズムのどちらかがある証明書を有効にすることができなければなりません。
Korver Standards Track [Page 35] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[35ページ]
As described in [17], both the MD5 and SHA-1 hash algorithms are weaker than originally expected with respect to hash collisions. Certificates that use these hash algorithms as part of their signature algorithms could conceivably be subject to an attack where a CA issues a certificate with a particular identity, and the recipient of that certificate can create a different valid certificate with a different identity. So far, such an attack is only theoretical, even with the weaknesses found in the hash algorithms.
[17]で説明されるように、MD5とSHA-1ハッシュアルゴリズムの両方が元々ハッシュ衝突に関して予想されるより弱いです。 カリフォルニアが特定のアイデンティティで証明書を下付するところでそれらの署名アルゴリズムの部分は多分攻撃を受けることがあるかもしれないとき、これらを使用する証明書がアルゴリズムを論じ尽くします、そして、その証明書の受取人は異なったアイデンティティで異なった有効な証明書を作成できます。 今までのところ、弱点さえハッシュアルゴリズムで見つけられている状態で、そのような攻撃は理論上であるだけです。
Because of the recent attacks, there has been a heightened interest in having widespread deployment of additional signature algorithms. The algorithm that has been mentioned most often is RSA-with-SHA256, two types of which are described in detail in [18]. It is widely expected that this signature algorithm will be much more resilient to collision-based attacks than the current RSA-with-SHA1 and RSA-with- MD5, although no proof of that has been shown. There is active discussion in the cryptographic community of better hash functions that could be used in signature algorithms.
最近の攻撃のために、追加署名アルゴリズムの広範囲の展開を持っていることへの高められた関心がありました。言及されたアルゴリズムはたいてい、SHA256とRSAです、それのタイプが[18]で詳細に説明される2。 この署名アルゴリズムはSHA1と現在のRSAとRSAより衝突ベースの攻撃にはるかに弾力があると広く予想されます。-いいえが、MD5その証拠は示されました。 活発な議論が署名アルゴリズムで使用されるかもしれないより良いハッシュ関数の暗号の共同体にあります。
In order to interoperate, all implementations need to be able to validate signatures for all algorithms that the implementations will encounter. Therefore, implementations SHOULD be able to use signatures that use the sha256WithRSAEncryption signature algorithm (PKCS#1 version 1.5) as soon as possible. At the time that this document is being written, there is at least one CA that supports generating certificates with sha256WithRSAEncryption signature algorithm, and it is expected that there will be significant deployment of this algorithm by the end of 2007.
共同利用するために、すべての実装が、実装が遭遇するすべてのアルゴリズムのための署名を有効にすることができる必要があります。 したがって、実装SHOULD、できるだけ早くsha256WithRSAEncryption署名アルゴリズム(PKCS#1バージョン1.5)を使用する署名は使用できてください。 このドキュメントが書かれている時に、生成するのが証明書であるとsha256WithRSAEncryption署名アルゴリズムでサポートする少なくとも1カリフォルニアがあります、そして、2007年の終わりまでにこのアルゴリズムの重要な展開があると予想されます。
6. Configuration Data Exchange Conventions
6. コンフィギュレーション・データ交換コンベンション
Below, we present a common format for exchanging configuration data. Implementations MUST support these formats, MUST support receiving arbitrary whitespace at the beginning and end of any line, MUST support receiving arbitrary line lengths although they SHOULD generate lines less than 76 characters, and MUST support receiving the following three line-termination disciplines: LF (US-ASCII 10), CR (US-ASCII 13), and CRLF.
以下では、私たちがコンフィギュレーション・データを交換するための一般的な形式を提示します。 実装は、これらの形式をサポートしなければならなくて、どんな系列の首尾でも受信が任意の空白であるとサポートしなければならなくて、サポートしなければなりません。それらですが、任意の行長を受けて、SHOULDは、系列が76未満のキャラクタであると生成して、受信が以下の3つのライン・ターミネーション規律であるとサポートしなければなりません: LF(米国-ASCII10)、CR(米国-ASCII13)、およびCRLF。
6.1. Certificates
6.1. 証明書
Certificates MUST be Base64 [19] encoded and appear between the following delimiters:
証明書は、コード化されたBase64[19]であり、以下のデリミタの間に現れなければなりません:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----証明書を始めてください。----- -----終わりの証明書-----
Korver Standards Track [Page 36] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[36ページ]
6.2. CRLs and ARLs
6.2. CRLsとARLs
CRLs and ARLs MUST be Base64 encoded and appear between the following delimiters:
CRLsとARLsはコード化されたBase64であり、以下のデリミタの間に現れなければなりません:
-----BEGIN CRL-----
-----END CRL-----
-----CRLを始めてください。----- -----終わりのCRL-----
6.3. Public Keys
6.3. 公開鍵
IKE implementations MUST support two forms of public keys: certificates and so-called "raw" keys. Certificates should be transferred in the same form as Section 6.1. A raw key is only the SubjectPublicKeyInfo portion of the certificate, and MUST be Base64 encoded and appear between the following delimiters:
IKE実装は2つのフォームの公開鍵をサポートしなければなりません: 証明書といわゆる「生」のキー。 セクション6.1と同じフォームで証明書を移すべきです。 生のキーは、証明書のSubjectPublicKeyInfo部分だけであり、コード化されたBase64であり、以下のデリミタの間に現れなければなりません:
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
-----公開鍵を始めてください。----- -----終わりの公開鍵-----
6.4. PKCS#10 Certificate Signing Requests
6.4. PKCS#10の証明書署名要求
A PKCS#10 [9] Certificate Signing Request MUST be Base64 encoded and appear between the following delimiters:
PKCS#10[9]証明書Signing Requestはコード化されたBase64であり、以下のデリミタの間に現れなければなりません:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
-----証明書要求を始めてください。----- -----終わりの証明書要求-----
7. Security Considerations
7. セキュリティ問題
7.1. Certificate Request Payload
7.1. 証明書要求有効搭載量
The Contents of CERTREQ are not encrypted in IKE. In some environments, this may leak private information. Administrators in some environments may wish to use the empty Certification Authority option to prevent such information from leaking, at the cost of performance.
CERTREQのContentsはIKEで暗号化されません。 いくつかの環境で、これは個人情報を漏らすかもしれません。 いくつかの環境における管理者はそのような情報が漏れるのを防ぐのに空の認証局のオプションを使用したがっているかもしれません、性能の費用で。
7.2. IKEv1 Main Mode
7.2. IKEv1の主なモード
Certificates may be included in any message, and therefore implementations may wish to respond with CERTs in a message that offers privacy protection in Main Mode messages 5 and 6.
証明書はどんなメッセージにも含まれるかもしれません、そして、したがって、実装はMain Modeメッセージ5と6におけるプライバシー保護を提供するメッセージのCERTsと共に応じたがっているかもしれません。
Implementations may not wish to respond with CERTs in the second message, thereby violating the identity protection feature of Main Mode in IKEv1.
実装は2番目のメッセージのCERTsと共に応じたがっていないかもしれません、その結果、IKEv1のMain Modeのアイデンティティ保護機能に違反します。
Korver Standards Track [Page 37] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[37ページ]
7.3. Disabling Certificate Checks
7.3. 証明書チェックを無効にします。
It is important to note that anywhere this document suggests implementers provide users with the configuration option to simplify, modify, or disable a feature or verification step, there may be security consequences for doing so. Deployment experience has shown that such flexibility may be required in some environments, but making use of such flexibility can be inappropriate in others. Such configuration options MUST default to "enabled" and it is appropriate to provide warnings to users when disabling such features.
そうするためのセキュリティ結果がどこでも、このドキュメントが、implementersが特徴か検証ステップを簡素化するか、変更するか、または無効にするために設定オプションをユーザに提供するのを示すあるかもしれないことに注意するのは重要です。 展開経験は、そのような柔軟性がいくつかの環境で必要であるかもしれないことを示しましたが、そのような柔軟性を利用するのは他のもので不適当である場合があります。 そのような設定オプションは「可能にされること」をデフォルトとしなければなりません、そして、そのような特徴を無効にするとき、警告をユーザに提供するのは適切です。
8. Acknowledgements
8. 承認
The authors would like to acknowledge the expired document "A PKIX Profile for IKE" (July 2000) for providing valuable materials for this document.
作者はこのドキュメントのための貴重な材料を供給するための「IKEのためのPKIXプロフィール」(2000年7月)という満期のドキュメントを承認したがっています。
The authors would like to especially thank Eric Rescorla, one of its original authors, in addition to Greg Carter, Steve Hanna, Russ Housley, Charlie Kaufman, Tero Kivinen, Pekka Savola, Paul Hoffman, and Gregory Lebovitz for their valuable comments, some of which have been incorporated verbatim into this document. Paul Knight performed the arduous task of converting the text to XML format.
作者はエリック・レスコラに特に感謝したがっています、原作者のひとり、それの或るものがこのドキュメントに逐語的に法人組織であった彼らの貴重なコメントのためのGreg Carter、スティーブ・ハンナ、ラスHousley、チャーリー・カウフマン、Tero Kivinen、ペッカSavola、ポール・ホフマン、およびグレゴリーLebovitzに加えて。 ポールKnightはXML形式にテキストを変換する激務を実行しました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[1] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[2] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol (ISAKMP)", RFC
2408, November 1998.
[2]Maughan、D.、シュナイダー、M.、およびM.Schertler、「協会とKey Managementが議定書の中で述べるインターネットセキュリティ(ISAKMP)」、RFC2408、1998年11月。
[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[3] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[4] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[5] 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.
[5]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[6] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[6] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
Korver Standards Track [Page 38] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[38ページ]
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[8] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[9] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request
Syntax Specification Version 1.7", RFC 2986, November 2000.
[9] ニストロム、M.、およびB.Kaliski、「PKCS#10:」 証明は2000年11月に構文仕様バージョン1.7インチ、RFC2986を要求します。
9.2. Informative References
9.2. 有益な参照
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[10] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, March
2005.
[11]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[12] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", RFC
3490, March 2003.
[12]Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[13] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[13] リン、C.、ケント、S.、およびK.Seo、「IPアドレスと識別子としてのX.509拡張子」、RFC3779、2004年6月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[14] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[15] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR):
The Internet Address Assignment and Aggregation Plan", BCP 122,
RFC 4632, August 2006.
[15] フラーとV.とT.李、「以下を掘る(CIDR)階級のない相互ドメイン」 「インターネットアドレス課題と集合は計画している」BCP122、RFC4632、2006年8月。
[16] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999.
[16] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[17] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005.
[17] ホフマンとP.とB.シュナイアー、「インターネットプロトコルの暗号のハッシュに対する攻撃」、RFC4270、2005年11月。
[18] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005.
[18]Schaad、J.、Kaliski、B.、R.Housley、および「中のインターネットX.509公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)が輪郭を描く使用のためのRSA Cryptographyのための追加AlgorithmsとIdentifiers」、RFC4055(2005年6月)
[19] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 4648, October 2006.
[19]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
Korver Standards Track [Page 39] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[39ページ]
Appendix A. The Possible Dangers of Delta CRLs
付録A.はデルタCRLsの可能な危険です。
The problem is that the CRL processing algorithm is sometimes written incorrectly with the assumption that all CRLs are base CRLs and it is assumed that CRLs will pass content validity tests. Specifically, such implementations fail to check the certificate against all possible CRLs: if the first CRL that is obtained from the keying material database fails to decode, no further revocation checks are performed for the relevant certificate. This problem is compounded by the fact that implementations that do not understand delta CRLs may fail to decode such CRLs due to the critical DeltaCRLIndicator extension. The algorithm that is implemented in this case is approximately:
問題はCRL処理アルゴリズムが時々すべてのCRLsがベースCRLsであるという仮定で不当に書かれていて、CRLsが内容的妥当性テストに合格すると思われるということです。 明確に、そのような実装はすべての可能なCRLsに対して証明書をチェックしません: 合わせることの物質的なデータベースから入手される最初のCRLが解読しないなら、さらなる取消しチェックは全く関連証明書のために実行されません。 デルタCRLsを理解していない実装が重要なDeltaCRLIndicator拡張子のためそのようなCRLsを解読しないかもしれないという事実によってこの問題は悪化させられます。 この場合実装されるアルゴリズムはおよそ以下の通りです。
o fetch newest CRL
o 最も新しいCRLをとって来てください。
o check validity of CRL signature
o CRL署名の正当性をチェックしてください。
o if CRL signature is valid, then
o 次に、CRL署名が有効であるなら
o if CRL does not contain unrecognized critical extensions and
certificate is on CRL, then set certificate status to revoked
o CRLが認識されていない重要な拡大を含んでいなくて、証明書がCRLにあるなら、証明書状態を取り消されるのに設定してください。
The authors note that a number of PKI toolkits do not even provide a method for obtaining anything but the newest CRL, which in the presence of delta CRLs may in fact be a delta CRL, not a base CRL.
作者は、多くのPKIツールキットが事実上、ベースではなく、デルタCRLsの面前でCRL CRLデルタであるかもしれない最も新しいCRL以外の何も得るためのメソッドを提供さえしないことに注意します。
Note that the above algorithm is dangerous in many ways. See the PKIX [5] certificate profile for the correct algorithm.
上のアルゴリズムが様々な意味で危険であることに注意してください。 正しいアルゴリズムのためのPKIX[5]証明書プロフィールを見てください。
Appendix B. More on Empty CERTREQs
さらに空のCERTREQsの上の付録B.
Sending empty certificate requests is commonly used in implementations, and in the IPsec interop meetings, vendors have generally agreed that it means that send all/any end-entity certificates you have (if multiple end-entity certificates are sent, they must have same public key, as otherwise, the other end does not know which key was used). For 99% of cases, the client has exactly one certificate and public key, so it really doesn't matter, but the server might have multiple; thus, it simply needs to say to the client, use any certificate you have. If we are talking about corporate VPNs, etc., even if the client has multiple certificates or keys, all of them would be usable when authenticating to the server, so the client can simply pick one.
空の証明書要求を送るのは実装に一般的に使用されます、そして、一般に、IPsec interopミーティングでは、ベンダーはそれがどんな終わり実体証明書もすべての/に送ることを(それらには、複数の終わり実体証明書を送るなら、同じ公開鍵がなければなりません、もう一方の端が、どのキーが使用されたかをさもなければ、知らないとき)意味するのに同意しました。 99%のケースのために、サーバには、クライアントでは、まさに1通の証明書と公開鍵がありますが、したがって、本当に重要ではありませんが、倍数があるかもしれません。 それは、単にしたがって、あらゆる証明書を使用するようにクライアントに言う必要があります。 サーバに認証するとき、クライアントが複数の証明書かキーを持っても私たちが法人のVPNsなどに関して話しているなら、それらは皆、使用可能でしょう、したがって、クライアントが単に1つを選ぶことができます。
If there is some real difference on which certificate to use (like ones giving different permissions), then the client must be configured anyway, or it might even ask the user which one to use
次に、とにかくクライアントを構成しなければならない、どの証明書を使用したらよいか(異なった許容を与えるもののように)何らかの本当の違いがある、またはさもなければ、どれを使用したらよいかをユーザに尋ねるかもしれなくても
Korver Standards Track [Page 40] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[40ページ]
(the user is the only one who knows whether he needs admin privileges, thus needs to use admin cert, or if the normal email privileges are ok, thus uses email only cert).
(ユーザが彼が、その結果、アドミン本命を使用する必要があるかどうか、アドミン特権が必要があって、または正常なメール特権が間違いないかどうかを知っている唯一の人である、その結果、用途は本命だけにメールします。)
In 99% of the cases, the client has exactly one certificate, so it will send it. In 90% of the rest of the cases, any of the certificates is ok, as they are simply different certificates from the same CA, or from different CAs for the same corporate VPN, thus any of them is ok.
ケースの99%では、クライアントにはまさに1通の証明書があるので、それはそれを送るでしょう。 ケースの残りの90%では、証明書のどれかは間違いありません、それらが同じカリフォルニアからの単に同じ法人のVPNのための異なったCAsと、異なった証明書であるかその結果、彼らのいずれも間違いありません。
Sending empty certificate requests has been agreed there to mean "give me your cert, any cert".
空の証明書要求を送るのは、「あなたの本命、どんな本命も私に与えます」と意味するためにそこで同意されました。
Justification:
正当化:
o Responder first does all it can to send a CERTREQ with a CA, check
for IP match in SPD, have a default set of CAs to use in ambiguous
cases, etc.
o 応答者は最初にカリフォルニアがあるCERTREQを送るためにそれができるすべてをして、IPマッチがないかどうかSPDでチェックしてください、そして、あいまいなケースなどに使用するCAsのデフォルトセットを持ってください。
o Sending empty CERTREQs is fairly common in implementations today,
and is generally accepted to mean "send me a certificate, any
certificate that works for you".
o 送付の空のCERTREQsを今日、実装でかなり一般的であり、一般に、「証明書を私に送ってください、あなたのために働いているどんな証明書も」と意味するために受け入れます。
o Saves responder sending potentially hundreds of certs, the
fragmentation problems that follow, etc.
o 潜在的に何百人もの本命、断片化に従う問題などを送る応答者を救います。
o In +90% of use cases, Initiators have exactly one certificate.
o +90%の使用で、Initiatorsには、ケースであり、まさに1通の証明書があります。
o In +90% of the remaining use cases, the multiple certificates it
has are issued by the same CA.
o 残りの+90%では、ケース、それが同じカリフォルニアによって発行された複数の証明書を使用してください。
o In the remaining use case(s) -- if not all the others above -- the
Initiator will be configured explicitly with which certificate to
send, so responding to an empty CERTREQ is easy.
o 残っている使用で、空のCERTREQに応じるのは、ケース--まして、上のすべての他のもの--Initiatorがどの証明書によって明らかに構成されるか、そして、発信するので、簡単です。
The following example shows why initiators need to have sufficient policy definition to know which certificate to use for a given connection it initiates.
以下の例は、創始者がなぜそれが開始する与えられた接続にどの証明書を使用したらよいかを知ることができるくらいの方針定義を必要とするかを示します。
EXAMPLE: Your client (initiator) is configured with VPN policies for gateways A and B (representing perhaps corporate partners).
例: あなたのクライアント(創始者)はVPN方針によってゲートウェイAとBに構成されます(恐らく企業パートナーの代理をして)。
Korver Standards Track [Page 41] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[41ページ]
The policies for the two gateways look something like:
2門への方針は何かに似ています:
Acme Company policy (gateway A)
Engineering can access 10.1.1.0
Trusted CA: CA-A, Trusted Users: OU=Engineering
Partners can access 20.1.1.0
Trusted CA: CA-B, Trusted Users: OU=AcmePartners
頂上会社方針(ゲートウェイA)工学は10.1に.1.0Trustedカリフォルニアにアクセスできます: カリフォルニア-A、信じられたユーザ: 工学OU=Partnersは20.1に.1.0Trustedカリフォルニアにアクセスできます: カリフォルニア-B、信じられたユーザ: OU=AcmePartners
Bizco Company policy (gateway B)
Sales can access 30.1.1.0
Trusted CA: CA-C, Trusted Users: OU=Sales
Partners can access 40.1.1.0
Trusted CA: CA-B, Trusted Users: OU=BizcoPartners
Bizco会社方針(ゲートウェイB)販売は30.1に.1.0Trustedカリフォルニアにアクセスできます: カリフォルニア-C、信じられたユーザ: 販売OU=Partnersは40.1に.1.0Trustedカリフォルニアにアクセスできます: カリフォルニア-B、信じられたユーザ: OU=BizcoPartners
You are an employee of Acme and you are issued the following certificates:
あなたはAcmeの従業員です、そして、以下の証明書をあなたに発行します:
o From CA-A: CN=JoeUser,OU=Engineering o From CA-B: CN=JoePartner,OU=BizcoPartners
o カリフォルニア-A:から CN=JoeUser、OUは工学o Fromカリフォルニア-Bと等しいです: CN=JoePartner、OU=BizcoPartners
The client MUST be configured locally to know which CA to use when connecting to either gateway. If your client is not configured to know the local credential to use for the remote gateway, this scenario will not work either. If you attempt to connect to Bizco, everything will work... as you are presented with responding with a certificate signed by CA-B or CA-C... as you only have a certificate from CA-B you are OK. If you attempt to connect to Acme, you have an issue because you are presented with an ambiguous policy selection. As the initiator, you will be presented with certificate requests from both CA-A and CA-B. You have certificates issued by both CAs, but only one of the certificates will be usable. How does the client know which certificate it should present? It must have sufficiently clear local policy specifying which one credential to present for the connection it initiates.
どちらのゲートウェイにも接続するとき、どのカリフォルニアを使用したらよいかを知るために局所的にクライアントを構成しなければなりません。 あなたのクライアントがリモートゲートウェイの使用へのローカルの信任状を知るために構成されないと、このシナリオは働かないでしょう。 あなたが、Bizcoに接続するのを試みると、すべてが働くでしょう… 証明書で応じるのは、あなたを与えるので、カリフォルニア-Bかカリフォルニア-C.にサインしました。カリフォルニア-Bからのa証明書があるだけであるとき、あなたはOKです。 あいまいな方針選択をあなたに与えるので、Acmeに接続するのを試みるなら、あなたには、問題があります。 創始者として、証明書要求をカリフォルニア-Aとカリフォルニア-Bの両方からあなたに与えるでしょう。 あなたは両方のCAsに証明書を発行させますが、証明書の1つだけが使用可能になるでしょう。 クライアントは、それがどの証明書を提示するべきであるかをどのように知っていますか? それには、それが開始する接続のためにどの1つの信任状を提示したらよいかを指定する十分明確なローカルの方針がなければなりません。
Author's Address
作者のアドレス
Brian Korver Network Resonance, Inc. 2483 E. Bayshore Rd. Palo Alto, CA 94303 US
ブライアンKorverネットワーク共鳴Inc.2483E.Bayshore通り パロアルト、カリフォルニア94303米国
Phone: +1 650 812 7705 EMail: briank@networkresonance.com
以下に電話をしてください。 +1 7705年の650 812メール: briank@networkresonance.com
Korver Standards Track [Page 42] RFC 4945 PKI Profile for IKE/ISAKMP/PKIX August 2007
RFC4945PKIが2007年8月にイケ/ISAKMP/PKIXのために輪郭を描くKorver標準化過程[42ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Korver Standards Track [Page 43]
Korver標準化過程[43ページ]
一覧
スポンサーリンク
