RFC5304 日本語訳

Network Working Group                                              T. Li
Request for Comments: 5304                        Redback Networks, Inc.
Obsoletes: 3567                                              R. Atkinson
Updates: 1195                                     Extreme Networks, Inc.
Category: Standards Track                                   October 2008

コメントを求めるワーキンググループT.李の要求をネットワークでつないでください: Inc.が時代遅れにする5304の20ドル紙幣ネットワーク: 3567のR.アトキンソンアップデート: 1195極端はInc.カテゴリをネットワークでつなぎます: 標準化過程2008年10月

                   IS-IS Cryptographic Authentication

-、暗号の認証

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 the authentication of Intermediate System to
   Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
   Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
   algorithm as found in RFC 2104.  IS-IS is specified in International
   Standards Organization (ISO) 10589, with extensions to support
   Internet Protocol version 4 (IPv4) described in RFC 1195.  The base
   specification includes an authentication mechanism that allows for
   multiple authentication algorithms.  The base specification only
   specifies the algorithm for cleartext passwords.  This document
   replaces RFC 3567.

このドキュメントがIntermediate Systemの認証についてIntermediate Systemに説明する、(-、)、Hashedメッセージ立証コードを使用して、Data Units(PDUs)について議定書の中で述べてください--RFC2104で見つけられるメッセージDigest5(HMAC-MD5)アルゴリズム。 -、国際Standards Organization(ISO)10589で拡大で指定されて、インターネットプロトコルがRFC1195で説明されたバージョン4である(IPv4)とサポートします。 基礎仕様はそれが複数の認証アルゴリズムのために許容する認証機構を含んでいます。基礎仕様はcleartextパスワードにアルゴリズムを指定するだけです。 このドキュメントはRFC3567を取り替えます。

   This document proposes an extension to that specification that allows
   the use of the HMAC-MD5 authentication algorithm to be used in
   conjunction with the existing authentication mechanisms.

このドキュメントはHMAC-MD5認証アルゴリズムの使用が既存の認証機構に関連して使用されるのを許容するその仕様に拡大を提案します。

Li & Atkinson               Standards Track                     [Page 1]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[1ページ]-、暗号の認証2008年10月

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Authentication Procedures . . . . . . . . . . . . . . . . . . . 3
     2.1.  Implementation Considerations . . . . . . . . . . . . . . . 5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Security Limitations  . . . . . . . . . . . . . . . . . . . 5
     3.2.  Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.3.  Key Configuration . . . . . . . . . . . . . . . . . . . . . 6
     3.4.  Other Considerations  . . . . . . . . . . . . . . . . . . . 7
     3.5.  Future Directions . . . . . . . . . . . . . . . . . . . . . 7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 9

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 認証手順. . . . . . . . . . . . . . . . . . . 3 2.1。 実装問題. . . . . . . . . . . . . . . 5 3。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 3.1。 セキュリティ制限. . . . . . . . . . . . . . . . . . . 5 3.2。 保証. . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3。 主要な構成. . . . . . . . . . . . . . . . . . . . . 6 3.4。 他の問題. . . . . . . . . . . . . . . . . . . 7 3.5。 将来の方向. . . . . . . . . . . . . . . . . . . . . 7 4。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 7 5。 承認. . . . . . . . . . . . . . . . . . . . . . . 8 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 8 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 9

Li & Atkinson               Standards Track                     [Page 2]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[2ページ]-、暗号の認証2008年10月

1.  Introduction

1. 序論

   The IS-IS protocol, as specified in [ISO-10589], provides for the
   authentication of Link State Protocol Data Units (LSPs) through the
   inclusion of authentication information as part of the LSP.  This
   authentication information is encoded as a Type-Length-Value (TLV)
   tuple.  The use of IS-IS for IPv4 networks is described in [RFC1195].

-、[ISO-10589]で指定されるプロトコルはLSPの一部として認証情報の包含によるLink州プロトコルData Units(LSPs)の認証に備えます。 この認証情報はType長さの価値(TLV)のtupleとしてコード化されます。 使用、-、IPv4ネットワークのために、説明されたコネ[RFC1195]はそうです。

   The type of the TLV is specified as 10.  The length of the TLV is
   variable.  The value of the TLV depends on the authentication
   algorithm and related secrets being used.  The first octet of the
   value is used to specify the authentication type.  Type 0 is
   reserved, type 1 indicates a cleartext password, and type 255 is used
   for routing domain private authentication methods.  The remainder of
   the TLV value is known as the Authentication Value.

