RFC5169 日本語訳

Network Working Group                                          T. Clancy
Request for Comments: 5169                                           LTS
Category: Informational                                      M. Nakhjiri
                                                                Motorola
                                                            V. Narayanan
                                                              L. Dondeti
                                                                Qualcomm
                                                              March 2008

コメントを求めるワーキンググループT.クランシー要求をネットワークでつないでください: 5169年のLTSカテゴリ: 2008年の情報のM.のV.ナラヤナンのL.DondetiクアルコムのNakhjiriモトローラの行進

    Handover Key Management and Re-Authentication Problem Statement

引き渡しKey Managementと再認証問題声明

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document describes the Handover Keying (HOKEY) re-authentication
   problem statement.  The current Extensible Authentication Protocol
   (EAP) keying framework is not designed to support re-authentication
   and handovers without re-executing an EAP method.  This often causes
   unacceptable latency in various mobile wireless environments.  This
   document details the problem and defines design goals for a generic
   mechanism to reuse derived EAP keying material for handover.

このドキュメントはHandover Keying(HOKEY)再認証問題声明について説明します。 フレームワークを合わせる現在の拡張認証プロトコル(EAP)は、EAPメソッドを実行し直さないで再認証と身柄の引き渡しをサポートするように設計されていません。 これはしばしば様々な移動無線環境における容認できない潜在を引き起こします。 ジェネリックメカニズムが引き渡しのための材料を合わせる派生しているEAPを再利用するように、このドキュメントは、問題を詳しく述べて、デザイン目標を定義します。

Clancy, et al.               Informational                      [Page 1]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[1ページ]のRFC5169

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Security Goals . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Key Context and Domino Effect  . . . . . . . . . . . . . .  7
     5.2.  Key Freshness  . . . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Authentication . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  8
     5.5.  Channel Binding  . . . . . . . . . . . . . . . . . . . . .  8
     5.6.  Transport Aspects  . . . . . . . . . . . . . . . . . . . .  8
   6.  Use Cases and Related Work . . . . . . . . . . . . . . . . . .  9
     6.1.  Method-Specific EAP Re-Authentication  . . . . . . . . . .  9
     6.2.  IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
     6.3.  CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 問題声明. . . . . . . . . . . . . . . . . . . . . . 4 4。 目標. . . . . . . . . . . . . . . . . . . . . . . . . 5 5を設計してください。 セキュリティ目標. . . . . . . . . . . . . . . . . . . . . . . . 6 5.1。 主要な文脈とドミノ効果. . . . . . . . . . . . . . 7 5.2。 主要な新しさ. . . . . . . . . . . . . . . . . . . . . . 7 5.3。 認証. . . . . . . . . . . . . . . . . . . . . . 8 5.4。 承認. . . . . . . . . . . . . . . . . . . . . . 8 5.5。 チャンネル結合. . . . . . . . . . . . . . . . . . . . . 8 5.6。 局面. . . . . . . . . . . . . . . . . . . . 8 6を輸送してください。 ケースと関連仕事. . . . . . . . . . . . . . . . . . 9 6.1を使用してください。 メソッド特有のEAP再認証.96.2。 IEEE 802.11rの適用性. . . . . . . . . . . . . . . . 10 6.3。 CAPWAPの適用性. . . . . . . . . . . . . . . . . . . 10 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 8。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 11 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 12

Clancy, et al.               Informational                      [Page 2]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[2ページ]のRFC5169

1.  Introduction

1. 序論

   The Extensible Authentication Protocol (EAP), specified in RFC 3748
   [RFC3748] is a generic framework supporting multiple authentication
   methods.  The primary purpose of EAP is network access control.  It
   also supports exporting session keys derived during the
   authentication.  The EAP keying hierarchy defines two keys that are
   derived at the top level, the Master Session Key (MSK) and the
   Extended Master Session Key (EMSK).

RFC3748[RFC3748]で指定された拡張認証プロトコル(EAP)は複数の認証がメソッドであるとサポートするジェネリックフレームワークです。 EAPのプライマリ目的はネットワークアクセスコントロールです。 また、それは認証の間に引き出された輸出セッションキーを支えます。 階層構造を合わせるEAPはトップレベル、Master Session Key(MSK)、およびExtended Master Session Key(EMSK)で引き出される2個のキーを定義します。

   In many common deployment scenarios, an EAP peer and EAP server
   authenticate each other through a third party known as the pass-
   through authenticator (hereafter referred to as simply
   "authenticator").  The authenticator is responsible for encapsulating
   EAP packets from a network-access technology lower layer within the
   Authentication, Authorization, and Accounting (AAA) protocol.  The
   authenticator does not directly participate in the EAP exchange, and
   simply acts as a gateway during the EAP method execution.

多くの一般的な展開シナリオでは、EAP同輩とEAPサーバはパスとして固有識別文字(今後単に「固有識別文字」と呼ばれる)を通して知られている第三者を通して互いを認証します。 固有識別文字はAuthenticationの中のネットワークアクセスの技術の低級層からパケットをEAPにカプセルに入れるのに原因となります、Authorization、そして、Accounting(AAA)は議定書を作ります。 固有識別文字は、直接EAP交換に参加しないで、EAPメソッド実行の間、ゲートウェイとして単に機能します。

   After successful authentication, the EAP server transports the MSK to
   the authenticator.  Note that this is performed using AAA protocols,
   not EAP itself.  The underlying L2 or L3 protocol uses the MSK to
   derive additional keys, including the transient session keys (TSKs)
   used for per-packet encryption and authentication.

うまくいっている認証の後に、EAPサーバはMSKを固有識別文字に輸送します。 これがEAP自身ではなく、AAAプロトコルを使用することで実行されることに注意してください。 基本的なL2かL3プロトコルが追加キーを引き出すのにMSKを使用します、1パケットあたりの暗号化と認証に使用される一時的なセッションキー(TSKs)を含んでいて。

   Note that while the authenticator is one logical device, there can be
   multiple physical devices involved.  For example, the CAPWAP model
   [RFC3990] splits authenticators into two logical devices: Wireless
   Termination Points (WTPs) and Access Controllers (ACs).  Depending on
   the configuration, authenticator features can be split in a variety
   of ways between physical devices; however, from the EAP perspective,
   there is only one logical authenticator.

