RFC4534 日本語訳
4534 Group Security Policy Token v1. A Colegrove, H Harney. June 2006. (Format: TXT=54157 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Colegrove
Request for Comments: 4534 H. Harney
Category: Standards Track SPARTA, Inc.
June 2006
コメントを求めるワーキンググループA.コールグローブの要求をネットワークでつないでください: 4534時間ハーニーCategory: 標準化過程スパルタInc.2006年6月
Group Security Policy Token v1
グループ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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
Group Security Policy Tokenは安全保障政策を指定するのに使用される構造と暗号のグループに、構成可能なパラメタです、安全なマルチキャストグループのように。 グループのセキュリティが通信基盤中で複数のセキュリティー・サービス、メカニズム、および属性の全体で構成されるので、システム中でサポートしなければならない特徴の認証可能表現が一貫したセキュリティを確実にするのに必要です。 このドキュメントはそのようなトークンの構造を指定します。
Colegrove & Harney Standards Track [Page 1] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[1ページ]RFC4534Group Security Policy Token v1 June 2006
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
1. 序論…3 2. トークン作成と領収書…4 3. 方針トークン…5 3.1. トークン識別子…6 3.2. 登録方針…6 3.3. Rekey方針…7 3.4. データ方針を分類してください…8 4. セキュリティ問題…8 5. IANA問題…8 6. 参照…9 6.1. 標準の参照…9 6.2. 有益な参照…10 7. 承認…10 付録A.コア方針トークンASN.1モジュール…11 付録B.GSAKMPv1は方針を基礎づけます…13 B.1。 GSAKMPv1登録方針…13 B.1.1。 承認…13 B.1.2。 AccessControl…14 B.1.3。 JoinMechanisms…15 B.1.3.1alaCarte…15 B.1.3.2スイート…17 B.1.4。 輸送…17 B.2。 GSAKMPv1登録ASN.1モジュール…17 B.3。 GSAKMPv1反-登録方針…20 B.4。 GSAKMPv1反-登録ASN.1モジュール…21 B.5。 GSAKMPv1 Rekey方針…22 B.5.1。 Rekey承認…22 B.5.2。 Rekeyメカニズム…23 B.5.3。 Rekeyイベント定義…23 B.5.4。 Rekeyメソッド…24 B.5.4.1はなにもにメソッドをRekeyします…24 B.5.4.2RekeyメソッドGSAKMP LKH…24B.5.5 Rekey間隔…25 B.5.6 Rekeyの信頼性…25 B.5.6.1はなにもに信頼性のメカニズムをRekeyします…25 Rekey信頼性のメカニズムが再送するB.5.6.2…25 B.5.6.3Rekey信頼性のメカニズムポスト…26 B.5.7は操作方針を分配しました…26 B.5.7.1のいいえの分配された操作…26 B.5.7.2の自治の分散モード…26 B.6。 GSAKMPv1 Rekey方針ASN.1モジュール…27付録C.データSA方針…30 C.1。 ジェネリックデータ方針…30 C.2。 ジェネリックデータ方針ASN.1モジュール…30
Colegrove & Harney Standards Track [Page 2] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[2ページ]RFC4534Group Security Policy Token v1 June 2006
1. Introduction
1. 序論
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.
Multicast Group Security Architecture[RFC3740]は、安全なグループコミュニケーションをサポートするためにセキュリティインフラストラクチャを定義します。 方針トークンは定義におけるこのアーキテクチャを仮定します。 それはGroup Secure Associationにおいて、実施できるセキュリティパラメタを定義します。
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.
方針トークンはGroup Owner(安全保障政策を作成する承認がある実体)によって署名された証明可能なデータ構造物です。 グループのグループコントローラは、グループを保証するのに使用されるメカニズムが確実に正しくなるようにして、メンバーに加わるためのアクセス制御規則を実施するのに方針トークンを使用するでしょう。 グループのメンバー(グループからグループかアクセスデータにデータを寄付するかもしれません)は、グループが信じられた権威によって所有されているのを保証するのに方針トークンを使用するでしょう。 また、メンバーは、アクセス制御規則がメンバーがグループに提出しているデータを保護するために適切であることを確かめたがっているかもしれません。
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
}
メカニズム:、:= 系列mechanismIdentifierオブジェクト識別子、mechanismParameters八重奏ストリング
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.
方針トークンは、Group Security AssociationのためにMSEC Architecture層を反映するために構造化されます。 それぞれの建築層を特定して、「コア」トークンでブランチに与えます。 これは次にいろいろな環境にプロトコルのどんなミックスも使用することで安全なグループを定義する1ポイントの参照として機能できる「コア」方針トークンを変える必要性なしでそれぞれの建築層の将来のプロトコル仕様のための高度合いの柔軟性を許容します。
Colegrove & Harney Standards Track [Page 3] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[3ページ]RFC4534Group Security Policy Token v1 June 2006
2. Token Creation and Receipt
2. トークン作成と領収書
At the time of group creation or whenever the policy of the group is updated, the Group Owner will create a new policy token.
グループ作成時点かグループの方針をアップデートするときはいつも、Group Ownerは新しい政策トークンを作成するでしょう。
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.
特約保険証券の信憑性を確実にするために、Group OwnerはTokenに署名しなければなりません。 Cryptographic Message Syntax(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}
イドct msecトークン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値はGroup Ownerのものでなければなりません。(SignerInfoは署名を有効にするのに必要である公開鍵を特定します)。
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によって特定されるGroup Ownerは予想された実体です。
- 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つのメカニズム)は、サポートされて、受取人のローカルの方針に従ってあります。
Colegrove & Harney Standards Track [Page 4] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[4ページ]RFC4534Group Security Policy Token v1 June 2006
3. The Policy Token
3. 方針トークン
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 TokenID、登録SEQUENCE OF Registration、rekey SEQUENCE OF GroupMngmtProtocol、データSEQUENCE OF DataProtocol
tokenInfo provides information about the instance of the Policy Token
(PT).
tokenInfoはPolicy Token(太平洋標準時の)のインスタンスの情報を提供します。
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系列は、グループがメンバーの登録と反-登録をサポートしないのを示します。 メンバーは、グループに加わるために少なくとも1セットのRegistrationメカニズムをサポートできなければなりません。 複数のメカニズムが存在しているとき、メンバーは記載されたメソッドのいずれも使用するかもしれません。 リストはGroup Owner好みで注文されます。 メンバーはローカルの方針がサポートする中で最も高い記載されたメカニズムを選ばなければなりません。
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プロトコルを提供します。 メンバーは、rekeyメッセージのタイプのひとりが記載されていると受け入れることができなければなりません。 リストはGroup Owner好みで注文されます。 メンバーはローカルの方針がサポートする中で最も高い記載されたメカニズムを選ばなければなりません。
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.
登録、rekey、およびデータ・フィールドに、未知のプロトコル識別子に遭遇する実装は、許されているプロトコルの系列の中に未知のプロトコルがあるというインディケータを提供することによって、優雅にこれを扱わなければなりません。 未知のプロトコルが系列で唯一の許容できるプロトコルであるなら、実装はその分野をサポートすることができません、そして、メンバーはグループに加わることができません。 未知のプロトコルが許容できて、知られているプロトコルの中に存在するとき、aが接合するかどうかが受入れられるのは、ローカルの方針の問題です。
Colegrove & Harney Standards Track [Page 5] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[5ページ]RFC4534Group Security Policy Token v1 June 2006
Protocols in addition to registration, rekey, and data SHOULD NOT be added to subsequent versions of this Token unless the MSEC architecture changes.
プロトコル、登録、rekey、およびデータSHOULD NOTに加えて、MSECアーキテクチャが変化しない場合、このTokenのその後のバージョンに追加されてください。
Each data field of the PT is specified further in the following sections.
太平洋標準時の各データ・フィールドは以下のセクションで、より遠くに指定されます。
3.1. Token Identifiers
3.1. トークン識別子
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
}
TokenID:、:= 系列tokenDefVersion INTEGER(1)、groupName OCTET STRING、版の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はGroup Policy Token Specificationのバージョンです。 この仕様(v1)は1つ(1)として表されます。 Group Security Policy Tokenの構造への変化はこの分野にアップデートを必要とするでしょう。
groupName is the identifier of the group and MUST be unique relative
to the Group Owner.
groupNameはグループに関する識別子であり、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.
版は太平洋標準時の一連番号を示す任意のINTEGERです。 値が有効なPTでそのグループに関して見られた最終値より大きいときにだけ、版が存在しているなら、グループ実体は太平洋標準時の1時を受け入れなければなりません。
The type LifeDate is also defined to provide standard methods of indicating timestamps and intervals in the Tokens.
また、タイプLifeDateは、Tokensでタイムスタンプと間隔を示す標準方法を提供するために定義されます。
LifeDate ::= CHOICE {
gt GeneralizedTime,
utc UTCTime,
interval INTEGER
}
LifeDate:、:= 選択gt GeneralizedTime、utc UTCTime、間隔INTEGER
3.2. Registration Policy
3.2. 登録方針
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 Architectureで定義されます。 登録の間、将来のグループのメンバーとグループコントローラは、それがグループに加わって、グループData SAに参加するために必要とするキーと情報へのグループメンバーアクセスを与えるために相互作用するでしょう。
Colegrove & Harney Standards Track [Page 6] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[6ページ]RFC4534Group Security Policy Token v1 June 2006
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.
反-登録断片で、現在のグループのメンバーは、もうData SAに参加しないようにGroup Controller Key Server(GC/カンザス)に通知できます。
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
登録:、:= 系列GroupMngmtProtocolを登録してください、そして、反-GroupMngmtProtocolを登録してください。
The protocols for registration and de-registration are each specified as
登録と反-登録のためのプロトコルとして、それぞれ指定されます。
GroupMngmtProtocol ::= CHOICE {
none NULL,
supported Protocol
}
GroupMngmtProtocol:、:= 選択なにも、プロトコルであるとサポートされたNULL
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
以下について議定書の中で述べてください:= 系列プロトコル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.
例えば、レジスタはGroup Secure Association Key Managementプロトコル(GSAKMP)[RFC4535]登録プロトコルとして指定されるかもしれません。 Appendix B.1での指定されるとしてのGSAKMP登録に使用されるパラメタはOBJECT IDENTIFIER TBSのあとに続いているでしょう。
3.3. Rekey Policy
3.3. Rekey方針
The Rekey SA is defined in the MSEC Architecture. During the Rekey of a group, several changes can potentially be made:
Rekey SAはMSEC Architectureで定義されます。 グループのRekeyの間、潜在的にいくつかの変更を行うことができます:
- 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の間、グループトラフィック保護キーをリフレッシュして、Policy Tokenをアップデートすることと同様にグループの会員資格を変更できます。
This field is also specified as a sequence of protocols that will be used by the GC/KS.
また、この分野はGC/カンザスによって使用されるプロトコルの系列として指定されます。
Colegrove & Harney Standards Track [Page 7] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[7ページ]RFC4534Group Security Policy Token v1 June 2006
3.4. Group Data Policy
3.4. グループ・データ方針
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.
Data SAはグループキーの最終消費者です。 データ・フィールドはグループのメンバーのコミュニケーションで使用されることになっているキーとメカニズムを示すでしょう。 グループキーを利用できたいくつかのプロトコルがあります、暗号化にキーを必要とするだけである簡単なセキュリティアプリケーション、そして/または、保全保護からIPsecやSecureレアル-時間Transportプロトコル(SRTP)[RFC3711]などの、より複雑な構成可能なセキュリティプロトコルに変化して。 メカニズムが「外に」“inside"からあるData SAの配列。 すなわち、方針トークンで定義された最初のData SAは生データに影響しなければなりません。 それが順番に適用された後にどんなData SAも指定しました。
DataProtocol ::= Protocol
DataProtocol:、:= プロトコル
4. Security Considerations
4. セキュリティ問題
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実装、方針トークンを使用するグループのための適切な強さの署名メカニズムの選択、および安全で、十分強いキーを当てにします。 さらに、それは方針実施の根としてよく知られるGroup Ownerに関する知識を当てにされます。
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.
その上、Group Ownerは様々な機能のために代替のメカニズムを記載するかもしれませんが、グループは単に最も弱いのがメカニズムを受け入れたのと同じくらい強いです。そういうものとして、Group Ownerは許容できるセキュリティー対策だけを提供するのに責任があります。
5. IANA Considerations
5. IANA問題
The following object identifiers have been assigned:
以下のオブジェクト識別子を割り当ててあります:
- id-ct-msec-token OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.1.1
- イドct msecトークンOBJECT IDENTIFIER:、:= 1.3.6.1.5.5.12.1.1
- id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
- イド-securitySuiteOneオブジェクト識別子:、:= 1.3.6.1.5.5.12.2.1
- id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
- イド-GSAKMPv1RegistrationProtocolオブジェクト識別子:、:= 1.3.6.1.5.5.12.3.1
- id-GSAKMPv1DeRegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
- イド-GSAKMPv1DeRegistrationProtocolオブジェクト識別子:、:= 1.3.6.1.5.5.12.3.2
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
- イド-GSAKMPv1Rekeyオブジェクト識別子:、:= 1.3.6.1.5.5.12.3.3
Colegrove & Harney Standards Track [Page 8] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[8ページ]RFC4534Group Security Policy Token v1 June 2006
- id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
- イド-rekeyNoneオブジェクト識別子:、:= 1.3.6.1.5.5.12.4.1
- id-rekeyMethodGSAKMPLKH
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
- イド-rekeyMethodGSAKMPLKHオブジェクト識別子:、:= 1.3.6.1.5.5.12.4.2
- id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
- イド-reliabilityNoneオブジェクト識別子:、:= 1.3.6.1.5.5.12.5.1
- id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
- イド-reliabilityResendオブジェクト識別子:、:= 1.3.6.1.5.5.12.5.2
- id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
- イド-reliabilityPostオブジェクト識別子:、:= 1.3.6.1.5.5.12.5.3
- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
- イド-subGCKSSchemeNoneオブジェクト識別子:、:= 1.3.6.1.5.5.12.6.1
- id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
- イド-subGCKSSchemeAutonomousオブジェクト識別子:、:= 1.3.6.1.5.5.12.6.2
- id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1
- イド-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).
仕様でGroup Security Policy Tokenを広げることができます。 IANAを通してオブジェクトの形における拡大を示すことができます。 プロトコル構造への変化を必要とする拡張子がTokenIDのtokenDefVersion分野にアップデートを必要とするでしょう(セクション3.1を見てください)。
6. References
6. 参照
6.1. Normative References
6.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.、コールグローブ、A.、およびG.グロス、「GSAKMP:」 「グループの安全な協会Key Managementプロトコル」、RFC4535、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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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)、正準な符号化規則(CER)、および顕著なコード化の仕様は(DER)、1997を統治します。
Colegrove & Harney Standards Track [Page 9] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[9ページ]RFC4534Group Security Policy Token v1 June 2006
6.2. Informative References
6.2. 有益な参照
[HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP
Token Specification", Work in Progress, February 2003.
[HCLM00] ハーニーとH.とコールグローブと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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、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.コールグローブとP.マクダニエルと「安全なグループの方針のプリンシプルズ」とネットワークの議事と2001年の分散システムセキュリティインターネット協会、サンディエゴ(カリフォルニア)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.、コールグローブ、A.、およびP.Dinsmore、「安全保障政策トークンを分類してください」 「定義と有効搭載量」は進歩、2003年8月に働いています。
7. Acknowledgements
7. 承認
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とトークンに関する知識に大いに感謝したユリMeth。 方針トークンの以前のバージョンに対する彼らの仕事のためのピーターLough、トーマスHardjono、パトリック・マクダニエル、およびピートDinsmore。 起動力にはよく指定されて、広げることができる方針トークンがあるジョージGross。 そして、導入問題を捕らえるためのRodフレイシャー。
The following technical works influenced the design of the Group Security Policy Token: [HCLM00], [HCM01], and [HHMCD01]
以下の技術的な作品はGroup Security Policy Tokenのデザインに影響を及ぼしました: そして[HCLM00]、[HCM01]。[HHMCD01]
Colegrove & Harney Standards Track [Page 10] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[10ページ]RFC4534Group Security Policy Token v1 June 2006
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
}
トークン:、:= 系列tokenInfo TokenID、登録SEQUENCE OF Registration、rekey SEQUENCE OF GroupMngmtProtocol、データSEQUENCE OF DataProtocol
------------------------------------------------------------
-- Token ID
------------------------------------------------------------ -- トークンID
TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1), -- Group Security Policy Token v1
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
TokenID:、:= 系列tokenDefVersion INTEGER(1)--Security Policy Token v1 groupName OCTET STRING、版のINTEGER OPTIONALを分類してください。
LifeDate ::= CHOICE {
gt GeneralizedTime,
utc UTCTime,
interval INTEGER
}
LifeDate:、:= 選択gt GeneralizedTime、utc UTCTime、間隔INTEGER
------------------------------------------------------------
-- Registration
------------------------------------------------------------ -- 登録
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
登録:、:= 系列GroupMngmtProtocolを登録してください、そして、反-GroupMngmtProtocolを登録してください。
------------------------------------------------------------
-- GroupMngmtProtocol
------------------------------------------------------------ -- GroupMngmtProtocol
GroupMngmtProtocol ::= CHOICE {
none NULL,
supported Protocol
}
GroupMngmtProtocol:、:= 選択なにも、プロトコルであるとサポートされたNULL
Colegrove & Harney Standards Track [Page 11] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[11ページ]RFC4534Group Security Policy Token v1 June 2006
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
以下について議定書の中で述べてください:= 系列プロトコルOBJECT IDENTIFIER、protocolInfo OCTET STRING
------------------------------------------------------------
-- DataProtocol
------------------------------------------------------------ -- DataProtocol
DataProtocol ::= Protocol
DataProtocol:、:= プロトコル
------------------------------------------------------------
------------------------------------------------------------
END
終わり
Colegrove & Harney Standards Track [Page 12] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[12ページ]RFC4534Group Security Policy Token v1 June 2006
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交換が登録、反-登録、そして/または、Rekey SAsにGroupMngmtProtocolとして使用される時の間必要であるデータ構造を提供します。 このGSAKMP基地のPolicy仕様は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が登録にGroup Managementプロトコルに使用されるとき、以下のオブジェクト識別子はコアトークンに使用されます。
id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.1}
イド-GSAKMPv1RegistrationProtocolオブジェクト識別子:、:= {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のための登録方針はGSAKMP登録交換がどんな輸送を使用するかのグループの役割のための承認の1)情報、グループのメンバーへの2)アクセス制御情報、メカニズムが登録手続で使用した3、)および4)情報を提供します。
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
GSAKMPv1RegistrationInfo:、:= 系列joinAuthorization JoinAuthorization(joinAccessControl SEQUENCE OF AccessControl、joinMechanisms JoinMechanisms)は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はだれがGroup Controller Key Server(GC/カンザス)とサブGC/カンザスであることが許容されているかの情報を提供します。 また、それは、だれがグループでデータを送ることができるかに関して制限があるかを示すことができます。
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
}
JoinAuthorization:、:= 系列gCKS GCKSName、subGCKS SEQUENCE OF GCKSName OPTIONAL、送付者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
GCKSName:、:= UserCAPairの系列
Colegrove & Harney Standards Track [Page 13] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[13ページ]RFC4534Group Security Policy Token v1 June 2006
UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID,
cA CertAuth
}
UserCAPair:、:= 系列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 Identificationタイプに文通される整数によって示されます。 定義された名前タイプの一部が「*」で満たされるとき、これはワイルドカードを示します、分野のためのどんな有効な選択も表して。 これは1セットの関連する名前である承認規則の仕様を許容します。
GSAKMPID ::= SEQUENCE {
typeValue INTEGER,
typeData OCTET STRING
}
GSAKMPID:、:= 系列typeValue整数、typeData八重奏ストリング
The certificate authority is identified by the X.509 [RFC3280] key identifier.
認証局はX.509[RFC3280]の主要な識別子によって特定されます。
CertAuth ::= KeyIdentifier
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.
グループの中のSendersは、すべてであることができる(送付者制限を全く示さない)かデータを送るのに権限を与えられたそれらのメンバーの明白なリストであるかもしれません。
SenderAuthorization ::= CHOICE {
all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair
}
SenderAuthorization:、:= 選択[0] NULL、限られた[1]EXPLICIT SEQUENCE OF UserCAPair
B.1.2. AccessControl
B.1.2。 AccessControl
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はだれがGroupメンバーであることが許容されているかの情報を提供します。 アクセスコントロールリストはそれぞれ満足させられなければならないメンバーが満たさなければならない1セットの許容、名前規則のリスト、および認証局として実装されます。 さらに、リストへの除外のリストを提供するかもしれません。
AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
}
AccessControl:、:= 系列許容[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.
初めは利用可能な許容は共同体に内部で解釈されるかもしれない抽象的な数値レベルです。
Colegrove & Harney Standards Track [Page 14] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[14ページ]RFC4534Group Security Policy Token v1 June 2006
Permission ::= CHOICE {
simplePermission [1] SimplePermission
}
許可:、:= 選択simplePermission[1]SimplePermission
SimplePermission ::= ENUMERATED {
one(1),
two(2),
three(3),
four(4),
five(5),
six(6),
seven(7),
eight(8),
nine(9)
}
SimplePermission:、:= 列挙されます。1つ(1)、2(2)、3(3)、4(4)、5(5)、6(6)、7(7)、8(8)、9(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
JoinMechanisms:、:= 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 Registrationで使用されるそれぞれのセットのメカニズムは明らかに定義されたセットとして、または、事前に定義されたセキュリティスイートとして指定されるかもしれません。
JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms,
suite [1] SecuritySuite
}
JoinMechanism:、:= 選択alaCarte[0]メカニズム、スイート[1]SecuritySuite
B.1.3.1. alaCarte
B.1.3.1alaCarte
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
}
メカニズム:、:= 系列signatureDef SigDef、kEAlg KEAlg、keyWrap KeyWrap、ackData AckData、opInfo OpInfo
Colegrove & Harney Standards Track [Page 15] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[15ページ]RFC4534Group Security Policy Token v1 June 2006
The signature definition requires specification of the signature algorithm for message signing. The INTEGER that defines the choice corresponds to the GSAKMP Signature type.
署名定義はメッセージ署名のために署名アルゴリズムの仕様を必要とします。 選択を定義するINTEGERはGSAKMP Signatureタイプに文通しています。
SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER
}
SigDef:、:= 系列sigAlgorithmID整数、hashAlgorithmID整数
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 Hashに写像するでしょう。 このアルゴリズムは結合した一回だけを計算する際に使用されます。
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
}
KEAlg:、:= 系列keyExchangeAlgorithmID整数で、keyExchangeAlgorithmData八重奏ストリング任意です。
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
KeyWrap:、:= 整数
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 Key Download ACK/失敗メッセージで潜在的にデータを返すかもしれません。 グループによって必要とされたデータのタイプはAckDataによって指定されます。 どんなそのような分野も、現在、サポートもされませんし、必要になりもしません。
AckData ::= CHOICE {
none [0] NULL
}
AckData:、:= 選択なにも、[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登録の操作のためのコンフィギュレーション・データを提供します。送信されたメッセージがmisroutedされるか、または失われると考えられる前にtimeOutは経過した時間を示します。 それが以前にコアトークンで定義されたタイムスタンプタイプLifeDateとして指定される、簡潔である、グループが簡潔(TRUE)か冗長な(FALSE)モードで経営されるべきであるかどうかをGC/カンザスに知らせます。 任意のタイムスタンプ分野は、タイムスタンプ(TRUE)か一回だけ(FALSE)が反反復操作による保護に使用されるかどうかを示します。 分野が欠けるなら、一回だけの使用はGSAKMP登録のためのデフォルトモードです。
Colegrove & Harney Standards Track [Page 16] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[16ページ]RFC4534Group Security Policy Token v1 June 2006
OpInfo ::= SEQUENCE {
timeOut LifeDate,
terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
}
OpInfo:、:= 系列timeOut LifeDateで、簡潔である、ブール、タイムスタンプ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.
メカニズムの選択である、接合、事前に定義されたセキュリティスイート、その時はそれが特定されるOBJECT IDENTIFIER(OID)ですか? 他のセキュリティスイートはほかの場所でOIDの仕様と登録で定義されるかもしれません。
SecuritySuite ::= OBJECT IDENTIFIER
SecuritySuite:、:= オブジェクト識別子
The OID for security suite 1, as defined within the GSAKMPv1 specification, is
セキュリティスイート1へのGSAKMPv1仕様の中で定義されるOIDがあります。
id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
イド-securitySuiteOneオブジェクト識別子:、:= {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の選択は、JoinメッセージへのGSAKMP RequestがUDPによって運ばれて、他のすべてのグループ設立メッセージがTCPによって伝えられるのを示します。
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL,
udpRTJtcpOther [2] NULL
}
以下を輸送してください:= 選択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を始めてください。
IMPORTS
LifeDate
FROM PolicyToken {1.3.6.1.5.5.12.0.1}
PolicyTokenからLifeDateをインポートします。{1.3.6.1.5.5.12.0.1}
Colegrove & Harney Standards Track [Page 17] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[17ページ]RFC4534Group Security Policy Token v1 June 2006
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) };
KeyIdentifier FROM PKIX1Implicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)。
id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.7}
イド-GSAKMPv1RegistrationProtocolオブジェクト識別子:、:= {1.3.6.1.5.5.12.7}
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
GSAKMPv1RegistrationInfo:、:= 系列joinAuthorization JoinAuthorization(joinAccessControl SEQUENCE OF AccessControl、joinMechanisms JoinMechanisms)はTransportを輸送します。
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
}
JoinAuthorization:、:= 系列gCKS GCKSName、subGCKS SEQUENCE OF GCKSName OPTIONAL、送付者SenderAuthorization
GCKSName ::= SEQUENCE OF UserCAPair
GCKSName:、:= UserCAPairの系列
UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID,
cA CertAuth
}
UserCAPair:、:= 系列groupEntity GSAKMPID、cA CertAuth
CertAuth ::= KeyIdentifier
CertAuth:、:= KeyIdentifier
SenderAuthorization ::= CHOICE {
all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair
}
SenderAuthorization:、:= 選択[0] NULL、限られた[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
}
AccessControl:、:= 系列許容[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[1]SimplePermission
Colegrove & Harney Standards Track [Page 18] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[18ページ]RFC4534Group Security Policy Token v1 June 2006
SimplePermission ::= ENUMERATED {
one(1),
two(2),
three(3),
four(4),
five(5),
six(6),
seven(7),
eight(8),
nine(9)
}
SimplePermission:、:= 列挙されます。1つ(1)、2(2)、3(3)、4(4)、5(5)、6(6)、7(7)、8(8)、9(9)
GSAKMPID ::= SEQUENCE {
typeValue INTEGER,
typeData OCTET STRING
}
GSAKMPID:、:= 系列typeValue整数、typeData八重奏ストリング
JoinMechanisms ::= SEQUENCE OF JoinMechanism
JoinMechanisms:、:= JoinMechanismの系列
JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms,
suite [1] SecuritySuite
}
JoinMechanism:、:= 選択alaCarte[0]メカニズム、スイート[1]SecuritySuite
Mechanisms ::= SEQUENCE {
signatureDef SigDef,
kEAlg KEAlg,
keyWrap KeyWrap,
ackData AckData,
opInfo OpInfo
}
メカニズム:、:= 系列signatureDef SigDef、kEAlg KEAlg、keyWrap KeyWrap、ackData AckData、opInfo OpInfo
SecuritySuite ::= OBJECT IDENTIFIER
SecuritySuite:、:= オブジェクト識別子
-- SECURITY SUITE ONE --
id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
-- セキュリティスイート1--イド-securitySuiteOneオブジェクト識別子:、:= {1.3.6.1.5.5.12.2.1}
SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER
}
SigDef:、:= 系列sigAlgorithmID整数、hashAlgorithmID整数
KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL
}
KEAlg:、:= 系列keyExchangeAlgorithmID整数で、keyExchangeAlgorithmData八重奏ストリング任意です。
KeyWrap ::= INTEGER
KeyWrap:、:= 整数
Colegrove & Harney Standards Track [Page 19] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[19ページ]RFC4534Group Security Policy Token v1 June 2006
AckData ::= CHOICE {
none [0] NULL
}
AckData:、:= 選択なにも、[0] NULL
OpInfo ::= SEQUENCE {
timeOut LifeDate,
terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
}
OpInfo:、:= 系列timeOut LifeDateで、簡潔である、ブール、タイムスタンプBOOLEAN OPTIONAL
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL,
udpRTJtcpOther [2] NULL
}
以下を輸送してください:= 選択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/カンザスに通知するメソッドを提供します。 GSAKMPがGroupのための反-登録プロトコルであるときに、以下のオブジェクト識別子はコアトークンに使用されます。
id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::=
{1.3.6.1.5.5.12.3.2}
イド-GSAKMPv1DeRegistrationProtocolオブジェクト識別子:、:= {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.
反-登録方針は反-登録交換メッセージ(GSAKMP反-登録メッセージに使用される簡潔(TRUE)か冗長な(FALSE)モード、および輸送を使用し終わるかどうか交換がことであるしるし)に必要であるメカニズムを提供します。
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
terse BOOLEAN,
transport Transport
}
GSAKMPv1DeRegistrationInfo:、:= 系列leaveMechanisms SEQUENCE OF LeaveMechanisms、ブール簡潔な輸送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
}
LeaveMechanisms:、:= 系列sigAlgorithm整数、hashAlgorithm整数、cA KeyIdentifier
Colegrove & Harney Standards Track [Page 20] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[20ページ]RFC4534Group Security Policy Token v1 June 2006
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP Signature type values. This algorithm set is to be used for message signing.
sigAlgorithmに対応するINTEGERはタイプ値をGSAKMP Signatureに写像するでしょう。 このアルゴリズムセットはメッセージ署名に使用されることになっています。
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 Hashに写像するでしょう。 このアルゴリズムは結合した一回だけを計算する際に使用されます。
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 Certificates(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
}
以下を輸送してください:= 選択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) };
IMPORTS KeyIdentifier FROM PKIX1Implicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)。
id-GSAKMPv1DeRegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.2}
イド-GSAKMPv1DeRegistrationProtocolオブジェクト識別子:、:= {1.3.6.1.5.5.12.3.2}
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
transport Transport
}
GSAKMPv1DeRegistrationInfo:、:= 系列leaveMechanisms SEQUENCE OF LeaveMechanisms、輸送Transport
Colegrove & Harney Standards Track [Page 21] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[21ページ]RFC4534Group Security Policy Token v1 June 2006
LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER,
cA KeyIdentifier
}
LeaveMechanisms:、:= 系列sigAlgorithm整数、hashAlgorithm整数、cA KeyIdentifier
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL
}
以下を輸送してください:= 選択tcp[0]NULL、udp[1]NULL
END
終わり
B.5. GSAKMPv1 Rekey Policy
B.5。 GSAKMPv1 Rekey方針
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がGroupにRekeyプロトコルとして使用されるとき、以下のオブジェクト識別子はrekeyプロトコルとしてコアトークンに使用されるべきです:
id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.0.4}
イド-GSAKMPv1Rekeyオブジェクト識別子:、:= {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方針は承認情報を提供します、rekeyイベントが使用するGSAKMP rekeyメッセージ、GC/カンザスがいつrekeyメッセージを送るべきであるかを定義するrekeyイベント定義を定義するインディケータ、プロトコルまたはメソッドのためのメカニズム; メンバーがrekeyプロセス(rekeyが(もしあれば)のrekey配送の見込み、および最終的に下位のGC/KSesがどうrekeyを扱うかしるしを増強するのに使用するメソッドを定義する信頼性のインディケータ)に失敗を認めることができるrekey間隔。 また、この方針は特定のrekey方針メソッド「なにも」と"GSAKMP LKH REKEY"を説明します。
GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization,
mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef,
rekeyMethod RekeyMethod,
rekeyInterval LifeDate,
reliability Reliability,
subGCKSInfo SubGCKSInfo
}
GSAKMPv1RekeyInfo:、:= 系列承認RekeyAuthorization、メカニズムRekeyMechanisms、rekeyEventDef RekeyEventDef、rekeyMethod RekeyMethod、rekeyInterval LifeDate、信頼性のReliability、subGCKSInfo SubGCKSInfo
B.5.1. Rekey Authorization
B.5.1。 Rekey承認
RekeyAuthorization ::= GCKSName
RekeyAuthorization:、:= GCKSName
Colegrove & Harney Standards Track [Page 22] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[22ページ]RFC4534Group Security Policy Token v1 June 2006
B.5.2. Rekey Mechanisms
B.5.2。 Rekeyメカニズム
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
}
RekeyMechanisms:、:= 系列sigAlgorithm整数、hashAlgorithm整数
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP Signature type values. This algorithm set is to be used for message signing.
sigAlgorithmに対応するINTEGERはタイプ値をGSAKMP Signatureに写像するでしょう。 このアルゴリズムセットはメッセージ署名に使用されることになっています。
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 Hashに写像するでしょう。 このアルゴリズムは結合した一回だけを計算する際に使用されます。
B.5.3. Rekey Event Definition
B.5.3。 Rekeyイベント定義
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 Event Definitionは送付rekeyメッセージのためのシステム要求に関してGC/カンザスに情報を提供します。 これは時間内に、イベントドリブン特性(例としての多くの反-登録通知)、または2つ(x反-登録証明書か24時間の例えば、一番になる後)のものの組み合わせと同様にrekeyイベントの定義を許します。
RekeyEventDef ::= CHOICE {
none [0] NULL, -- never rekey
timeOnly [1] LifeDate, -- rekey every x units
event [2] INTEGER, -- rekey after x events
timeAndEvent [3] TimeAndEvent
}
RekeyEventDef:、:= 選択xイベントtimeAndEvent[3]TimeAndEventの後の[0]NULL--rekey timeOnly[1]LifeDate(あらゆるxユニットイベント[2]INTEGERを決してrekeyするというわけではない)rekeyでないなにも
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はグループが「再-キー」の間に存在するべきである最大の時代に指定します。 地方の時計(送付rekeyメッセージのためのGC/カンザス時計かメッセージが逃されたかどうか決定するためのメンバー時計)に関して使用されるとき、これは時計同期を必要としません。
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.
rekeyメッセージを送る前にイベントに対応するINTEGERはグループが支えるべきであるイベントの数のインディケータです。 これは「再-キー」の間のイベントを定義します。 関連イベントに関する例は反-登録通知です。
The TimeAndEvent is defined as a couple of the LifeDate and Integer policies.
TimeAndEventはLifeDateとInteger方針のカップルと定義されます。
Colegrove & Harney Standards Track [Page 23] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[23ページ]RFC4534Group Security Policy Token v1 June 2006
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
TimeAndEvent:、:= 系列時間LifeDate--xユニットの時間ORイベントINTEGERの後のrekey--xイベントは起こります。
B.5.4. Rekey Methods
B.5.4。 Rekeyメソッド
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
}
RekeyMethod:、:= 系列rekeyMethodTypeオブジェクト識別子、rekeyMethodInfo八重奏ストリング
The rekeyMethodType will define the rekey method to be used by the group.
rekeyMethodTypeはグループによって使用されるべきrekeyメソッドを定義するでしょう。
The rekeyMethodInfo will supply the GMs with the information they need to operate in the correct rekey mode.
rekeyMethodInfoは彼らが正しいrekeyモードで操作する必要がある情報をGMに供給するでしょう。
B.5.4.1. Rekey Method NONE
B.5.4.1。 なにもにメソッドをRekeyします。
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}
イド-rekeyNoneオブジェクト識別子:、:= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL
RekeyMethodNoneInfo:、:= ヌル
B.5.4.2. Rekey Method GSAKMP LKH
B.5.4.2。 Rekeyメソッド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プロトコル仕様はLogical Key Hierarchy(LKH)プロトコルの解釈をrekeyメソッドと定義しました。 このメソッドは以下の値によってサポートされます。
id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
イド-rekeyMethodGSAKMPLKHオブジェクト識別子:、:= {1.3.6.1.5.5.12.4.2}
RekeyMethodGSAKMPLKHInfo ::= INTEGER
RekeyMethodGSAKMPLKHInfo:、:= 整数
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暗号化への地図がタイプするこの値。
Colegrove & Harney Standards Track [Page 24] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[24ページ]RFC4534Group Security Policy Token v1 June 2006
B.5.5. Rekey Interval
B.5.5。 Rekey間隔
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間隔はGMが有効な「再-キー」の間で見るべきである最大の遅れを定義します。 これはGMが連動するのを保証する手段を提供します、かぎ管理見解から、グループの残りで。 それは時間/日付のスタンプと定義されます。
B.5.6. Rekey Reliability
B.5.6。 Rekeyの信頼性
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方針はこれらの関心に対処するのに使用されるメカニズムを定義します。
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING
}
信頼性:、:= 系列reliabilityMechanismオブジェクト識別子、reliabilityMechContent八重奏ストリング
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).
信頼性のメカニズムがOBJECT IDENTIFIERによって定義されて、そのメカニズムを操作するのに必要である情報は、reliabilityMechContentと定義されて、OCTET STRING(従来と同様)です。
B.5.6.1. Rekey Reliability Mechanism None
B.5.6.1。 なにもに信頼性のメカニズムをRekeyします。
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メッセージの信頼性を改良するのにメカニズムを使用するのは必要でないかもしれません。 これらのネットワークにおいて、ReliabilityMechanism NONEは適切です。
id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
イド-reliabilityNoneオブジェクト識別子:、:= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL
ReliabilityContentNone:、:= ヌル
B.5.6.2. Rekey Reliability Mechanism Resend
B.5.6.2。 信頼性のメカニズムが再送するRekey
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 Messageの信頼性を改良するのにメカニズムを使用するのが必要であるかもしれません。 これらのネットワークにおいて、ReliabilityMechanism RESENDは潜在的に適切です。 このメカニズムで、GC/カンザスは繰り返して同じメッセージを出します。
id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
イド-reliabilityResendオブジェクト識別子:、:= {1.3.6.1.5.5.12.5.2}
ReliabilityResendInfo ::= INTEGER
ReliabilityResendInfo:、:= 整数
The INTEGER value in the ReliabilityResendInfo indicates the number of times the message should be resent.
ReliabilityResendInfoのINTEGER値はメッセージが再送されるべきである回数を示します。
Colegrove & Harney Standards Track [Page 25] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[25ページ]RFC4534Group Security Policy Token v1 June 2006
B.5.6.3. Rekey Reliability Mechanism Post
B.5.6.3。 Rekey信頼性のメカニズムポスト
Another reliability mechanism is to post the rekey message on some service that will make it generally available. This is the reliabilityPost method.
別の信頼性のメカニズムはそれを一般に、利用可能にする何らかのサービスに関するrekeyメッセージを掲示することです。 これはreliabilityPostメソッドです。
id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
イド-reliabilityPostオブジェクト識別子:、:= {1.3.6.1.5.5.12.5.3}
ReliabilityContentPost ::= IA5String
ReliabilityContentPost:、:= IA5String
The IA5String associated with ReliabilityPost is the identifier of the posting site and rekey message.
ReliabilityPostに関連しているIA5Stringは任命サイトとrekeyメッセージに関する識別子です。
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/カンザスとS-GC/カンザスとの関係を決める方針はSubGCKSInfoと定義されます。 それはsGCKSContentでそのSchemeに関連するsubGCKSSchemeと何らかの情報のカップルと定義されます。
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
SubGCKSInfo:、:= 系列subGCKSSchemeオブジェクト識別子、sGCKSContent八重奏ストリング
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/カンザスを使用しないつもりであるなら、そのSchemeはSGCKSSchemeNoneでしょう。
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
イド-subGCKSSchemeNoneオブジェクト識別子:、:= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL
SGCKSNoneContent:、:= ヌル
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仕様に基づきAutonomousモードと定義されるようにS-GC/カンザスを使用するつもりであるなら、その体系はSGCKSAutonomousでしょう。
id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
イド-subGCKSSchemeAutonomousオブジェクト識別子:、:= {1.3.6.1.5.5.12.6.2}
SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName,
domain OCTET STRING OPTIONAL
}
SGCKSAutonomous:、:= 系列authSubs GCKSName、ドメインOCTET STRING OPTIONAL
Colegrove & Harney Standards Track [Page 26] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[26ページ]RFC4534Group Security Policy Token v1 June 2006
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 Rekey方針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};
GSAKMPv1RegistrationSAからGCKSNameをインポートする、1.3、.6、.1、.5、.5、.12、.0、.2、PolicyTokenからのLifeDate、1.3、.6、.1、.5、.5、.12、.0、.1、。
id-GSAKMPv1Rekey OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.0.4}
イド-GSAKMPv1Rekeyオブジェクト識別子:、:= {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
}
GSAKMPv1RekeyInfo:、:= 系列承認RekeyAuthorization、メカニズムRekeyMechanisms、rekeyEventDef RekeyEventDef--メンバーは、いつ信頼性のReliabilityに再び加わるかを知っています--mechされることがあるために使用されていた状態で望んでいるというrekeyInterval LifeDateがrekey配送subGCKSInfo SubGCKSInfoの可能性をrekey rekeyMethod RekeyMethodに広げると、GCKSは言います--、下位のGCKSが必要とするもの
RekeyAuthorization ::= GCKSName
RekeyAuthorization:、:= GCKSName
RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER
}
RekeyMechanisms:、:= 系列sigAlgorithm整数、hashAlgorithm整数
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
}
RekeyEventDef:、:= 選択xイベントtimeAndEvent[3]TimeAndEventの後の[0]NULL--rekey timeOnly[1]EXPLICIT LifeDate(あらゆるxユニットイベント[2]INTEGERを決してrekeyするというわけではない)rekeyでないなにも
Colegrove & Harney Standards Track [Page 27] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[27ページ]RFC4534Group Security Policy Token v1 June 2006
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
TimeAndEvent:、:= 系列時間LifeDate--xユニットの時間ORイベントINTEGERの後のrekey--xイベントは起こります。
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING
}
RekeyMethod:、:= 系列rekeyMethodTypeオブジェクト識別子、rekeyMethodInfo八重奏ストリング
-- REKEY METHOD NONE --
-- REKEYメソッド、なにも--
id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
イド-rekeyNoneオブジェクト識別子:、:= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL
RekeyMethodNoneInfo:、:= ヌル
-- REKEY METHOD GSAKMP LKH --
-- REKEYメソッドGSAKMP LKH--
id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
イド-rekeyMethodGSAKMPLKHオブジェクト識別子:、:= {1.3.6.1.5.5.12.4.2}
RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for
-- wrapping mechanism
RekeyMethodGSAKMPLKHInfo:、:= INTEGER--、メカニズムを包装して、タイプ値をgsakmpします。
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING
}
信頼性:、:= 系列reliabilityMechanismオブジェクト識別子、reliabilityMechContent八重奏ストリング
-- RELIABILITY MECHANISM NONE --
-- 信頼性のメカニズム、なにも--
id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
イド-reliabilityNoneオブジェクト識別子:、:= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL
ReliabilityContentNone:、:= ヌル
-- RELIABILITY MECHANISM RESEND --
-- メカニズムが再送する信頼性--
id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
イド-reliabilityResendオブジェクト識別子:、:= {1.3.6.1.5.5.12.5.2}
ReliabilityResendInfo ::= INTEGER -- # of times rekey message should
-- be resent
ReliabilityResendInfo:、:= INTEGER--#回では、rekeyメッセージはそうするべきです--再送してください。
-- RELIABILITY MECHANISM POST --
-- 信頼性のメカニズムポスト--
id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
イド-reliabilityPostオブジェクト識別子:、:= {1.3.6.1.5.5.12.5.3}
ReliabilityContentPost ::= IA5String
ReliabilityContentPost:、:= IA5String
Colegrove & Harney Standards Track [Page 28] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[28ページ]RFC4534Group Security Policy Token v1 June 2006
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
SubGCKSInfo:、:= 系列subGCKSSchemeオブジェクト識別子、sGCKSContent八重奏ストリング
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
イド-subGCKSSchemeNoneオブジェクト識別子:、:= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL
SGCKSNoneContent:、:= ヌル
id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
イド-subGCKSSchemeAutonomousオブジェクト識別子:、:= {1.3.6.1.5.5.12.6.2}
SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName,
domain OCTET STRING OPTIONAL
}
SGCKSAutonomous:、:= 系列authSubs GCKSName、ドメインOCTET STRING OPTIONAL
END
終わり
Colegrove & Harney Standards Track [Page 29] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[29ページ]RFC4534Group Security Policy Token v1 June 2006
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.
Data SAはグループのメンバーの間で交換されたデータの保護に必要であるデータ構造を提供します。 この付録は固定セキュリティー対策を利用する簡単なジェネリックセキュリティアプリケーションに必要であるデータ構造を定義します。そのようなData SAは、登録で提供されたキーとrekeyプロトコルがそれらを使用することでサービスに写像されるだけであるのを必要とします。
C.1. Generic Data Policy
C.1。 ジェネリックデータ方針
The Generic Data Policy has the following identifier:
Generic Data Policyには、以下の識別子があります:
id-genericDataSA OBJECT IDENTIFIER :: = {1.3.6.1.5.5.12.7.1}
イド-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
}
GenericDataSAInfo:、:= 系列認証[0]EXPLICIT KeyInfo OPTIONAL、暗号化[1]EXPLICIT KeyInfo OPTIONAL
KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL
}
KeyInfo:、:= 系列kMKeyID八重奏ストリングで、keyExpirationDate LifeDate任意です。
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.
-- データアプリケーション: ジェネリック--データアプリケーションのための仕様とのものであるこのトークン(固定セキュリティー対策そのようなデータアプリケーション専用)は管理プロトコルの主要な識別に関するマッピングを必要とします--セキュリティー・サービスへのタグ。
Colegrove & Harney Standards Track [Page 30] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[30ページ]RFC4534Group Security Policy Token v1 June 2006
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) };
KeyIdentifier FROM PKIX1Implicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)。
id-genericDataSA OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.7.1}
イド-genericDataSAオブジェクト識別子:、:= {1.3.6.1.5.5.12.7.1}
GenericDataSAInfo ::= SEQUENCE {
authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] EXPLICIT KeyInfo OPTIONAL
}
GenericDataSAInfo:、:= 系列認証[0]EXPLICIT KeyInfo OPTIONAL、暗号化[1]EXPLICIT KeyInfo OPTIONAL
KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL
}
KeyInfo:、:= 系列kMKeyID八重奏ストリングで、keyExpirationDate LifeDate任意です。
END
終わり
Colegrove & Harney Standards Track [Page 31] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[31ページ]RFC4534Group Security Policy Token v1 June 2006
Authors' Addresses
作者のアドレス
Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
アンドレアコールグローブスパルタInc.7110サミュエル・モースDriveコロンビア、MD 21046
Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com
以下に電話をしてください。 (443) 430-8014 Fax: (443) 430-8163 メールしてください: acc@sparta.com
Hugh Harney SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046
ヒューハーニースパルタInc.7110サミュエル・モースDriveコロンビア、MD 21046
Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com
以下に電話をしてください。 (443) 430-8032 Fax: (443) 430-8181 メールしてください: hh@sparta.com
Colegrove & Harney Standards Track [Page 32] RFC 4534 Group Security Policy Token v1 June 2006
コールグローブとハーニーStandards Track[32ページ]RFC4534Group Security Policy Token v1 June 2006
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Colegrove & Harney Standards Track [Page 33]
コールグローブとハーニー標準化過程[33ページ]
一覧
スポンサーリンク