TLVのタイプは10として指定されます。 TLVの長さは可変です。 TLVの値は使用される認証アルゴリズムと関連する秘密に依存します。 価値の最初の八重奏は、認証タイプを指定するのに使用されます。 タイプ0は控え目です、そして、タイプ1はcleartextパスワードを示します、そして、タイプ255は経路ドメインの個人的な認証方法に使用されます。 TLV価値の残りはAuthentication Valueとして知られています。

   This document extends the above situation by allocating a new
   authentication type for HMAC-MD5 and specifying the algorithms for
   the computation of the Authentication Value.  This document also
   describes modifications to the base protocol to ensure that the
   authentication mechanisms described in this document are effective.

このドキュメントは、HMAC-MD5のために新しい認証タイプを割り当てて、Authentication Valueの計算にアルゴリズムを指定することによって、上の状況を広げています。 また、このドキュメントは、本書では説明された認証機構が確実に有効になるようにするためにベースプロトコルに変更を説明します。

   This document is a publication of the IS-IS Working Group within the
   IETF.  This document replaces [RFC3567], which is an Informational
   RFC.  This document is on the Standards Track.  This document has
   revised Section 3, with the significant addition of a discussion of
   recent attacks on MD5 in Section 3.2.  This document has also added a
   substantive "IANA Considerations" section to create a missing
   codepoint registry.

このドキュメントが刊行物である、-、IETFの中の作業部会。 このドキュメントは[RFC3567]を取り替えます。(それは、Informational RFCです)。 このドキュメントはStandards Trackにあります。 このドキュメントはセクション3を改訂しました、セクション3.2におけるMD5についての最近の攻撃の議論の重要な追加で。 また、このドキュメントは、なくなったcodepoint登録を作成するために実質的な「IANA問題」セクションを加えました。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Authentication Procedures

2. 認証手順

   The authentication type used for HMAC-MD5 is 54 (0x36).  The length
   of the Authentication Value for HMAC-MD5 is 16, and the length field
   in the TLV is 17.

HMAC-MD5に使用される認証タイプは54歳(0×36)です。 HMAC-MD5のためのAuthentication Valueの長さは16です、そして、TLVの長さの分野は17です。

   The HMAC-MD5 algorithm requires a key K and text T as input
   [RFC2104].  The key K is the password for the PDU type, as specified
   in ISO 10589.  The text T is the IS-IS PDU to be authenticated with
   the Authentication Value field (inside of the Authentication
   Information TLV) set to zero.  Note that the Authentication Type is
   set to 54 and the length of the TLV is set to 17 before
   authentication is computed.  When LSPs are authenticated, the

HMAC-MD5アルゴリズムは入力されるように[RFC2104]主要なKとテキストTを必要とします。 主要なKはISO10589で指定されるようにPDUタイプへのパスワードです。 テキストTがそうである、-、IS PDU、Authentication Value分野(Authentication情報TLVの内部)で認証されるのはゼロにセットしました。 Authentication Typeが54に用意ができて、認証が計算される前にTLVの長さが17に設定されることに注意してください。 LSPsが認証されるとき

Li & Atkinson               Standards Track                     [Page 3]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[3ページ]-、暗号の認証2008年10月

   Checksum and Remaining Lifetime fields are set to zero (0) before
   authentication is computed.  The result of the algorithm is placed in
   the Authentication Value field.

認証が計算される前にチェックサムとRemaining Lifetime分野が(0)のゼロに合うように設定されます。 アルゴリズムの結果はAuthentication Value分野に置かれます。

   When calculating the HMAC-MD5 result for Sequence Number PDUs, Level
   1 Sequence Number PDUs SHALL use the Area Authentication string as in
   Level 1 Link State PDUs.  Level 2 Sequence Number PDUs SHALL use the
   domain authentication string as in Level 2 Link State PDUs.  IS-IS
   Hello PDUs SHALL use the Link Level Authentication String, which MAY
   be different from that of Link State PDUs.  The HMAC-MD5 result for
   the IS-IS Hello PDUs SHALL be calculated after the packet is padded
   to the MTU size, if padding is not disabled.  Implementations that
   support the optional checksum for the Sequence Number PDUs and IS-IS
   Hello PDUs MUST NOT include the Checksum TLV.