固有識別文字が1台の論理的なデバイスですが、かかわった複数のフィジカル・デバイスがあることができることに注意してください。 例えば、CAPWAPモデル[RFC3990]は固有識別文字を2台の論理的なデバイスに分けます: ワイヤレスの終了は(WTPs)と入場管理者(ACs)を指します。 構成によって、フィジカル・デバイスの間のさまざまな方法で固有識別文字機能を分けることができます。 しかしながら、EAP見解から、1つの論理的な固有識別文字だけが来ています。

   Wireless handover between access points or base stations is typically
   a complex process that involves several layers of protocol execution.
   Often times executing these protocols results in unacceptable delays
   for many real-time applications such as voice [MSA03].  One part of
   the handover process is EAP re-authentication, which can contribute
   significantly to the overall handover time [MSPCA04].  Thus, in many
   environments we can lower overall handover time by lowering EAP re-
   authentication time.

通常、アクセスポイントか基地局の間のワイヤレスの引き渡しは数個の層のプロトコル実行にかかわる複雑なプロセスです。 しばしばこれらのプロトコルを実行する回が声[MSA03]などのリアルタイムの多くのアプリケーションのための容認できない遅れをもたらします。 業務引き継ぎ作業の一部はEAP再認証です。(その認証は総合的な引き渡し時間[MSPCA04]までかなり貢献できます)。 したがって、多くの環境で、私たちは、EAP再認証時間を下げることによって、総合的な引き渡し時間を下げることができます。

   In EAP existing implementations, when a peer arrives at the new
   authenticator, it runs an EAP method irrespective of whether it has
   been authenticated to the network recently and has unexpired keying
   material.  This typically involves an EAP-Response/Identity message
   from the peer to the server, followed by one or more round trips
   between the EAP server and peer to perform the authentication,

EAPの既存の実装では、同輩が新しい固有識別文字に到着すると、最近、ネットワークに認証されて、満期になっていない合わせることを物質的にするかどうかの如何にかかわらずそれはEAPメソッドを実行します。 これはEAP-応答/アイデンティティメッセージに通常同輩からEAPサーバと同輩の間の1つ以上の周遊旅行があとに続いた、認証を実行したサーバまでかかわります。

Clancy, et al.               Informational                      [Page 3]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[3ページ]のRFC5169

   followed by the EAP-Success or EAP-Failure message from the EAP
   server to the peer.  At a minimum, the EAP exchange consists of 1.5
   round trips.  However, given the way EAP interacts with AAA, and
   given that an EAP identity exchange is typically employed, at least 2
   round trips are required to the EAP server.  An even higher number of
   round trips is required by the most commonly used EAP methods.  For
   instance, EAP-TLS (Extensible Authentication Protocol - Transport
   Layer Security) requires at least 3, but typically 4 or more, round
   trips.

EAPサーバから同輩までのEAP-成功かEAP-失敗メッセージはあとに続いています。 最小限では、EAP交換は1.5の周遊旅行から成ります。 しかしながら、EAPがAAAと対話する方法を与えられていて、EAPアイデンティティ交換が通常使われるなら、少なくとも2つの周遊旅行がEAPサーバに必要です。さらに大きい数の周遊旅行が最も一般的に使用されたEAPメソッドによって必要とされます。 例えば、EAP-TLS(拡張認証プロトコル--輸送Layer Security)は少なくとも3、しかし、通常4以上を必要とします、周遊旅行。

   There have been attempts to solve the problem of efficient re-
   authentication in various ways.  However, those solutions are either
   EAP-method specific or EAP lower-layer specific.  Furthermore, these
   solutions do not deal with scenarios involving handovers to new
   authenticators, or they do not conform to the AAA keying requirements
   specified in [RFC4962].

いろいろ効率的な再認証の問題を解決する試みがありました。 しかしながら、それらのソリューションは、EAP-メソッド特有であるか、またはEAPの低級層の特有です。 その上、これらのソリューションは新しい固有識別文字に身柄の引き渡しにかかわるシナリオに対処しないか、またはそれらが[RFC4962]で指定された要件を合わせるAAAに従いません。

   This document provides a detailed description of efficient EAP-based
   re-authentication protocol design goals.  The scope of this protocol
   is specifically re-authentication and handover between authenticators
   within a single administrative domain.  While the design goals
   presented in this document may facilitate inter-technology handover
   and inter-administrative-domain handover, they are outside the scope
   of this protocol.

このドキュメントは効率的なEAPベースの再認証プロトコルデザイン目標の詳述を提供します。 このプロトコルの範囲は、ただ一つの管理ドメインの中の固有識別文字の間の明確に再認証と引き渡しです。 本書では提示されたデザイン目標は相互技術引き渡しと相互管理のドメイン引き渡しを容易にするかもしれませんが、このプロトコルの範囲の外にそれらはあります。

2.  Terminology

2. 用語

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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], with the
   qualification that, unless otherwise stated, they apply to the design
   of the re-authentication protocol, not its implementation or
   application.

本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 」 「5月」、「推薦され」て、このドキュメントで「任意」は[RFC2119]で資格で説明されるように解釈されることであるべきではありません。キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「別の方法で述べられない場合、それらはその実装かアプリケーションではなく、再認証プロトコルのデザインに適用するものとします。

   With respect to EAP, this document follows the terminology that has
   been defined in [RFC3748] and [EAP-KEYING].

EAPに関して、このドキュメントは[RFC3748]と[EAP-KEYING]で定義された用語に従います。

3.  Problem Statement

3. 問題声明

   Under the existing model, any re-authentication requires a full EAP
   exchange with the EAP server to which the peer initially
   authenticated [RFC3748].  This introduces handover latency from both
   network transit time and processing delay.  In service provider
   networks, the home EAP server for a peer could be on the other side
   of the world, and typical intercontinental latencies across the
   Internet are 100 to 300 milliseconds per round trip [LGS07].

既存のモデルの下では、どんな再認証も同輩が初めは[RFC3748]を認証したEAPサーバによる完全なEAP交換を必要とします。 これはネットワークトランジット時間と処理遅れの両方から引き渡し潜在を導入します。 サービスプロバイダーネットワークには、世界の反対側の上に同輩のためのホームEAPサーバがあるかもしれません、そして、周遊旅行[LGS07]あたりインターネット中の典型的な大陸間潜在は100〜300ミリセカンドです。

Clancy, et al.               Informational                      [Page 4]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[4ページ]のRFC5169

   Processing delays average a couple of milliseconds for symmetric-key
   operations and hundreds of milliseconds for public-key operations.

