[要約] RFC 4534は、グループセキュリティポリシートークン（GSP）のバージョン1に関する仕様書であり、GSPの目的は、グループメンバーシップ情報を安全に伝達するための標準化された方法を提供することです。
Network Working Group A. Colegrove
Request for Comments: 4534 H. Harney
Category: Standards Track SPARTA, Inc.
June 2006
Group Security Policy Token v1
グループセキュリティポリシートークン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).
Copyright（c）The Internet Society（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値は、署名を検証するために必要な公開鍵を識別し、グループ所有者のCMSでなければなりません。
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.
- 指定されたセキュリティおよび通信メカニズム（または、各選択の少なくとも1つのメカニズム）がサポートされており、受信者のローカルポリシーに準拠しています。
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.
登録は、メンバーが開始したグループからの参加と出発を管理するために使用できる許容可能な登録と登録解除ポリシーとメカニズムのリストを提供します。ヌルシーケンスは、グループがメンバーの登録と解体をサポートしていないことを示しています。メンバーは、グループに参加するために、少なくとも1つの登録メカニズムをサポートできる必要があります。複数のメカニズムが存在する場合、メンバーはリストされている方法のいずれかを使用できます。リストは、グループ所有者の好みの観点から注文されます。メンバーは、ローカルポリシーがサポートする最高のリストされているメカニズムを選択する必要があります。
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.
Rekeyは、グループの管理に使用されるRekeyプロトコルを提供します。メンバーは、リストされているRekeメッセージの種類の1つを受け入れることができる必要があります。リストは、グループ所有者の好みの観点から注文されます。メンバーは、ローカルポリシーがサポートする最高のリストされているメカニズムを選択する必要があります。
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.
データは、グループメンバー間の通信で使用されるアプリケーションを提供します。複数のアプリケーションが提供される場合、リストの順序は、データのカプセル化の順序を意味します。メンバーは、リストされているすべてのアプリケーションをサポートできる必要があり、アプリケーションごとにメカニズムの選択が提供されている場合、メンバーは少なくとも1つのメカニズムをサポートする必要があります。
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.
登録、Reke、およびデータフィールドの場合、未知のプロトコル識別子に遭遇する実装は、未知のプロトコルが許容プロトコルのシーケンスの1つであることを指標に提供することにより、この優雅に処理する必要があります。未知のプロトコルがシーケンス内の唯一の許容プロトコルである場合、実装はそのフィールドをサポートできず、メンバーはグループに参加できません。許容可能な既知のプロトコルの間に不明なプロトコルが存在する場合、参加が許可されるかどうかはローカルポリシーの問題です。
Protocols in addition to registration, rekey, and data SHOULD NOT be added to subsequent versions of this Token unless the MSEC architecture changes.
MSECアーキテクチャが変更されない限り、登録、Rekey、およびデータをこのトークンの後続のバージョンに追加しないでください。
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.
GroupNameはグループの識別子であり、グループ所有者と比較して一意でなければなりません。
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 ::= 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:
Rekey 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.
Rekeyの間、グループのメンバーシップを変更し、グループトラフィック保護キーを更新し、ポリシートークンを更新することができます。
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は、順番に適用されます。
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-CT-MSEC-TOKENオブジェクト識別子:: = 1.3.6.1.5.5.12.1.1.1
- id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
- id-securitysuiteoneオブジェクト識別子:: = 1.3.6.1.5.5.12.2.11
- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
- ID-GSAKMPV1REGISTRATIONPROTOCOLオブジェクト識別子:: = 1.3.6.1.5.5.12.3.1
- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
- ID-GSAKMPV1DEREGISTRATIONPROTOCOLオブジェクト識別子:: = 1.3.6.1.5.5.12.3.2
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
- ID-GSAKMPV1REKEYオブジェクト識別子:: = 1.3.6.1.5.5.12.3.3
- id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
- ID-Rekeynoneオブジェクト識別子:: = 1.3.6.1.5.5.12.4.1
- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
- id-rekeymethodgsakmplkhオブジェクト識別子:: = 1.3.6.1.5.5.12.4.2
- id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
- id-reliabilitynoneオブジェクト識別子:: = 1.3.6.1.5.5.12.5.1
- id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
- id-reliabilityresendオブジェクト識別子:: = 1.3.6.1.5.5.12.5.2
- id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
- id-reliabilitypostオブジェクト識別子:: = 1.3.6.1.5.5.12.5.3
- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
- id-subgcksschemenoneオブジェクト識別子:: = 1.3.6.1.5.5.5.12.6.1
- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
- id-subgcksschemeautonolutoentoencyオブジェクト識別子:: = 1.3.6.1.5.5.5.12.6.2
- id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1
- id-genericdatasaオブジェクト識別子:: = 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を介して登録できます。プロトコル構造の変更を必要とする拡張には、トークンドの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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、2006年6月。
[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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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、抽象的構文表記の仕様（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）、標準エンコードルール（CER）、および区別されたエンコードルール（DER）の仕様、1997。
[HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP Token Specification", Work in Progress, February 2003.
[HCLM00] Harney、H.、Colegrove、A.、Lough、P。、およびU. Meth、「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.、McGrew、D.、Naslund、M.、Carrara、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. Weis、「The Multicast Group Security Architecture」、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. Harney、A。Colegrove、P。McDaniel、「安全なグループにおける政策の原則」、2001年2月、カリフォルニア州サンディエゴのネットワークおよび分散システムセキュリティ2001インターネットソサエティの議事録。
[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.、Harney、H.、McDaniel、P.、Colegrove、A。、およびP. Dinsmore、「グループセキュリティポリシートークン：定義とペイロード」、Progress、Progress、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とトークンの知識が非常に高く評価され、この文書を提出する彼の助けを求めています。Peter Lough、Thomas Hardjono、Patrick McDaniel、Pete Dinsmoreの以前のバージョンのポリシートークンでの作業について。ジョージ・グロスは、明確に指定された拡張可能な政策トークンを持つための推進力を獲得しました。実装の問題をキャッチするためのロッドフライシャー。
The following technical works influenced the design of the Group Security Policy Token: [HCLM00], [HCM01], and [HHMCD01]
以下の技術作品は、グループセキュリティポリシートークンの設計に影響を与えました：[HCLM00]、[HCM01]、および[HHMCD01]
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
終わり
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交換が登録、登録解除、および/またはReke SASのGroupMngMTProtocolとして使用される場合に必要なデータ構造を提供します。このGSAKMPベースポリシーの仕様は、GSAKMPに精通しています。
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の登録ポリシーは、1）グループロールの認可に関する情報、2）グループメンバーのアクセス制御情報、3）登録プロセスで使用されるメカニズム、および4）GSAKMP登録交換の輸送に関する情報を提供します。
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
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.
JoinOuthorizationは、グループコントローラーキーサーバー（GC/KS）およびSub-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.
グループエンティティは、タイプと値によって定義されます。このタイプは、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
}
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)
}
Allowable GSAKMP mechanism choices for a particular group are specified in joinMechanisms. Any set of JoinMechanism is acceptable from a policy perspective.
特定のグループの許容GSAKMPメカニズムの選択は、結合メカニズムで指定されています。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
}
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に対応する整数は、GSAKMP NonCe Hashタイプの値にマッピングされます。このアルゴリズムは、結合された非CEの計算に使用されます。
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.
データは、GSAKMPキーダウンロードACK/障害メッセージで返される可能性があります。グループが必要とするデータのタイプは、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登録の操作のための構成データを提供します。タイムアウトは、送信されたメッセージが誤って失われたり失われたりすると見なされる前の経過時間を示します。これは、コアトークンで以前に定義されていたタイムスタンプタイプのライフエデュテートとして指定されています。Terseは、GC/KSに、グループをTerse（True）またはVerbose（False）モードで操作する必要があるかどうかを通知します。オプションのタイムスタンプフィールドは、タイムスタンプ（TRUE）またはNONCE（false）がアンチレプレイ保護に使用されるかどうかを示します。フィールドがない場合、noncesの使用はGSAKMP登録のデフォルトモードです。
OpInfo ::= SEQUENCE {
timeOut LifeDate,
terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
}
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 1
id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
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
}
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;
exports gcksnameを開始します。
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) };
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
終わり
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.
登録解除ポリシーは、登録交換メッセージに必要なメカニズム、Terse（True）またはVerbose（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
登録交換に必要なメカニズムを決定するポリシーは、Leavemechanismによって定義されます。このフィールドは、として指定されています
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に対応する整数は、GSAKMP NonCe Hashタイプの値にマッピングされます。このアルゴリズムは、結合された非CEの計算に使用されます。
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
}
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) };
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
終わり
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がグループのRekeyプロトコルとして使用される場合、次のオブジェクト識別子をCoreトークンでRekeyプロトコルとして使用する必要があります。
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 Rekeyポリシーは、GSAKMP REKEYメッセージの認可情報、メカニズム、GC/KSがRekeyメッセージを送信する時期、Rekeyイベントが使用するプロトコルまたはメソッド、Rekeメンバーは、Rekeyプロセスの障害、RekeyがRekey Deliveryの可能性を高めるために使用する方法を定義する信頼性インジケーター（もしあれば）、および最終的に下位GC/KSEがRekeyを処理する方法の指標を認識するメンバーです。このポリシーでは、特定のRekeyポリシー方法「NONE」および「GSAKMP LKH REKEY」についても説明しています。
GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization,
mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef,
rekeyMethod RekeyMethod,
rekeyInterval LifeDate,
reliability Reliability,
subGCKSInfo SubGCKSInfo
}
RekeyAuthorization ::= GCKSName
The policy dictating the mechanisms needed for rekey message processing is defined by RekeyMechanisms. This field is specified as
Rekeyメッセージ処理に必要なメカニズムを決定するポリシーは、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に対応する整数は、GSAKMP NonCe Hashタイプの値にマッピングされます。このアルゴリズムは、結合された非CEの計算に使用されます。
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).
Rekeyイベント定義は、Rekeyメッセージを送信するためのシステム要件に関する情報をGC/KSに提供します。これにより、時間内のRekeyイベントの定義と、イベント駆動型の特性（例としての多数の登録通知）、または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は、グループがRekeys間に存在する最大時間を指定します。これは、ローカルクロック（メッセージが見逃されているかどうかを判断するためのRekeメッセージまたはメンバークロックを送信するための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.
イベントに対応する整数は、再キーメッセージが送信される前にグループが維持すべきイベントの数の指標です。これは、Rekeys間のイベントを定義します。関連するイベントの例は、登録解除通知です。
The TimeAndEvent is defined as a couple of the LifeDate and Integer policies.
TimeanDeventは、いくつかのライフエッジおよび整数ポリシーとして定義されています。
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
The rekey method defines the policy of how the rekey is to be accomplished. This field is specified as
Rekeyメソッドは、Rekeyがどのように達成されるかのポリシーを定義します。このフィールドは、として指定されています
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING
}
The rekeyMethodType will define the rekey method to be used by the group.
RekeymethodTypeは、グループが使用するRekeメソッドを定義します。
The rekeyMethodInfo will supply the GMs with the information they need to operate in the correct rekey mode.
Rekeymethodinfoは、正しいRekeyモードで動作するために必要な情報をGMSに提供します。
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.
それをサポートするRekeyプロトコルなしで動作するように定義されたグループは、RekeymethodType Noneによってサポートされています。このオプションに関連付けられたRekeymethodnoneinfoはありません。
id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL
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プロトコル仕様は、Rekyメソッドとして論理キー階層（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暗号化タイプにマップします。
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.
Rekey間隔は、有効なRekeys間にGMが表示する最大遅延を定義します。これは、GMが主要な管理の観点から、グループの残りの部分と同期していることを保証する手段を提供します。時間/日付スタンプとして定義されます。
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プロトコルのRekeyメッセージは、単一のプッシュメッセージです。このような承認されていないメッセージ（つまり、メッセージ交換）には信頼性の懸念があります。信頼性ポリシーは、これらの懸念に対処するために使用されるメカニズムを定義します。
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).
信頼性メカニズムは、オブジェクト識別子によって定義され、そのメカニズムが信頼性MechContentとして定義され、Octet String（前）として定義されていることを動作させるために必要な情報が定義されます。
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.
適切な信頼性を備えたネットワークでは、メカニズムを使用してRekeyメッセージの信頼性を向上させる必要がない場合があります。これらのネットワークの場合、信頼性のメカニズムは適切ではありません。
id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL
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.
不明または疑わしい信頼性を持つネットワークでは、メカニズムを使用してRekeyメッセージの信頼性を向上させる必要がある場合があります。これらのネットワークでは、信頼性のメカニズムの再送信が潜在的に適切です。このメカニズムには、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.
信頼性Resendinfoの整数値は、メッセージがresする必要がある回数を示します。
Another reliability mechanism is to post the rekey message on some service that will make it generally available. This is the reliabilityPost method.
別の信頼性メカニズムは、一般的に利用可能になるサービスにRekeyメッセージを投稿することです。これが信頼性ポストメソッドです。
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.
信頼性Postに関連付けられたIA5STRINGは、投稿サイトとRekeyメッセージの識別子です。
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として定義されます。これは、いくつかのサブグッケスシェームと、SGCKSContentのそのスキームに関連するいくつかの情報として定義されています。
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
If the group is not to use S-GC/KS, then that Scheme would be SGCKSSchemeNone.
グループがS-GC/KSを使用しない場合、そのスキームはSGCKSCHEMENONEになります。
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL
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を使用する場合、そのスキームはSGCKSAUTONOUSになります。
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です。
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};
gsakmpv1registrationsaからgcksnameをインポート{1.3.6.1.5.5.55.12.0.2} PolicyToken {1.3.6.1.1.5.5.12.0.1}からのライフエッジ。
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 --
- レキー方法なし -
id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL
-- REKEY METHOD GSAKMP LKH --
-Rekey MethodGSAKMPLKH-
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 --
- 信頼性メカニズムなし -
id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL
-- RELIABILITY MECHANISM 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 --
- 信頼性メカニズムの投稿 -
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
終わり
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は、登録によって配信されたキーとRekeプロトコルを使用してサービスにマッピングすることのみを必要とします。
The Generic Data Policy has the following identifier:
一般的なデータポリシーには、次の識別子があります。
id-genericDataSA OBJECT IDENTIFIER :: = {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
}
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) };
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
Andrea Colegrove Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
電話：（443）430-8014ファックス：（443）430-8163メール：acc@sparta.com
Hugh Harney SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
Hugh Harney Sparta、Inc。7110 Samuel Morse Drive Columbia、MD 21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
電話：（443）430-8032ファックス：（443）430-8181メール：hh@sparta.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。