Sequence Number PDUsのためのHMAC-MD5結果について計算するとき、Level1Sequence Number PDUs SHALLはLevel1Link州PDUsのようにArea Authenticationストリングを使用します。 レベル2 Sequence Number PDUs SHALLはLevel2Link州PDUsのようにドメイン認証ストリングを使用します。 -、Hello PDUs SHALLはLink Level Authentication Stringを使用します。(Link Level Authentication StringはLink州PDUsのものと異なっているかもしれません)。 HMAC-MD5が結果になる、-、Hello PDUs SHALL、パケットがMTUサイズに水増しされた後に計算されてください、詰め物は障害がないなら。 そして、Sequence Number PDUsのために任意のチェックサムをサポートする実装、-、Hello PDUsはChecksum TLVを含んではいけません。

   To authenticate an incoming PDU, a system should save the values of
   the Authentication Value field, the Checksum field, and the Remaining
   Lifetime field, set these fields to zero, compute authentication, and
   then restore the values of these fields.

入って来るPDUを認証するために、システムがAuthentication Value分野の値を節約するはずであり、Checksum分野、およびRemaining Lifetime分野は、これらの分野をゼロに設定して、認証を計算して、次に、これらの分野の値を回復します。

   An implementation that implements HMAC-MD5 authentication and
   receives HMAC-MD5 Authentication Information MUST discard the PDU if
   the Authentication Value is incorrect.

Authentication Valueが不正確であるなら、HMAC-MD5が認証であると実装して、HMAC-MD5 Authentication情報を受け取る実装はPDUを捨てなければなりません。

   An implementation MAY have a transition mode where it includes HMAC-
   MD5 Authentication Information in PDUs but does not verify the HMAC-
   MD5 Authentication Information.  This is a transition aid for
   networks in the process of deploying authentication.

実装は、PDUsにそれがHMAC MD5 Authentication情報を含んでいる変遷モードを持っているかもしれませんが、HMAC MD5 Authentication情報について確かめません。 これは認証を配布することの途中にネットワークのための変遷援助です。

   An implementation MAY check a set of passwords when verifying the
   Authentication Value.  This provides a mechanism for incrementally
   changing passwords in a network.

Authentication Valueについて確かめるとき、実装は1セットのパスワードをチェックするかもしれません。 これはネットワークにおけるパスワードを増加して変えるのにメカニズムを提供します。

   An implementation that does not implement HMAC-MD5 authentication MAY
   accept a PDU that contains the HMAC-MD5 Authentication Type.  ISes
   (routers) that implement HMAC-MD5 authentication and initiate LSP
   purges MUST remove the body of the LSP and add the authentication
   TLV.  ISes implementing HMAC-MD5 authentication MUST NOT accept
   unauthenticated purges.  ISes MUST NOT accept purges that contain
   TLVs other than the authentication TLV.  These restrictions are
   necessary to prevent a hostile system from receiving an LSP, setting
   the Remaining Lifetime field to zero, and flooding it, thereby
   initiating a purge without knowing the authentication password.

HMAC-MD5が認証であると実装しない実装はHMAC-MD5 Authentication Typeを含むPDUを受け入れるかもしれません。 HMAC-MD5が認証であると実装して、LSPパージを開始するISes(ルータ)はLSPのボディーを取り除いて、認証TLVを加えなければなりません。 HMAC-MD5が認証であると実装するISesは非認証されたパージを受け入れてはいけません。 ISesは認証TLV以外のTLVsを含むパージを受け入れてはいけません。 これらの制限が敵軍のシステムがLSPを受けるのを防ぐのに必要です、Remaining Lifetime分野をゼロに設定して、それをあふれさせて、その結果、認証パスワードを知らないで、パージを開始します。

Li & Atkinson               Standards Track                     [Page 4]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[4ページ]-、暗号の認証2008年10月

2.1.  Implementation Considerations

2.1. 実装問題

   There is an implementation issue that occurs just after password
   rollover on an IS-IS router and that might benefit from additional
   commentary.  Immediately after password rollover on the router, the
   router or IS-IS process may restart.  If this happens, this causes
   the LSP Sequence Number to restart from the value 1 using the new
   password.  However, neighbors will reject those new LSPs because the
   Sequence Number is smaller.  The router cannot increase its own LSP
   Sequence Number because it fails to authenticate its own old LSP that
   neighbors keep sending to it.  So the router cannot update its LSP
   Sequence Number to its neighbors until all the neighbors time out all
   of the original LSPs.  One possible solution to this problem is for
   the IS-IS process to detect if any inbound LSP with an authentication
   failure has the local System ID and also has a higher Sequence Number
   than the IS-IS process has.  In this event, the IS-IS process SHOULD
   increase its own LSP Sequence Number accordingly and re-flood the
   LSPs.  However, as this scenario could also be triggered by an active
   attack by an adversary, it is recommended that a counter be kept on
   this case to mitigate the risk from such an attack.