処理は対称鍵操作と公開鍵操作のための何百ミリセカンドのためにも平均を2、3のミリセカンドと同じくらい遅らせます。

   An EAP conversation with a full EAP method run can take two or more
   round trips to complete, causing delays in re-authentication and
   handover times.  Some methods specify the use of keys and state from
   the initial authentication to finish subsequent authentications in
   fewer round trips and without using public-key operations (detailed
   in Section 6.1).  However, even in those cases, multiple round trips
   to the EAP server are required, resulting in unacceptable handover
   times.

完全なEAPメソッド走行とのEAPの会話は終了する2つ以上の周遊旅行を取ることができます、再認証と引き渡し時代に遅れをきたして。 いくつかのメソッドが、より少ない周遊旅行と公開鍵操作を使用しないでその後の認証を終えるために初期の認証からキーと状態の使用を指定します(セクション6.1で詳細な)。 しかしながら、それらの場合ではさえ、容認できない引き渡し時間をもたらして、EAPサーバへの複数の周遊旅行が必要です。

   In summary, it is undesirable to run an EAP Identity and complete EAP
   method exchange each time a peer authenticates to a new authenticator
   or needs to extend its current authentication with the same
   authenticator.  Furthermore, it is desirable to specify a method-
   independent, efficient, re-authentication protocol.  Keying material
   from the initial authentication can be used to enable efficient re-
   authentication.  It is also desirable to have a local server with
   low-latency connectivity to the peer that can facilitate re-
   authentication.  Lastly, a re-authentication protocol should also be
   capable of supporting scenarios where an EAP server passes
   authentication information to a remote re-authentication server,
   allowing a peer to re-authenticate locally, without having to
   communicate with its home re-authentication server.

概要では、EAP Identityを実行するのが望ましくなく、完全なEAPメソッドは同輩が新しい固有識別文字に認証するか、または同じ固有識別文字で現在の認証を広げるために必要とする各回を交換します。 その上、メソッドの独立していて、効率的な再認証プロトコルを指定するのは望ましいです。 効率的な再認証を可能にするのに初期の認証から材料を合わせるのを使用できます。 また、再認証を容易にすることができる同輩に低遅延の接続性があるローカルサーバを持っているのも望ましいです。 また、最後に、再認証プロトコルはEAPサーバがリモート再認証サーバに認証情報を通過するシナリオをサポートすることができるべきです、有なしで局所的に再認証する同輩がホーム再認証サーバとコミュニケートするのを許容して。

   These problems are the primary issues to be resolved.  In solving
   them, there are a number of constraints to conform to, and those
   result in some additional work to be done in the area of EAP keying.

これらの問題は決議されるべきプライマリ問題です。 それらを解決するのにおいて、従う多くの規制があります、そして、ものはEAPの合わせることの領域でのいくらかの追加やるべき仕事をもたらします。

4.  Design Goals

4. デザイン目標

   The following are the goals and constraints in designing the EAP re-
   authentication and key management protocol:

↓これは、EAP再認証とかぎ管理プロトコルを設計することにおいて目標と規制です:

   Lower-latency operation:  The protocol MUST be responsive to handover
      and re-authentication latency performance objectives within a
      mobile access network.  A solution that reduces latency as
      compared to a full EAP authentication will be most favorable,
      since in networks that rely on reactive re-authentication this
      will directly impact handover times.

下側の潜在操作: プロトコルはモバイルアクセスネットワークの中で引き渡しと再認証潜在パフォーマンス目標に敏感であるに違いありません。 完全なEAP認証と比べて、レイテンシを減少させるソリューションは最も好ましくなるでしょう、反応再認証に依存するネットワークではこれが直接引き渡し時間に影響を与えるので。

   EAP lower-layer independence:  Any keying hierarchy and protocol
      defined MUST be lower-layer independent in order to provide
      capabilities over heterogeneous technologies.  The defined
      protocols MAY require some additional support from the lower
      layers that use it, but should not require any particular lower
      layer.

EAP下層独立: 階層構造を合わせて、プロトコルが定義したいずれは、異種の技術の上に能力を提供する下層独立者でなければなりません。 定義されたプロトコルは、それを使用する下層から何らかの追加的支援を必要とするかもしれませんが、どんな特定の下層も必要とするべきではありません。

Clancy, et al.               Informational                      [Page 5]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[5ページ]のRFC5169

   EAP method independence:  Changes to existing EAP methods MUST NOT be
      required as a result of the re-authentication protocol.  There
      MUST be no requirements imposed on future EAP methods, provided
      they satisfy [EAP-KEYING] and [RFC4017].  Note that the only EAP
      methods for which independence is required are those that
      currently conform to the specifications of [EAP-KEYING] and
      [RFC4017].  In particular, methods that do not generate the keys
      required by [EAP-KEYING] need not be supported by the re-
      authentication protocol.

EAPメソッド独立: その結果、既存のEAPメソッドへの変化に再認証プロトコルを要求してはいけません。 彼らが[EAP-KEYING]と[RFC4017]を満たすなら将来のEAPメソッドに課された要件が全くあるはずがありません。 独立が必要である唯一のEAPメソッドが現在[EAP-KEYING]と[RFC4017]の仕様に従うものであることに注意してください。 特に、[EAP-KEYING]によって必要とされたキーを生成しないメソッドは再認証プロトコルによってサポートされる必要はありません。

   AAA protocol compatibility and keying:  Any modifications to EAP and
      EAP keying MUST be compatible with RADIUS [RADEXT-DESIGN] and
      Diameter [DIME-APP-DESIGN].  Extensions to both RADIUS and
      Diameter to support these EAP modifications are acceptable.  The
      designs and protocols must be configurable to satisfy the AAA key
      management requirements specified in RFC 4962 [RFC4962].

AAAプロトコルの互換性と合わせること: EAPへのどんな変更ともEAPの合わせるのはRADIUS[RADEXT-DESIGN]とDiameter[DIME-APP-DESIGN]と互換性があるに違いありません。 これらのEAP変更をサポートするRADIUSとDiameterの両方への拡大は許容できます。 デザインとプロトコルはRFC4962[RFC4962]で指定されたAAAかぎ管理要件を満たすのにおいて構成可能であるに違いありません。

   Compatibility:  Compatibility and coexistence with compliant
      ([RFC3748] [EAP-KEYING]) EAP deployments MUST be provided.
      Specifically, the protocol should be designed such that a peer not
      supporting fast re-reauthentication should still function in a
      network supporting fast re-authentication, and also a peer
      supporting fast re-authentication should still function in a
      network not supporting fast re-authentication.

