RFC4285 日本語訳
4285 Authentication Protocol for Mobile IPv6. A. Patel, K. Leung, M.Khalil, H. Akhtar, K. Chowdhury. January 2006. (Format: TXT=40874 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Patel
Request for Comments: 4285 K. Leung
Category: Informational Cisco Systems
M. Khalil
H. Akhtar
Nortel Networks
K. Chowdhury
Starent Networks
January 2006
コメントを求めるワーキンググループA.パテル要求をネットワークでつないでください: 4285年のK.レオンカテゴリ: K.チョードリStarentが2006年1月にネットワークでつなぐ情報のシスコシステムズのM.カリルH.Akhtarノーテルネットワーク
Authentication Protocol for Mobile IPv6
モバイルIPv6のための認証プロトコル
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. RFC 3775 and 3776 define Mobile IPv6 and its security mechanism. This document presents an alternate security mechanism for Mobile IPv6 used in 3GPP2 networks.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 RFC3775と3776はモバイルIPv6とそのセキュリティー対策を定義します。 このドキュメントは3GPP2ネットワークに使用されるモバイルIPv6のために代替のセキュリティー対策を提示します。
The security properties of this mechanism have not been reviewed in the IETF. Conducting this review proved difficult because the standards-track security mechanism for Mobile IPv6 is tightly integrated into the protocol; extensions to Mobile IPv6 and the core documents make assumptions about the properties of the security model without explicitly stating what assumptions are being made. There is no documented service model. Thus it is difficult to replace the security mechanism and see if the current protocol and future extensions meet appropriate security requirements both under the original and new security mechanisms. If a service model for Mobile IPv6 security is ever formally defined and reviewed, a mechanism similar to this one could be produced and fully reviewed.
このメカニズムのセキュリティの特性はIETFで見直されていません。 モバイルIPv6のための標準化過程セキュリティー対策がしっかりプロトコルと統合されるので、このレビューを行うのは難しいと判明しました。 どんな仮定がされているかを明らかに述べない、モバイルIPv6への拡大とコアドキュメントは機密保護モデルの特性に関する仮定をします。 記録されたサービスモデルが全くありません。 したがって、セキュリティー対策を置き換えて、現在のプロトコルと今後の拡大がともにオリジナルの、そして、新しいセキュリティー対策の下で適切なセキュリティ必要条件を満たすかどうかわかるのは難しいです。モバイルIPv6セキュリティのためのサービスモデルが今までに、正式に定義されて、見直されるなら、これと同様のメカニズムは、作成されて、完全に見直されるかもしれません。
Section 1.1 of this document provides an applicability statement for this RFC. The IESG recommends against the usage of this specification outside of environments that meet the conditions of that applicability statement. In addition the IESG recommends those
このドキュメントのセクション1.1はこのRFCに適用性証明を供給します。 IESGはこの仕様の用法に対してその適用性証明に関する条件を満たす環境の外部を推薦します。 さらに、IESGはそれらを推薦します。
Patel, et al. Informational [Page 1] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[1ページ]のRFC4285認証プロトコル
considering deploying or implementing this specification conduct a sufficient security review to meet the conditions of the environments in which this RFC will be used.
この仕様を配布するか、または履行すると考える場合、このRFCが使用される環境に関する条件を満たすことができるくらいの安全レビューを行ってください。
Abstract
要約
IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages.
IPsecはモバイルIPv6(MIPv6)のためにシグナリングがモバイルNodeとホームのエージェントの間のメッセージであると機密保護する手段として指定されます。 保証されるMIPv6シグナリングメッセージはメッセージがモバイルNodeとそのホームのエージェントの間の結合を管理するのに使用したBinding UpdatesとAcknowledgementを含んでいます。 このドキュメントはMIPv6シグナリングがモバイルNodesとホームのエージェントの間のメッセージであると機密保護するための代替方法を提案します。 ここで定義された代替方法はMIPv6シグナリングメッセージに追加できるMIPv6特有の移動性通報認証オプションから成ります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
2. Overview ........................................................4
3. Terminology .....................................................5
3.1. General Terms ..............................................5
4. Operational Flow ................................................6
5. Mobility Message Authentication Option ..........................7
5.1. MN-HA Mobility Message Authentication Option ...............8
5.1.1. Processing Considerations ...........................9
5.2. MN-AAA Mobility Message Authentication Option ..............9
5.2.1. Processing Considerations ..........................10
5.3. Authentication Failure Detection at the Mobile Node .......11
6. Mobility Message Replay Protection Option ......................11
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................15
Appendix A. Rationale for mobility message replay protection
option ................................................16
1. 序論…3 1.1. 適用性声明…3 2. 概要…4 3. 用語…5 3.1. 一般項…5 4. 操作上の流れ…6 5. 移動性通報認証オプション…7 5.1. Mn、-、ハ、移動性通報認証オプション…8 5.1.1. 処理問題…9 5.2. ミネソタ-AAA移動性通報認証オプション…9 5.2.1. 処理問題…10 5.3. モバイルノードでの認証失敗検出…11 6. 移動性メッセージ反復操作による保護オプション…11 7. セキュリティ問題…13 8. IANA問題…14 9. 承認…15 10. 参照…15 10.1. 標準の参照…15 10.2. 有益な参照…15 移動性メッセージのための付録A.Rationaleは保護オプションを再演します…16
Patel, et al. Informational [Page 2] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[2ページ]のRFC4285認証プロトコル
1. Introduction
1. 序論
The base Mobile IPv6 specification [RFC3775] specifies the signaling messages, Binding Update (BU) and Binding Acknowledgement (BA), between the Mobile Node (MN) and Home Agent (HA) to be secured by the IPsec Security Associations (IPsec SAs) that are established between these two entities.
ベースモバイルIPv6仕様[RFC3775]はシグナリングメッセージ、Binding Update(BU)、およびBinding Acknowledgement(BA)を指定します、これらの2つの実体の間に設立されるIPsec Security Associations(IPsec SAs)によって固定されるモバイルNode(ミネソタ)とホームのエージェント(HA)の間で。
This document proposes a solution for securing the Binding Update and Binding Acknowledgment messages between the Mobile Node and Home Agent using a mobility message authentication option that is included in these messages. Such a mechanism enables IPv6 mobility in a host without having to establish an IPsec SA with its Home Agent. A Mobile Node can implement Mobile IPv6 without having to integrate it with the IPsec module, in which case the Binding Update and Binding Acknowledgement messages (between MN-HA) are secured with the mobility message authentication option.
このドキュメントは、Binding UpdateとBinding AcknowledgmentがモバイルNodeとホームのエージェントの間のメッセージであるとこれらのメッセージに含まれている移動性通報認証オプションを使用することで機密保護するためにソリューションを提案します。 ホームのエージェントと共にIPsec SAを設立する必要はなくて、そのようなメカニズムはホストでIPv6の移動性を可能にします。 IPsecモジュールとそれを統合する必要はなくて、モバイルNodeはモバイルIPv6を実装することができます、その場合、Binding UpdateとBinding Acknowledgementメッセージ(ミネソタ-HAの間の)は移動性通報認証オプションで固定されています。
The authentication mechanism proposed here is similar to the authentication mechanism used in Mobile IPv4 [RFC3344].
ここで提案された認証機構はモバイルIPv4[RFC3344]で使用される認証機構と同様です。
1.1. Applicability Statement
1.1. 適用性証明
The mobility message authentication option specified in Section 5 is applicable in certain types of networks that have the following characteristics:
セクション5で指定された移動性通報認証オプションは以下の特性を持っているあるタイプのネットワークで適切です:
- Networks in which the authentication of the MN for network access is done by an authentication server in the home network via the home agent. The security association is established by the network operator (provisioning methods) between the MN and a backend authentication server (e.g., Authentication, Authorization, and Accounting (AAA) home server). MIPv6 as per RFCs 3775 and 3776 relies on the IPsec SA between the MN and an HA. In cases where the assignment of the HA is dynamic and the only static or long-term SA is between the MN and a backend authentication server, the mobility message authentication option is desirable.
- ネットワークアクセスのためのミネソタの認証がホームのエージェントを通してホームネットワークにおける認証サーバによって行われるネットワーク。 セキュリティ協会はミネソタとバックエンド認証サーバ(例えば、Authentication、Authorization、およびAccounting(AAA)ホームサーバ)の間にネットワーク・オペレータによって設立されます(メソッドに食糧を供給します)。 RFCs3775と3776に従ってMIPv6はミネソタとHAの間のIPsec SAを当てにします。 HAの課題がダイナミックであり、ミネソタとバックエンド認証サーバの間に唯一の静的であるか長期のSAがある場合では、移動性通報認証オプションは望ましいです。
- In certain deployment environments, the mobile node needs dynamic assignment of a home agent and home address. The assignment of such can be on a per-session basis or on a per-MN power-up basis. In such scenarios, the MN relies on an identity such as a Network Access Identifier (NAI) [RFC4283], and a security association with a AAA server to obtain such bootstrapping information. The security association is created via an out-of-band mechanism or by non Mobile IPv6 signaling. The out-of-band mechanism can be specific to the deployment environment of a network operator. In Code Division Multiple Access (CDMA) network deployments, this information can be
- ある展開環境で、モバイルノードはホームのエージェントとホームアドレスのダイナミックな課題を必要とします。 1セッションあたり1個のベースの上、または、1ミネソタあたり1個のパワーアップするベースの上にそのようなものの課題があることができます。 そのようなシナリオでは、ミネソタは、そのようなブートストラップ法情報を得るためにNetwork Access Identifier(NAI)などのアイデンティティ[RFC4283]、およびAAAサーバとのセキュリティ協会を当てにします。 セキュリティ協会はバンドで出ているメカニズムか非モバイルのIPv6シグナリングによって創設されます。 バンドで出ているメカニズムはネットワーク・オペレータの展開環境に特定である場合があります。 符号分割多重アクセス方式(CDMA)ネットワーク展開では、この情報はそうであることができます。
Patel, et al. Informational [Page 3] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[3ページ]のRFC4285認証プロトコル
obtained at the time of network access authentication via [3GPP2] specific extensions to PPP or DHCPv6 on the access link and by AAA extensions in the core. It should be noted that the out-of-band mechanism is not within the scope of the mobility message authentication option (Section 5) and hence is not described therein.
ネットワークアクセス時点で、アクセスリンクとコアでのAAA拡大でPPPかDHCPv6への[3GPP2]特定の拡大で認証を得ました。 バンドで出ているメカニズムが移動性通報認証オプション(セクション5)の範囲の中になくて、またしたがって、そこに説明されないことに注意されるべきです。
- Network deployments in which not all Mobile Nodes and Home Agents have IKEv2 implementations and support for the integration of IKEv2 with backend AAA infrastructures. IKEv2 as a technology has yet to reach maturity status and widespread implementations needed for commercial deployments on a large scale. At the time of this writing, [RFC4306] is yet to be published as an RFC. Hence from a practical perspective that operators face, IKEv2 is not yet capable of addressing the immediate need for MIPv6 deployment.
- すべてのモバイルNodesとどんなホームのエージェントもバックエンドAAAインフラストラクチャがあるIKEv2の統合のIKEv2実装とサポートを持っていない展開をネットワークでつないでください。 技術としてのIKEv2には、まだ成熟していない状態と大規模に商業展開に必要である広範囲の実装があります。 この書くこと時点で、RFCとしてまだ[RFC4306]を発行していてはいけません。 したがって、オペレータが直面している実用的な見解から、IKEv2はMIPv6展開の即座の必要性をまだ扱うことができません。
- Networks that expressly rely on the backend AAA infrastructure as the primary means for identifying and authentication/authorizing a mobile user for MIPv6 service.
- 予備選挙が特定と認証/のために意味するようにMIPv6サービスのためにモバイルユーザに権限を与えながら明白にバックエンドAAAインフラストラクチャを当てにするネットワーク。
- Networks in which the establishment of the security association between the Mobile Node and the authentication server (AAA Home) is established using an out-of-band mechanism and not by any key exchange protocol. Such networks will also rely on out-of-band mechanisms to renew the security association (between MN and AAA Home) when needed.
- モバイルNodeと認証サーバ(AAAホーム)とのセキュリティ協会の設立がバンドで出ているメカニズムを使用することで設立されてどんな主要な交換プロトコルでないことでもあるネットワーク。 また、必要であると、そのようなネットワークは、セキュリティ協会(ミネソタとAAAホームの間の)を更新するためにバンドの外でメカニズムを当てにするでしょう。
- Networks that are bandwidth constrained (such as cellular wireless networks) and for which there exists a strong desire to minimize the number of signaling messages sent over such interfaces. MIPv6 signaling that relies on Internet Key Exchange (IKE) as the primary means for setting up an SA between the MN and HA requires more signaling messages compared with the use of an mobility message authentication option carried in the BU/BA messages.
- 抑制された帯域幅(セルワイヤレス・ネットワークなどの)であり、シグナリングメッセージの数を最小にする強い願望が存在するネットワークはそのようなインタフェースを移動しました。 移動性通報認証オプションのBU/BAメッセージで運ばれる使用と比べて、予備選挙がミネソタとHAの間のSAをセットアップするために意味するようにインターネット・キー・エクスチェンジ(IKE)を当てにするMIPv6シグナリングが、より多くのシグナリングメッセージを必要とします。
One such example of networks that have such characteristics are CDMA networks as defined in [3GPP2].
そのような特性を持っているネットワークに関するその一例は[3GPP2]で定義されるようにCDMAネットワークです。
2. Overview
2. 概要
This document presents a lightweight mechanism to authenticate the Mobile Node at the Home Agent or at the Authentication, Authorization, and Accounting (AAA) server in Home network (AAAH) based on a shared-key-based mobility security association between the Mobile Node and the respective authenticating entity. This shared- key-based mobility security association (shared-key-based mobility SA) may be statically provisioned or dynamically created. The term
このドキュメントは、モバイルNodeとそれぞれの認証実体との共有されたキーを拠点とする移動性セキュリティ協会に基づくホームネットワーク(AAAH)でモバイルNodeをホームのエージェントにおいて、または、Authenticationと、Authorizationと、Accounting(AAA)サーバにおいて認証するために軽量のメカニズムを提示します。 この共有されたキーを拠点とする移動性セキュリティ協会(共有されたキーベースの移動性SA)は、静的に食糧を供給されるか、またはダイナミックに創設されるかもしれません。 用語
Patel, et al. Informational [Page 4] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[4ページ]のRFC4285認証プロトコル
"mobility security association" referred to in this document is understood to be a "shared-key-based Mobile IPv6 authentication" security association.
言及された「移動性セキュリティ協会」は「共有されたキーベースのモバイルIPv6認証」セキュリティ協会であることが本書では理解されています。
This document introduces new mobility options to aid in authentication of the Mobile Node to the Home Agent or AAAH server. The confidentiality protection of Return Routability messages and authentication/integrity protection of Mobile Prefix Discovery (MPD) is not provided when these options are used for authentication of the Mobile Node to the Home Agent. Thus, unless the network can guarantee such protection (for instance, like in 3GPP2 networks), Route Optimization and Mobile Prefix Discovery should not be used when using the mobility message authentication option.
このドキュメントはホームのエージェントかAAAHサーバへのモバイルNodeの認証における援助に新しい移動性オプションを紹介します。これらのオプションがモバイルNodeの認証にホームのエージェントに使用されるとき、Return Routabilityメッセージの秘密性保護とモバイルPrefixディスカバリー(MPD)の認証/保全保護は提供されません。 移動性通報認証オプションを使用するとき、したがって、ネットワークがそのような保護(例えば3GPP2ネットワークなどのように)を保証できないなら、Route OptimizationとモバイルPrefixディスカバリーを使用するべきではありません。
3. Terminology
3. 用語
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3.1. General Terms
3.1. 一般項
First (size, input)
1番目(サイズ入力されて、
Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used.
この仕様によるいくつかの定石が「入力」データのトランケーションを示すのに機能的なフォーム「1(サイズ、入力)番目」を使用するので、最初の「サイズ」ビットだけが使用されるために残っています。
Shared-key-based Mobility Security Association
共有されたキーを拠点とする移動性セキュリティ協会
Security relation between the Mobile Node and its Home Agent, used
to authenticate the Mobile Node for mobility service. The
shared-key-based mobility security association between Mobile Node
and Home Agent consists of a mobility Security Parameter Index
(SPI), a shared key, an authentication algorithm, and the replay
protection mechanism in use.
移動性サービスのためにモバイルNodeを認証するのに使用されるモバイルNodeとそのホームのエージェントとのセキュリティ関係。 モバイルNodeとホームのエージェントとの共有されたキーを拠点とする移動性セキュリティ仲間は移動性Security Parameter Index(SPI)、共有されたキー、認証アルゴリズム、および使用中の反復操作による保護メカニズムから成ります。
Mobility SPI
移動性SPI
A number in the range [0-4294967296] used to index into the
shared-key-based mobility security associations.
範囲[0-4294967296]の数は以前はよく共有されたキーを拠点とする移動性セキュリティ協会に索引をつけていました。
Patel, et al. Informational [Page 5] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[5ページ]のRFC4285認証プロトコル
4. Operational Flow
4. 操作上の流れ
The figure below describes the sequence of messages sent and received between the MN and HA in the registration process. Binding Update (BU) and Binding Acknowledgement (BA) messages are used in the registration process.
以下の図は登録手続でミネソタとHAの間に送られて、受け取られたメッセージの系列について説明します。 拘束力があるUpdate(BU)とBinding Acknowledgement(BA)メッセージは登録手続で使用されます。
MN HA/AAAH
ハ、ミネソタ/AAAH
| BU to HA |
(a) |----------------------------------------------------->|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| HA/AAAH authenticates MN
| |
| |
| BA to MN |
(b) |<-----------------------------------------------------|
| (including MN-ID option, |
| mobility message replay protection option[optional],|
| mobility message authentication option) |
| |
| BU、ハ。| (a) |----------------------------------------------------->| | (| | ミネソタ-IDオプション、移動性メッセージ反復操作による保護オプション[任意の]を含んでいます| | 移動性通報認証オプション) | | | | HA/AAAHはミネソタを認証します。| | | | | ミネソタへのBa| (b) |<-----------------------------------------------------| | (| | ミネソタ-IDオプション、移動性メッセージ反復操作による保護オプション[任意の]を含んでいます| | 移動性通報認証オプション) | | |
Figure 1: Home Registration with Authentication Protocol
図1: 認証プロトコルとの本国登録
The Mobile Node MUST use the Mobile Node Identifier option, specifically the MN-NAI mobility option as defined in [RFC4283] to identify itself while authenticating with the Home Agent. The Mobile Node uses the Mobile Node Identifier option as defined in [RFC4283] to identify itself as may be required for use with some existing AAA infrastructure designs.
モバイルNodeはモバイルNode Identifierオプション(明確にホームのエージェントと共に認証している間、それ自体を特定するために[RFC4283]で定義されるミネソタ-NAI移動性オプション)を使用しなければなりません。 モバイルNodeは使用にいくつかの既存のAAAインフラストラクチャデザインで必要であるかもしれないようにそれ自体を特定するために[RFC4283]で定義されるようにモバイルNode Identifierオプションを使用します。
The Mobile Node MAY use the Message Identifier option as defined in Section 6 for additional replay protection.
モバイルNodeは追加反復操作による保護のためにセクション6で定義されるようにMessage Identifierオプションを使用するかもしれません。
The mobility message authentication option described in Section 5 may be used by the Mobile Node to transfer authentication data when the Mobile Node and the Home Agent are utilizing a mobility SPI (a number in the range [0-4294967296] used to index into the shared-key-based mobility security associations) to index between multiple mobility security associations.
セクション5で説明された移動性通報認証オプションは、モバイルNodeとホームのエージェントが複数の移動性セキュリティ関係の間で索引をつけるのに、移動性SPI(範囲[0-4294967296]の数は以前はよく共有されたキーを拠点とする移動性セキュリティ協会に索引をつけていた)を利用しているとき、認証データを移すのにモバイルNodeによって使用されるかもしれません。
Patel, et al. Informational [Page 6] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[6ページ]のRFC4285認証プロトコル
5. Mobility Message Authentication Option
5. 移動性通報認証オプション
This section defines a mobility message authentication option that may be used to secure Binding Update and Binding Acknowledgement messages. This option can be used along with IPsec or preferably as an alternate mechanism to authenticate Binding Update and Binding Acknowledgement messages in the absence of IPsec.
このセクションはBinding UpdateとBinding Acknowledgementがメッセージであると機密保護するのに使用されるかもしれない移動性通報認証オプションを定義します。 IPsec、または、望ましくは代替のメカニズムとしてIPsecが不在のときBinding UpdateとBinding Acknowledgementメッセージを認証するのにこのオプションを使用できます。
This document also defines subtype numbers, which identify the mode of authentication and the peer entity to authenticate the message. Two subtype numbers are specified in this document. Other subtypes may be defined for use in the future.
また、このドキュメントは「副-タイプ」番号を定義します。(番号は、メッセージを認証するために認証の方法と同輩実体を特定します)。 2つの「副-タイプ」番号が本書では指定されます。 他の血液型亜型は将来、使用のために定義されるかもしれません。
Only one instance of a mobility message authentication option of a particular subtype can be present in the message. One message may contain multiple instances of the mobility message authentication option with different subtype values. If both MN-HA and MN-AAA authentication options are present, the MN-HA authentication option must be present before the MN-AAA authentication option (else, the HA MUST discard the message).
特定の「副-タイプ」の移動性通報認証オプションの1つのインスタンスだけがメッセージに存在している場合があります。 1つのメッセージが異なった「副-タイプ」値で移動性通報認証オプションの複数のインスタンスを含むかもしれません。 ミネソタ-HAとミネソタ-AAA認証オプションの両方が存在しているなら、ミネソタ-HA認証オプションはミネソタ-AAA認証オプションの前に存在していなければなりません(ほかに、HA MUSTはメッセージを捨てます)。
When a Binding Update or Binding Acknowledgement is received without a mobility message authentication option and the entity receiving it is configured to use the mobility message authentication option or has the shared-key-based mobility security association for the mobility message authentication option, the entity should silently discard the received message.
移動性通報認証オプションなしでBinding UpdateかBinding Acknowledgementを受け取って、それを受ける実体が移動性通報認証オプションを使用するために構成されるか、または移動性通報認証オプションのために共有されたキーを拠点とする移動性セキュリティ協会を持っているとき、実体は静かに受信されたメッセージを捨てるべきです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| Subtype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 移動性SPI| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Mobility Message Authentication Option
図2: 移動性通報認証オプション
Option Type:
オプションタイプ:
AUTH-OPTION-TYPE value 9 has been defined by IANA. An 8-bit
identifier of the type mobility option.
AUTH-OPTION-TYPE値9はIANAによって定義されました。 タイプ移動性オプションの8ビットの識別子。
Patel, et al. Informational [Page 7] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[7ページ]のRFC4285認証プロトコル
Option Length:
オプションの長さ:
8-bit unsigned integer, representing the length in octets of
the Subtype, mobility Security Parameter Index (SPI) and
Authentication Data fields.
8ビットの符号のない整数、Subtypeの八重奏における長さを表す、移動性Security Parameter Index(SPI)、およびAuthentication Data分野。
Subtype:
Subtype:
A number assigned to identify the entity and/or mechanism to be
used to authenticate the message.
メッセージを認証するのに使用されるために実体、そして/または、メカニズムを特定するために割り当てられた数。
Mobility SPI:
移動性SPI:
Mobility Security Parameter Index
移動性セキュリティパラメタインデックス
Authentication Data:
認証データ:
This field has the information to authenticate the relevant
mobility entity. This protects the message beginning at the
Mobility Header up to and including the mobility SPI field.
この分野には、関連移動性実体を認証する情報があります。 これはMobility Headerで移動性SPI分野を含めて始まるメッセージを保護します。
Alignment requirements :
整列要求:
The alignment requirement for this option is 4n + 1.
このオプションのための整列要求は4n+1です。
5.1. MN-HA Mobility Message Authentication Option
5.1. Mn、-、ハ、移動性通報認証オプション
The format of the MN-HA mobility message authentication option is as defined in Figure 2. This option uses the subtype value of 1. The MN-HA mobility message authentication option is used to authenticate the Binding Update and Binding Acknowledgement messages based on the shared-key-based security association between the Mobile Node and the Home Agent.
ミネソタ-HA移動性通報認証オプションの形式が図2で定義されるようにあります。 このオプションは1の「副-タイプ」値を使用します。 ミネソタ-HA移動性通報認証オプションは、モバイルNodeとホームのエージェントとの共有されたキーを拠点とするセキュリティ仲間に基づくBinding UpdateとBinding Acknowledgementメッセージを認証するのに使用されます。
The shared-key-based mobility security association between Mobile Node and Home Agent used within this specification consists of a mobility SPI, a key, an authentication algorithm, and the replay protection mechanism in use. The mobility SPI is a number in the range [0-4294967296], where the range [0-255] is reserved. The key consists of an arbitrary value and is 16 octets in length. The authentication algorithm is HMAC_SHA1. The replay protection mechanism may use the Sequence number as specified in [RFC3775] or the Timestamp option as defined in Section 6. If the Timestamp option is used for replay protection, the mobility security association includes a "close enough" field to account for clock drift. A default value of 7 seconds SHOULD be used. This value SHOULD be greater than 3 seconds.
この仕様の中で使用されたモバイルNodeとホームのエージェントとの共有されたキーを拠点とする移動性セキュリティ仲間は移動性SPI、キー、認証アルゴリズム、および使用中の反復操作による保護メカニズムから成ります。 移動性SPIは範囲[0-4294967296]の数です。そこでは、範囲[0-255]は予約されています。 キーは、任意の価値から成って、長さが16の八重奏です。 認証アルゴリズムはHMAC_SHA1です。 反復操作による保護メカニズムはセクション6で定義されるように[RFC3775]の指定されるとしてのSequence番号かTimestampオプションを使用するかもしれません。 Timestampオプションが反復操作による保護に使用されるなら、移動性セキュリティ協会は、時計ドリフトの原因になるように「十分近い」分野を含めます。 7のデフォルト値はSHOULDを後援します。使用されます。 これは3以上が秒であったならSHOULDを評価します。
Patel, et al. Informational [Page 8] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[8ページ]のRFC4285認証プロトコル
The MN-HA mobility message authentication option MUST be the last option in a message with a mobility header if it is the only mobility message authentication option in the message.
それがメッセージで唯一の移動性通報認証オプションであるなら、ミネソタ-HA移動性通報認証オプションは移動性ヘッダーがあるメッセージで最後のオプションであるに違いありません。
The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option.
このオプションの移動性SPI価値を含めて移動性ヘッダーから始めて、認証データはメッセージで計算されます。
Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility Data))
認証データは1番目と等しいです。(96、HMAC_SHA1(ミネソタ-HA Sharedキー、Mobility Data))
Mobility Data = care-of address | home address | Mobility Header (MH) Data
移動性Dataが等しい、注意、-、アドレス| ホームアドレス| 移動性ヘッダー(MH)データ
MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The Checksum field in the Mobility Header MUST be set to 0 to calculate the Mobility Data.
MH Dataはこのオプションの移動性SPI分野を含めたMobility Headerの内容です。 Mobility HeaderのChecksum分野をMobility Dataについて計算するように0に設定しなければなりません。
The first 96 bits from the Message Authentication Code (MAC) result are used as the Authentication Data field.
メッセージ立証コード(MAC)結果から最初の96ビットはAuthentication Data分野として使用されます。
5.1.1. Processing Considerations
5.1.1. 処理問題
The assumption is that the Mobile Node has a shared-key-based security association with the Home Agent. The Mobile Node MUST include this option in a BU if it has a shared-key-based mobility security association with the Home Agent. The Home Agent MUST include this option in the BA if it received this option in the corresponding BU and Home Agent has a shared-key-based mobility security association with the Mobile Node.
仮定はモバイルNodeにはホームのエージェントとの共有されたキーを拠点とするセキュリティ仲間がいるということです。 それにホームのエージェントとの共有されたキーを拠点とする移動性セキュリティ仲間がいるなら、モバイルNodeはBUにこのオプションを含まなければなりません。 対応するBUのこのオプションを受け取ったなら、ホームのエージェントはBAのこのオプションを入れなければなりません、そして、ホームのエージェントには、モバイルNodeとの共有されたキーを拠点とする移動性セキュリティ協会があります。
The Mobile Node or Home Agent receiving this option MUST verify the authentication data in the option. If authentication fails, the Home Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home Agent does not have shared-key-based mobility SA, Home Agent MUST discard the BU. The Home Agent MAY log such events.
このオプションを受け取るモバイルNodeかホームのエージェントがオプションにおける認証データについて確かめなければなりません。 認証が失敗するなら、ホームのエージェントはStatus Code MIPV6-AUTH-FAILとBAを送らなければなりません。 ホームのエージェントが共有されたキーベースの移動性SAを持っていないなら、ホームのエージェントはBUを捨てなければなりません。 ホームのエージェントはそのようなイベントを登録するかもしれません。
5.2. MN-AAA Mobility Message Authentication Option
5.2. ミネソタ-AAA移動性通報認証オプション
The format of the MN-AAA mobility message authentication option is as defined in Figure 2. This option uses the subtype value of 2. The MN-AAA authentication mobility option is used to authenticate the Binding Update message based on the shared mobility security association between the Mobile Node and AAA server in Home network (AAAH). It is not used in Binding Acknowledgement messages. The corresponding Binding Acknowledgement messages must be authenticated using the MN-HA mobility message authentication option (Section 5.1).
ミネソタ-AAA移動性通報認証オプションの形式が図2で定義されるようにあります。 このオプションは2の「副-タイプ」値を使用します。 ミネソタ-AAA認証移動性オプションは、ホームネットワーク(AAAH)でモバイルNodeとAAAサーバとの共有された移動性セキュリティ協会に基づくBinding Updateメッセージを認証するのに使用されます。 それはBinding Acknowledgementメッセージで使用されません。 ミネソタ-HA移動性通報認証オプション(セクション5.1)を使用することで対応するBinding Acknowledgementメッセージを認証しなければなりません。
Patel, et al. Informational [Page 9] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[9ページ]のRFC4285認証プロトコル
The MN-AAA mobility message authentication option must be the last option in a message with a mobility header. The corresponding response MUST include the MN-HA mobility message authentication option, and MUST NOT include the MN-AAA mobility message authentication option.
ミネソタ-AAA移動性通報認証オプションは移動性ヘッダーがあるメッセージで最後のオプションであるに違いありません。 対応する応答は、ミネソタ-HA移動性通報認証オプションを含まなければならなくて、ミネソタ-AAA移動性通報認証オプションは含んではいけません。
The Mobile Node MAY use the Mobile Node Identifier option [RFC4283] to enable the Home Agent to make use of available AAA infrastructure.
モバイルNodeは、ホームのエージェントが利用可能なAAAインフラストラクチャを利用するのを可能にするのに、モバイルNode Identifierオプション[RFC4283]を使用するかもしれません。
The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option.
このオプションの移動性SPI価値を含めて移動性ヘッダーから始めて、認証データはメッセージで計算されます。
The authentication data shall be calculated as follows:
認証データは以下の通り計算されるものとします:
Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)
認証データはハッシュ_fnと等しいです。(ミネソタ-AAA Sharedキー、MAC_Mobility Data)
hash_fn() is decided by the value of mobility SPI field in the MN-AAA mobility message authentication option.
ハッシュ_fn()はSPIがミネソタ-AAA移動性通報認証オプションでさばく移動性の値によって決められます。
SPI = HMAC_SHA1_SPI:
SPIはHMAC_SHA1_SPIと等しいです:
If mobility SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication. In that case, MAC_Mobility Data is calculated as follows:
移動性SPIによく知られる値の_HMAC_SHA1SPIがあるなら、ハッシュ_fn()はHMAC_SHA1です。 HMAC_SHA1_SPIが使用されているとき、BUは、HMAC_SHA1認証を使用することでAAAによって認証されます。 その場合、MAC_Mobility Dataは以下の通り計算されます:
MAC_Mobility Data = SHA1(care-of address | home address | MH Data)
MAC_移動性データはSHA1と等しいです。(注意、-、アドレス|ホームアドレス|MH Data)
MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option.
MH Dataはこのオプションの移動性SPI分野を含めたMobility Headerの内容です。
5.2.1. Processing Considerations
5.2.1. 処理問題
The use of the MN-AAA mobility message authentication option assumes that AAA entities at the home site communicate with the HA via an authenticated channel. Specifically, a BU with the MN-AAA mobility message authentication option is authenticated via a home AAA server. The specific details of the interaction between the HA and the AAA server is beyond the scope of this document.
ミネソタ-AAA移動性通報認証オプションの使用は、ホームサイトのAAA実体が認証されたチャンネルでHAとコミュニケートすると仮定します。 明確に、ミネソタ-AAA移動性通報認証オプションがあるBUはホームAAAサーバで認証されます。HAとAAAサーバとの相互作用の特定の詳細はこのドキュメントの範囲を超えています。
When the Home Agent receives a Binding Update with the MN-AAA mobility message authentication option, the Binding Update is authenticated by an entity external to the Home Agent, typically a AAA server.
ホームのエージェントがミネソタ-AAA移動性通報認証オプションでBinding Updateを受け取るとき、Binding Updateはホームのエージェント、通常AAAサーバへの外部の実体によって認証されます。
Patel, et al. Informational [Page 10] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[10ページ]のRFC4285認証プロトコル
5.3. Authentication Failure Detection at the Mobile Node
5.3. モバイルノードでの認証失敗検出
In case of authentication failure, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, if a shared-key-based mobility security association to be used between Mobile Node and Home Agent for authentication exists. If there is no shared-key-based mobility security association, HA drops the Binding Update. HA may log the message for administrative action.
認証失敗の場合には、ホームのエージェントはステータスコードMIPV6-AUTH-FAILとBinding AcknowledgementをモバイルNodeに送らなければなりません、認証にモバイルNodeとホームのエージェントの間で使用されるべき共有されたキーを拠点とする移動性セキュリティ協会が存在するなら。 どんな共有されたキーを拠点とする移動性セキュリティ協会もなければ、HAはBinding Updateを下げます。 HAは管理動作へのメッセージを登録するかもしれません。
Upon receiving a Binding Acknowledgement with status code MIPV6- AUTH-FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the Home Agent.
ステータスコードMIPV6- AUTH-FAILと共にBinding Acknowledgementを受けると、モバイルNode SHOULDは、新しいBinding Updatesをホームのエージェントに送るのを止めます。
6. Mobility Message Replay Protection Option
6. 移動性メッセージ反復操作による保護オプション
The Mobility message replay protection option MAY be used in Binding Update/Binding Acknowledgement messages when authenticated using the mobility message authentication option as described in Section 5.
セクション5で説明されるように移動性通報認証オプションを使用することで認証されると、Mobilityメッセージ反復操作による保護オプションはBinding Update/拘束力があるAcknowledgementメッセージで使用されるかもしれません。
The mobility message replay protection option is used to let the Home Agent verify that a Binding Update has been freshly generated by the Mobile Node and not replayed by an attacker from some previous Binding Update. This is especially useful for cases where the Home Agent does not maintain stateful information about the Mobile Node after the binding entry has been removed. The Home Agent does the replay protection check after the Binding Update has been authenticated. The mobility message replay protection option when included is used by the Mobile Node for matching BA with BU.
ホームのエージェントにBinding UpdateがモバイルNodeによって新たに生成されて、攻撃者によって前のいくらかのBinding Updateから再演されていないことを確かめさせるのに移動性メッセージ反復操作による保護オプションは使用されます。 これは特に拘束力があるエントリーを取り除いた後にホームのエージェントがモバイルNodeのstateful情報を保守しないケースの役に立ちます。 Binding Updateが認証された後にホームのエージェントは反復操作による保護チェックをします。 含まれていると、移動性メッセージ反復操作による保護オプションは合っているBAにBUと共にモバイルNodeによって使用されます。
If this mode of replay protection is used, it needs to be part of the shared-key-based mobility security association.
反復操作による保護のこの方法が使用されているなら、それは、共有されたキーを拠点とする移動性セキュリティ協会の一部である必要があります。
If the policy at Home Agent mandates replay protection using this option (as opposed to the sequence number in the Mobility Header in Binding Update) and the Binding Update from the Mobile Node does not include this option, the Home Agent discards the BU and sets the Status Code in BA to MIPV6-MESG-ID-REQD.
モバイルNodeからこのオプション(Binding UpdateのMobility Headerの一連番号と対照的に)とBinding Updateを使用する反復操作による保護がホームエージェント命令における方針であるならこのオプションを含んでいなくて、ホームのエージェントは、BUを捨てて、MIPV6-MESG ID REQDへのBAにStatus Codeをはめ込みます。
When the Home Agent receives the mobility message replay protection option in Binding Update, it MUST include the mobility message replay protection option in Binding Acknowledgement. Appendix A provides details regarding why the mobility message replay protection option MAY be used when using the authentication option.
ホームのエージェントがBinding Updateの移動性メッセージ反復操作による保護オプションを受け取るとき、それはBinding Acknowledgementの移動性メッセージ反復操作による保護オプションを含まなければなりません。 付録Aは認証オプションを使用するとき移動性メッセージ反復操作による保護オプションが使用されるかもしれない理由に関する詳細を明らかにします。
Patel, et al. Informational [Page 11] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[11ページ]のRFC4285認証プロトコル
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mobility Message Replay Protection Option
図3: 移動性メッセージ反復操作による保護オプション
Option Type:
オプションタイプ:
MESG-ID-OPTION-TYPE value 10 has been defined by IANA. An
8-bit identifier of the type mobility option.
MESG ID OPTION-TYPE値10はIANAによって定義されました。 タイプ移動性オプションの8ビットの識別子。
Option Length:
オプションの長さ:
8-bit unsigned integer, representing the length in octets of
the Timestamp field.
Timestamp分野の八重奏における長さを表す8ビットの符号のない整数。
Timestamp:
タイムスタンプ:
This field carries the 64 bit timestamp.
この分野は64ビットのタイムスタンプを運びます。
Alignment requirements :
整列要求:
The alignment requirement for this option is 8n + 2.
このオプションのための整列要求は8n+2です。
The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the shared-key-based mobility security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. The two nodes must have adequately synchronized time-of-day clocks.
タイムスタンプ反復操作による保護の基本原理はメッセージを生成するノードが現在の時刻を挿入して、メッセージを受け取るノードが、このタイムスタンプがそれ自身の時刻の十分近くにあるのをチェックするということです。 ノードの間の共有されたキーを拠点とする移動性セキュリティ協会で異なって指定されない場合、7秒のデフォルト値は、時差を制限するのに使用されるかもしれません。 これは3以上が秒であったならSHOULDを評価します。 2つのノードが時刻時計を適切に連動させたに違いありません。
The Mobile Node MUST set the Timestamp field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [RFC1305]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits that are not available from a time source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the 64-bit timestamp used in a Binding Update from the Mobile Node MUST be greater than that used in any previous successful Binding Update.
モバイルNodeはNetwork Timeプロトコル(NTP)[RFC1305]によって指定されるようにフォーマットされた64ビットの値にTimestamp分野を設定しなければなりません。 NTP形式の下位の32ビットは有効でない断片的な秒、およびそれらのビットを表します。時間ソースSHOULDから、偶発性の良い源から生成されてください。 しかしながら、タイムスタンプを使用するとき、Binding UpdateでモバイルNodeから使用される64ビットのタイムスタンプが前のどんなうまくいっているBinding Updateでも使用されるそれよりすばらしいに違いないことに注意してください。
Patel, et al. Informational [Page 12] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[12ページ]のRFC4285認証プロトコル
After successful authentication of Binding Update (either locally at the Home Agent or when a success indication is received from the AAA server), the Home Agent MUST check the Timestamp field for validity. In order to be valid, the timestamp contained in the Timestamp field MUST be close enough to the Home Agent's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting Mobile Node.
Binding Updateのうまくいっている認証の後、(どちらか、局所的である、ホームのエージェントかそれともいつAAAサーバから成功指示を受けるか、)、ホームのエージェントは正当性がないかどうかTimestamp分野をチェックしなければなりません。 有効になるようにホームのエージェントの時刻時計にはTimestamp分野に保管されていたタイムスタンプが十分近くにあるに違いなくて、タイムスタンプはすべてが以前に要求モバイルのNodeのためのタイムスタンプを受け入れたよりすばらしいに違いありません。
If the timestamp is valid, the Home Agent copies the entire Timestamp field into the Timestamp field in the BA it returns to the Mobile Node. If the timestamp is not valid, the Home Agent copies only the low-order 32 bits into the BA, and supplies the high-order 32 bits from its own time of day.
タイムスタンプが有効であるなら、ホームのエージェントはそれがモバイルNodeに返すBAのTimestamp分野に全体のTimestamp分野をコピーします。 タイムスタンプが有効でないなら、ホームのエージェントは、BAに下位だけを32ビットコピーして、高位をそれ自身の時刻から32ビット供給します。
If the Timestamp field is not valid but the authentication of the BU succeeds, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. The Home Agent does not create a binding cache entry if the timestamp check fails.
Timestamp分野が有効ではありませんが、BUの認証が成功するなら、ホームのエージェントはステータスコードMIPV6ID MISMATCHとBinding Acknowledgementを送らなければなりません。 タイムスタンプチェックが失敗するなら、ホームのエージェントは拘束力があるキャッシュエントリーを作成しません。
If the Mobile Node receives a Binding Acknowledgement with the code MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by processing the MN-HA authentication mobility option.
モバイルNodeがコードMIPV6ID MISMATCHと共にBinding Acknowledgementを受けるなら、モバイルNodeは、ミネソタ-HA認証移動性オプションを処理することによって、BAを認証しなければなりません。
If authentication succeeds, the Mobile Node MUST adjust its timestamp and send subsequent Binding Update using the updated value.
認証が成功するなら、アップデートされた値を使用して、モバイルNodeはタイムスタンプを調整して、その後のBinding Updateを送らなければなりません。
Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH status code, the Mobile Node MUST compare the Timestamp value in the BA to the Timestamp value it sent in the corresponding BU. If the values match, the Mobile Node proceeds to process the MN-HA authentication data in the BA. If the values do not match, the Mobile Node silently discards the BA.
MIPV6ID MISMATCHステータスコードを含まないBAを受けると、モバイルNodeはBAでそれが対応するBUで送ったTimestamp値とTimestamp値を比較しなければなりません。 値が合っているなら、モバイルNodeはBAのミネソタ-HA認証データを処理しかけます。 値が合っていないなら、モバイルNodeは静かにBAを捨てます。
7. Security Considerations
7. セキュリティ問題
This document proposes new mobility message authentication options to authenticate the control message between Mobile Node, Home Agent, and/or home AAA (as an alternative to IPsec). The new options provide for authentication of Binding Update and Binding Acknowledgement messages. The MN-AAA mobility message authentication option provide for authentication with AAA infrastructure.
このドキュメントは、モバイルNode、ホームのエージェント、そして/または、ホームAAA(IPsecに代わる手段として)の間のコントロールメッセージを認証するために新しい移動性通報認証オプションを提案します。 新しいオプションはBinding UpdateとBinding Acknowledgementメッセージの認証に備えます。 ミネソタ-AAA移動性通報認証オプションはAAAインフラストラクチャで認証に備えます。
This specification also introduces an optional replay protection mechanism in Section 6, to prevent replay attacks. The sequence number field in the Binding Update is not used if this mechanism is used. This memo defines the timestamp option to be used for mobility message replay protection.
また、この仕様は、反射攻撃を防ぐためにセクション6の任意の反復操作による保護メカニズムを紹介します。 このメカニズムが使用されているなら、Binding Updateの一連番号分野は使用されていません。 このメモは、移動性メッセージ反復操作による保護に使用されるためにタイムスタンプオプションを定義します。
Patel, et al. Informational [Page 13] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[13ページ]のRFC4285認証プロトコル
8. IANA Considerations
8. IANA問題
IANA services are required for this specification. The values for new mobility options and status codes must be assigned from the Mobile IPv6 [RFC3775] numbering space.
IANAサービスがこの仕様に必要です。 モバイルIPv6[RFC3775]付番スペースから新しい移動性オプションとステータスコードのための値を割り当てなければなりません。
The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID- OPTION-TYPE, as defined in Section 5 and Section 6, have been assigned. The values are 9 for the AUTH-OPTION-TYPE and 10 for the MESG-ID-OPTION-TYPE Mobility Option.
Mobility OptionタイプのAUTH-OPTION-TYPEとMESG-ID OPTION-TYPEのためのセクション5とセクション6で定義される値を割り当ててあります。 値は、AUTH-OPTION-TYPEのための9とMESG ID OPTION-TYPE Mobility Optionのための10です。
The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL, and MIPV6-MESG-ID-REQD, as defined in Section 6 and Section 5.3, have been assigned. The values are 144 for MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL.
ステータスコードのMIPV6ID MISMATCH、MIPv6-AUTH-FAIL、およびMIPV6-MESG ID REQDのためのセクション6とセクション5.3で定義される値を割り当ててあります。 値はMIPV6-MESG ID REQDのためのMIPV6ID MISMATCH145とMIPV6-AUTH-FAILのための146のための144です。
A new section for enumerating algorithms identified by specific mobility SPIs within the range 0-255 has to be added to
追加される範囲0-255の中のSPIsが持っている特定の移動性によって特定されたアルゴリズムを列挙するための新しいセクション
http://www.iana.org/assignments/mobility-parameters
http://www.iana.org/assignments/mobility-parameters
The currently defined values are as follows:
現在定義された値は以下の通りです:
The value 0 should not be assigned.
値0を割り当てるべきではありません。
The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
値3はHMAC_SHA1_SPIのためにセクション5.2で定義されるように予約されます。
The value 5 is reserved for use by 3GPP2.
値5は使用のために3GPP2によって予約されます。
New values for this namespace can be allocated using IETF Consensus. [RFC2434].
IETF Consensusを使用することでこの名前空間のための新しい値を割り当てることができます。 [RFC2434。]
In addition, IANA has created a new namespace for the Subtype field of the MN-HA and MN-AAA mobility message authentication options under
さらに、IANAは下でミネソタ-HAとミネソタ-AAA移動性通報認証オプションのSubtype分野への新しい名前空間を作成しました。
http://www.iana.org/assignments/mobility-parameters
http://www.iana.org/assignments/mobility-parameters
The currently allocated values are as follows:
現在割り当てられた値は以下の通りです:
1 MN-HA mobility message authentication option Section 5.1
1 ミネソタ-HA移動性通報認証オプションセクション5.1
2 MN-AAA mobility message authentication option Section 5.2
2 ミネソタ-AAA移動性通報認証オプションセクション5.2
New values for this namespace can be allocated using IETF Consensus. [RFC2434].
IETF Consensusを使用することでこの名前空間のための新しい値を割り当てることができます。 [RFC2434。]
Patel, et al. Informational [Page 14] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[14ページ]のRFC4285認証プロトコル
9. Acknowledgements
9. 承認
The authors would like to thank Basavaraj Patil, Charlie Perkins, Vijay Devarapalli, Jari Arkko, and Gopal Dommety, and Avi Lior for their thorough review and suggestions on the document. The authors would like to acknowledge the fact that a similar authentication method was considered in base protocol [RFC3775] at one time.
作者はドキュメントの上に彼らの徹底的なレビューと提案についてBasavarajパティル、チャーリー・パーキンス、ビジェイDevarapalli、ヤリArkko、ゴパルDommety、およびアヴィLiorに感謝したがっています。 作者は同様の認証方法がひところベースプロトコル[RFC3775]で考えられたという事実を承認したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile
IPv6", RFC 4283, November 2005.
[RFC4283] パテルとA.とレオンとK.とカリルとM.とAkhtar、H.とK.チョードリ、「モバイルIPv6"、RFC4283、2005年11月のためのモバイルノード識別子オプション。」
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1305] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実装」RFC1305、3月1992日
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
10.2. Informative References
10.2. 有益な参照
[3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D,
September 2005.
[3GPP2]「cdma2000のワイヤレスのIPネットワーク規格」、3GPP2X.S0011-D、2005年9月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
Patel, et al. Informational [Page 15] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[15ページ]のRFC4285認証プロトコル
Appendix A. Rationale for Mobility Message Replay Protection Option
移動性メッセージ反復操作による保護オプションのための付録A.原理
Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility header to prevent replay attacks. There are two aspects that stand out in regards to using the Sequence Number to prevent replay attacks.
モバイルIPv6[RFC3775]は、反射攻撃を防ぐために移動性ヘッダーでSequence Numberを定義します。 Sequence Numberを使用することに関する外で反射攻撃を防ぐのに耐える2つの局面があります。
First, the specification states that the Home Agent should accept a BU with a Sequence Number greater than the Sequence Number from the previous Binding Update. This implicitly assumes that the Home Agent has some information regarding the Sequence Number from the previous BU (even when the binding cache entry is not present). Second, the specification states that if the Home Agent has no binding cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this Mobile Node.
まず最初に、仕様は、Sequence NumberにSequence Numberよりすばらしい状態でホームのエージェントが前のBinding UpdateからBUを受け入れるべきであると述べます。 これは、ホームのエージェントには前のBUからのSequence Numberの何らかの情報があるとそれとなく仮定します(拘束力があるキャッシュエントリーが存在してさえいないとき)。 2番目に、仕様は、ホームのエージェントに示されたホームアドレスのためのどんな拘束力があるキャッシュエントリーもないなら、容認されたBinding UpdateでこのモバイルNodeからどんなSequence Number値も受け入れなければならないと述べます。
With the mechanism defined in this document, it is possible for the Mobile Node to register with a different Home Agent during each mobility session. Thus, it is unreasonable to expect each Home Agent in the network to maintain state about the Mobile Node. Also, if the Home Agent does not cache information regarding sequence number, as per the second point above, a replayed BU can cause a Home Agent to create a binding cache entry for the Mobile Node. Thus, when authentication option is used, Sequence Number does not provide protection against replay attack.
メカニズムが本書では定義されている状態で、モバイルNodeがそれぞれの移動性セッションの間、異なったホームのエージェントとともに記名するのは、可能です。 したがって、ネットワークのそれぞれのホームのエージェントがモバイルNodeに関して状態を維持すると予想するのは無理です。 また、ホームのエージェントが一連番号の情報をキャッシュしないなら、2番目のポイントに従って、上では、再演されたBUがホームのエージェントにモバイルNodeのために拘束力があるキャッシュエントリーを作成させることができます。 認証オプションが使用されているとき、したがって、Sequence Numberは反射攻撃に対する保護を提供しません。
One solution to this problem (when the Home Agent does not save state information for every Mobile Node) would be for the Home Agent to reject the first BU and assign a (randomly generated) starting sequence number for the session and force the Mobile Node to send a fresh BU with the suggested sequence number. While this would work in most cases, it would require an additional round trip, and this extra signaling and latency is not acceptable in certain deployments [3GPP2]. Also, this rejection and using sequence number as a nonce in rejection is a new behavior that is not specified in [RFC3775].
この問題(ホームのエージェントが、状態があらゆるモバイルNodeのための情報であると保存しないと)への1つの解決は、ホームのエージェントがモバイルNodeに最初のBUを拒絶して、セッションのために(手当たりしだいに発生する)の始めの一連番号を割り当てて、提案された一連番号と共に新鮮なBUを強制的に送らせるだろうことです。 多くの場合、これが働いているだろうという間、追加周遊旅行を必要とするでしょう、そして、この付加的なシグナリングと潜在はある展開[3GPP2]で許容できません。 また、拒絶における一回だけとしてのこの拒絶と使用一連番号は[RFC3775]で指定されない新しい振舞いです。
Thus, this specification uses the mobility message replay protection option to prevent replay attacks. Specifically, timestamps are used to prevent replay attacks as described in Section 6.
したがって、この仕様は、反射攻撃を防ぐのに移動性メッセージ反復操作による保護オプションを使用します。 明確に、タイムスタンプは、セクション6で説明されるように反射攻撃を防ぐのに使用されます。
It is important to note that as per Mobile IPv6 [RFC3775] this problem with sequence number exists. Since the base specification mandates the use of IPsec (and naturally that goes with IKE in most cases), the real replay protection is provided by IPsec/IKE. In case of BU/BA between Mobile Node and Client Node (CN), the liveness proof is provided by the use of nonces that the CN generates.
モバイルIPv6[RFC3775]に従って一連番号に関するこの問題が存在することに注意するのは重要です。 基礎仕様がIPsecの使用を強制するので(当然、多くの場合、それはIKEを伴います)、本当の反復操作による保護はIPsec/IKEによって提供されます。 モバイルNodeとClient Node(CN)の間のBU/BAの場合には、CNが生成する一回だけの使用で活性証拠を提供します。
Patel, et al. Informational [Page 16] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[16ページ]のRFC4285認証プロトコル
Authors' Addresses
作者のアドレス
Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
Alpeshパテルシスコシステムズ170w.タスマンDriveサンノゼ、カリフォルニア95134米国
Phone: +1 408-853-9580 EMail: alpesh@cisco.com
以下に電話をしてください。 +1 408-853-9580 メールしてください: alpesh@cisco.com
Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US
ケントレオン・シスコシステムズ170w.タスマン・Driveカリフォルニア95134サンノゼ(米国)
Phone: +1 408-526-5030 EMail: kleung@cisco.com
以下に電話をしてください。 +1 408-526-5030 メールしてください: kleung@cisco.com
Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
モハメドカリルノーテルは2221年の湖畔Blvd.をネットワークでつなぎます。 テキサス75082リチャードソン(米国)
Phone: +1 972-685-0574 EMail: mkhalil@nortel.com
以下に電話をしてください。 +1 972-685-0574 メールしてください: mkhalil@nortel.com
Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US
Haseeb Akhtarノーテルは2221年の湖畔Blvd.をネットワークでつなぎます。 テキサス75082リチャードソン(米国)
Phone: +1 972-684-4732 EMail: haseebak@nortel.com
以下に電話をしてください。 +1 972-684-4732 メールしてください: haseebak@nortel.com
Patel, et al. Informational [Page 17] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[17ページ]のRFC4285認証プロトコル
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US
KuntalチョードリStarentネットワーク30の国際Place MA01876テュークスベリー(米国)
Phone: +1 214 550 1416 EMail: kchowdhury@starentnetworks.com
以下に電話をしてください。 +1 1416年の214 550メール: kchowdhury@starentnetworks.com
Patel, et al. Informational [Page 18] RFC 4285 Authentication Protocol for Mobile IPv6 January 2006
パテル、他 モバイルIPv6 January 2006のための情報[18ページ]のRFC4285認証プロトコル
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Patel, et al. Informational [Page 19]
パテル、他 情報[19ページ]
一覧
スポンサーリンク