それがパスワードロールオーバーのすぐ後に起こる導入問題がある、-、ルータ、そして、追加論評のおかげで得します力がその。 ルータ、ルータに関するパスワードロールオーバー直後または、-、プロセスは再開するかもしれません。 起こるなら、これで、LSP Sequence Numberは、値1から新しいパスワードを使用することで再開します。 しかしながら、Sequence Numberが、より小さいので、隣人はそれらの新しいLSPsを拒絶するでしょう。 隣人がそれに送り続けるそれ自身の古いLSPを認証しないので、ルータはそれ自身のLSP Sequence Numberを増強できません。 したがって、ルータはすべての隣人タイムアウトまでLSP Sequence Numberを隣人にアップデートできません。オリジナルのLSPsのすべて。 この問題への1つの可能な解決がある、-、処理して、何か認証失敗がある本国行きのLSPが地方のSystem IDを持っていて、また、より高いSequence Numberを持っているかどうか検出してください、-、プロセス、持っています。 このイベントで-、プロセスSHOULDはそれに従って、それ自身のLSP Sequence Numberを増強して、LSPsを再あふれさせます。 また、敵による活発な攻撃でこのシナリオを引き起こすことができるでしょう、しかしながら、したがって、カウンタがそのような攻撃から危険を緩和するために本件の上に保たれるのは、お勧めです。

3.  Security Considerations

3. セキュリティ問題

   This document enhances the security of the IS-IS routing protocol.
   Because a routing protocol contains information that need not be kept
   secret, privacy is not a requirement.  However, authentication of the
   messages within the protocol is of interest in order to reduce the
   risk of an adversary compromising the routing system by deliberately
   injecting false information into that system.

このドキュメントがセキュリティを高める、-、ルーティング・プロトコル。 ルーティング・プロトコルが必要性が秘密にされないという情報を含んでいるので、プライバシーは要件ではありません。 しかしながら、プロトコルの中のメッセージの認証は、故意にそのシステムに偽情報を注ぐことによってルーティングシステムに感染する敵の危険を減少させるために興味があります。

3.1.  Security Limitations

3.1. セキュリティ制限

   The technology in this document provides an authentication mechanism
   for IS-IS.  The mechanism described here is not perfect and does not
   need to be perfect.  Instead, this mechanism represents a significant
   increase in the work function of an adversary attacking the IS-IS
   protocol, while not causing undue implementation, deployment, or
   operational complexity.  It provides improved security against
   passive attacks, as defined in [RFC1704], when compared to cleartext
   password authentication.

技術が本書では認証機構を提供する、- ここで説明されたメカニズムは、完全でなく、完全である必要はありません。 代わりに、このメカニズムが敵が攻撃する仕事機能のかなりの増加を表す、-、過度の実装、展開、または操作上の複雑さを引き起こしていない間、議定書を作ってください。 cleartextパスワード認証と比べると、それは[RFC1704]で定義されるように受け身の攻撃に対して向上したセキュリティを提供します。

   This mechanism does not prevent replay attacks; however, in most
   cases, such attacks would trigger existing mechanisms in the IS-IS
   protocol that would effectively reject old information.  Denial-of-
   service attacks are not generally preventable in a useful networking
   protocol [DoS].

このメカニズムは反射攻撃を防ぎません。 しかしながら、多くの場合、そのような攻撃が既存のメカニズムの引き金となるだろう、-、事実上、旧情報を拒絶するプロトコル。 -一般に、攻撃が役に立つネットワーク・プロトコル[DoS]でサービスでは、予防可能でないという否定。

Li & Atkinson               Standards Track                     [Page 5]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[5ページ]-、暗号の認証2008年10月

   The mechanisms in this document do not provide protection against
   compromised, malfunctioning, or misconfigured routers.  Such routers
   can, either accidentally or deliberately, cause malfunctions that
   affect the whole routing domain.  The reader is encouraged to consult
   [RFC4593] for a more comprehensive description of threats to routing
   protocols.

メカニズムは本書では感染しているか、誤動作しているか、misconfiguredされたルータに対する保護を提供しません。 そのようなルータは偶然か故意に全体の経路ドメインに影響する不調を引き起こす場合があります。 読者がルーティング・プロトコルへの脅威の、より包括的な記述のために[RFC4593]に相談するよう奨励されます。

3.2.  Assurance