互換性: 言いなりになっている[RFC3748][EAP-KEYING)EAP展開との互換性と共存を提供しなければなりません。 明確に、プロトコルは速い再再認証をサポートしない同輩が速い再認証をサポートするネットワークでまだ機能しているべきであるように、設計されるべきです、そして、また、速い再認証をサポートする同輩は速い再認証をサポートしないネットワークでまだ機能しているべきです。

   Cryptographic Agility:  Any re-authentication protocol MUST support
      cryptographic algorithm agility, to avoid hard-coded primitives
      whose security may eventually prove to be compromised.  The
      protocol MAY support cryptographic algorithm negotiation, provided
      it does not adversely affect overall performance (i.e., by
      requiring additional round trips).

暗号の機敏さ: どんな再認証プロトコルも、セキュリティが結局感染されると判明するかもしれない一生懸命コード化された基関数を避けるために暗号アルゴリズムが機敏さであるとサポートしなければなりません。 プロトコルは、暗号アルゴリズムが交渉であるとサポートするかもしれません、総合的な性能(すなわち、追加周遊旅行を必要とするのによる)に悪影響を与えないなら。

   Impact to Existing Deployments:  Any re-authentication protocol MAY
      make changes to the peer, authenticator, and EAP server, as
      necessary to meet the aforementioned design goals.  In order to
      facilitate protocol deployment, protocols should seek to minimize
      the necessary changes, without sacrificing performance.

既存の展開に影響を与えてください: どんな再認証プロトコルも、前述のデザイン目標を達成するために必要に応じて同輩、固有識別文字、およびEAPサーバへの変更を行うかもしれません。 プロトコル展開を容易にするために、性能を犠牲にしないで、プロトコルは必要な改革を最小にしようとするべきです。

5.  Security Goals

5. セキュリティ目標

   This section draws from the guidance provided in [RFC4962] to further
   define the security goals to be achieved by a complete re-
   authentication keying solution.

このセクションはソリューションを合わせながら完全な再認証で達成されるためにさらにセキュリティ目標を定義するために[RFC4962]に提供された指導から描かれます。

Clancy, et al.               Informational                      [Page 6]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[6ページ]のRFC5169

5.1.  Key Context and Domino Effect

5.1. 主要な文脈とドミノ効果

   Any key must have a well-defined scope and must be used in a specific
   context and for the intended use.  This specifically means the
   lifetime and scope of each key must be defined clearly so that all
   entities that are authorized to have access to the key have the same
   context during the validity period.  In a hierarchical key structure,
   the lifetime of lower-level keys must not exceed the lifetime of
   higher-level keys.  This requirement may imply that the context and
   the scope parameters have to be exchanged.  Furthermore, the
   semantics of these parameters must be defined to provide proper
   channel binding specifications.  The definition of exact parameter
   syntax definition is part of the design of the transport protocol
   used for the parameter exchange, and that may be outside scope of
   this protocol.

どんなキーも明確な範囲を持たなければならなくて、特定の文脈と意図している使用に使用しなければなりません。 これが、明確にそれぞれのキーの生涯と範囲を定義しなければならないことを明確に意味するので、キーに近づく手段を持っているのが認可されるすべての実体が有効期間の間、同じ文脈を持っています。 階層的な主要な構造では、低レベルキーの寿命は、よりハイレベルのキーの生涯を超えてはいけません。 この要件は、文脈と範囲パラメタが交換されなければならないのを含意するかもしれません。 その上、拘束力がある仕様を適切なチャンネルに供給するためにこれらのパラメタの意味論を定義しなければなりません。 正確なパラメタ構文定義の定義はパラメータ変換に使用されるこのプロトコルの範囲の外にあるかもしれないトランスポート・プロトコルのデザインの一部です。

   If a key hierarchy is deployed, compromising lower-level keys must
   not result in a compromise of higher-level keys that were used to
   derive the lower-level keys.  The compromise of keys at each level
   must not result in compromise of other keys at the same level.  The
   same principle applies to entities that hold and manage a particular
   key defined in the key hierarchy.  Compromising keys on one
   authenticator must not reveal the keys of another authenticator.
   Note that the compromise of higher-level keys has security
   implications on lower levels.

主要な階層構造が配布されるなら、低レベルがキーであると感染するのが低レベルキーを引き出すのに使用されたよりハイレベルのキーの感染をもたらしてはいけません。 各レベルにおけるキーの感染は同じレベルで他のキーの感染をもたらしてはいけません。 同じ原則は主要な階層構造で定義された特定のかぎを保持して、管理する実体に適用されます。 1つの固有識別文字でキーに感染すると、別の固有識別文字のキーは明らかにされてはいけません。 よりハイレベルのキーの感染が下のレベルにセキュリティ意味を持っていることに注意してください。

   Guidance on parameters required, caching, and storage and deletion
   procedures to ensure adequate security and authorization provisioning
   for keying procedures must be defined in a solution document.

パラメタにおける指導が必要です、キャッシュしていて、ソリューションドキュメントで手順を合わせる十分な安全性と承認の食糧を供給することを確実にするストレージと削除手順を定義しなければなりません。

   All the keying material must be uniquely named so that it can be
   managed effectively.

有効にそれに対処できるように唯一すべての合わせることの材料を命名しなければなりません。

5.2.  Key Freshness

5.2. 主要な新しさ

   As [RFC4962] defines, a fresh key is one that is generated for the
   intended use.  This would mean the key hierarchy must provide for
   creation of multiple cryptographically separate child keys from a
   root key at higher level.  Furthermore, the keying solution needs to
   provide mechanisms for refreshing each of the keys within the key
   hierarchy.

[RFC4962]が定義する、新鮮なキーは意図している使用のために生成されるものです。 これは、倍数の作成がルートキーと、より高いレベルで子供キーを暗号で切り離すので主要な階層構造が提供されなければならないことを意味するでしょう。 その上、合わせるソリューションは、主要な階層構造の中でそれぞれのキーをリフレッシュするのにメカニズムを提供する必要があります。

Clancy, et al.               Informational                      [Page 7]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[7ページ]のRFC5169

5.3.  Authentication

5.3. 認証

   Each handover keying participant must be authenticated to any other
   party with whom it communicates to the extent it is necessary to
   ensure proper key scoping, and securely provide its identity to any
   other entity that may require the identity for defining the key
   scope.

それが適切な主要な見ることを確実にして、しっかりと主要な範囲を定義するためにアイデンティティを必要とするかもしれないいかなる他の実体にもアイデンティティを提供するのが必要であるという範囲に交信するいかなる他のパーティーにも関係者を合わせる各引き渡しを認証しなければなりません。

