Network Working Group A. Colegrove
Request for Comments: 4534 H. Harney
Category: Standards Track SPARTA, Inc.
June 2006
Group Security Policy Token v1
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token.
グループセキュリティポリシーのトークンは、このような安全なマルチキャストグループとしての暗号化グループ、のセキュリティポリシーおよび設定可能なパラメータを指定するために使用される構造です。グループのセキュリティは、複数のセキュリティサービス、メカニズム、および通信インフラストラクチャ全体の属性の全体から構成されているので、システム全体でサポートされなければならない機能の認証可能表現は、一貫したセキュリティを確保するために必要とされます。この文書では、このようなトークンの構造を指定します。
Table of Contents
目次
1. Introduction ....................................................3
2. Token Creation and Receipt ......................................4
3. The Policy Token ................................................5
3.1. Token Identifiers ..........................................6
3.2. Registration Policy ........................................6
3.3. Rekey Policy ...............................................7
3.4. Group Data Policy ..........................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
6. References.......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
7. Acknowledgements ...............................................10
Appendix A. Core Policy Token ASN.1 Module ........................11
Appendix B. GSAKMPv1 Base Policy ..................................13
B.1. GSAKMPv1 Registration Policy ..............................13
B.1.1. Authorization .......................................13
B.1.2. AccessControl .......................................14
B.1.3. JoinMechanisms ......................................15
B.1.3.1. alaCarte ...................................15
B.1.3.2. suite ......................................17
B.1.4. Transport ...........................................17
B.2. GSAKMPv1 Registration ASN.1 Module ........................17
B.3. GSAKMPv1 De-Registration Policy ...........................20
B.4. GSAKMPv1 De-Registration ASN.1 Module .....................21
B.5. GSAKMPv1 Rekey Policy .....................................22
B.5.1. Rekey Authorization ................................22
B.5.2. Rekey Mechanisms ...................................23
B.5.3. Rekey Event Definition .............................23
B.5.4. Rekey Methods ......................................24
B.5.4.1 Rekey Method NONE ..........................24
B.5.4.2 Rekey Method GSAKMP LKH ....................24
B.5.5 Rekey Interval ......................................25
B.5.6 Rekey Reliability ...................................25
B.5.6.1 Rekey Reliability Mechanism None ............25
B.5.6.2 Rekey Reliability Mechanism Resend ..........25
B.5.6.3 Rekey Reliability Mechanism Post ............26
B.5.7 Distributed Operation Policy ........................26
B.5.7.1 No Distributed Operation ....................26
B.5.7.2 Autonomous Distributed Mode .................26
B.6. GSAKMPv1 Rekey Policy ASN.1 Module ........................27
Appendix C. Data SA Policy ........................................30
C.1. Generic Data Policy .......................................30
C.2. Generic Data Policy ASN.1 Module ..........................30
The Multicast Group Security Architecture [RFC3740] defines the security infrastructure to support secure group communications. The policy token assumes this architecture in its definition. It defines the enforceable security parameters for a Group Secure Association.
マルチキャストグループのセキュリティアーキテクチャ[RFC3740]は、安全なグループ通信をサポートするためのセキュリティインフラストラクチャを定義します。ポリシーのトークンは、その定義にこのアーキテクチャを前提としています。これは、グループセキュア協会強制力のセキュリティパラメータを定義します。
The policy token is a verifiable data construct signed by the Group Owner, the entity with the authorization to create security policy. The group controllers in a group will use the policy token to ensure that the mechanisms used to secure the group are correct and to enforce the access control rules for joining members. The group members, who may contribute data to the group or access data from the group, will use the policy token to ensure that the group is owned by a trusted authority. Also, the members may want to verify that the access control rules are adequate to protect the data that the member is submitting to the group.
ポリシーのトークンは、グループ所有者、セキュリティポリシーを作成する権限を持つエンティティによって署名検証データ構造です。グループ内のグループコントローラはグループを保護するために使用されるメカニズムが正しいことを確認し、部材を接合するためのアクセス制御規則を適用するポリシー・トークンを使用します。グループからグループまたはアクセスのデータに貢献するかもしれないグループのメンバーは、グループが信頼できる機関によって所有されていることを確認するために、ポリシートークンを使用します。また、メンバーは、アクセス制御ルールは、メンバーがグループに提出されたデータを保護するのに十分であることを確認することをお勧めします。
The policy token is specified in ASN.1 [X.208] and is to be DER [X.660] encoded. This specification ability allows the token to easily import group definitions that span different applications and environments. ASN.1 allows the token to specify branches that can be used by any multicast security protocol. Any group can use this policy token structure to specify the use of multiple protocols in securing the group.
ポリシートークンはASN.1 [X.208]で指定し、DERは[X.660]符号化されるています。この仕様能力は、トークンが簡単に別のアプリケーションや環境にまたがるグループ定義をインポートすることができます。 ASN.1は、トークンがどのマルチキャストセキュリティプロトコルで使用することができます枝を指定することができます。任意のグループは、グループの確保に複数のプロトコルの使用を指定するには、このポリシー・トークン構造体を使用することができます。
Care was taken in this specification to provide a core level of token specificity that would allow ease of extensibility and flexibility in supporting mechanisms. This was done by using the following abstracted construct:
注意が支持機構に拡張性と柔軟性の容易さを可能にするトークンの特異性のコアレベルを提供するために、本明細書に取りました。これは、次の抽象化された構文を使用して行われました。
Mechanism ::= SEQUENCE {
mechanismIdentifier OBJECT IDENTIFIER,
mechanismParameters OCTET STRING
}
This construct will allow the use of group mechanisms specified in other documents with the policy token.
この構築物は、ポリシーのトークンを使用して他のドキュメントで指定されたグループのメカニズムを使用することができるようになります。
The policy token is structured to reflect the MSEC Architecture layers for a Group Security Association. Each of the architectural layers is identified and given a branch in the "Core" token. This allows a high degree of flexibility for future protocol specifications at each architectural layer without the need to change the "Core" policy token, which can then act as a single point of reference for defining secure groups using any mix of protocols for any number of environments.
ポリシーのトークンは、グループセキュリティ協会MSECアーキテクチャ層を反映するように構成されています。建築層のそれぞれが識別され、「コア」トークンに支店を与えています。これは、次いで、任意の数のプロトコルの任意の組み合わせを使用して安全なグループを定義するための基準の一点として作用することができる「コア」ポリシー・トークンを、変更することなく、各建築層における将来のプロトコル仕様のための高度の柔軟性を可能にします環境。
At the time of group creation or whenever the policy of the group is updated, the Group Owner will create a new policy token.
グループの作成やグループのポリシーが更新されるたびに、グループの所有者は、新しいポリシーのトークンを作成する時に。
To ensure authenticity of the specified policy, the Token MUST be signed by the Group Owner. The signed token MUST be in accordance with the Cryptographic Message Syntax (CMS) [RFC3852] SignedData type.
指定されたポリシーの信憑性を確保するために、トークンは、グループ所有者によって署名されなければなりません。署名されたトークンは、暗号メッセージ構文（CMS）[RFC3852]のSignedData種類に応じなければなりません。
The content of the SignedData is the token itself. It is represented with the ContentType object identifier of
SignedDataの内容は、トークンそのものです。これは、ののContentTypeオブジェクト識別子で表されます。
id-ct-msec-token OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.1.1}
The CMS sid value of the SignerInfo, which identifies the public key needed to validate the signature, MUST be that of the Group Owner.
署名を検証するために必要な公開鍵を特定のSignerInfoのCMSのSID値は、グループの所有者のものでなければなりません。
The signedAttrs field MUST be present. In addition to the minimally required fields of signedAttrs, the signing-time attribute MUST be present.
signedAttrsフィールドが存在しなければなりません。 signedAttrsの最低限必要なフィールドに加えて、署名時の属性が存在しなければなりません。
Upon receipt of a policy token, the recipient MUST check that
ポリシーのトークンを受信すると、受信者はそれをチェックしなければなりません
- the Group Owner, as identified by the sid in the SignerInfo, is the expected entity.
- グループの所有者は、のSignerInfoにSIDによって識別されるように、予想されるエンティティです。
- the signing-time value is more recent than the signing-time value seen in a previously received policy token for that group, or the policy token is the first token seen by the recipient for that group.
- 署名タイム値は、そのグループのために以前に受信したポリシートークンに見署名タイム値よりも新しい、またはポリシートークンは、そのグループの受信者が見る最初のトークンです。
- the processing of the signature successfully validates in accordance with RFC 3852.
- 署名の処理が正常にRFC 3852に従って検証します。
- the specified security and communication mechanisms (or at least one mechanism of each choice) are supported and are in compliance with the recipient's local policy.
- 指定されたセキュリティと通信メカニズム（または各選択された少なくとも一つのメカニズム）がサポートされ、受信者のローカルポリシーに準拠しているれています。
The structure of the policy token is as follows:
次のように方針トークンの構造は次のとおりです。
Token ::= SEQUENCE {
tokenInfo TokenID,
registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol
}
tokenInfo provides information about the instance of the Policy Token (PT).
tokenInfoは、ポリシー・トークン（PT）のインスタンスに関する情報を提供します。
registration provides a list of acceptable registration and de-registration policy and mechanisms that may be used to manage member-initiated joins and departures from a group. A NULL sequence indicates that the group does not support registration and de-registration of members. A member MUST be able to support at least one set of Registration mechanisms in order to join the group. When multiple mechanisms are present, a member MAY use any of the listed methods. The list is ordered in terms of Group Owner preference. A member MUST choose the highest listed mechanism that local policy supports.
登録が許容される登録および登録解除ポリシー部材が開始グループから参加及び離脱を管理するために使用することができる機構のリストを提供します。 NULL列は、グループが登録し、会員の登録解除をサポートしていないことを示しています。メンバーがグループに参加するために登録機構の少なくとも一つのセットをサポートすることができなければなりません。複数の機構が存在する場合、メンバーは、リストされた方法のいずれかを使用するかもしれません。リストは、グループの所有者の嗜好の観点から発注されます。メンバーは、ローカルポリシーがサポートする最高の記載されているメカニズムを選択する必要があります。
rekey provides the rekey protocols that will be used in managing the group. The member MUST be able to accept one of the types of rekey messages listed. The list is ordered in terms of Group Owner preference. A member MUST choose the highest listed mechanism that local policy supports.
リキーは、グループの管理に使用されるキーの再生成プロトコルを提供します。メンバーがリストされているリキーメッセージのタイプのいずれかを受け入れることができなければなりません。リストは、グループの所有者の嗜好の観点から発注されます。メンバーは、ローカルポリシーがサポートする最高の記載されているメカニズムを選択する必要があります。
data provides the applications used in the communications between group members. When multiple applications are provided, the order of the list implies the order of encapsulation of the data. A member MUST be able to support all the listed applications and if any choices of mechanisms are provided per application, the member MUST support at least one of the mechanisms.
データは、グループのメンバー間の通信に使用されるアプリケーションを提供します。複数のアプリケーションが提供されている場合は、リストの順序は、データのカプセル化の順序を意味しています。メンバーは、リストされたすべてのアプリケーションをサポートすることができなければならず、機構の任意選択肢は、アプリケーションごとに設けられている場合、メンバーは、機構の少なくとも一つをサポートしなければなりません。
For the registration, rekey, and data fields, implementations encountering unknown protocol identifiers MUST handle this gracefully by providing indicators that an unknown protocol is among the sequence of permissible protocols. If the unknown protocol is the only allowable protocol in the sequence, then the implementation cannot support that field, and the member cannot join the group. It is a matter of local policy whether a join is permitted when an unknown protocol exists among the allowable, known protocols.
登録のために、リキー、及びデータフィールドは、未知のプロトコル識別子に遭遇する実装は、未知のプロトコルが許容プロトコルのシーケンスの中にある指標を提供することにより、正常にこれを処理しなければなりません。不明なプロトコルがシーケンスの唯一の許容プロトコルである場合、実装は、そのフィールドをサポートすることはできませんし、メンバーがグループに参加することはできません。これは、未知のプロトコルが許容、既知のプロトコル間に存在するときの参加が許可されているかどうかのローカルポリシーの問題です。
Protocols in addition to registration, rekey, and data SHOULD NOT be added to subsequent versions of this Token unless the MSEC architecture changes.
登録に加えてプロトコル、再入力、及びデータはMSECアーキテクチャの変更がない限り、このトークンの後続バージョンに追加しないでください。
Each data field of the PT is specified further in the following sections.
PTの各データフィールドは、以下のセクションでさらに指定されています。
tokenInfo explicitly identifies a version of the policy token for a particular group. It is defined as
tokenInfoは、明示的に特定のグループのポリシートークンのバージョンを識別します。それは以下のように定義されます
TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1),
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
tokenDefVersion is the version of the Group Policy Token Specification. This specification (v1) is represented as one (1). Changes to the structure of the Group Security Policy Token will require an update to this field.
tokenDefVersionは、グループポリシートークン仕様のバージョンです。この仕様（V1）がオン（1）のように表されます。グループセキュリティポリシートークンの構造の変更は、この分野へのアップデートが必要になります。
groupName is the identifier of the group and MUST be unique relative to the Group Owner.
グループ名は、グループの識別子であり、グループの所有者に対して一意でなければなりません。
edition is an optional INTEGER indicating the sequence number of the PT. If edition is present, group entities MUST accept a PT only when the value is greater than the last value seen in a valid PT for that group.
版は、PTのシーケンス番号を示すオプションの整数です。版が存在する場合、グループ企業は、値がそのグループの有効なPTで見られる最後の値よりも大きい場合にのみ、PTを受け入れなければなりません。
The type LifeDate is also defined to provide standard methods of indicating timestamps and intervals in the Tokens.
型LifeDateはまた、トークンのタイムスタンプとの間隔を指示する標準的な方法を提供することで定義されます。
LifeDate ::= CHOICE {
gt GeneralizedTime,
utc UTCTime,
interval INTEGER
}
The registration security association (SA) is defined in the MSEC Architecture. During registration, a prospective group member and the group controller will interact to give the group member access to the keys and information it needs to join the group and participate in the group Data SA.
登録セキュリティアソシエーション（SA）はMSECアーキテクチャで定義されています。登録時に、将来のグループメンバーとグループコントローラは、それがグループに参加し、グループデータSAに参加する必要があり、キーや情報へのグループメンバーへのアクセスを与えるために相互作用します。
The de-registration piece allows a current group member to notify the Group Controller Key Server (GC/KS) that it will no longer be participating in the Data SA.
登録解除片が現在のグループのメンバーが、それはもはやデータSAに参加しないことをグループコントローラキーサーバー（GC / KS）に通知することができます。
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
The protocols for registration and de-registration are each specified as
登録および登録解除するためのプロトコルは、各として指定され
GroupMngmtProtocol ::= CHOICE {
none NULL,
supported Protocol
}
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
For example, register might be specified as the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] registration protocol. The OBJECT IDENTIFIER TBS would be followed by the parameters used in GSAKMP registration as specified in Appendix B.1.
例えば、レジスタは、グループセキュア協会鍵管理プロトコル（GSAKMP）[RFC4535]登録プロトコルとして指定される可能性があります。オブジェクト識別子TBSは、付録B.1に指定されているGSAKMP登録に使用されるパラメータが続くことになります。
The Rekey SA is defined in the MSEC Architecture. During the Rekey of a group, several changes can potentially be made:
リキーSAはMSECアーキテクチャで定義されています。グループのキーの再生成中、いくつかの変更が潜在的に行うことができます。
- refresh/change group protection keys,
- リフレッシュ/変更グループ保護キー、
- update the policy token,
- ポリシーのトークンを更新し、
- change the group membership.
- グループメンバーシップを変更します。
During Rekey, the membership of the group can be modified as well as refreshing the group traffic protection keys and updating the Policy Token.
キーの再生成中、グループのメンバーシップは、グループトラフィック保護キーをリフレッシュし、ポリシートークンの更新だけでなく、変更することができます。
This field is also specified as a sequence of protocols that will be used by the GC/KS.
このフィールドは、GC / KSによって使用されるプロトコルのシーケンスとして指定されています。
The Data SA is the ultimate consumer of the group keys. The data field will indicate the keys and mechanisms that are to be used in communications between group members. There are several protocols that could make use of group keys, ranging from simple security applications that only need key for encryption and/or integrity protection to more complex configurable security protocols such as IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711]. The sequencing of the Data SA mechanisms are from "inside" to "outside". That is, the first Data SA defined in a policy token must act on the raw data. Any Data SA specified after that will be applied in turn.
データSAは、グループキーの最終的な消費者です。データフィールドは、グループのメンバー間の通信に使用されるキーおよび機構を示すであろう。唯一のIPsecなど、より複雑な設定可能なセキュリティプロトコルに暗号化および/または完全性保護のためのキーを必要とするシンプルなセキュリティ・アプリケーションに至るまで、グループ鍵を利用し、リアルタイムトランスポートプロトコル（SRTP）を確保でき、いくつかのプロトコルがあります[RFC3711] 。データSAメカニズムの配列決定は、「内部」から「外部」にあります。つまり、ポリシーのトークンで定義された最初のデータSAは、生データに基づいて行動しなければなりません。その後指定されたデータSAは、順番に適用されます。
DataProtocol ::= Protocol
This document specifies the structure for a group policy token. As such, the structure as received by a group entity must be verifiably authentic. This policy token uses CMS to apply authentication through digital signatures. The security of this scheme relies upon a secure CMS implementation, choice of signature mechanism of appropriate strength for the group using the policy token, and secure, sufficiently strong keys. Additionally, it relies upon knowledge of a well-known Group Owner as the root of policy enforcement.
この文書では、グループポリシートークンの構造を指定します。このように、グループエンティティによって受信されるような構造は、検証可能本物でなければなりません。このポリシートークンは、デジタル署名による認証を適用するためにCMSを使用しています。この方式のセキュリティは、安全なCMSの実装、ポリシーのトークンを使用して、グループに適切な強度の署名メカニズムの選択、および安全な、十分に強力なキーに依存しています。さらに、それは、ポリシー施行のルートとしてよく知られているグループの所有者の知識に依存しています。
Furthermore, while the Group Owner may list alternate mechanisms for various functions, the group is only as strong as the weakest accepted mechanisms. As such, the Group Owner is responsible for providing only acceptable security mechanisms.
グループの所有者は、様々な機能のための代替メカニズムをリストするかもしれないがまた、グループは、最も弱い受け入れメカニズムとしてのみとして強いです。そのため、グループの所有者のみ許容できるセキュリティメカニズムを提供する責任があります。
The following object identifiers have been assigned:
以下のオブジェクト識別子が割り当てられています：
- id-ct-msec-token OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.1.1
- id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
- id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
- id-GSAKMPv1DeRegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
- id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
- id-rekeyMethodGSAKMPLKH
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
- id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
- id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
- id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
- id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
- id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1
The Group Security Policy Token can be extended through specification. Extensions in the form of objects can be registered through IANA. Extensions requiring changes to the protocol structure will require an update to the tokenDefVersion field of the TokenID (see Section 3.1).
グループセキュリティポリシーのトークンは、仕様によって拡張することができます。オブジェクトの形で機能拡張は、IANAによって登録することができます。プロトコル構造の変更を必要とする拡張機能はのTokenIdのtokenDefVersionフィールドの更新を必要とするであろう（セクション3.1を参照）。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[X.208] Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988.
[X.208]勧告X.208、抽象構文記法1（ASN.1）、1988の仕様。
[X.660] Recommendation X.660, Information Technology ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1997.
[X.660]勧告X.660、情報技術ASN.1符号化規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）、1997。
[HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP Token Specification", Work in Progress, February 2003.
[HCLM00]ハーニー、H.、Colegrove、A.、ラフ、P.、およびU.論、 "GSAKMPトークン仕様"、進歩、2003年2月での作業。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。
[HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy in Secure Groups", Proceedings of Network and Distributed Systems Security 2001 Internet Society, San Diego, CA, February 2001.
[HCM01] H.ハーニー、A. Colegrove、P.マクダニエル、「セキュア・グループにおける政策の原則」、ネットワークの議事および分散システムのセキュリティ2001インターネット協会、サンディエゴ、CA、2001年2月。
[HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "Group Security Policy Token: Definition and Payloads", Work in Progress, August 2003.
[HHMCD01] Hardjono、T.、ハーニー、H.、マクダニエル、P.、Colegrove、A.、およびP. Dinsmore、 "グループセキュリティポリシートークン：定義とペイロード"、進歩、2003年8月の作業。
The following individuals deserve recognition and thanks for their contributions, which have greatly improved this specification: Uri Meth, whose knowledge of GSAKMP and tokens was greatly appreciated as well as his help in getting this document submitted; Peter Lough, Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work on earlier versions of policy tokens; George Gross for the impetus to have a well-specified, extensible policy token; and Rod Fleischer for catching implementation issues.
以下の個人が大幅にこの仕様を改善している彼らの貢献、の認識と感謝に値する：その知識GSAKMPとトークンの大幅提出し、この文書を得ることに彼の助けだけでなく、高く評価されたウリメタ;ピーター・ラフ、トーマスHardjono、パトリック・マクダニエル、そしてピートDinsmore政策トークンの以前のバージョンに自分の仕事のために。弾みのためのジョージ・グロスは、よく指定された、拡張可能なポリシーのトークンを持っています。ロッドフライシャー、実装上の問題を捕捉します。
The following technical works influenced the design of the Group Security Policy Token: [HCLM00], [HCM01], and [HHMCD01]
[HCLM00]、[HCM01]、および[HHMCD01]：以下の技術的な作品は、グループセキュリティポリシートークンのデザインに影響を与えました
Appendix A. Core Policy Token ASN.1 Module
付録A.基本方針トークンASN.1モジュール
PolicyToken {1.3.6.1.5.5.12.0.1}
PolicyToken {1.3.6.1.5.5.12.0.1}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
Token ::= SEQUENCE {
tokenInfo TokenID,
registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol
}
------------------------------------------------------------
-- Token ID
TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1), -- Group Security Policy Token v1
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
LifeDate ::= CHOICE {
gt GeneralizedTime,
utc UTCTime,
interval INTEGER
}
------------------------------------------------------------
-- Registration
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
------------------------------------------------------------
-- GroupMngmtProtocol
GroupMngmtProtocol ::= CHOICE {
none NULL,
supported Protocol
}
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
------------------------------------------------------------
-- DataProtocol
DataProtocol ::= Protocol
------------------------------------------------------------
END
終わり
Appendix B. GSAKMPv1 Base Policy
付録B. GSAKMPv1基本方針
This appendix provides the data structures needed for when GSAKMP exchanges are used as the GroupMngmtProtocol for the registration, de-registration, and/or Rekey SAs. This GSAKMP Base Policy specification assumes familiarity with GSAKMP.
この付録では、GSAKMP交換は、登録、登録抹消のためGroupMngmtProtocol、および/またはリキーのSAとして使用する場合に必要なデータ構造を提供します。このGSAKMP基本方針仕様はGSAKMPに精通している前提としています。
B.1. GSAKMPv1 Registration Policy
B.1。 GSAKMPv1登録ポリシー
When GSAKMP is used in the Group Management Protocol for registration, the following object identifier is used in the core token.
GSAKMPは、登録のためのグループ管理プロトコルで使用されている場合は、以下のオブジェクト識別子は、コア・トークンに使用されています。
id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.1}
The registration policy for GSAKMP provides 1) information on authorizations for group roles, 2) access control information for group members, 3) the mechanisms used in the registration process, and 4) information on what transport the GSAKMP registration exchange will use.
GSAKMPの登録ポリシーは、グループの役割、グループのメンバー、登録プロセスで使用される3）メカニズム、及びGSAKMP登録交換が使用するどのような輸送上の4）については、2）アクセス制御情報の権限に1）情報を提供します。
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
B.1.1. Authorization
B.1.1。認定
joinAuthorization provides information on who is allowed to be a Group Controller Key Server (GC/KS) and a sub-GC/KS. It also can indicate if there are limitations on who can send data in a group.
joinAuthorizationは、グループコントローラキーサーバー（GC / KS）とサブGC / KSことを許可するユーザーに関する情報を提供します。グループ内のデータを送信できるユーザーには制限がある場合にも示すことができます。
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
}
The authorization information is in the form of an access control list indicating entity name and acceptable certification authority information for the entity's certificate.
認証情報は、エンティティ名とエンティティの証明書のための許容可能な認証局情報を示すアクセス制御リストの形です。
GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID,
cA CertAuth
}
groupEntity is defined by type and value. The types are indicated by integers that correspond to the GSAKMP Identification types. When a portion of a defined name type is filled with an "*", this indicates a wildcard, representing any valid choice for a field. This allows the specification of an authorization rule that is a set of related names.
groupEntityは、タイプおよび値によって定義されます。タイプは、GSAKMP識別タイプに対応する整数で示しています。定義された名前のタイプの部分は「*」で満たされている場合は、このフィールドの有効な選択肢を表す、ワイルドカードを示します。これは、関連する名前の集合である認可ルールを指定できます。
GSAKMPID ::= SEQUENCE {
typeValue INTEGER,
typeData OCTET STRING
}
The certificate authority is identified by the X.509 [RFC3280] key identifier.
認証局は、X.509 [RFC3280]キー識別子によって識別されます。
CertAuth ::= KeyIdentifier
Senders within a group either can be all (indicating no sender restrictions) or can be an explicit list of those members authorized to send data.
グループ内の送信者のすべて（ない送信者の制限がないことを示す）ことができるか、それらのメンバーの明示的なリストのいずれかであることができるが、データを送信することを承認しました。
SenderAuthorization ::= CHOICE {
all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair
}
B.1.2. AccessControl
B.1.2。アクセス制御
joinAccessControl provides information on who is allowed to be a Group Member. The access control list is implemented as a set of permissions that the member must satisfy and a list of name rules and the certificate authority that each must satisfy. Additionally, a list of exclusions to the list may be provided.
joinAccessControlは、グループのメンバーであることを許可するユーザーに関する情報を提供します。アクセス制御リストは、メンバーが満たさなければならない一連の権限と名前ルールのリストとそれぞれが満たさなければならない証明機関として実装されています。また、リストに除外リストを提供することができます。
AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
}
The permissions initially available are an abstract set of numeric levels that may be interpreted internal to a community.
最初に利用可能なアクセス許可は、コミュニティの内部に解釈することができる数値レベルの抽象的集合です。
Permission ::= CHOICE {
simplePermission [1] SimplePermission
}
SimplePermission ::= ENUMERATED {
one(1),
two(2),
three(3),
four(4),
five(5),
six(6),
seven(7),
eight(8),
nine(9)
}
B.1.3. JoinMechanisms
B.1.3。 JoinMechanisms
Allowable GSAKMP mechanism choices for a particular group are specified in joinMechanisms. Any set of JoinMechanism is acceptable from a policy perspective.
特定のグループのための許容GSAKMP機構選択肢がjoinMechanismsで指定されています。 JoinMechanismの任意のセットは、ポリシーの観点から許容可能です。
JoinMechanisms ::= SEQUENCE OF JoinMechanism
Each set of mechanisms used in the GSAKMP Registration may be specified either as an explicitly defined set or as a pre-defined security suite.
GSAKMP登録に使用される機構の各セットは、明示的に定義されたセットとして、または事前定義されたセキュリティ・スイートのいずれかとして指定することができます。
JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms,
suite [1] SecuritySuite
}
B.1.3.1. alaCarte
B.1.3.1。アラカルト
In an explicitly defined -- or alaCarte -- set, a mechanism is defined for the signature, the key exchange algorithm, the key wrapping algorithm, the type of acknowledgement data, and configuration data for the setting of timeouts.
またはalaCarte - - 明示的に定義さに設定され、機構は、タイムアウトの設定のための署名、鍵交換アルゴリズム、鍵ラッピングアルゴリズム、確認応答データのタイプ、および構成データのために定義されています。
Mechanisms ::= SEQUENCE {
signatureDef SigDef,
kEAlg KEAlg,
keyWrap KeyWrap,
ackData AckData,
opInfo OpInfo
}
The signature definition requires specification of the signature algorithm for message signing. The INTEGER that defines the choice corresponds to the GSAKMP Signature type.
署名定義は、メッセージの署名のための署名アルゴリズムの仕様を必要とします。選択を定義する整数がGSAKMP署名タイプに対応します。
SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER
}
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP Nonce Hash type values. This algorithm is used in computing the combined nonce.
hashAlgorithmに対応するINTEGERはGSAKMPナンスハッシュタイプの値にマップされます。このアルゴリズムは、組み合わさnonceを計算する際に使用されます。
The key exchange algorithm requires an integer to define the GSAKMP key creation type and may require additional per type data.
鍵交換アルゴリズムは、GSAKMP鍵生成タイプを定義する整数を必要とし、追加あたりのタイプのデータを必要とするかもしれません。
KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL
}
The keyWrap is the algorithm that is used to wrap the group key(s) and the policy token (if included). The integer corresponds to the GSAKMP encryption type.
keyWrapグループ鍵（単数または複数）およびポリシートークン（含まれる場合）を包むために使用されるアルゴリズムです。整数はGSAKMPの暗号化の種類に対応しています。
KeyWrap ::= INTEGER
Data may potentially be returned in a GSAKMP Key Download ACK/Failure message. The type of data required by a group is specified by AckData. No such field is currently supported or required.
データは、潜在的にACK /失敗メッセージをダウンロードGSAKMPキーで返されることがあります。グループによって必要とされるデータの種類はAckDataによって指定されます。そのようなフィールドは、現在サポートされていないかが必要です。
AckData ::= CHOICE {
none [0] NULL
}
OpInfo provides configuration data for the operation of GSAKMP registration. timeOut indicates the elapsed amount of time before a sent message is considered to be misrouted or lost. It is specified as the timestamp type LifeDate, previously defined in the core token. terse informs a GC/KS whether the group should be operated in terse (TRUE) or verbose (FALSE) mode. The optional timestamp field indicates whether a timestamp (TRUE) or a nonce (FALSE) is used for anti-replay protection. If the field is absent, the use of nonces is the default mode for GSAKMP registration.
OpInfoはGSAKMP登録の操作のための構成データを提供します。タイムアウトは、送信されたメッセージが誤ってルーティングまたは紛失されたと見なされる前に、時間の経過量を示します。これは、以前にコアトークンで定義されたタイムスタンプ型LifeDateとして指定されています。簡潔には、グループは簡潔（TRUE）または冗長（FALSE）モードで動作する必要があるかどうかをGC / KSに通知します。オプションのタイムスタンプフィールドは、タイムスタンプ（TRUE）又はノンス（FALSE）はリプレイ保護のために使用されているかどうかを示します。フィールドが存在しない場合は、ナンスの使用はGSAKMP登録のデフォルトのモードです。
OpInfo ::= SEQUENCE {
timeOut LifeDate,
terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
}
B.1.3.2. suite
B.1.3.2。組
If the choice of mechanism for the join is a predefined security suite, then it is identified by OBJECT IDENTIFIER (OID). Other security suites may be defined elsewhere by specification and registration of an OID.
参加するためのメカニズムの選択は、事前に定義されたセキュリティスイートであれば、それはオブジェクト識別子（OID）によって識別されます。他のセキュリティスイートは、OIDの仕様と登録で他の場所で定義することができます。
SecuritySuite ::= OBJECT IDENTIFIER
The OID for security suite 1, as defined within the GSAKMPv1 specification, is
GSAKMPv1仕様に定義されるセキュリティ・スイート1のOIDは、あります
id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
B.1.4. Transport
B.1.4。輸送
transport indicates what protocol GSAKMP should ride over. The choice of udpRTJtcpOther indicates that the GSAKMP Request to Join message is carried by UDP and all other group establishment messages are carried by TCP.
トランスポートプロトコルGSAKMPが乗り越えるべきかを示しています。 udpRTJtcpOtherの選択は、メッセージに参加するGSAKMP要求はUDPで行われ、他のすべてのグループの確立メッセージは、TCPによって運ばれることを示しています。
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL,
udpRTJtcpOther [2] NULL
}
B.2. GSAKMPv1 Registration ASN.1 Module
B.2。 GSAKMPv1登録ASN.1モジュール
GSAKMPv1RegistrationSA {1.3.6.1.5.5.12.0.2}
GSAKMPv1RegistrationSA {1.3.6.1.5.5.12.0.2}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN EXPORTS GCKSName;
GCKSName輸出をBEGIN;
IMPORTS LifeDate FROM PolicyToken {1.3.6.1.5.5.12.0.1}
PolicyTokenからの輸入LifeDate {1.3.6.1.5.5.12.0.1}
KeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) };
PKIX1Implicit88 FROM KeyIdentifier {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙（19）}。
id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.7}
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
}
GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID,
cA CertAuth
}
CertAuth ::= KeyIdentifier
SenderAuthorization ::= CHOICE {
all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair
}
AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
}
Permission ::= CHOICE {
simplePermission [1] SimplePermission
}
SimplePermission ::= ENUMERATED {
one(1),
two(2),
three(3),
four(4),
five(5),
six(6),
seven(7),
eight(8),
nine(9)
}
GSAKMPID ::= SEQUENCE {
typeValue INTEGER,
typeData OCTET STRING
}
JoinMechanisms ::= SEQUENCE OF JoinMechanism
JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms,
suite [1] SecuritySuite
}
Mechanisms ::= SEQUENCE {
signatureDef SigDef,
kEAlg KEAlg,
keyWrap KeyWrap,
ackData AckData,
opInfo OpInfo
}
SecuritySuite ::= OBJECT IDENTIFIER
-- SECURITY SUITE ONE --
id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER
}
KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL
}
KeyWrap ::= INTEGER
AckData ::= CHOICE {
none [0] NULL
}
OpInfo ::= SEQUENCE {
timeOut LifeDate,
terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
}
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL,
udpRTJtcpOther [2] NULL
}
END
終わり
B.3. GSAKMPv1 De-Registration Policy
B.3。 GSAKMPv1登録解除ポリシー
GSAKMP de-registration provides a method to notify a (S-)GC/KS that a member needs to leave a group. When GSAKMP is the de-registration Protocol for the Group, the following object identifier is used in the core token.
GSAKMP登録解除は、メンバーがグループから脱退する必要がある（S-）GC / KSを通知するための方法を提供します。 GSAKMPは、グループの登録解除プロトコルである場合、以下のオブジェクト識別子は、コアトークンに使用されます。
id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::=
{1.3.6.1.5.5.12.3.2}
The de-registration policy provides the mechanisms needed for the de-registration exchange messages, an indication of whether the exchange is to be done using terse (TRUE) or verbose (FALSE) mode, and the transport used for the GSAKMP de-registration messages.
登録解除ポリシーが登録解除メッセージを交換するために必要な機構、交換は簡潔（TRUE）または冗長（FALSE）モードを使用して行われるべきかどうかの指示、及びGSAKMP登録解除メッセージのために使用されるトランスポートを提供します。
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
terse BOOLEAN,
transport Transport
}
The policy dictating the mechanisms needed for the de-registration exchange is defined by leaveMechanisms. This field is specified as
登録解除の交換に必要なメカニズムを規定ポリシーはleaveMechanismsによって定義されます。このフィールドは、次のように指定されています
LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER,
cA KeyIdentifier
}
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP Signature type values. This algorithm set is to be used for message signing.
sigAlgorithmに対応する整数は、GSAKMP署名タイプの値にマッピングされます。このアルゴリズムセットは、メッセージの署名に使用されます。
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP Nonce Hash type values. This algorithm is used in computing the combined nonce.
hashAlgorithmに対応するINTEGERはGSAKMPナンスハッシュタイプの値にマップされます。このアルゴリズムは、組み合わさnonceを計算する際に使用されます。
cA represents a trust point off of which the signer's certificate must certify. It is identified by the Public Key Infrastructure for X.509 Certificates (PKIX) KeyIdentifier [RFC3280] type.
CAは、署名者の証明書が証明する必要がありますオフその信頼ポイントを表します。これは、X.509証明書の公開鍵インフラストラクチャによって識別されます（PKIX）KeyIdentifierは、[RFC3280]と入力します。
transport will provide the expected transport for GSAKMP de-registration messages. Initially, either UDP or TCP will be the policy for a group.
輸送はGSAKMP登録解除メッセージのために期待されるトランスポートを提供します。最初は、UDPまたはTCPのいずれかは、グループのポリシーになります。
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL
}
B.4. GSAKMPv1 De-Registration ASN.1 Module
B.4。 GSAKMPv1登録解除ASN.1モジュール
GSAKMPv1DeRegistrationSA {1.3.6.1.5.5.12.0.3}
GSAKMPv1DeRegistrationSA {1.3.6.1.5.5.12.0.3}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
IMPORTS KeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) };
PKIX1Implicit88からの輸入KeyIdentifier {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙（19）} ;
id-GSAKMPv1DeRegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.2}
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
transport Transport
}
LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER,
cA KeyIdentifier
}
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL
}
END
終わり
B.5. GSAKMPv1 Rekey Policy
B.5。 GSAKMPv1リキーポリシー
When GSAKMP is used as the Rekey Protocol for the Group, the following object identifier should be used in the core token as the rekey protocol:
GSAKMPはグループリキープロトコルとして使用される場合、以下のオブジェクト識別子はリキープロトコルとしてコアトークンに使用されるべきです。
id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.0.4}
The GSAKMP rekey policy provides authorization information, mechanisms for the GSAKMP rekey messages, indicators defining rekey event definitions that define when the GC/KS should send a rekey message, the protocol or method the rekey event will use, the rekey interval that will allow a member to recognize a failure in the rekey process, a reliability indicator that defines the method the rekey will use to increase the likelihood of a rekey delivery (if any), and finally an indication of how subordinate-GC/KSes will handle rekey. This policy also describes the specific rekey policy methods "None" and "GSAKMP LKH REKEY".
GSAKMP指標はGC / KSはリキーメッセージ、再入力イベントが使用するプロトコルまたは方法を可能にする鍵再生成間隔を送るべきときを定義リキーイベント定義を定義する、GSAKMPのためのメカニズムがメッセージをリキー、認証情報を提供するポリシーをリキーリキー処理に失敗したことを認識する部材、リキーを再入力送達（もしあれば）の可能性を増加させ、最終的に下位-GC / KSESはリキーを処理する方法を指示するために使用するメソッドを定義する信頼度インジケータ。このポリシーは、特定のキー再生成ポリシー・メソッド「なし」と「GSAKMP LKH REKEY」を説明しています。
GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization,
mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef,
rekeyMethod RekeyMethod,
rekeyInterval LifeDate,
reliability Reliability,
subGCKSInfo SubGCKSInfo
}
B.5.1. Rekey Authorization
B.5.1。認証キーを再生成
RekeyAuthorization ::= GCKSName
B.5.2. Rekey Mechanisms
B.5.2。リキーメカニズム
The policy dictating the mechanisms needed for rekey message processing is defined by RekeyMechanisms. This field is specified as
リキーメッセージ処理のために必要なメカニズムを規定ポリシーはRekeyMechanismsによって定義されます。このフィールドは、次のように指定されています
RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER
}
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP Signature type values. This algorithm set is to be used for message signing.
sigAlgorithmに対応する整数は、GSAKMP署名タイプの値にマッピングされます。このアルゴリズムセットは、メッセージの署名に使用されます。
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP Nonce Hash type values. This algorithm is used in computing the combined nonce.
hashAlgorithmに対応するINTEGERはGSAKMPナンスハッシュタイプの値にマップされます。このアルゴリズムは、組み合わさnonceを計算する際に使用されます。
B.5.3. Rekey Event Definition
B.5.3。イベント定義をキーの再生成
Rekey Event Definition provides information to the GC/KS about the system requirements for sending rekey messages. This allows definition of the rekey event in time as well as event-driven characteristics (a number of de-registration notifications as an example), or a combination of the two (e.g., after x de-registrations or 24 hours, whichever comes first).
イベント定義は、リキーメッセージを送信するためのシステム要件に関するGC / KSに情報を提供するキーの再生成。これは、時間だけでなく、イベント駆動型特性（一例として、登録解除通知の数）に再入力イベントの定義を可能にする、またはこの2つの組合せ（例えば、Xデ登録または24時間後に、いずれか早い方）。
RekeyEventDef ::= CHOICE {
none [0] NULL, -- never rekey
timeOnly [1] LifeDate, -- rekey every x units
event [2] INTEGER, -- rekey after x events
timeAndEvent [3] TimeAndEvent
}
The LifeDate specifies the maximum time a group should exist between rekeys. This does not require clock synchronization as this is used with respect to a local clock (a GC/KS clock for sending rekey messages or a member clock for determining whether a message has been missed).
LifeDateは、グループがキー更新の間に存在しなければならない最大時間を指定します。これは、ローカルクロック（リキーメッセージを送信するためのGC / KSクロックまたはメッセージが失われているかどうかを決定するための部材クロック）に対して使用され、これはクロック同期を必要としません。
The INTEGER corresponding to the event is an indicator of the number of events a group should sustain before a rekey message is sent. This defines the events between rekeys. An example of a relevant event is de-registration notifications.
イベントに対応する整数は、イベントグループの数のインジケータリキーメッセージが送信される前に維持すべきです。これは、キー更新の間でイベントを定義します。関連するイベントの例は、登録解除の通知です。
The TimeAndEvent is defined as a couple of the LifeDate and Integer policies.
TimeAndEventはLifeDateと整数政策のカップルのように定義されます。
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
B.5.4. Rekey Methods
B.5.4。メソッドのキーの再生成
The rekey method defines the policy of how the rekey is to be accomplished. This field is specified as
再入力方法は、キーの再生成が達成される方法のポリシーを定義します。このフィールドは、次のように指定されています
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING
}
The rekeyMethodType will define the rekey method to be used by the group.
rekeyMethodTypeグループによって使用されるキーの再生成方法を定義します。
The rekeyMethodInfo will supply the GMs with the information they need to operate in the correct rekey mode.
rekeyMethodInfoは、彼らが正しい鍵再生成モードで動作するために必要な情報でのGMを供給します。
B.5.4.1. Rekey Method NONE
B.5.4.1。メソッドNONEキーを再生成しません
The group defined to work without a rekey protocols supporting it is supported by the rekeyMethodType NONE. There is no RekeyMethodNoneInfo associated with this option.
それを支持リキープロトコルなしで動作するように定義されたグループはrekeyMethodTypeのNONEに支持されています。このオプションに関連したRekeyMethodNoneInfoはありません。
id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL
B.5.4.2. Rekey Method GSAKMP LKH
B.5.4.2。メソッドGSAKMP LKHをキーの再生成
The GSAKMP protocol specification defined an interpretation of the Logical Key Hierarchy (LKH) protocol as a rekey method. This method is supported by the following values.
GSAKMPプロトコル仕様は、再入力方法として論理鍵階層（LKH）プロトコルの解釈を定義しました。この方法は、以下の値によってサポートされています。
id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
RekeyMethodGSAKMPLKHInfo ::= INTEGER
The GSAKMP LKH method requires a gsakmp type value for identifying the cryptographic algorithm used to wrap the keys. This value maps to the GSAKMP encryption type.
GSAKMP LKH法は、キーをラップするために使用される暗号アルゴリズムを特定するためのGSAKMP型の値を必要とします。この値は、GSAKMP暗号化タイプにマップされます。
B.5.5. Rekey Interval
B.5.5。リキー間隔
Rekey interval defines the maximum delay the GM should see between valid rekeys. This provides a means to ensure the GM is synchronized, from a key management perspective, with the rest of the group. It is defined as a time/date stamp.
キーの再生成間隔は、GMが有効なキー更新の間見るべき最大遅延を定義します。これは、GMは、グループの残りの部分と、キー管理の観点から、同期されていることを確認する手段を提供します。これは、時間/日付スタンプのように定義されます。
B.5.6. Rekey Reliability
B.5.6。信頼性のキーの再生成
The rekey message in the GSAKMP protocol is a single push message. There are reliability concerns with such non-acknowledged messages (i.e., message exchange). The Reliability policy defines the mechanism used to deal with these concerns.
GSAKMPプロトコルにおける再入力メッセージは、単一のプッシュメッセージです。このような非定評のメッセージ（すなわち、メッセージ交換）を持つ信頼性の問題があります。信頼ポリシーは、これらの懸念に対処するために使用されるメカニズムを定義します。
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING
}
The reliability mechanism is defined by an OBJECT IDENTIFIER and the information needed to operate that mechanism is defined as reliabilityMechContent and is an OCTET STRING (as before).
信頼性の機構は、オブジェクト識別子によって定義され、その機構を動作させるために必要な情報がreliabilityMechContentとして定義され、（前と同様）オクテット列です。
B.5.6.1. Rekey Reliability Mechanism None
B.5.6.1。信頼性のメカニズムなしキーを再生成しません
In networks with adequate reliability, it may not be necessary to use a mechanism to improve reliability of the rekey message. For these networks the ReliabilityMechanism NONE is appropriate.
十分な信頼性のネットワークでは、リキーメッセージの信頼性を向上させる機構を使用する必要はないかもしれません。これらのネットワークではReliabilityMechanismなしは適切ではありません。
id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL
B.5.6.2. Rekey Reliability Mechanism Resend
B.5.6.2。信頼メカニズム再送信をキーの再生成
In networks with unknown or questionable reliability, it may be necessary to use a mechanism to improve reliability of the Rekey Message. For these networks, the ReliabilityMechanism RESEND is potentially appropriate. This mechanism has the GC/KS repeatedly sending out the same message.
未知の、または疑わしい信頼性のネットワークでは、リキーメッセージの信頼性を向上させるメカニズムを使用する必要があるかもしれません。これらのネットワークでは、ReliabilityMechanism RESENDは潜在的に適切です。このメカニズムは、GC / KSは、繰り返し同じメッセージを送信しています。
id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
ReliabilityResendInfo ::= INTEGER
The INTEGER value in the ReliabilityResendInfo indicates the number of times the message should be resent.
ReliabilityResendInfoの整数値は、メッセージが再送信されるべき回数を示します。
B.5.6.3. Rekey Reliability Mechanism Post
B.5.6.3。信頼メカニズムのポストをキーの再生成
Another reliability mechanism is to post the rekey message on some service that will make it generally available. This is the reliabilityPost method.
別の信頼性のメカニズムは、それが一般的に利用できるようになりますいくつかのサービスにリキーメッセージを投稿することです。これはreliabilityPost方法です。
id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
ReliabilityContentPost ::= IA5String
The IA5String associated with ReliabilityPost is the identifier of the posting site and rekey message.
ReliabilityPostに関連付けられているIA5Stringは、投稿サイトの識別子であり、メッセージをリキー。
B.5.7. Distributed Operation Policy
B.5.7。分散運営方針
The policy dictating the relationships between GC/KS and S-GC/KS for distributed operations is defined as SubGCKSInfo. It is defined as a couple of a subGCKSScheme and some information relating to that Scheme in sGCKSContent.
分散操作のためのGC / KSとS-GC / KSの関係を規定ポリシーはSubGCKSInfoとして定義されます。それはsubGCKSSchemeのカップルやsGCKSContentでそのスキームに関連するいくつかの情報として定義されます。
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
B.5.7.1. No Distributed Operation
B.5.7.1。いいえ、分散運用ん
If the group is not to use S-GC/KS, then that Scheme would be SGCKSSchemeNone.
グループはS-GC / KSを使用しない場合、スキームはSGCKSSchemeNoneだろうと。
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL
B.5.7.2. Autonomous Distributed Mode
B.5.7.2。自律分散モード
If the group is to use S-GC/KS as defined in the GSAKMP specification as Autonomous mode, then that scheme would be SGCKSAutonomous.
グループは、自律モードとしてGSAKMP仕様で定義されるようにS-GC / KSを使用する場合、その方式はSGCKSAutonomousあろう。
id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName,
domain OCTET STRING OPTIONAL
}
The policy information needed for autonomous mode is a list of authorized S-GC/KSes and restrictions on who they may serve. The domain field representing these restrictions is NULL for this version.
自律モードのために必要なポリシー情報は、許可されたS-GC / KSES、彼らが働くことができる人の制限の一覧です。これらの制限を表すドメインフィールドには、このバージョンのNULLです。
B.6. GSAKMPv1 Rekey Policy ASN.1 Module
B.6。 GSAKMPv1リキーポリシーASN.1モジュール
GSAKMPv1RekeySA {1.3.6.1.5.5.12.0.4}
GSAKMPv1RekeySA {} 1.3.6.1.5.5.12.0.4
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
IMPORTS GCKSName FROM GSAKMPv1RegistrationSA {1.3.6.1.5.5.12.0.2} LifeDate FROM PolicyToken {1.3.6.1.5.5.12.0.1};
PolicyToken {1.3.6.1.5.5.12.0.1} FROM GSAKMPv1RegistrationSA {1.3.6.1.5.5.12.0.2} LifeDateからの輸入GCKSName。
id-GSAKMPv1Rekey OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.0.4}
GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization,
mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey
rekeyMethod RekeyMethod,
rekeyInterval LifeDate, -- member knows when to rejoin
reliability Reliability, -- what mech will be used to
-- increase the likelihood
-- of rekey delivery
subGCKSInfo SubGCKSInfo -- what subordinate GCKS needs
}
RekeyAuthorization ::= GCKSName
RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER
}
RekeyEventDef ::= CHOICE {
none [0] NULL, -- never rekey
timeOnly [1] EXPLICIT LifeDate, -- rekey every x units
event [2] INTEGER, -- rekey after x events
timeAndEvent [3] TimeAndEvent
}
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING
}
-- REKEY METHOD NONE --
- REKEY方法のNONE -
id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL
-- REKEY METHOD GSAKMP LKH --
- REKEY METHOD GSAKMP LKH -
id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for
-- wrapping mechanism
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING
}
-- RELIABILITY MECHANISM NONE --
- 信頼性のためのメカニズムNONE -
id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL
-- RELIABILITY MECHANISM RESEND --
- 信頼性のためのメカニズムRESEND -
id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
ReliabilityResendInfo ::= INTEGER -- # of times rekey message should
-- be resent
-- RELIABILITY MECHANISM POST --
- 信頼性のためのメカニズムPOST -
id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
ReliabilityContentPost ::= IA5String
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL
id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName,
domain OCTET STRING OPTIONAL
}
END
終わり
Appendix C. Data SA Policy
付録C.データSA方針
The Data SA provides the data structures needed for the protection of the data exchanged between group members. This appendix defines the data structures needed for a simple, generic security application making use of fixed security mechanisms. Such a Data SA requires only that keys delivered by the registration and rekey protocols be mapped to the service using them.
データSAは、グループのメンバー間で交換されるデータの保護のために必要なデータ構造を提供します。この付録では、修正されたセキュリティ・メカニズムを利用して、簡単な、一般的なセキュリティアプリケーションのために必要なデータ構造を定義します。このようなデータSAは、キーが登録によって提供され、それらを利用したサービスにマップされたプロトコルキーを再生成することだけです。
C.1. Generic Data Policy
C.1。一般的なデータポリシー
The Generic Data Policy has the following identifier:
一般的なデータポリシーは、次の識別子があります。
id-genericDataSA OBJECT IDENTIFIER :: = {1.3.6.1.5.5.12.7.1}
ID-genericDataSAオブジェクト識別子:: = {} 1.3.6.1.5.5.12.7.1
If an authentication mechanism is used within the security application, the key identifier (kMKeyID) used in the key management protocol is given, as well as an optional key expiration date. Likewise, if an encryption mechanism is used within the security application, the encryption key identifier is given, as well as an optional key expiration date (keyExpirationDate).
認証メカニズムは、セキュリティ・アプリケーション内で使用される場合、キー管理プロトコルに使用されるキー識別子（kMKeyID）は同様にオプションキー有効期限として、与えられます。同様に、暗号化機構は、セキュリティ・アプリケーション内で使用される場合、暗号鍵識別子が与えられ、ならびに任意キー有効期限（keyExpirationDate）。
GenericDataSAInfo ::= SEQUENCE {
authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] EXPLICIT KeyInfo OPTIONAL
}
KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL
}
C.2. Generic Data Policy ASN.1 Module
C.2。一般的なデータポリシーASN.1モジュール
GenericDataSA {1.3.6.1.5.5.12.0.5}
GenericDataSA {1.3.6.1.5.5.12.0.5}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
ベギン
-- DATA APPLICATION: Generic -- This token specification is for data applications with -- fixed security mechanisms. Such data applications only -- need a mapping of management protocol key identification -- tags to security service.
- データアプリケーション：ジェネリック - 固定されたセキュリティメカニズム - このトークン仕様を有するデータアプリケーションのためのものです。このようなデータアプリケーションのみ - 管理プロトコルキー識別のマッピングを必要とする - セキュリティサービスへのタグ。
IMPORTS LifeDate FROM PolicyToken {1.3.6.1.5.5.12.0.1}
PolicyTokenからの輸入LifeDate {1.3.6.1.5.5.12.0.1}
KeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) };
PKIX1Implicit88 FROM KeyIdentifier {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙（19）}。
id-genericDataSA OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.7.1}
GenericDataSAInfo ::= SEQUENCE {
authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] EXPLICIT KeyInfo OPTIONAL
}
KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL
}
END
終わり
Authors' Addresses
著者のアドレス
Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
アンドレアColegrove SPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
電話：（443）430-8014ファックス：（443）430-8163 Eメール：acc@sparta.com
Hugh Harney SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
ヒューハーニーSPARTA、Inc.の7110サミュエル・モールスドライブコロンビア、MD 21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
電話：（443）430-8032ファックス：（443）430-8181 Eメール：hh@sparta.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。