3.2. 保証

   Users need to understand that the quality of the security provided by
   this mechanism depends completely on the strength of the implemented
   authentication algorithms, the strength of the key being used, and
   the correct implementation of the security mechanism in all
   communicating IS-IS implementations.  This mechanism also depends on
   the IS-IS Authentication Key being kept confidential by all parties.
   If any of these are incorrect or insufficiently secure, then no real
   security will be provided to the users of this mechanism.

ユーザが、このメカニズムによって提供されたセキュリティの品質をすべての交信で完全実装している認証アルゴリズムの強さ、使用されるキーの強さ、およびセキュリティー対策の正しい実装に依存するのを理解する必要がある、-、実装。 また、このメカニズムがよる、-、すべてによって秘密にされるAuthentication Keyはパーティーへ行きます。 これらのどれかが不正確であるか、または不十分に安全であるなら、このメカニズムのユーザに物上担保を全く提供しないでしょう。

   Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were
   first published a dozen years ago, there have been growing concerns
   about the effectiveness of the compression function within MD5.  More
   recent work by Wang and Yu [WY05] accentuates these concerns.
   However, despite these research results, there are no published
   attacks at present on either Keyed-MD5 or HMAC-MD5.  A recent paper
   by Bellare [Bell06a] [Bell06b] provides new proofs for the security
   of HMAC that require fewer assumptions than previous published proofs
   for HMAC.  Those proofs indicate that the published issues with MD5
   (and separately with SHA-1) do not create an attack on HMAC-MD5 (or
   HMAC SHA-1).  Most recently, Fouque and others [FLN07] have published
   new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5.  However, their
   attacks are non-trivial computationally, and they have not found an
   equivalent attack on HMAC-MD5.  So, despite the published issues with
   the MD5 algorithm, there is currently no published attack that
   applies to HMAC-MD5 as used in this IS-IS specification.  As with any
   cryptographic technique, there is the possibility of the discovery of
   future attacks against this mechanism.

MD5[Dobb96a][Dobb96b][Dobb98]に対するDobbertinの攻撃が12年前に最初に発行されたので、MD5の中に圧縮機能の有効性に関して懸念の増大がありました。 ワングとユー[WY05]による、より最近の仕事はこれらの関心を強調します。 しかしながら、これらの研究結果にもかかわらず、Keyed-MD5かHMAC-MD5のどちらかに対する現在のところの攻撃は発行されません。 Bellare[Bell06a][Bell06b]による最近の紙はHMACのために前の発行された証拠より少ない仮定を必要とするHMACのセキュリティに新しい証拠を提供します。 それらの証拠が示す、発行がMD5と共に発行する、(別々に、SHA-1) HMAC-MD5(または、HMAC SHA-1)に対する攻撃を作成しないでください。 ごく最近、フークと他のもの[FLN07]はNMAC-MD4、HMAC-MD4、およびNMAC-MD5に対する新しい攻撃を発行しました。 しかしながら、彼らの攻撃は計算上重要です、そして、彼らはHMAC-MD5に対する同等な攻撃を見つけていません。 それで、MD5アルゴリズムの発行された問題にもかかわらず、これで使用されるようにHMAC-MD5に適用される現在発行されなかった攻撃がある、-、仕様。 どんな暗号のテクニックのようにも、今後の攻撃の発見の可能性はこのメカニズムに反対しています。

3.3.  Key Configuration

3.3. 主要な構成

   It should be noted that the key configuration mechanism of routers
   may restrict the possible keys that may be used between peers.  It is
   strongly recommended that an implementation be able to support, at
   minimum, a key composed of a string of printable ASCII of 80 bytes or
   less, as this is current practice.

ルータの主要な構成メカニズムが同輩の間で使用されるかもしれない可能なキーを制限するかもしれないことに注意されるべきです。 実装が最小限で80バイト以下の印刷可能なASCIIのストリングで構成されたキーを支えることができることが強く勧められます、これが現在の習慣であるので。

Li & Atkinson               Standards Track                     [Page 6]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[6ページ]-、暗号の認証2008年10月

3.4.  Other Considerations

3.4. 他の問題

   Changes to the authentication mechanism described here (primarily: to
   add a Key-ID field such as that of OSPFv2 and RIPv2) were considered
   at some length, but ultimately were rejected.  The mechanism here was
   already widely implemented in 1999.  As of this writing, this
   mechanism is fairly widely deployed within the users interested in
   cryptographic authentication of IS-IS.  The improvement provided by
   the proposed revised mechanism was not large enough to justify the
   change, given the installed base and lack of operator interest in
   deploying a revised mechanism.