5.4.  Authorization

5.4. 承認

   The EAP Key management document [EAP-KEYING] discusses several
   vulnerabilities that are common to handover mechanisms.  One
   important issue arises from the way the authorization decisions might
   be handled at the AAA server during network access authentication.
   Furthermore, the reasons for making a particular authorization
   decision are not communicated to the authenticator.  In fact, the
   authenticator only knows the final authorization result.  The
   proposed solution must make efforts to document and mitigate
   authorization attacks.

EAP Key管理ドキュメント[EAP-KEYING]は引き渡しメカニズムに共通のいくつかの脆弱性について議論します。1つの切迫した課題がネットワークアクセス認証の間承認決定がAAAサーバで扱われるかもしれない方法で起こります。 その上、特定の承認決定をする理由は固有識別文字に伝えられません。 事実上、固有識別文字は確定授権結果を知っているだけです。 提案されたソリューションは、承認攻撃を記録して、緩和するために努力しなければなりません。

5.5.  Channel Binding

5.5. チャンネル結合

   Channel Binding procedures are needed to avoid a compromised
   intermediate authenticator providing unverified and conflicting
   service information to each of the peer and the EAP server.  To
   support fast re-authentication, there will be intermediate entities
   between the peer and the back-end EAP server.  Various keys need to
   be established and scoped between these parties and some of these
   keys may be parents to other keys.  Hence, the channel binding for
   this architecture will need to consider layering intermediate
   entities at each level to make sure that an entity with a higher
   level of trust can examine the truthfulness of the claims made by
   intermediate parties.

チャンネルBinding手順が、提供が非検証した感染している中間的固有識別文字と闘争しているサービス情報を同輩各人とEAPサーバとして避けるのに必要です。速い再認証をサポートするために、同輩とバックエンドEAPサーバの間には、中間的実体があるでしょう。様々なキーは、これらのパーティーの間で設立されて、見られる必要があります、そして、これらのいくつかのキーが他のキーへの両親であるかもしれません。 したがって、このアーキテクチャで付くチャンネルは、より高いレベルの信頼がある実体が中間的パーティーによってされたクレームの正直さを調べることができるのを確実にするために各レベルで中間的実体を層にすると考える必要があるでしょう。

5.6.  Transport Aspects

5.6. 輸送局面

   Depending on the physical architecture and the functionality of the
   elements involved, there may be a need for multiple protocols to
   perform the key transport between entities involved in the handover
   keying architecture.  Thus, a set of requirements for each of these
   protocols, and the parameters they will carry, must be developed.

物理的なアーキテクチャと要素のかかわった機能性によって、アーキテクチャを合わせる引き渡しにかかわる実体の間には、複数のプロトコルが主要な輸送を実行する必要があるかもしれません。 したがって、それぞれのこれらのプロトコル、およびそれらが運ぶパラメタのための1セットの要件を開発しなければなりません。

   The use of existing AAA protocols for carrying EAP messages and
   keying material between the AAA server and AAA clients that have a
   role within the architecture considered for the keying problem will
   be carefully examined.  Definition of specific parameters, required
   for keying procedures and for being transferred over any of the links

合わせる問題のための既存のAAAプロトコルのEAPメッセージを伝えて、アーキテクチャの中の役割を考えさせるAAAサーバとAAAのクライアントの間の材料を合わせる使用は慎重に調べられるでしょう。 手順を合わせて、リンクのどれかの上に移すのに必要である特定のパラメタの定義

Clancy, et al.               Informational                      [Page 8]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[8ページ]のRFC5169

   in the architecture, are part of the scope.  The relation between the
   identities used by the transport protocol and the identities used for
   keying also needs to be explored.

アーキテクチャでは、範囲の一部がそうですか? また、トランスポート・プロトコルによって使用されるアイデンティティと合わせるのに使用されるアイデンティティとの関係は、探検される必要があります。

6.  Use Cases and Related Work

6. ケースと関連仕事を使用してください。

   In order to further clarify the items listed in scope of the proposed
   work, this section provides some background on related work and the
   use cases envisioned for the proposed work.

さらに提案された仕事の範囲に記載された項目をはっきりさせるために、このセクションはケースが提案された仕事のために思い描いた関連する仕事と使用のときに何らかのバックグラウンドを提供します。

6.1.  Method-Specific EAP Re-Authentication

6.1. メソッド特有のEAP再認証

   A number of EAP methods support fast re-authentication.  In this
   section, we examine their properties in further detail.

多くのEAPメソッドが速い再認証をサポートします。 このセクションで、私たちは詳細で彼らの特性を調べます。

   EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re-
   authentication, bootstrapped by the keys generated during an initial
   full authentication.  In response to the typical EAP-Request/
   Identity, the peer sends a specially formatted identity indicating a
   desire to perform a fast re-authentication.  A single round-trip
   occurs to verify knowledge of the existing keys and provide fresh
   nonces for generating new keys.  This is followed by an EAP success.
   In the end, it requires a single local round trip between the peer
   and authenticator, followed by another round trip between the peer
   and EAP server.  AKA is based on symmetric-key cryptography, so
   processing latency is minimal.

EAP-SIM[RFC4186]とEAP-AKA[RFC4187]は初期の完全な認証の間に生成されたキーによって独力で進まれた速い再認証をサポートします。 典型的なEAP-要求/アイデンティティに対応して、同輩は特に、フォーマットされたアイデンティティに速い再認証を実行する願望を示させます。 ただ一つの丸い旅行は、既存のキーに関する知識について確かめて、新しいキーを生成するのに新鮮な一回だけを提供するために起こります。 EAP成功はこれのあとに続いています。 結局、それは同輩とEAPサーバの間の別の周遊旅行があとに続いた同輩と固有識別文字の間のただ一つの地方の周遊旅行を必要とします。AKAは対称鍵暗号に基づいています、したがって、処理潜在が最小限です。

   EAP-TTLS [EAP-TTLS] and PEAP (Protected EAP Protocol)
   [JOSEFSSON-PPPEXT] support using TLS session resumption for fast re-
   authentication.  During the TLS handshake, the client includes the
   message ID of the previous session he wishes to resume, and the
   server can echo that ID back if it agrees to resume the session.
   EAP-FAST [RFC4851] also supports TLS session resumption, but
   additionally allows stateless session resumption as defined in
   [RFC5077].  Overall, for all three protocols, there are still two
   round trips between the peer and EAP server, in addition to the local
   round trip for the Identity request and response.

