RFC4895 日本語訳
4895 Authenticated Chunks for the Stream Control Transmission Protocol(SCTP). M. Tuexen, R. Stewart, P. Lei, E. Rescorla. August 2007. (Format: TXT=42507 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Tuexen
Request for Comments: 4895 Muenster Univ. of Applied Sciences
Category: Standards Track R. Stewart
P. Lei
Cisco Systems, Inc.
E. Rescorla
RTFM, Inc.
August 2007
Tuexenがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4895年の応用科学カテゴリのMuenster大学: 標準化過程R.スチュワートP.レイシスコシステムズInc.E.レスコラRTFM Inc.2007年8月
Authenticated Chunks for
the Stream Control Transmission Protocol (SCTP)
流れの制御伝動プロトコルのための認証された塊(SCTP)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys.
このドキュメントはStream Control Transmissionプロトコル(SCTP)のために新しい塊タイプ、いくつかのパラメタ、および手順について説明します。 送付者と受信機の間の共有されたキーを使用することによってSCTP塊を認証するのにこの新しい塊タイプを使用できます。新しいパラメタは、共有されたキーを証明するのに使用されます。
Tuexen, et al. Standards Track [Page 1] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Parameter Types . . . . . . . . . . . . . . . . . . . . . 4
3.1. Random Parameter (RANDOM) . . . . . . . . . . . . . . . . 4
3.2. Chunk List Parameter (CHUNKS) . . . . . . . . . . . . . . 5
3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO) . . . . . . 6
4. New Error Cause . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Unsupported HMAC Identifier Error Cause . . . . . . . . . 7
5. New Chunk Type . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Authentication Chunk (AUTH) . . . . . . . . . . . . . . . 8
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Establishment of an Association Shared Key . . . . . . . . 10
6.2. Sending Authenticated Chunks . . . . . . . . . . . . . . . 11
6.3. Receiving Authenticated Chunks . . . . . . . . . . . . . . 12
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. A New Chunk Type . . . . . . . . . . . . . . . . . . . . . 15
8.2. Three New Parameter Types . . . . . . . . . . . . . . . . 15
8.3. A New Error Cause . . . . . . . . . . . . . . . . . . . . 15
8.4. A New Table for HMAC Identifiers . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 新しいパラメタは.43.1をタイプします。 確率パラメータ(無作為の).43.2。 塊リストパラメタ(塊。). . . . . . . . . . . . . . 5 3.3 HMACアルゴリズムパラメタ(HMAC-痛).6 4を要求しました。 新しい誤り原因. . . . . . . . . . . . . . . . . . . . . . . 7 4.1。 サポートされないHMAC識別子誤り原因. . . . . . . . . 7 5。 新しい塊タイプ. . . . . . . . . . . . . . . . . . . . . . . . 8 5.1。 認証塊(AUTH。). . . . . . . . . . . . . . . 8 6 手順. . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1。 協会設立はキー. . . . . . . . 10 6.2を共有しました。 発信は塊. . . . . . . . . . . . . . . 11 6.3を認証しました。 受信は塊. . . . . . . . . . . . . . 12 7を認証しました。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 8.1。 新しい塊タイプ. . . . . . . . . . . . . . . . . . . . . 15 8.2。 3の新しいパラメタは.158.3をタイプします。 新しい誤り原因. . . . . . . . . . . . . . . . . . . . 15 8.4。 HMAC識別子. . . . . . . . . . . . . 16 9のための新しいテーブル。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 17 11。 引用規格. . . . . . . . . . . . . . . . . . . . . 17
Tuexen, et al. Standards Track [Page 2] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[2ページ]。
1. Introduction
1. 序論
SCTP uses 32-bit verification tags to protect itself against blind attackers. These values are not changed during the lifetime of an SCTP association.
SCTPは、盲目の攻撃者に対して我が身をかばうのに32ビットの検証タグを使用します。 これらの値はSCTP協会の生涯変えられません。
Looking at new SCTP extensions, there is the need to have a method of proving that an SCTP chunk(s) was really sent by the original peer that started the association and not by a malicious attacker.
新しいSCTP拡張子を見て、悪意がある攻撃者で持っているのではなく、協会を始めたオリジナルの同輩でSCTP塊が本当に送られたと立証する方法を持つ必要があります。
Using Transport Layer Security (TLS), as defined in RFC 3436 [6], does not help because it only secures SCTP user data.
それがSCTP利用者データを保証するだけであるので、RFC3436[6]で定義されるようにTransport Layer Security(TLS)を使用するのは助けません。
Therefore, an SCTP extension that provides a mechanism for deriving shared keys for each association is presented. These association shared keys are derived from endpoint pair shared keys, which are configured and might be empty, and data that is exchanged during the SCTP association setup.
したがって、各協会のために共有されたキーを引き出すのにメカニズムを提供するSCTP拡張子は提示されます。 これらの協会の共有されたキーは、SCTP協会セットアップの間に交換される終点組から派生している共有されたキーと、どれが、構成されて、空であるかもしれないか、そして、データです。
The extension presented in this document allows an SCTP sender to authenticate chunks using shared keys between the sender and receiver. The receiver can then verify that the chunks are sent from the sender and not from a malicious attacker (as long as the attacker does not know an association shared key).
本書では提示される拡大で、SCTP送付者は、送付者と受信機の共有されたキーを使用することで塊を認証できます。次に、受信機は、塊が悪意がある攻撃者から送るのではなく、送付者から送られることを確かめることができます(攻撃者が協会の共有されたキーを知らない限り、dmyです)。
The extension described in this document places the result of a Hashed Message Authentication Code (HMAC) computation before the data covered by that computation. Placing it at the end of the packet would have required placing a control chunk after DATA chunks in case of authenticating DATA chunks. This would break the rule that control chunks occur before DATA chunks in SCTP packets. It should also be noted that putting the result of the HMAC computation after the data being covered would not allow sending the packet during the computation of the HMAC because the result of the HMAC computation is needed to compute the CRC32C checksum of the SCTP packet, which is placed in the common header of the SCTP packet.
拡大は本書ではデータの前のHashedメッセージ立証コード(HMAC)計算の結果がその計算で覆った場所について説明しました。 パケットの端にそれを置くのは、DATA塊を認証することの場合に次々とコントロールDATA塊を置くのを必要としたでしょう。 これはコントロール塊がDATA塊の前にSCTPパケットに起こるという規則を破るでしょう。 また、HMAC計算の結果がSCTPパケットのCRC32Cチェックサムを計算するのに必要であるので、カバーされているデータの後にHMAC計算の結果を置くのがHMACの計算の間パケットを送らせないのが有名であるべきです。パケットはSCTPパケットの一般的なヘッダーに置かれます。
The SCTP extension for Dynamic Address Reconfiguration (ADD-IP) requires the usage of the extension described in this document. The SCTP Partial Reliability Extension (PR-SCTP) can be used in conjunction with the extension described in this document.
Dynamic Address Reconfiguration(ADD-IP)のためのSCTP拡張子は本書では説明された拡大の用法を必要とします。 本書では説明された拡大に関連してSCTP Partial Reliability Extension(PR-SCTP)を使用できます。
2. Conventions
2. コンベンション
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTは本書では現れるとき、RFC2119[3]で説明されるように解釈されることであるべきですか?
Tuexen, et al. Standards Track [Page 3] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[3ページ]。
3. New Parameter Types
3. 新しいパラメータの型
This section defines the new parameter types that will be used to negotiate the authentication during association setup. Table 1 illustrates the new parameter types.
このセクションは協会セットアップの間、認証を交渉するのに使用される新しいパラメータの型を定義します。 テーブル1は新しいパラメータの型を例証します。
+----------------+------------------------------------------------+
| Parameter Type | Parameter Name |
+----------------+------------------------------------------------+
| 0x8002 | Random Parameter (RANDOM) |
| 0x8003 | Chunk List Parameter (CHUNKS) |
| 0x8004 | Requested HMAC Algorithm Parameter (HMAC-ALGO) |
+----------------+------------------------------------------------+
+----------------+------------------------------------------------+ | パラメータの型| パラメタ名| +----------------+------------------------------------------------+ | 0×8002| 確率パラメータ(無作為の)| | 0×8003| 塊リストパラメタ(塊)| | 0×8004| 要求されたHMACアルゴリズムパラメタ(HMAC-痛)| +----------------+------------------------------------------------+
Table 1
テーブル1
Note that the parameter format requires the receiver to ignore the parameter and continue processing if the parameter is not understood. This is accomplished (as described in RFC 2960 [5], Section 3.2.1.) by the use of the upper bits of the parameter type.
パラメタが理解されていないならパラメタ形式が、受信機が、パラメタを無視して、処理し続けているのを必要とすることに注意してください。 これはパラメータの型の上側のビットの使用で達成されます(RFC2960[5]で説明されるように、セクション3.2.1です)。
3.1. Random Parameter (RANDOM)
3.1. 確率パラメータ(無作為)です。
This parameter is used to carry a random number of an arbitrary length.
このパラメタは、任意の長さの乱数を運ぶのに使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8002 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ Random Number /
/ +-------------------------------\
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメータの型=0×8002| パラメタの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \乱数//+-------------------------------\ | | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
Parameter Type: 2 bytes (unsigned integer)
This value MUST be set to 0x8002.
パラメータの型: 2バイト(符号のない整数)、この値を0×8002に設定しなければなりません。
Parameter Length: 2 bytes (unsigned integer)
This value is the length of the Random Number in bytes plus 4.
パラメタの長さ: この値はバイトと4で、2バイト(符号のない整数)、Random Numberの長さです。
Tuexen, et al. Standards Track [Page 4] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[4ページ]。
Random Number: n bytes (unsigned integer)
This value represents an arbitrary Random Number in network byte
order.
乱数: nバイト(符号のない整数)、この値はネットワークバイトオーダーで任意のRandom Numberを表します。
Padding: 0, 1, 2, or 3 bytes (unsigned integer)
If the length of the Random Number is not a multiple of 4 bytes,
the sender MUST pad the parameter with all zero bytes to make the
parameter 32-bit aligned. The Padding MUST NOT be longer than 3
bytes and it MUST be ignored by the receiver.
詰め物: 1バイトか2バイトか0バイトか3バイト(符号のない整数)、送付者は、Random Numberの長さが4バイトの倍数でないなら、パラメタの32ビットを並べさせるためにすべてのバイトでどんなパラメタを水増ししてはいけません。 Paddingは受信機で3バイトとそれを無視しなければならないより長いはずがありません。
The RANDOM parameter MUST be included once in the INIT or INIT-ACK chunk, if the sender wants to send or receive authenticated chunks, to provide a 32-byte Random Number. For 32-byte Random Numbers, the Padding is empty.
一度INITかINIT-ACK塊にRANDOMパラメタを含まなければなりません、送付者が発信したいか、または32バイトのRandom Numberを提供するために認証された塊を受けたいなら。 32バイトのRandom民数記において、Paddingは空です。
3.2. Chunk List Parameter (CHUNKS)
3.2. 塊リストパラメタ(塊)
This parameter is used to specify which chunk types are required to be authenticated before being sent by the peer.
このパラメタは、どの塊タイプが同輩によって送られる前に認証されるのに必要であるかを指定するのに使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8003 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type 1 | Chunk Type 2 | Chunk Type 3 | Chunk Type 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメータの型=0×8003| パラメタの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊タイプ1| 塊タイプ2| 塊タイプ3| 塊タイプ4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊Type n| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
図2
Parameter Type: 2 bytes (unsigned integer)
This value MUST be set to 0x8003.
パラメータの型: 2バイト(符号のない整数)、この値を0×8003に設定しなければなりません。
Parameter Length: 2 bytes (unsigned integer)
This value is the number of listed Chunk Types plus 4.
パラメタの長さ: この値は2バイト(符号のない整数)、記載されたChunk Typesと4の数です。
Chunk Type n: 1 byte (unsigned integer)
Each Chunk Type listed is required to be authenticated when sent
by the peer.
塊Type n: 同輩によって送られると、各Chunk Typeが記載した1バイト(符号のない整数)が、認証されるのに必要です。
Tuexen, et al. Standards Track [Page 5] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[5ページ]。
Padding: 0, 1, 2, or 3 bytes (unsigned integer)
If the number of Chunk Types is not a multiple of 4, the sender
MUST pad the parameter with all zero bytes to make the parameter
32-bit aligned. The Padding MUST NOT be longer than 3 bytes and
it MUST be ignored by the receiver.
詰め物: 1バイトか2バイトか0バイトか3バイト(符号のない整数)、送付者は、Chunk Typesの数が4の倍数でないなら、パラメタの32ビットを並べさせるためにすべてのバイトでどんなパラメタを水増ししてはいけません。 Paddingは受信機で3バイトとそれを無視しなければならないより長いはずがありません。
The CHUNKS parameter MUST be included once in the INIT or INIT-ACK chunk if the sender wants to receive authenticated chunks. Its maximum length is 260 bytes.
送付者が認証された塊を受けたいなら、一度、INITかINIT-ACK塊にCHUNKSパラメタを含まなければなりません。 最大の長さは260バイトです。
The chunk types for INIT, INIT-ACK, SHUTDOWN-COMPLETE, and AUTH chunks MUST NOT be listed in the CHUNKS parameter. However, if a CHUNKS parameter is received then the types for INIT, INIT-ACK, SHUTDOWN-COMPLETE, and AUTH chunks MUST be ignored.
CHUNKSパラメタにINIT、INIT-ACK、SHUTDOWN-COMPLETE、およびAUTH塊のための塊タイプを記載してはいけません。 しかしながら、CHUNKSパラメタが受信されているなら、INIT、INIT-ACK、SHUTDOWN-COMPLETE、およびAUTH塊のためのタイプを無視しなければなりません。
3.3. Requested HMAC Algorithm Parameter (HMAC-ALGO)
3.3. 要求されたHMACアルゴリズムパラメタ(HMAC-痛)
This parameter is used to list the HMAC Identifiers the peer MUST use.
このパラメタは、同輩が使用しなければならないHMAC Identifiersを記載するのに使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8004 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier 1 | HMAC Identifier 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
\ ... \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメータの型=0×8004| パラメタの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC識別子1| HMAC識別子2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC Identifier n| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
図3
Parameter Type: 2 bytes (unsigned integer)
This value MUST be set to 0x8004.
パラメータの型: 2バイト(符号のない整数)、この値を0×8004に設定しなければなりません。
Parameter Length: 2 bytes (unsigned integer)
This value is the number of HMAC Identifiers multiplied by 2, plus
4.
パラメタの長さ: この値は2バイト(符号のない整数)、2、プラス4が掛けられたHMAC Identifiersの数です。
HMAC Identifier n: 2 bytes (unsigned integer)
The values expressed are a list of HMAC Identifiers that may be
used by the peer. The values are listed by preference, with
respect to the sender, where the first HMAC Identifier listed is
the one most preferable to the sender.
HMAC Identifier n: 値が表した2バイト(符号のない整数)は同輩によって使用されるかもしれないHMAC Identifiersのリストです。 値は好みで記載されています、送付者に関して最初のHMAC Identifierがどこに記載したかは、送付者より最も望ましい方です。
Tuexen, et al. Standards Track [Page 6] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[6ページ]。
Padding: 0 or 2 bytes (unsigned integer)
If the number of HMAC Identifiers is not even, the sender MUST pad
the parameter with all zero bytes to make the parameter 32-bit
aligned. The Padding MUST be 0 or 2 bytes long and it MUST be
ignored by the receiver.
詰め物: HMAC Identifiersの数が偶数でないなら、0バイトか2バイト(符号のない整数)、送付者は、パラメタの32ビットを並べさせるためにすべてのバイトでどんなパラメタを水増ししてはいけません。 Paddingは0か2バイト長であるに違いありません、そして、受信機でそれを無視しなければなりません。
The HMAC-ALGO parameter MUST be included once in the INIT or INIT-ACK chunk if the sender wants to send or receive authenticated chunks.
送付者が認証された塊を送りたいか、または受けたいなら、一度、INITかINIT-ACK塊にHMAC-ALGOパラメタを含まなければなりません。
Table 2 shows the currently defined values for HMAC Identifiers.
テーブル2はHMAC Identifiersのために現在定義された値を示しています。
+-----------------+--------------------------+
| HMAC Identifier | Message Digest Algorithm |
+-----------------+--------------------------+
| 0 | Reserved |
| 1 | SHA-1 defined in [8] |
| 2 | Reserved |
| 3 | SHA-256 defined in [8] |
+-----------------+--------------------------+
+-----------------+--------------------------+ | HMAC識別子| メッセージダイジェストアルゴリズム| +-----------------+--------------------------+ | 0 | 予約されます。| | 1 | [8]で定義されたSHA-1| | 2 | 予約されます。| | 3 | [8]で定義されたSHA-256| +-----------------+--------------------------+
Table 2
テーブル2
Every endpoint supporting SCTP chunk authentication MUST support the HMAC based on the SHA-1 algorithm.
SCTP塊認証を支持するあらゆる終点がSHA-1アルゴリズムに基づくHMACを支持しなければなりません。
4. New Error Cause
4. 新しい誤り原因
This section defines a new error cause that will be sent if an AUTH chunk is received with an unsupported HMAC Identifier. Table 3 illustrates the new error cause.
このセクションはサポートされないHMAC Identifierと共にAUTH塊を受け取るなら送る新しい誤り原因を定義します。 テーブル3は新しい誤り原因を例証します。
+------------+-----------------------------+
| Cause Code | Error Cause Name |
+------------+-----------------------------+
| 0x0105 | Unsupported HMAC Identifier |
+------------+-----------------------------+
+------------+-----------------------------+ | 原因コード| 誤り原因名| +------------+-----------------------------+ | 0×0105| サポートされないHMAC識別子| +------------+-----------------------------+
Table 3
テーブル3
4.1. Unsupported HMAC Identifier Error Cause
4.1. サポートされないHMAC識別子誤り原因
This error cause is used to indicate that an AUTH chunk has been received with an unsupported HMAC Identifier.
この誤り原因は、AUTH塊がサポートされないHMAC Identifierと共に受け取られたのを示すのに使用されます。
Tuexen, et al. Standards Track [Page 7] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[7ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 0x0105 | Cause Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Identifier | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コード=0x0105| 原因の長さ=6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC識別子| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
図4
Cause Code: 2 bytes (unsigned integer)
This value MUST be set to 0x0105.
コードを引き起こしてください: 2バイト(符号のない整数)、この値を0×0105に設定しなければなりません。
Cause Length: 2 bytes (unsigned integer)
This value MUST be set to 6.
長さを引き起こしてください: 2バイト(符号のない整数)、この値を6に設定しなければなりません。
HMAC Identifier: 2 bytes (unsigned integer)
This value is the HMAC Identifier which is not supported.
HMAC識別子: この値は2バイト(符号のない整数)、支持されないHMAC Identifierです。
Padding: 2 bytes (unsigned integer)
The sender MUST pad the error cause with all zero bytes to make
the cause 32-bit aligned. The Padding MUST be 2 bytes long and it
MUST be ignored by the receiver.
詰め物: 2バイト(符号のない整数)、送付者は、32ビットが並べた原因を作るためにすべてのバイトでどんな誤り原因を水増ししてはいけません。 Paddingは2バイト長であるに違いありません、そして、受信機でそれを無視しなければなりません。
5. New Chunk Type
5. 新しい塊タイプ
This section defines the new chunk type that will be used to authenticate chunks. Table 4 illustrates the new chunk type.
このセクションは塊を認証するのに使用される新しい塊タイプを定義します。 テーブル4は新しい塊タイプを例証します。
+------------+-----------------------------+
| Chunk Type | Chunk Name |
+------------+-----------------------------+
| 0x0F | Authentication Chunk (AUTH) |
+------------+-----------------------------+
+------------+-----------------------------+ | 塊タイプ| 塊名| +------------+-----------------------------+ | 0x0F| 認証塊(AUTH)| +------------+-----------------------------+
Table 4
テーブル4
It should be noted that the AUTH-chunk format requires the receiver to ignore the chunk if it is not understood and silently discard all chunks that follow. This is accomplished (as described in RFC 2960 [5], Section 3.2.) by the use of the upper bits of the chunk type.
AUTH-塊形式がそれが分かって、静かに続くすべての塊を捨てないことであるなら塊を無視するために受信機を必要とすることに注意されるべきです。 これは塊タイプの上側のビットの使用で達成されます(RFC2960[5](セクション3.2)で説明されるように)。
5.1. Authentication Chunk (AUTH)
5.1. 認証塊(AUTH)
This chunk is used to hold the result of the HMAC calculation.
この塊は、HMAC計算の結果を保持するのに使用されます。
Tuexen, et al. Standards Track [Page 8] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[8ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0F | Flags=0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Key Identifier | HMAC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ HMAC /
/ \
/ +-------------------------------\
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0Fをタイプしてください。| 旗=0| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 共有された主要な識別子| HMAC識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \HMAC//\/+-------------------------------\ | | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
Type: 1 byte (unsigned integer)
This value MUST be set to 0x0F for all AUTH-chunks.
以下をタイプしてください。 1バイト(符号のない整数)、すべてのAUTH-塊のための0x0Fにこの値を設定しなければなりません。
Flags: 1 byte (unsigned integer)
SHOULD be set to zero on transmit and MUST be ignored on receipt.
旗: 1バイト(符号のない整数)のSHOULDをゼロにオンなセットが伝わるということであり、領収書の上で無視しなければなりません。
Length: 2 bytes (unsigned integer)
This value holds the length of the HMAC in bytes plus 8.
長さ: 2バイト(符号のない整数)、この値はバイトと8における、HMACの長さを保持します。
Shared Key Identifier: 2 bytes (unsigned integer)
This value describes which endpoint pair shared key is used.
共有された重要識別子: 2バイト(符号のない整数)、この値は、主要な状態で共有されたどの終点組が使用されているかを説明します。
HMAC Identifier: 2 bytes (unsigned integer)
This value describes which message digest is being used. Table 2
shows the currently defined values.
HMAC識別子: 2バイト(符号のない整数)、この値は、どのメッセージダイジェストが使用されているかを説明します。 テーブル2は現在定義された値を示しています。
HMAC: n bytes (unsigned integer)
This holds the result of the HMAC calculation.
HMAC: nバイト(符号のない整数)、これはHMAC計算の結果を保持します。
Padding: 0, 1, 2, or 3 bytes (unsigned integer)
If the length of the HMAC is not a multiple of 4 bytes, the sender
MUST pad the chunk with all zero bytes to make the chunk 32-bit
aligned. The Padding MUST NOT be longer than 3 bytes and it MUST
be ignored by the receiver.
詰め物: 1バイトか2バイトか0バイトか3バイト(符号のない整数)、送付者は、HMACの長さが4バイトの倍数でないなら、塊の32ビットを並べさせるためにすべてのバイトでどんな塊を水増ししてはいけません。 Paddingは受信機で3バイトとそれを無視しなければならないより長いはずがありません。
The control chunk AUTH MUST NOT appear more than once in an SCTP packet. All control and data chunks that are placed after the AUTH chunk in the packet are sent in an authenticated way. Those chunks placed in a packet before the AUTH chunk are not authenticated. Please note that DATA chunks can not appear before control chunks in an SCTP packet.
コントロール塊AUTH MUST NOTはSCTPパケットで一度より多く見えます。 認証された方法でAUTH塊の後にパケットに置かれるすべてのコントロールとデータ塊を送ります。 AUTH塊の前にパケットに置かれたそれらの塊は認証されません。 DATA塊はコントロール塊の前にSCTPパケットに現れることができません。
Tuexen, et al. Standards Track [Page 9] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[9ページ]。
6. Procedures
6. 手順
6.1. Establishment of an Association Shared Key
6.1. 協会の共有されたキーの設立
An SCTP endpoint willing to receive or send authenticated chunks MUST send one RANDOM parameter in its INIT or INIT-ACK chunk. The RANDOM parameter MUST contain a 32-byte Random Number. The Random Number should be generated in accordance with RFC 4086 [7]. If the Random Number is not 32 bytes, the association MUST be aborted. The ABORT chunk SHOULD contain the error cause 'Protocol Violation'. In case of INIT collision, the rules governing the handling of this Random Number follow the same pattern as those for the Verification Tag, as explained in Section 5.2.4 of RFC 2960 [5]. Therefore, each endpoint knows its own Random Number and the peer's Random Number after the association has been established.
認証された塊を受ける、または送っても構わないと思っているSCTP終点はそのINITかINIT-ACK塊における1つのRANDOMパラメタを送らなければなりません。 RANDOMパラメタは32バイトのRandom Numberを含まなければなりません。 RFC4086[7]に応じて、Random Numberは発生するべきです。 Random Numberが32バイトでないなら、協会を中止しなければなりません。 ABORT塊SHOULDは誤り原因'プロトコルViolation'を含んでいます。 INIT衝突の場合には、このRandom Numberの取り扱いを治める規則はVerification Tagのためのそれらと同じパターンに従います、.4セクション5.2RFC2960[5]で説明されるように。 したがって、協会が設立された後に各終点はそれ自身のRandom Numberと同輩のRandom Numberを知っています。
An SCTP endpoint has a list of chunks it only accepts if they are received in an authenticated way. This list is included in the INIT and INIT-ACK, and MAY be omitted if it is empty. Since this list does not change during the lifetime of the SCTP endpoint there is no problem in case of INIT collision.
SCTP終点には、認証された方法でそれらを受け取るなら、それが受け入れるだけである塊のリストがあります。 このリストは、INITとINIT-ACKに含まれていて、それが空であるなら、省略されるかもしれません。 以来、このリストはINIT衝突の場合にあるSCTP終点の生涯問題を全く変えません。
Each SCTP endpoint MUST include in the INIT and INIT-ACK a HMAC-ALGO parameter containing a list of HMAC Identifiers it requests the peer to use. The receiver of an HMAC-ALGO parameter SHOULD use the first listed algorithm it supports. The HMAC algorithm based on SHA-1 MUST be supported and included in the HMAC-ALGO parameter. An SCTP endpoint MUST NOT change the parameters listed in the HMAC-ALGO parameter during the lifetime of the endpoint.
それぞれのSCTP終点はINITとINIT-ACKにそれが、同輩が使用するよう要求するHMAC Identifiersのリストを含むHMAC-ALGOパラメタを含まなければなりません。 HMAC-ALGOパラメタSHOULDの受信機はそれが支持する最初の記載されたアルゴリズムを使用します。 HMAC-ALGOパラメタに支持されて、含まれていたSHA-1 MUSTに基づくHMACアルゴリズム。 SCTP終点は終点の生涯HMAC-ALGOパラメタにリストアップされたパラメタを変えてはいけません。
Both endpoints of an association MAY have endpoint pair shared keys that are byte vectors and pre-configured or established by another mechanism. They are identified by the Shared Key Identifier. For each endpoint pair shared key, an association shared key is computed. If there is no endpoint pair shared key, only one association shared key is computed by using an empty byte vector as the endpoint pair shared key.
協会の両方の終点で、終点はバイトベクトルであってあらかじめ設定されていて、別のメカニズムによって設立される共有されたキーを対にするかもしれません。 それらはShared Key Identifierによって特定されます。 主要な状態で共有されたそれぞれの終点組において、協会の共有されたキーは計算されます。 主要な状態で共有された終点組が全くなければ、1個の協会の共有されたキーだけが、終点組がキーを共有しながら空のバイトベクトルを使用することによって、計算されます。
The RANDOM parameter, the CHUNKS parameter, and the HMAC-ALGO parameter sent by each endpoint are concatenated as byte vectors. These parameters include the parameter type, parameter length, and the parameter value, but padding is omitted; all padding MUST be removed from this concatenation before proceeding with further computation of keys. Parameters that were not sent are simply omitted from the concatenation process. The resulting two vectors are called the two key vectors.
各終点によって送られたRANDOMパラメタ、CHUNKSパラメタ、およびHMAC-ALGOパラメタはバイトベクトルとして連結されます。 これらのパラメタはパラメータの型、パラメタの長さ、およびパラメタ値を含んでいますが、詰め物は省略されます。 キーのさらなる計算を続ける前に、この連結からすべての詰め物を取り除かなければなりません。 送られなかったパラメタは連結の過程から単に省略されます。 結果として起こる2つのベクトルが2つの主要なベクトルと呼ばれます。
Tuexen, et al. Standards Track [Page 10] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[10ページ]。
From the endpoint pair shared keys and the key vectors, the association shared keys are computed. This is performed by selecting the numerically smaller key vector and concatenating it to the endpoint pair shared key, and then concatenating the numerically larger key vector to that. If the key vectors are equal as numbers but differ in length, then the concatenation order is the endpoint shared key, followed by the shorter key vector, followed by the longer key vector. Otherwise, the key vectors are identical, and may be concatenated to the endpoint pair key in any order. The concatenation is performed on byte vectors, and all numerical comparisons use network byte order to convert the key vectors to a number. The result of the concatenation is the association shared key.
終点組から、共有されたキーと主要なベクトル、協会の共有されたキーは計算されます。 これは、数の上でよりわずかな主要なベクトルを選択して、主要な状態で共有された終点組にそれを連結して、次に、数の上でより大きい主要なベクトルをそれに連結することによって、実行されます。 主要なベクトルが数として等しいのですが、長さにおいて異なるなら、連結命令は、より長い主要なベクトルがあとに続いたより短い主要なベクトルがいうことになった終点の共有されたキーです。 さもなければ、主要なベクトルは、同じであり、どんなオーダーでも主要な終点組に連結されるかもしれません。 連結はバイトベクトルに実行されます、そして、すべての数字の比較が主要なベクトルを数に変換するのにネットワークバイトオーダーを使用します。 連結の結果は協会の共有されたキーです。
6.2. Sending Authenticated Chunks
6.2. 発信は塊を認証しました。
Endpoints MUST send all requested chunks that have been authenticated where this has been requested by the peer. The other chunks MAY be sent whether or not they have been authenticated. If endpoint pair shared keys are used, one of them MUST be selected for authentication.
終点はこれが同輩によって要求されているところで認証されたすべての要求された塊を送らなければなりません。 それらが認証されたか否かに関係なく、他の塊を送るかもしれません。 終点組が共有したならキーが使用されている、認証のためにそれらの1つを選択しなければなりません。
To send chunks in an authenticated way, the sender MUST include these chunks after an AUTH chunk. This means that a sender MUST bundle chunks in order to authenticate them.
塊を送るために、認証された方法で、送付者はAUTH塊の後にこれらの塊を入れなければなりません。 これは、送付者がそれらを認証するために塊を束ねなければならないことを意味します。
If the endpoint has no endpoint pair shared key for the peer, it MUST use Shared Key Identifier zero with an empty endpoint pair shared key. If there are multiple endpoint shared keys the sender selects one and uses the corresponding Shared Key Identifier.
どんな終点も同輩のために終点で共有されたキーを対にしないなら、それは主要な状態で共有される空の終点組と共にShared Key Identifierゼロを使用しなければなりません。 複数の終点の共有されたキーがあれば、送付者は、1つを選択して、対応するShared Key Identifierを使用します。
The sender MUST calculate the Message Authentication Code (MAC) (as described in RFC 2104 [2]) using the hash function H as described by the HMAC Identifier and the shared association key K based on the endpoint pair shared key described by the Shared Key Identifier. The 'data' used for the computation of the AUTH-chunk is given by the AUTH chunk with its HMAC field set to zero (as shown in Figure 6) followed by all the chunks that are placed after the AUTH chunk in the SCTP packet.
送付者はメッセージ立証コード(MAC)について計算しなければなりません。(RFC2104で[2]) ハッシュ関数を使用することで説明されるように、HMAC Identifierと終点組に基づく共有された協会主要なKによって説明されるHはShared Key Identifierによって説明されたキーを共有しました。 AUTH塊の後にSCTPパケットに置かれるすべての塊がゼロ(図6に示されるように)にHMAC分野セットのあとに続いていて、AUTH塊はAUTH-塊の計算に使用される'データ'を与えます。
Tuexen, et al. Standards Track [Page 11] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[11ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0F | Flags=0 | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Key Identifier | HMAC Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ 0 / / +-------------------------------\ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x0Fをタイプしてください。| 旗=0| 塊の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 共有された主要な識別子| HMAC識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ 0 / / +-------------------------------\ | | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図6
Please note that all fields are in network byte order and that the field that will contain the complete HMAC is filled with zeroes. The length of the field shown as zero is the length of the HMAC described by the HMAC Identifier. The padding of all chunks being authenticated MUST be included in the HMAC computation.
ネットワークバイトオーダーにはすべての分野があります、そして、完全なHMACを含む分野はゼロでいっぱいにされます。 ゼロとして示された分野の長さはHMAC Identifierによって説明されたHMACの長さです。 HMAC計算に認証されるすべての塊の詰め物を含まなければなりません。
The sender fills the HMAC into the HMAC field and sends the packet.
送付者は、HMAC分野にHMACをいっぱいにしていて、パケットを送ります。
6.3. Receiving Authenticated Chunks
6.3. 受信は塊を認証しました。
The receiver has a list of chunk types that it expects to be received only after an AUTH-chunk. This list has been sent to the peer during the association setup. It MUST silently discard these chunks if they are not placed after an AUTH chunk in the packet.
受信機には、それがAUTH-塊の後にだけ受け取られると予想する塊タイプのリストがあります。 協会セットアップの間、このリストを同輩に送ります。 それらがAUTH塊の後にパケットに置かれないなら、それは静かにこれらの塊を捨てなければなりません。
The receiver MUST use the HMAC algorithm indicated in the HMAC Identifier field. If this algorithm was not specified by the receiver in the HMAC-ALGO parameter in the INIT or INIT-ACK chunk during association setup, the AUTH chunk and all the chunks after it MUST be discarded and an ERROR chunk SHOULD be sent with the error cause defined in Section 4.1.
受信機はHMAC Identifier分野で示されたHMACアルゴリズムを使用しなければなりません。 捨てられてERROR塊SHOULDになったに違いない後に協会セットアップ、AUTH塊、およびすべての塊の間、INITかINIT-ACK塊におけるHMAC-ALGOパラメタの受信機でこのアルゴリズムを指定しなかったなら、誤り原因がセクション4.1で定義されている状態で、送ってください。
If an endpoint with no shared key receives a Shared Key Identifier other than 0, it MUST silently discard all authenticated chunks. If the endpoint has at least one endpoint pair shared key for the peer, it MUST use the key specified by the Shared Key Identifier if a key has been configured for that Shared Key Identifier. If no endpoint pair shared key has been configured for that Shared Key Identifier, all authenticated chunks MUST be silently discarded.
共有されたキーのない終点が0以外のShared Key Identifierを受けるなら、それは静かにすべての認証された塊を捨てなければなりません。 終点に同輩のための少なくとも1終点組共有されたキーがあるなら、それはキーがそのShared Key Identifierのために構成されたならShared Key Identifierによって指定されたキーを使用しなければなりません。 主要な状態で共有されなかった終点組が全くそのShared Key Identifierのために構成されたなら、静かにすべての認証された塊を捨てなければなりません。
The receiver now performs the same calculation as described for the sender based on Figure 6. If the result of the calculation is the
受信機は現在、図6に基づく送付者のために説明されるのと同じ計算を実行します。 計算の結果はそうです。
Tuexen, et al. Standards Track [Page 12] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[12ページ]。
same as given in the HMAC field, all the chunks following the AUTH chunk are processed. If the field does not match the result of the calculation, all the chunks following the AUTH chunk MUST be silently discarded.
HMAC分野で与えるのと同じであることで、AUTH塊に続くすべての塊が処理されます。 分野が計算の結果に合っていないなら、静かにAUTH塊に続くすべての塊を捨てなければなりません。
It should be noted that if the receiver wants to tear down an association in an authenticated way only, the handling of malformed packets should not result in tearing down the association.
誤った形式のパケットの取り扱いが認証された方法だけで協会を取りこわす受信機必需品であるなら、協会を取りこわすのに結果として生じるべきでないことに注意されるべきです。
An SCTP implementation has to maintain state for each SCTP association. In the following, we call this data structure the SCTP transmission control block (STCB).
SCTP実現はそれぞれのSCTP協会のために状態を維持しなければなりません。 以下では、私たちは、このデータ構造をSCTPトランスミッション制御ブロック(STCB)と呼びます。
When an endpoint requires COOKIE-ECHO chunks to be authenticated, some special procedures have to be followed because the reception of a COOKIE-ECHO chunk might result in the creation of an SCTP association. If a packet arrives containing an AUTH chunk as a first chunk, a COOKIE-ECHO chunk as the second chunk, and possibly more chunks after them, and the receiver does not have an STCB for that packet, then authentication is based on the contents of the COOKIE- ECHO chunk. In this situation, the receiver MUST authenticate the chunks in the packet by using the RANDOM parameters, CHUNKS parameters and HMAC_ALGO parameters obtained from the COOKIE-ECHO chunk, and possibly a local shared secret as inputs to the authentication procedure specified in Section 6.3. If authentication fails, then the packet is discarded. If the authentication is successful, the COOKIE-ECHO and all the chunks after the COOKIE-ECHO MUST be processed. If the receiver has an STCB, it MUST process the AUTH chunk as described above using the STCB from the existing association to authenticate the COOKIE-ECHO chunk and all the chunks after it.
終点が、COOKIE-ECHO塊が認証されるのを必要とするとき、COOKIE-ECHO塊のレセプションがSCTP協会の創設をもたらすかもしれないので、いくつかの特別な手順が従われなければなりません。 最初の塊、2番目の塊としてのCOOKIE-ECHO塊、およびそれらの後のことによるとより多くの塊としてAUTH塊を含んでいて、パケットが到着して、受信機がそのパケットのためのSTCBを持っていないなら、認証はCOOKIE- ECHO塊のコンテンツに基づいています。 この状況で、受信機は、パケットでRANDOMパラメタ(認証手順への入力がセクション6.3で指定したようにパラメタとHMAC_ALGOパラメタがCOOKIE-ECHO塊、およびことによるとローカルの共有秘密キーから入手したCHUNKS)を使用することによって、塊を認証しなければなりません。 認証が失敗するなら、パケットは捨てられます。 認証がCOOKIE-ECHO MUSTの後のうまくいってCOOKIE-ECHOとすべて、塊であるなら処理されてください。 受信機にSTCBがあるなら、それはそれの後にCOOKIE-ECHO塊とすべての塊を認証する既存の協会からSTCBを使用する上で説明されるようにAUTH塊を処理しなければなりません。
If the receiver does not find an STCB for a packet containing an AUTH chunk as the first chunk and does not find a COOKIE-ECHO chunk as the second chunk, it MUST use the chunks after the AUTH chunk to look up an existing association. If no association is found, the packet MUST be considered as out of the blue. The out of the blue handling MUST be based on the packet without taking the AUTH chunk into account. If an association is found, it MUST process the AUTH chunk using the STCB from the existing association as described earlier.
受信機がAUTH塊を含むパケットのために最初の塊としてSTCBに当たらないで、また2番目の塊としてCOOKIE-ECHO塊に当たらないなら、それは、AUTH塊の後に既存の協会を見上げるのに塊を使用しなければなりません。 協会が全く見つけられないなら、青からパケットをみなさなければなりません。 青から、AUTH塊を考慮に入れないで、取り扱いをパケットに基礎づけなければなりません。 協会が見つけられるなら、より早く説明されるように既存の協会からSTCBを使用して、それはAUTH塊を処理しなければなりません。
Requiring ABORT chunks and COOKIE-ECHO chunks to be authenticated makes it impossible for an attacker to bring down or restart an association as long as the attacker does not know the association shared key. But it should also be noted that if an endpoint accepts ABORT chunks only in an authenticated way, it may take longer to detect that the peer is no longer available. If an endpoint accepts COOKIE-ECHO chunks only in an authenticated way, the restart
ABORT塊とCOOKIE-ECHO塊が認証されるのが必要であるのに、協会の共有されたキーを知らない限り、攻撃者が協会を破滅しているか、または再開するのが不可能になります。 しかし、また、同輩が検出するために、より長い撮影ですが、終点が認証された方法だけでABORT塊を受け入れるなら、もう利用可能でない状態で受け入れるかもしれないことに注意されるべきです。 終点が認証された道、再開だけにおけるCOOKIE-ECHO塊を受け入れるなら
Tuexen, et al. Standards Track [Page 13] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[13ページ]。
procedure does not work, because the restarting endpoint most likely does not know the association shared key of the old association to be restarted. However, if the restarting endpoint does know the old association shared key, he can successfully send the COOKIE-ECHO chunk in a way that it is accepted by the peer by using this old association shared key for the packet containing the AUTH chunk. After this operation, both endpoints have to use the new association shared key.
手順は利きません、再開終点がたぶん再開するべき古い協会の協会の共有されたキーを知らないので。 しかしながら、再開終点が古い協会共有されたキーを知っているなら、彼は、AUTH塊を含むパケットにこの古い協会共有されたキーを使用することによって、それが同輩によって受け入れられる方法でCOOKIE-ECHO塊を首尾よく送ることができます。 この操作の後に、両方の終点は新連合の共有されたキーを使用しなければなりません。
If a server has an endpoint pair shared key with some clients, it can request the COOKIE_ECHO chunk to be authenticated and can ensure that only associations from clients with a correct endpoint pair shared key are accepted.
終点がサーバで共有されたキーを何人かのクライアントと対にするなら、それは、認証されるようCOOKIE_ECHO塊に要求できて、正しい終点組が主要な状態で共有されているクライアントからの協会だけが受け入れられるのを確実にすることができます。
Furthermore, it is important that the cookie contained in an INIT-ACK chunk and in a COOKIE-ECHO chunk MUST NOT contain any endpoint pair shared keys.
その上、INIT-ACK塊とCOOKIE-ECHO塊に含まれたクッキーがどんな終点の組の共有されたキーも含んではいけないのは、重要です。
7. Examples
7. 例
This section gives examples of message exchanges for association setup.
このセクションは協会セットアップのための交換処理に関する例を出します。
The simplest way of using the extension described in this document is given by the following message exchange.
以下の交換処理で本書では説明された拡張子を使用する最も簡単な方法を与えます。
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
-------------------- COOKIE-ECHO -------------------->
<-------------------- COOKIE-ACK ---------------------
---------- イニット[無作為; 塊;のHMAC-痛]----------><。------- イニット-ACK[無作為; 塊;のHMAC-痛]--------- -------------------- クッキーエコー--------------------><。-------------------- クッキー-ACK---------------------
Please note that the CHUNKS parameter is optional in the INIT and INIT-ACK.
CHUNKSパラメタはINITとINIT-ACKで任意です。
If the server wants to receive DATA chunks in an authenticated way, the following message exchange is possible:
サーバが認証された方法でDATA塊を受けたいなら、以下の交換処理は可能です:
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
--------------- COOKIE-ECHO; AUTH; DATA ------------->
<----------------- COOKIE-ACK; SACK ------------------
---------- イニット[無作為; 塊;のHMAC-痛]----------><。------- イニット-ACK[無作為; 塊;のHMAC-痛]--------- --------------- クッキーエコー。 AUTH。 データ-------------><。----------------- クッキー-ACK。 袋------------------
Please note that if the endpoint pair shared key depends on the client and the server, and is only known by the upper layer, this message exchange requires an upper layer intervention between the processing of the COOKIE-ECHO chunk and the processing of the AUTH and DATA chunk at the server side. This intervention may be realized by a COMMUNICATION-UP notification followed by the presentation of
主要な状態で共有された終点組がクライアントとサーバに頼っていて、上側の層によって知られているだけであるなら、この交換処理はサーバ側でCOOKIE-ECHO塊の処理とAUTHとDATA塊の処理の間の上側の層の介入を必要とします。 この介入はプレゼンテーションがあとに続いたCOMMUNICATION-UP通知で実現されるかもしれません。
Tuexen, et al. Standards Track [Page 14] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[14ページ]。
the endpoint pair shared key by the upper layer to the SCTP stack, see for example Section 10 of RFC 2960 [5]. If this intervention is not possible due to limitations of the API (for example, the socket API), the server might discard the AUTH and DATA chunk, making a retransmission of the DATA chunk necessary. If the same endpoint pair shared key is used for multiple endpoints and does not depend on the client, this intervention might not be necessary.
終点組は上側の層のそばでSCTPスタックとキーを共有しました、と例えば、RFC2960[5]のセクション10は見ます。 この介入がAPI(例えば、ソケットAPI)の制限のために可能でないなら、サーバはAUTHとDATA塊を捨てるかもしれません、DATA塊の「再-トランスミッション」を必要にして。 主要な状態で共有された同じ終点組が複数の終点に使用されて、クライアントに頼っていないなら、この介入は必要でないかもしれません。
8. IANA Considerations
8. IANA問題
This document (RFC 4895) is the reference for all registrations described in this section. All registrations need to be listed in the document available at SCTP-parameters [9]. The changes are described below.
このドキュメント(RFC4895)はこのセクションで説明されたすべての登録証明書の参照です。 すべての登録証明書が、SCTP-パラメタ[9]で利用可能なドキュメントに記載されている必要があります。 変化は以下で説明されます。
8.1. A New Chunk Type
8.1. 新しい塊タイプ
A chunk type for the AUTH chunk has been assigned by IANA. IANA has assigned the value (15), as given in Table 4. An additional line has been added in the "CHUNK TYPES" table of SCTP-parameters [9]:
AUTH塊のための塊タイプはIANAによって選任されました。 IANAはTable4で与えるように値(15)を割り当てました。 追加線はSCTP-パラメタ[9]の「塊タイプ」テーブルで加えられます:
CHUNK TYPES
塊タイプ
ID Value Chunk Type Reference ----- ---------- --------- 15 Authentication Chunk (AUTH) [RFC4895]
ID値の塊タイプ参照----- ---------- --------- 15 認証塊(AUTH)[RFC4895]
8.2. Three New Parameter Types
8.2. 3人の新しいパラメータの型
Parameter types have been assigned for the RANDOM, CHUNKS, and HMAC- ALGO parameter by IANA. The values are as given in Table 1. This required two modifications to the "CHUNK PARAMETER TYPES" tables in SCTP-parameters [9]: the first is the addition of three new lines to the "INIT Chunk Parameter Types" table:
パラメータの型はRANDOM、CHUNKS、およびHMAC- ALGOパラメタのためにIANAによって選任されました。 値がTable1で与えるようにあります。 これはSCTP-パラメタ[9]の「塊パラメータの型」テーブルへの2つの変更を必要としました: 1番目は「イニット塊パラメータの型」テーブルへの3個の復帰改行の添加です:
Chunk Parameter Type Value -------------------- ----- Random 32770 (0x8002) Chunk List 32771 (0x8003) Requested HMAC Algorithm Parameter 32772 (0x8004)
塊パラメータの型価値-------------------- ----- 無作為の32770(0×8002)塊リスト32771(0×8003)はHMACアルゴリズムパラメタ32772を要求しました。(0×8004)
The second required change is the addition of the same three lines to the to the "INIT ACK Chunk Parameter Types" table.
2番目の必要な変化が3が立ち並ぶ同じくらいの添加である、「INIT ACK塊パラメータの型」テーブルに。
8.3. A New Error Cause
8.3. 新しい誤り原因
An error cause for the Unsupported HMAC Identifier error cause has been assigned. The value (261) has been assigned as in Table 3.
Unsupported HMAC Identifier誤り原因の誤り原因を割り当ててあります。 Table3のように値(261)を割り当ててあります。
Tuexen, et al. Standards Track [Page 15] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[15ページ]。
This requires an additional line of the "CAUSE CODES" table in SCTP- parameters [9]:
これはSCTPパラメタ[9]で「原因コード」テーブルの追加線を必要とします:
VALUE CAUSE CODE REFERENCE ----- ---------------- --------- 261 (0x0105) Unsupported HMAC Identifier [RFC4895]
値の原因コード参照----- ---------------- --------- 261 (0×0105)サポートされないHMAC識別子[RFC4895]
8.4. A New Table for HMAC Identifiers
8.4. HMAC識別子のための新しいテーブル
HMAC Identifiers have to be maintained by IANA. Four initial values have been assigned by IANA as described in Table 2. This required a new table "HMAC IDENTIFIERS" in SCTP-parameters [9]:
HMAC IdentifiersはIANAによって維持されなければなりません。 4つの初期の値がTable2で説明されるようにIANAによって割り当てられました。 これはSCTP-パラメタ[9]で「HMAC識別子」という新しいテーブルを必要としました:
HMAC Identifier Message Digest Algorithm REFERENCE --------------- ------------------------ --------- 0 Reserved [RFC4895] 1 SHA-1 [RFC4895] 2 Reserved [RFC4895] 3 SHA-256 [RFC4895]
HMAC識別子メッセージダイジェストアルゴリズム参照--------------- ------------------------ --------- 0 予約された[RFC4895]1SHA-1[RFC4895]2は[RFC4895]3SHA-256を予約しました。[RFC4895]
For registering a new HMAC Identifier with IANA, in this table, a request has to be made to assign such a number. This number must be unique and a message digest algorithm usable with the HMAC defined in RFC 2104 [2] MUST be specified. The "Specification Required" policy of RFC 2434 [4] MUST be applied.
このテーブルに新しいHMAC IdentifierをIANAに登録するのにおいて、そのような数を割り当てるのを要求をしなければなりません。 この数はユニークであるに違いありません、そして、使用可能なRFC2104[2]で定義されているHMACでメッセージダイジェストアルゴリズムを指定しなければなりません。 「仕様が必要である」というRFC2434[4]の方針を適用しなければなりません。
9. Security Considerations
9. セキュリティ問題
Without using endpoint shared keys, this extension only protects against modification or injection of authenticated chunks by attackers who did not capture the initial handshake setting up the SCTP association.
終点の共有されたキーを使用しないで、この拡大はSCTP協会を設立する初期の握手を得なかった攻撃者による認証された塊の変更か注射から守るだけです。
If an endpoint pair shared key is used, even a true man in the middle cannot inject chunks, which are required to be authenticated, even if he intercepts the initial message exchange. The endpoint also knows that it is accepting authenticated chunks from a peer who knows the endpoint pair shared key.
主要な状態で共有された終点組が使用されているなら、中央の本当の男性さえ塊を注入できません、彼が初期の交換処理を傍受しても。(塊が、認証されるのに必要です)。 また、終点は、終点組がキーを共有したのを知っている同輩から認証された塊を受け入れているのを知っています。
The establishment of endpoint pair shared keys is out of the scope of this document. Other mechanisms can be used, like using TLS or manual configuration.
このドキュメントの範囲の外に終点の組の共有されたキーの設立があります。 TLSか手動の構成を使用するように他のメカニズムを使用できます。
When an endpoint accepts COOKIE-ECHO chunks only in an authenticated way the restart procedure does not work. Neither an attacker nor a restarted endpoint not knowing the association shared key can perform an restart. However, if the association shared key is known, it is possible to restart the association.
終点が認証された方法だけでCOOKIE-ECHO塊を受け入れるとき、再開手順は利きません。 協会の共有されたキーを知らない攻撃者も再開している終点も再開を実行できません。 しかしながら、協会の共有されたキーが知られているなら、協会を再開するのは可能です。
Tuexen, et al. Standards Track [Page 16] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[16ページ]。
Because SCTP already has a built-in mechanism that handles the reception of duplicated chunks, the presented solution makes use of this functionality and does not provide a method to avoid replay attacks by itself. Of course, this only works within each SCTP association. Therefore, a separate shared key is used for each SCTP association to handle replay attacks covering multiple SCTP associations.
SCTPにはコピーされた塊のレセプションを扱う内蔵のメカニズムが既にあるので、提示された解決策は、この機能性を利用して、それ自体で反射攻撃を避ける方法を提供しません。 もちろん、これはそれぞれのSCTP協会の中で働いているだけです。 したがって、別々の共有されたキーは複数のSCTP協会を覆う反射攻撃を扱うそれぞれのSCTP協会に使用されます。
Each endpoint presenting a list of more than one element in the HMAC- ALGO parameter must be prepared for the peer using the weakest algorithm listed.
使用している中でアルゴリズム最も弱い同輩のためにHMAC- ALGOパラメタの1つ以上の要素のリストを提示するのを準備しなければならない各終点は記載しました。
When an endpoint pair uses non-NULL endpoint pair shared keys and one of the endpoints still accepts a NULL key, an attacker who captured the initial handshake can still inject or modify authenticated chunks by using the NULL key.
終点組が非NULL終点組を使用すると共有されたキーと終点の1つが、NULLが主要であるとまだ受け入れていて、初期の握手を得た攻撃者は、NULLキーを使用することによって、まだ認証された塊を注入するか、または変更できます。
10. Acknowledgments
10. 承認
The authors wish to thank David Black, Sascha Grau, Russ Housley, Ivan Arias Rodriguez, Irene Ruengeler, and Magnus Westerlund for their invaluable comments.
作者は彼らの非常に貴重なコメントについてデヴィッドBlack、Saschaグラウ、ラスHousley、イワン・Ariasロドリゲス、アイリーンRuengeler、およびマグヌスWesterlundに感謝したがっています。
11. Normative References
11. 引用規格
[1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[1] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[2]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
[6]Jungmaier、A.、レスコラ、E.、およびM.Tuexen、「流れの制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、2002年12月。
[7] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[7] イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Tuexen, et al. Standards Track [Page 17] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[17ページ]。
[8] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[8]米国商務省標準技術局、「安全な細切れ肉料理規格」、FIPS PUB180-2、2002年8月、<http://csrc.nist.gov/刊行物/fips/fips180-2/fips180-2.pdf>。
[9] <http://www.iana.org/assignments/sctp-parameters>
[9] <sctp http://www.iana.org/課題/パラメタ>。
Authors' Addresses
作者のアドレス
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのマイケルTuexen Muenster大学。 39 48565Steinfurtドイツ
EMail: tuexen@fh-muenster.de
メール: tuexen@fh-muenster.de
Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA
ランドルR.スチュワートシスコシステムズInc.4875森林ドライブSuite200SC29206コロンビア(米国)
EMail: rrs@cisco.com
メール: rrs@cisco.com
Peter Lei Cisco Systems, Inc. 8735 West Higgins Road Suite 300 Chicago, IL 60631 USA
ピーターレイシスコシステムズInc.8735西ヒギンズ道路Suite300IL60631シカゴ(米国)
Phone: EMail: peterlei@cisco.com
以下に電話をしてください。 メール: peterlei@cisco.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
エリックレスコラRTFM Inc.2064Edgewood Driveカリフォルニア94303パロアルト(米国)
Phone: +1 650-320-8549 EMail: ekr@rtfm.com
以下に電話をしてください。 +1 650-320-8549 メールしてください: ekr@rtfm.com
Tuexen, et al. Standards Track [Page 18] RFC 4895 SCTP Authentication Chunk August 2007
Tuexen、他 規格はSCTP認証塊2007年8月にRFC4895を追跡します[18ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Tuexen, et al. Standards Track [Page 19]
Tuexen、他 標準化過程[19ページ]
一覧
スポンサーリンク