加えてください。認証機構への変化がここで説明した、(主として:、OSPFv2とRIPv2のものなどのKey-ID分野) 何らかの長さで考えられましたが、結局、拒絶されました。 ここのメカニズムは1999年に既に広く実装されました。 この書くこと現在このメカニズムが暗号の認証に興味を持っているユーザの中で広く公正に配布される、- 提案された改訂されたメカニズムによって提供された改良は変化を正当化できるくらいには大きくはありませんでした、改訂されたメカニズムを配布することへのオペレータ関心のインストールされたベースと不足を考えて。

   If and when a key management protocol appears that is both widely
   implemented and easily deployed to secure routing protocols such as
   IS-IS, a different authentication mechanism that is designed for use
   with that key management schema could be added if desired.

a主要な管理プロトコルが現れるなら、それがルーティング・プロトコルを保証するために広く実装されて、かつ容易に配布される、-、望まれているなら、使用のためにそのかぎ管理図式で設計されている異なった認証機構は加えられるかもしれません。

3.5.  Future Directions

3.5. 将来の方向

   If a stronger authentication were believed to be required, then the
   use of a full digital signature [RFC2154] would be an approach that
   should be seriously considered.  It was rejected for this purpose at
   this time because the computational burden of full digital signatures
   is believed to be much higher than is reasonable, given the current
   threat environment in operational commercial networks.

より強い認証が必要であると信じられているなら、完全なデジタル署名[RFC2154]の使用は真剣に考えられるべきであるアプローチでしょうに。 妥当であるというよりも完全なデジタル署名のコンピュータの負担がはるかに高いと信じられているので、それはこのためにこのとき拒絶されました、操作上の商業ネットワークにおける現在の脅威環境を考えて。

   If and when additional authentication mechanisms are defined (for
   example, to provide a cryptographically stronger hash function), it
   will also be necessary to define mechanisms that allow graceful
   transition from the existing mechanisms (as defined in this document)
   to any future mechanism.

また、追加認証機構が定義されると(例えば、暗号でより強い状態でaを提供するには、機能を論じ尽くしてください)、優雅な既存のメカニズム(本書では定義されるように)から将来のどんなメカニズムまでの変遷も許容するメカニズムを定義するのも必要でしょう。

4.  IANA Considerations

4. IANA問題

   IANA has created a new codepoint registry to administer the
   Authentication Type codepoints for TLV 10.  This registry is part of
   the existing IS-IS codepoints registry as established by [RFC3563]
   and [RFC3359].  This registry is managed using the Designated Expert
   policy as described in [RFC5226] and is called "IS-IS Authentication
   Type Codes for TLV 10".

IANAは、TLV10のためにAuthentication Type codepointsを管理するために新しいcodepoint登録を作成しました。 この登録が存在の一部である、-、[RFC3563]と[RFC3359]によって確立されるcodepoints登録。 この登録が[RFC5226]で説明されるようにDesignated Expert方針を使用することで管理されて、呼ばれる、「-、認証タイプがTLVのために10インチをコード化する、」

   The values in the "IS-IS Authentication Type Codes for TLV 10"
   registry should be recorded in decimal and should only be approved
   after a designated expert, appointed by the IESG area director, has
   been consulted.  The intention is that any allocation will be
   accompanied by a published RFC.  However, the designated expert can
   approve allocations once it seems clear that an RFC will be
   published, allowing for the allocation of values prior to the

中の値、「-、IESG領域ディレクターによって任命された指定された専門家が相談された後に、TLVの10インチの登録への認証タイプコードが小数に記録されるべきであり、承認されるだけであるべきである、」 意志はどんな配分も発行されたRFCによって伴われるということです。 しかしながら、いったん値の配分を考慮して、RFCが発行されるのが明確である前に見えると、指定された専門家は配分を承認できます。

Li & Atkinson               Standards Track                     [Page 7]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[7ページ]-、暗号の認証2008年10月

   document being approved for publication as an RFC.  New items should
   be documented in a publicly and freely available specification.  We
   should also allow external specifications to allocate and use the
   IS-IS Authentication Type Codes maintained by this registry.

公表のためにRFCとして承認されていた状態で存在を記録してください。 新商品は公的で自由に利用可能な仕様に記録されるべきです。 また、私たちが割り当てる外部仕様と使用を許すべきである、-、この登録によって維持されたAuthentication Type Codes。

   Initial values for the "IS-IS Authentication Type Codes for TLV 10"
   registry are given below; future assignments are to be made through
   Expert Review.  Assignments consist of an authentication type name
   and its associated value.