EAP-TTLS[EAP-TTLS]とPEAP(EAPプロトコルを保護します)[JOSEFSSON-PPPEXT]は、使用が速い再認証のためのTLSセッション再開であるとサポートします。 TLS握手の間、クライアントは彼が再開したがっている前のセッションのメッセージIDを入れます、そして、セッションを再開するのに同意するなら、サーバはそのIDをecho backであることができます。 EAP-FAST[RFC4851]はまた、TLSがセッション再開であるとサポートしますが、[RFC5077]で定義されるようにさらに、状態がないセッション再開を許します。 すべての3つのプロトコルに総合的です、まだ、2つの周遊旅行が同輩とEAPサーバの間にIdentity要求と応答のための地方の周遊旅行に加えています。

   To improve performance, fast re-authentication needs to reduce the
   number of overall round trips.  Optimal performance could result from
   eliminating the EAP-Request/Identity and EAP-Response/Identity
   messages observed in typical EAP method execution, and allowing a
   single round trip between the peer and a local re-authentication
   server.

性能を向上させるために、速い再認証は、総合的な周遊旅行の数を減少させる必要があります。 最適の性能は同輩とローカルの再認証サーバの間に典型的なEAPメソッド実行と、単発旅行を許す際にEAP-要求/アイデンティティとEAP-応答/アイデンティティメッセージが観測した排泄から生じるかもしれません。

Clancy, et al.               Informational                      [Page 9]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[9ページ]のRFC5169

6.2.  IEEE 802.11r Applicability

6.2. IEEE 802.11rの適用性

   One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in
   the process of specifying a fast handover mechanism.  Access Points
   (APs) are grouped into mobility domains.  Initial authentication to
   any AP in a mobility domain requires execution of EAP, but handover
   between APs within the mobility domain does not require the use of
   EAP.

速い引き渡しメカニズムを指定することの途中にEAPの低級層の1つ(IEEE802.11[IEEE.802-11R-D9.0])があります。 アクセスPoints(APs)は移動性ドメインに分類されます。 移動性ドメインのどんなAPへの初期の認証もEAPの実行を必要としますが、移動性ドメインの中のAPsの間の引き渡しはEAPの使用を必要としません。

   Internal to the mobility domain are sets of security associations to
   support key transfers between APs.  In one model, relatively few
   devices, called R0-KHs, act as authenticators.  All EAP traffic
   traverses an R0-KH, and it derives the initial IEEE 802.11 keys.  It
   then distributes cryptographically separate keys to APs in the
   mobility domain, as necessary, to support the client mobility.  For a
   deployment with M designated R0-KHs and N APs, this requires M*N
   security associations.  For small M, this approach scales reasonably.
   Another approach allows any AP to act as an R0-KH, necessitating a
   full mesh of N2 security associations, which scales poorly.

移動性ドメインに内部であることは、APsの間の主要な転送をサポートするセキュリティ協会のセットです。 1つのモデルでは、R0-KHsと呼ばれる比較的わずかなデバイスしか固有識別文字として作動しません。 すべてのEAPトラフィックがR0-KHを横断します、そして、それは初期のIEEE802.11キーを引き出します。 そして、それは、クライアントの移動性をサポートするために必要に応じて暗号で移動性ドメインのAPsの別々のキーを分配します。 MがR0-KHsとN APsに指定されている展開のために、これはM*Nセキュリティ協会を必要とします。 小さいMに関しては、このアプローチは合理的に比例します。 どんなAPもR0-KHとして別のアプローチで機能できます、N2セキュリティ協会の完全なメッシュ(不十分に比例する)を必要として。

   The model that utilizes designated R0-KHs is architecturally similar
   to the fast re-authentication model proposed by HOKEY.  HOKEY,
   however, allows for handover between authenticators.  This would
   allow an IEEE 802.11r-enabled peer to handover from one mobility
   domain to another without performing an EAP authentication.

建築上、指定されたR0-KHsを利用するモデルはHOKEYによって提案された速い再認証モデルと同様です。 しかしながら、HOKEYは固有識別文字の間の引き渡しを考慮します。 EAP認証を実行しないで、これは1つの移動性ドメインから別のドメインまでの引き渡しにIEEE 802.11rによって可能にされた同輩を許容するでしょう。

6.3.  CAPWAP Applicability

6.3. CAPWAPの適用性

   The CAPWAP (Control and Provisioning of Wireless Access Points)
   protocol [CAPWAP-PROTOCOL-SPEC] allows the functionality of an IEEE
   802.11 access point to be split into two physical devices in
   enterprise deployments.  Wireless Termination Points (WTPs) implement
   the physical and low-level Media Access Control (MAC) layers, while a
   centralized Access Controller (AC) provides higher-level management
   and protocol execution.  Client authentication is handled by the AC,
   which acts as the AAA authenticator.

CAPWAP(Wireless Access PointsのコントロールとProvisioning)プロトコル[CAPWAPプロトコルSPEC]で、IEEE802.11アクセスポイントの機能性は企業展開で2個のフィジカル・デバイスに分かれます。 ワイヤレスのTermination Points(WTPs)は、物理的で低レベルであるメディアがAccess Control(MAC)層であると実装します、集結されたAccess Controller(西暦)は、よりハイレベルの管理とプロトコル実行を提供しますが。 クライアント認証は西暦によって扱われます。(それは、AAA固有識別文字として機能します)。

   One of the many features provided by CAPWAP is the ability to roam
   between WTPs without executing an EAP authentication.  To accomplish
   this, the AC caches the MSK from an initial EAP authentication, and
   uses it to execute a separate four-way handshake with the station as
   it moves between WTPs.  The keys resulting from the four-way
   handshake are then distributed to the WTP to which the station is
   associated.  CAPWAP is transparent to the station.

CAPWAPによって提供された多くの特徴の1つはWTPsの間をEAP認証を実行しないで移動する能力です。 これを達成するなら、西暦は、初期のEAP認証からMSKをキャッシュして、WTPsの間で移行するとき別々の4方法の握手をステーションに実行するのにそれを使用します。 そして、4方法の握手から生じるキーはステーションが関連しているWTPに分配されます。 CAPWAPはステーションに透明です。

   CAPWAP currently has no means to support roaming between ACs in an
   enterprise network.  The proposed work on EAP efficient re-
   authentication addresses is an inter-authenticator handover problem

CAPWAPは現在、ACsの間に企業網でローミングをサポートする手段を全く持っていません。 EAPの効率的な再認証アドレスに対する提案された仕事は相互固有識別文字引き渡し問題です。

