この文書はRFC3097の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group                                          R. Braden
Request for Comments: 3097                                           ISI
Updates: 2747                                                   L. Zhang
Category: Standards Track                                           UCLA
                                                              April 2001


                  RSVP Cryptographic Authentication --
                       Updated Message Type Value
                ＲＳＶＰ暗号認証−メッセージタイプ値更新


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.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
   １）の現在の版を参照してください。このメモの配布は無制限です。


Copyright Notice
著作権表示


   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract
概要


   This memo resolves a duplication in the assignment of RSVP Message
   Types, by changing the Message Types assigned by RFC 2747 to
   Challenge and Integrity Response messages.
   このメモは、ＲＦＣ２７４７によって挑戦と完全性回答メッセージに割り当
   てられたメッセージタイプを変えることで、ＲＳＶＰメッセージタイプ割当
   ての重複を解決します。

1. Introduction
1. はじめに


   RFC 2747 ("RSVP Cryptographic Authentication") [RFC2747] assigns RSVP
   Message Type 12 to an Integrity Response message, while RFC 2961
   ("RSVP Refresh Overhead Reduction Extensions") [RFC2961] assigns the
   same value to a Bundle message.  This memo resolves the conflict over
   RSVP Message Type 12 by assigning a different value to the Message
   Type of the Integrity Response Message in RFC 2747.  It is believed
   that the protocol defined by RFC 2961 entered use in the field before
   the RFC's publication and before the conflicting Message Type was
   noticed, and that it may be easier to install new software in
   environments that have deployed the Integrity object than in those
   that have deployed the refresh reduction extension.
   ＲＦＣ２７４７（「ＲＳＶＰ暗号認証」）[RFC2747]が、完全性回答メッセー
   ジに、ＲＳＶＰメッセージタイプ１２を割り当て、ＲＦＣ２９６１（「ＲＳ
   ＶＰリフレッシュオーバーヘッド縮小拡張」）[RFC2961]が同じ値をバンドル
   メッセージに割り当てます。このメモはＲＦＣ２７４７の完全性回答メッセー
   ジのメッセージタイプに他の値を割当てることで、ＲＳＶＰメッセージタイ
   プ１２の競合を解決します。ＲＦＣ２９６１で定義されたプロトコルは、Ｒ
   ＦＣの出版とメッセージの競合に気づく前に使用され、そしてリフレッシュ
   オーバーヘッド縮小拡張を使用する環境のソフトウェアの変更をするよりも、
   完全性オブジェクトを実装した環境でソフトウェアを変更するよりも容易で
   あると信じられます。


   To simplify possible interoperability problems caused by this change,
   we also assign a new value to the Message Type of RFC 2747's
   Challenge message, to which the Integrity Response message is a
   reply.
   この変更によって起きうる互換性問題を単純化するために、完全性回答メッ
   セージの元になるＲＦＣ２７４７のチャレンジメッセージのメッセージタイ
   プに新しい値を割り当てます。


2. Modification
2. 変更

   Message Types defined in the RSVP Integrity extension [RFC 2747]
   shall be changed as follows:
   ＲＳＶＰ完全性拡張[RFC 2747]で定義されたメッセージタイプが次のように
   変えられるべきです：

      o Challenge message has Message Type 25.
      o チャレンジメッセージがメッセージタイプ２５です。
      o Integrity Response message has Message Type 25+1.
      o 完全性回答メッセージがメッセージタイプ２５＋１です。

3. Compatibility
3. 互換性

   Two communicating nodes whose Integrity implementations are
   conformant with this modification will interoperate, using Message
   Type 12 for Bundle messages and Message Types 25 and 26 for the
   Integrity handshake.  A non-conformant implementation of the
   Integrity extension will not interoperate with a conformant
   implementation (though two non-conformant implementations can
   interoperate as before).
   この修正に準拠する完全性を実装した２つの通信ノードが、メッセージタイ
   プ１２をバンドルメッセージに、メッセージタイプ２５と２６を完全性ハン
   ドシェークに使って、相互運用するでしょう。完全性拡張に非準拠の実装が
   準拠実装と相互運用しないでしょう（２つの非準拠実装が以前通り相互運用
   できるけれども）。

   There is no possibility of an Integrity handshake succeeding
   accidentally due to this change, since both sides of the handshake
   use the new numbers or the old numbers.  Furthermore, the Integrity
   Response message includes a 32-bit cookie that must match a cookie in
   the Challenge message, else the challenge will fail.  Finally, a
   non-conformant implementation should never receive a Bundle message
   that it interprets as an Integrity Response message, since RFC 2961
   requires that Bundle messages be sent only to a Bundle-capable node.
   ハンドシェークの両側が新しい番号か古い番号かを使うので、この変更によ
   り偶然ハンドシェークが成功する可能性がありません。さらに、完全性回答
   メッセージはチャレンジメッセージのクッキーと一致しなくてはならない３
   ２ビットのクッキーを含むので、チャレンジは失敗するでしょう。ＲＦＣ２
   ９６１がバンドルメッセージをバンドル対応のノードにだけ送る様に要求す
   るので、最終的に、非準拠実装は決して完全性回答メッセージと解釈するこ
   とになるバンドルメッセージを受け取るべきではありません。

4. References
4. 参考文献

   [RFC2747]  Baker, F., Lindell, R. and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, April 2001.

Security Considerations
セキュリティの考察

   No new security considerations are introduced beyond RFC 2747 itself
   and the compatibility issues above.
   ＲＦＣ２７４７にある以上の新しいセキュリティの懸念が発生せず、互換性
   問題は上記の通りです。



Authors' Addresses
著者のアドレス


   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: (310) 822-1511
   EMail: Braden@ISI.EDU


   Lixia Zhang
   UCLA Computer Science Department
   4531G Boelter Hall
   Los Angeles, CA 90095-1596 USA

   Phone: 310-825-2695
   EMail: lixia@cs.ucla.edu



Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.
   著作権（Ｃ）インターネット学会（２００１）。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。