値に頭文字をつける、「-、TLVの10インチの登録への認証タイプコードを以下に与える、」、。 将来の課題はExpert Reviewを通して作られていることです。 課題は認証型名とその関連価値から成ります。

   +---------------------------------------------+-------+-------------+
   | Authentication Type Code                    | Value | Reference   |
   +---------------------------------------------+-------+-------------+
   | Reserved                                    | 0     | [ISO-10589] |
   | Cleartext Password                          | 1     | [ISO-10589] |
   | ISO 10589 Reserved                          | 2     | [ISO-10589] |
   | HMAC-MD5 Authentication                     | 54    | RFC 5304    |
   | Routeing Domain private authentication      | 255   | [ISO-10589] |
   | method                                      |       |             |
   +---------------------------------------------+-------+-------------+

+---------------------------------------------+-------+-------------+ | 認証タイプコード| 値| 参照| +---------------------------------------------+-------+-------------+ | 予約されます。| 0 | [ISO-10589]| | Cleartextパスワード| 1 | [ISO-10589]| | 予約されたISO10589| 2 | [ISO-10589]| | HMAC-MD5認証| 54 | RFC5304| | Routeing Domainの個人的な認証| 255 | [ISO-10589]| | メソッド| | | +---------------------------------------------+-------+-------------+

5.  Acknowledgements

5. 承認

   The authors would like to thank (in alphabetical order) Stephen
   Farrell, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and
   Henk Smit for their comments and suggestions on this document.

作者はこのドキュメントの上に彼らのコメントと提案についてNai-明のスティーブン・ファレル、デーヴ・キャッツ、スティーブンLuong、トニーPrzygienda、シン、およびヘンク・スミットに感謝したがっています(アルファベット順に)。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [ISO-10589]  ISO, "Intermediate System to Intermediate System intra-
                domain routeing information exchange protocol for use in
                conjunction with the protocol for providing the
                connectionless-mode network service (ISO 8473)",
                International Standard 10589:2002, Second Edition, 2002.