Clancy, et al.               Informational                     [Page 10]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[10ページ]のRFC5169

   from an EAP perspective, which applies during handover between ACs.
   Inter-AC handover is a topic yet to be addressed in great detail and
   the re-authentication work can potentially address it in an effective
   manner.

EAP見解から。(それは、引き渡しの間、ACsの間で適用されます)。 相互交流引き渡しはまだ丹念に扱われていない話題です、そして、再認証仕事は効果的な方法で潜在的にそれを扱うことができます。

7.  Security Considerations

7. セキュリティ問題

   This document details the HOKEY problem statement.  Since HOKEY is an
   authentication protocol, there is a myriad of security-related issues
   surrounding its development and deployment.

このドキュメントはHOKEY問題声明を詳しく述べます。 HOKEYが認証プロトコルであるので、その開発と展開を囲む安全保障関連問題の無数があります。

   In this document, we have detailed a variety of security properties
   inferred from [RFC4962] to which HOKEY must conform, including the
   management of key context, scope, freshness, and transport;
   resistance to attacks based on the domino effect; and authentication
   and authorization.  See Section 5 for further details.

本書では、私たちは[RFC4962]からどのHOKEYが従わなければならないかまで推論されたさまざまなセキュリティの特性について詳述しました、主要な文脈、範囲、新しさ、および輸送の管理を含んでいて。 攻撃への抵抗はドミノ効果を基礎づけました。 認証と承認。 さらに詳しい明細についてはセクション5を見てください。

8.  Contributors

8. 貢献者

   This document represents the synthesis of two problem statement
   documents.  In this section, we acknowledge their contributions, and
   involvement in the early documents.

このドキュメントは2通の問題声明ドキュメントの統合を表します。 このセクションでは、私たちは早めのドキュメントで彼らの貢献、およびかかわり合いを承諾します。

      Mohan Parthasarathy
      Nokia
      EMail: mohan.parthasarathy@nokia.com

モハンパルタサラティノキアEMail: mohan.parthasarathy@nokia.com

      Julien Bournelle
      France Telecom R&D
      EMail: julien.bournelle@orange-ftgroup.com

ジュリアンBournelleフランステレコム研究開発メール: julien.bournelle@orange-ftgroup.com

      Hannes Tschofenig
      Siemens
      EMail: Hannes.Tschofenig@siemens.com

ハンネスTschofenigシーメンスはメールされます: Hannes.Tschofenig@siemens.com

      Rafael Marin Lopez
      Universidad de Murcia
      EMail: rafa@dif.um.es

ラファエルマリンロペスUniversidad deムルシアEMail: rafa@dif.um.es

9.  Acknowledgements

9. 承認

   The authors would like to thank the participants of the HOKEY working
   group for their review and comments including: Glen Zorn, Dan
   Harkins, Joe Salowey, and Yoshi Ohba.  The authors would also like to
   thank those that provided last-call reviews including: Bernard Aboba,
   Alan DeKok, Jari Arkko, and Hannes Tschofenig.

感謝して、:作者は彼らのレビューとコメントについてHOKEYワーキンググループの関係者に感謝したがっています。 谷間のゾルン、ダン・ハーキンズ、ジョーSalowey、およびYoshiオオバ。 感謝して、:また、作者は最後の呼び出しレビューを提供したものに感謝したがっています。 バーナードAboba、アランDeKok、ヤリArkko、およびハンネスTschofenig。