[ISO-10589]ISO、「Intermediate Systemイントラドメインrouteing情報交換への中間的Systemは使用のためにコネクションレスなモードネットワーク・サービス(ISO8473)を提供するためのプロトコルに関連して議定書を作ります」、国際規格。10589:2002 Second Edition、2002。

   [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", RFC 2104,
                February 1997.

[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Li & Atkinson               Standards Track                     [Page 8]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[8ページ]-、暗号の認証2008年10月

6.2.  Informative References

6.2. 有益な参照

   [Bell06a]    Bellare, M., "New Proofs for NMAC and HMAC: Security
                without Collision-Resistance", Preliminary Version, in
                Proceedings of Crypto 2006, Lecture Notes in Computer
                Science, Vol. 4117, August 2006.

[Bell06a]Bellare、M.、「NMACとHMACのための新しい証拠:」 「衝突抵抗のないセキュリティ」(暗号2006の議事における準備段階)はコンピュータサイエンス、Vol.4117、2006年8月に注意について講義します。

   [Bell06b]    Bellare, M., "New Proofs for NMAC and HMAC: Security
                without Collision-Resistance", August 2006, <http://
                www-cse.ucsd.edu/users/mihir/papers/hmac-new.html>.

[Bell06b]Bellare、M.、「NMACとHMACのための新しい証拠:」 「Collision-抵抗のないセキュリティ」、2006年8月、<http://www-cse.ucsd.edu/ユーザ/mihir/書類/hmac-new.html>。

   [DoS]        Voydock, V. and S. Kent, "Security Mechanisms in High-
                level Networks", ACM Computing Surveys Vol. 15, No. 2,
                June 1983.

[DoS] Voydock、V.、およびS.ケント、「HighのセキュリティMechanismsはNetworksを平らにします」、ACM Computing Surveys Vol.15、No.2、1983年6月。

   [Dobb96a]    Dobbertin, H., "Cryptanalysis of MD5 Compress",
                EuroCrypt Rump Session 1996, May 1996.

[Dobb96a]Dobbertin(H.、「MD5湿布の暗号文解読術」、EuroCrypt臀部セッション1996)は1996がそうするかもしれません。

   [Dobb96b]    Dobbertin, H., "The Status of MD5 After a Recent
                Attack", CryptoBytes, Vol. 2, No. 2, 1996.

[Dobb96b]Dobbertin、H.、「最近の攻撃の後のMD5の状態」CryptoBytes2、Vol.No.2、1996。

   [Dobb98]     Dobbertin, H., "Cryptanalysis of MD4", Journal of
                Cryptology, Vol. 11, No. 4, 1998.

[Dobb98] Dobbertin、H.、「MD4"の暗号文解読術、暗号理論、Vol.11、No.4、1998のジャーナル。」

   [FLN07]      Fouque, P., Leurent, G., and P. Nguyen, "Full Key-
                Recovery Attacks on HMAC/NMAC-MD5 and NMAC-MD5",
                Proceedings of Crypto 2007, August 2007.

[FLN07] フーク、P.、Leurent、G.、およびP.Nguyen、「完全な主要な回復はHMAC/NMAC-MD5とNMAC-MD5"で攻撃されます、暗号2007の議事、2007年8月。」

   [RFC1195]    Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
                dual environments", RFC 1195, December 1990.

[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日

   [RFC1704]    Haller, N. and R. Atkinson, "On Internet
                Authentication", RFC 1704, October 1994.

[RFC1704] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。

   [RFC2154]    Murphy, S., Badger, M., and B. Wellington, "OSPF with
                Digital Signatures", RFC 2154, June 1997.

1997年6月の[RFC2154]マーフィーとS.とムジナ、M.とB.ウェリントン、「デジタル署名があるOSPF」RFC2154。

   [RFC3359]    Przygienda, T., "Reserved Type, Length and Value (TLV)
                Codepoints in Intermediate System to Intermediate
                System", RFC 3359, August 2002.

[RFC3359]Przygienda、2002年8月のT.、「控え目なタイプ、中間システムへの中間システムの長さと値(TLV)のCodepoints」RFC3359。

   [RFC3563]    Zinin, A., "Cooperative Agreement Between the ISOC/IETF
                and ISO/IEC Joint Technical Committee 1/Sub Committee 6
                (JTC1/SC6) on IS-IS Routing Protocol Development",
                RFC 3563, July 2003.

[RFC3563]ジニン、A.、「ISOC/IETFとISO/IECの共同専門委員会1/潜水艦委員会6(JTC1/SC6)の間の共同契約、オンである、-、ルーティング・プロトコル開発、」、RFC3563(2003年7月)

Li & Atkinson               Standards Track                     [Page 9]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[9ページ]-、暗号の認証2008年10月

   [RFC3567]    Li, T. and R. Atkinson, "Intermediate System to
                Intermediate System (IS-IS) Cryptographic
                Authentication", RFC 3567, July 2003.

[RFC3567] 李、T.、およびR.アトキンソン、「中間システムへの中間システム、(-、)、暗号の認証、」、RFC3567、7月2003日

   [RFC4593]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
                Routing Protocols", RFC 4593, October 2006.

2006年10月の[RFC4593]BarbirとA.とマーフィー、S.とY.陽、「ルーティング・プロトコルへのジェネリックの脅威」RFC4593。

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。

   [WY05]       Wang, X. and H. Yu, "How to Break MD5 and Other Hash
                Functions", Proceedings of EuroCrypt 2005, Lecture Notes
                in Computer Science, Vol. 3494, 2005.

[WY05] ワング、X.、およびH.ユー(「どうMD5と他のハッシュを壊すかは機能する」EuroCrypt2005の議事)はコンピュータサイエンス(Vol.3494、2005)での注意について講義します。

Authors' Addresses

作者のアドレス

   Tony Li
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA  95134
   USA

トニー李RedbackがInc.300オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぐ、米国

   Phone: +1 408 750 5160
   EMail: tony.li@tony.li

以下に電話をしてください。 +1 5160年の408 750メール: tony.li@tony.li

   R. Atkinson
   Extreme Networks, Inc.
   3585 Monroe St.
   Santa Clara, CA  95051
   USA

R.アトキンソン極端はInc.3585モンロー聖サンタクララ、カリフォルニア95051米国をネットワークでつなぎます。

   Phone: +1 408 579 2800
   EMail: rja@extremenetworks.com

以下に電話をしてください。 +1 2800年の408 579メール: rja@extremenetworks.com

Li & Atkinson               Standards Track                    [Page 10]

RFC 5304           IS-IS Cryptographic Authentication       October 2008

李とアトキンソンStandardsがRFC5304を追跡する、[10ページ]-、暗号の認証2008年10月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   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に情報を扱ってください。

Li & Atkinson               Standards Track                    [Page 11]

李とアトキンソン標準化過程[11ページ]