Clancy, et al.               Informational                     [Page 11]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[11ページ]のRFC5169

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [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月。

   [RFC3748]               Aboba, B., Blunk, L., Vollbrecht, J.,
                           Carlson, J., and H. Levkowetz, "Extensible
                           Authentication Protocol (EAP)", RFC 3748,
                           June 2004.

[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。

   [RFC4017]               Stanley, D., Walker, J., and B. Aboba,
                           "Extensible Authentication Protocol (EAP)
                           Method Requirements for Wireless LANs",
                           RFC 4017, March 2005.

[RFC4017] スタンリー、D.、ウォーカー、J.、およびB.Aboba、「ワイヤレスのLANのための拡張認証プロトコル(EAP)メソッド要件」、RFC4017(2005年3月)。

   [RFC4962]               Housley, R. and B. Aboba, "Guidance for
                           Authentication, Authorization, and Accounting
                           (AAA) Key Management", BCP 132, RFC 4962,
                           July 2007.

[RFC4962]Housley、R.とB.Aboba、「認証、承認、および会計(AAA)Key Managementのための指導」BCP132、RFC4962(2007年7月)。

10.2.  Informative References

10.2. 有益な参照

   [CAPWAP-PROTOCOL-SPEC]  Calhoun, P., Montemurro, M., and D. Stanely,
                           "CAPWAP Protocol Specification", Work
                           in Progress, March 2008.

[CAPWAPプロトコル仕様] カルフーン、P.、Montemurro、M.、およびD.スタンリー、「CAPWAPプロトコル仕様」は進歩、2008年3月に働いています。

   [DIME-APP-DESIGN]       Fajardo, V., Asveren, T., Tschofenig, H.,
                           McGregor, G., and J. Loughney, "Diameter
                           Applications Design Guidelines", Work
                           in Progress, January 2008.

[10セント硬貨装置デザイン] ファハルド、V.、Asveren、T.、Tschofenig、H.、マクレガー、G.、J.Loughney、「直径アプリケーションはガイドラインを設計すること」が進行中(2008年1月)で働いています。

   [EAP-KEYING]            Aboba, B., Simon, D., and P. Eronen,
                           "Extensible Authentication Protocol (EAP) Key
                           Management Framework", Work in Progress,
                           November 2007.

B.、サイモン、D.、およびP.Eronen、「拡張認証プロトコル(EAP)Key Managementフレームワーク」という[EAPを合わせます]のAbobaは進歩、2007年11月に働いています。

   [EAP-TTLS]              Funk, P. and S. Blake-Wilson, "EAP Tunneled
                           TLS Authentication Protocol Version 0 (EAP-
                           TTLSv0)", Work in Progress, March 2008.

[EAP-TTLS] 「EAPはTLS認証プロトコルバージョン0(EAP- TTLSv0)にトンネルを堀った」というファンク、P.、およびS.ブレーク-ウィルソンは進歩、2008年3月に働いています。

Clancy, et al.               Informational                     [Page 12]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[12ページ]のRFC5169

   [IEEE.802-11R-D9.0]     "Information technology - Telecommunications
                           and information exchange between systems -
                           Local and metropolitan area networks -
                           Specific requirements - Part 11: Wireless LAN
                           Medium Access Control (MAC) and Physical
                           Layer (PHY) specifications - Amendment 2:
                           Fast BSS Transition", IEEE Standard 802.11r,
                           January 2008.

[IEEE.802-11R-D9.0] 「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(決められた一定の要求)は11を分けます」。 無線LAN Medium Access Control(MAC)とPhysical Layer(PHY)仕様--修正2: 「速いBSS変遷」、IEEEの標準の802.11r、2008年1月。

   [JOSEFSSON-PPPEXT]      Josefsson, S., Palekar, A., Simon, D., and G.
                           Zorn, "Protected EAP Protocol (PEAP) Version
                           2", Work in Progress, October 2004.

[JOSEFSSON-PPPEXT] Josefsson、S.、Palekar、A.、サイモン、D.、およびG.ゾルン、「保護されたEAPプロトコル(PEAP)バージョン2インチ、進歩、2004年10月に働いてください。」

   [LGS07]                 Ledlie, J., Gardner, P., and M. Selter,
                           "Network Coordinates in the Wild",
                           USENIX Symposium on Networked System Design
                           and Implementation, April 2007.

ネットワークでつながれたシステム設計と実現(2007年4月)に関する[LGS07]LedlieとJ.とガードナー、P.とM.Selter、「荒野のネットワーク座標」USENIXシンポジウム。

   [MSA03]                 Mishra, A., Shin, M., and W. Arbaugh, "An
                           Empirical Analysis of the IEEE 802.11 MAC-
                           Layer Handoff Process", ACM SIGCOMM Computer
                           and Communications Review, April 2003.

[MSA03]Mishra(A.)はよじ登ります、M.、W.Arbaugh、「IEEE802.11MACの実証的分析は移管の過程を層にする」、ACM SIGCOMMコンピュータ、およびコミュニケーションは再検討されます、2003年4月。

   [MSPCA04]               Mishra, A., Shin, M., Petroni, N., Clancy,
                           T., and W. Arbaugh, "Proactive Key
                           Distribution using Neighbor Graphs",
                           IEEE Wireless Communications, February 2004.

[MSPCA04]Mishra(A.)はよじ登ります、M.、ペトローニ、N.、クランシー、T.とW.Arbaugh、「隣人グラフを使用して、主要な分配を予測してください」IEEE無線通信、2004年2月。

   [RADEXT-DESIGN]         Weber, G. and A. DeKok, "RADIUS Design
                           Guidelines", Work in Progress, December 2007.

「半径デザインガイドライン」という[RADEXT-デザイン]のウェーバー、G.、およびA.DeKokは進歩、2007年12月に働いています。

   [RFC3990]               O'Hara, B., Calhoun, P., and J. Kempf,
                           "Configuration and Provisioning for Wireless
                           Access Points (CAPWAP) Problem Statement",
                           RFC 3990, February 2005.

[RFC3990] オハラ、B.、カルフーン、P.、およびJ.ケンフ、「構成と無線電信のために食糧を供給するのはポイント(CAPWAP)問題声明にアクセスします」、RFC3990、2005年2月。

   [RFC4186]               Haverinen, H. and J. Salowey, "Extensible
                           Authentication Protocol Method for Global
                           System for Mobile Communications (GSM)
                           Subscriber Identity Modules (EAP-SIM)",
                           RFC 4186, January 2006.

[RFC4186]Haverinen、H.とJ.Salowey、「汎欧州デジタルセルラーシステム(GSM)加入者アイデンティティモジュール(EAP-SIM)のための拡張認証プロトコル方法」RFC4186(2006年1月)。

   [RFC4187]               Arkko, J. and H. Haverinen, "Extensible
                           Authentication Protocol Method for 3rd
                           Generation Authentication and Key Agreement
                           (EAP-AKA)", RFC 4187, January 2006.

[RFC4187] Arkko、J.、およびH.Haverinen、「広げることができる認証は第3世代認証のための方法と主要な協定(EAP-別名)について議定書の中で述べます」、RFC4187、2006年1月。

Clancy, et al.               Informational                     [Page 13]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[13ページ]のRFC5169

   [RFC4851]               Cam-Winget, N., McGrew, D., Salowey, J., and
                           H. Zhou, "The Flexible Authentication via
                           Secure Tunneling Extensible Authentication
                           Protocol Method (EAP-FAST)", RFC 4851,
                           May 2007.

[RFC4851]カム-Winget、N.、マグリュー、D.、Salowey、J.、およびH.周、「Secure Tunneling拡張認証プロトコルMethodを通したFlexible Authentication(EAP-FAST)」、RFC4851(2007年5月)。

   [RFC5077]               Salowey, J., Zhou, H., Eronen, P., and H.
                           Tschofenig, "Transport Layer Security (TLS)
                           Session Resumption without Server-Side
                           State", RFC 5077, January 2008.

[RFC5077]Salowey(J.、周、H.、Eronen、P.、およびH.Tschofenig)は「サーバサイド州なしで層のセキュリティ(TLS)セッション再開を輸送します」、RFC5077、2008年1月。

Authors' Addresses

作者のアドレス

   T. Charles Clancy, Editor
   Laboratory for Telecommunications Sciences
   US Department of Defense
   College Park, MD
   USA

T.チャールズクランシー、テレコミュニケーション科学米国国防総省MDカレッジパーク(米国)へのエディタ研究所

   EMail: clancy@LTSnet.net

メール: clancy@LTSnet.net

   Madjid Nakhjiri
   Motorola

Madjid Nakhjiriモトローラ

   EMail: madjid.nakhjiri@motorola.com

メール: madjid.nakhjiri@motorola.com

   Vidya Narayanan
   Qualcomm, Inc.
   San Diego, CA
   USA

Vidyaナラヤナン・クアルコムInc.カリフォルニアサンディエゴ(米国)

   EMail: vidyan@qualcomm.com

メール: vidyan@qualcomm.com

   Lakshminath Dondeti
   Qualcomm, Inc.
   San Diego, CA
   USA

Lakshminath DondetiクアルコムInc.カリフォルニアサンディエゴ(米国)

   EMail: ldondeti@qualcomm.com

メール: ldondeti@qualcomm.com

Clancy, et al.               Informational                     [Page 14]

RFC 5169                    HOKEY Re-Auth PS                  March 2008

クランシー、他 2008年の再Auth PS行進のときにいやに感情的な情報[14ページ]のRFC5169

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に情報を記述してください。

Clancy, et al.               Informational                     [Page 15]

クランシー、他 情報[15ページ]