Network Working Group C. Perkins
Request for Comments: 3957 Nokia Research Center
Category: Standards Track P. Calhoun
Airespace
March 2005
Network Working Group C. Perkins
Request for Comments: 3957 Nokia Research Center
Category: Standards Track P. Calhoun
Airespace
March 2005
Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
移动IPv4的身份验证、授权和记帐（AAA）注册密钥
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent.
身份验证、授权和记帐（AAA）服务器，如RADIUS和DIAMETER，目前在Internet中用于为拨号计算机提供身份验证和授权服务。IPv4的移动IP要求移动节点与其归属代理之间进行强身份验证。然而，当移动节点与其归属AAA服务器共享AAA安全关联时，可以使用该AAA安全关联来创建移动节点与其归属代理之间的派生移动安全关联，并且再次在移动节点与当前提供到移动节点的连接的外部代理之间创建派生移动安全关联。本文档指定了移动IP注册消息的扩展，可用于在移动节点及其归属代理之间和/或移动节点与外部代理之间创建移动安全关联。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operations with Key Generation Nonce Extensions. . 5
4. Mobility Security Associations . . . . . . . . . . . . . . . . 7
5. Key Generation Nonce Creation and Key Derivation . . . . . . . 8
6. Key Generation Extensions. . . . . . . . . . . . . . . . . . . 9
6.1. Generalized MN-FA Key Generation Nonce Request Extension 10
6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 11
6.3. Generalized MN-HA Key Generation Nonce Request Extension 13
6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 14
7. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. AAA Infrastructure. . . . . . . . . . . . . . . . . . . . . 20
B. Message Flow for Requesting and Receiving Registration Keys 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operations with Key Generation Nonce Extensions. . 5
4. Mobility Security Associations . . . . . . . . . . . . . . . . 7
5. Key Generation Nonce Creation and Key Derivation . . . . . . . 8
6. Key Generation Extensions. . . . . . . . . . . . . . . . . . . 9
6.1. Generalized MN-FA Key Generation Nonce Request Extension 10
6.2. Generalized MN-FA Key Generation Nonce Reply Extension . 11
6.3. Generalized MN-HA Key Generation Nonce Request Extension 13
6.4. Generalized MN-HA Key Generation Nonce Reply Extension . 14
7. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. AAA Infrastructure. . . . . . . . . . . . . . . . . . . . . 20
B. Message Flow for Requesting and Receiving Registration Keys 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 27
AAA servers, such as RADIUS [11] and DIAMETER [12], are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be valuable for mobile nodes using Mobile IP for IPv4 [1], when the nodes are attempting to connect to foreign domains with AAA servers. In this document Mobile IP for IPv4 is called "Mobile IPv4" or just "Mobile IP" for short, since no confusion with other versions is expected. Requirements for interactions between AAA and Mobile IP are outlined in RFC 2977 [13]; that document describes an infrastructure which enables AAA servers to authenticate and authorize network access requests from mobile nodes. See also appendix A. The Mobile IP Registration Request is considered to be a request for network access. It is then possible to augment the functionality of the Mobile IP mobility agents so that they can translate between Mobile IP registration messages and the messages used within the AAA infrastructure, as described in RFC 2977. Mobility agents and AAA servers that conform to the requirements of RFC 2977 can be considered as appropriate network entities to support the message types specified in this document. Please consult RFC 2977 [13] for further details.
AAA服务器，如RADIUS[11]和DIAMETER[12]，目前在互联网中使用，为拨号计算机提供身份验证和授权服务。当节点试图连接到具有AAA服务器的外部域时，此类服务对于使用IPv4移动IP的移动节点来说可能很有价值[1]。在本文档中，IPv4的移动IP称为“移动IPv4”，简称为“移动IP”，因为不会与其他版本混淆。RFC 2977[13]概述了AAA和移动IP之间的交互要求；该文档描述了一种基础设施，它使AAA服务器能够对来自移动节点的网络访问请求进行身份验证和授权。另见附录A。移动IP注册请求被视为网络访问请求。然后可以增强移动IP移动代理的功能，以便它们能够在移动IP注册消息和AAA基础设施内使用的消息之间进行转换，如RFC 2977中所述。符合RFC 2977要求的移动代理和AAA服务器可被视为适当的网络实体，以支持本文档中指定的消息类型。有关更多详细信息，请咨询RFC 2977[13]。
This specification makes use of a single AAA Security Association to create derivative Mobility Security Associations. A Mobility Security Association in this specification is a simplex connection that serves to authenticate MIPv4 control traffic between a MN and HA and/or a MN and FA. A Mobility Security Association is identified by the two end points, such as a MN IP address and a HA IP address, and a SPI. Two nodes may have one or more Mobility Security Associations established between each other; however, typically there is no reason to have more than one Mobility Security Association between two nodes.
本规范使用单个AAA安全关联来创建派生的移动安全关联。本规范中的移动安全关联是一个单工连接，用于验证MN和HA和/或MN和FA之间的MIPv4控制流量。移动安全关联由两个端点标识，例如MN IP地址和HA IP地址，以及SPI。两个节点可以具有在彼此之间建立的一个或多个移动性安全关联；然而，通常没有理由在两个节点之间具有多个移动安全关联。
This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the MN and FA and/or MN and HA based on the AAA Security Association between the MN and AAA server. These new Mobility Security Associations may then be used to calculate the Authentication Data needed by authentication extensions used in Mobile IP control messages.
本文档指定了移动IP注册消息的扩展，可用于基于MN和AAA服务器之间的AAA安全关联在MN和FA和/或MN和HA之间创建移动安全关联。这些新的移动安全关联随后可用于计算移动IP控制消息中使用的认证扩展所需的认证数据。
It is assumed that the security association between the mobile node and its AAA server has been appropriately configured so that the AAA server can provide key material to be used as the basis for the necessary Mobility Security Association(s) between the mobile node and its prospective mobility agents.
假设移动节点与其AAA服务器之间的安全关联已被适当地配置，使得AAA服务器可以提供用作移动节点与其预期移动代理之间必要的移动安全关联的基础的关键材料。
AAA servers typically use the Network Access Identifier (NAI) [2] to uniquely identify the mobile node; the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without having any home address. However, for Mobile IP to work, the mobile node is required to have a home address and a Mobility Security Association [1] with its home agent. When the Mobile IP Registration Reply packet is authenticated by the MN-AAA Authentication Extension [3], the mobile node can verify that the key material contained in the extensions were produced by the AAA server, and thus may be reliably used to create Mobility Security Associations with the home agent and/or the foreign agent.
AAA服务器通常使用网络接入标识符（NAI）[2]来唯一地标识移动节点；移动节点的家庭地址并不总是提供该功能所必需的。因此，移动节点可以在不具有任何家庭地址的情况下认证自身，并被授权连接到外域。然而，为了使移动IP工作，移动节点需要具有归属地址以及与其归属代理的移动安全关联[1]。当移动IP注册应答分组由MN-AAA认证扩展[3]认证时，移动节点可以验证扩展中包含的密钥材料是由AAA服务器生成的，因此可以可靠地用于创建与归属代理和/或外部代理的移动安全关联。
It is also assumed that the AAA entities involved (i.e., the AAAH, AAAL, and the AAA interface features of the foreign agents and home agents) all have means outside of the scope of this document for exchanging keys. The extensions within this document are intended to work with any AAA protocol suite that allows for such key exchange, as long as it satisfies the requirements specified in RFC 2977 [13]. One such AAA protocol is defined within the Diameter framework [14].
还假设所涉及的AAA实体（即AAAH、AAAL以及外国代理和本国代理的AAA接口功能）都具有本文件范围外的密钥交换手段。本文件中的扩展旨在与允许此类密钥交换的任何AAA协议套件一起使用，只要它满足RFC 2977[13]中规定的要求。Diameter框架中定义了一个这样的AAA协议[14]。
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[4]中所述进行解释。
AAA Authentication, Authorization, and Accounting (see [10]).
AAA认证、授权和记帐（见[10]）。
AAA entity A network node processing AAA messages according to the requirements for AAA protocols (see [10]).
AAA实体根据AAA协议的要求处理AAA消息的网络节点（参见[10]）。
AAA Security Association A security association between a AAA entity and another node needing the services of that AAA entity. In this document all AAA Security Associations are between a mobile node and its home AAA server (AAAH). A mobile node's AAA Security Association with its home AAA server (AAAH) may be based either on the mobile node's IP address or on its NAI [2]. The key is referred to as "AAA-key" in this specification.
AAA安全关联AAA实体和需要该AAA实体服务的另一个节点之间的安全关联。在本文档中，所有AAA安全关联都位于移动节点及其主AAA服务器（AAAH）之间。移动节点与其家庭AAA服务器（AAAH）的AAA安全关联可以基于移动节点的IP地址或其NAI[2]。该密钥在本规范中称为“AAA密钥”。
Key A number, kept secret. Only nodes in possession of the key have any hope of using the security transform to obtain correct results.
钥匙号码，保密。只有拥有密钥的节点才有希望使用安全转换来获得正确的结果。
Key Generation Nonce Nonce data used for the purpose of creating a key.
密钥生成用于创建密钥的Nonce数据。
Mobility Security Association A Mobility Security Association is a simplex connection that applies security services to RFC 3344 MIPv4 control traffic between a MN and HA (or MN and FA) using RFC 3344 Authentication Extensions. A Mobility Security Association is uniquely identified by the peer source and destination IP addresses and an SPI. Two nodes may have one or more Mobility Security Associations; however, typically there is no reason to have more than one Mobility Security Association between two nodes, except as a transient condition during re-keying events.
移动安全关联移动安全关联是一种单工连接，它将安全服务应用于RFC 3344 MIPv4，使用RFC 3344身份验证扩展控制MN和HA（或MN和FA）之间的流量。移动安全关联由对等源和目标IP地址以及SPI唯一标识。两个节点可以具有一个或多个移动安全关联；然而，通常没有理由在两个节点之间有一个以上的移动安全关联，除非在重设密钥事件期间作为一个暂时条件。
Registration Key A key used in the MN-FA or MN-HA Mobility Security Association. A registration key is typically only used once or a very few times, and only for the purposes of verifying a small volume of Authentication data.
注册密钥MN-FA或MN-HA移动安全关联中使用的密钥。注册密钥通常只使用一次或几次，并且仅用于验证少量身份验证数据。
Security Algorithm A set of rules for using input data and a secret key for producing data for use in security protocols.
安全算法用于使用输入数据的一组规则和用于生成用于安全协议的数据的密钥。
SPI Security Parameters Index. The SPI is an arbitrary 32-bit value that assists in the identification of an AAA, IP, or Mobility Security Association.
SPI安全参数索引。SPI是一个任意32位值，有助于识别AAA、IP或移动安全关联。
Other terminology is used as defined in the base Mobile IP specification [1]. Furthermore, in order to simplify the discussion, we have used the word "Extension" instead of "Subtype of the Generalized Extension" in many cases. So, for instance, instead of using the phrase "The MN-FA Key Generation Nonce From AAA Subtype of the Generalized MN-FA Key Generation Nonce Reply Extension", we would instead use the phrase "The MN-FA Key Generation Nonce From AAA Extension".
使用基本移动IP规范[1]中定义的其他术语。此外，为了简化讨论，我们在许多情况下使用了“扩展”一词而不是“广义扩展的子类型”。因此，例如，我们将使用短语“来自AAA扩展的MN-FA密钥生成非应答扩展的AAA子类型的MN-FA密钥生成非应答”，而不是使用短语“来自AAA扩展的MN-FA密钥生成非应答”。
When a mobile node depends on an AAA infrastructure to obtain authorization for network connectivity and Mobile IP registration, it may lack any pre-existing Mobility Security Associations with either its home agent, or the foreign agent controlling the access to the foreign network. The extensions defined in this document allow a AAA entity to supply key material to mobile nodes to be used as the basis of its Mobility Security Association with mobile agents. The AAA entity that will act on these extensions is part of the AAA infrastructure, and is typically identified within the foreign domain by methods outside the scope of this specification (see appendix A).
当移动节点依赖AAA基础设施来获得网络连接和移动IP注册的授权时，它可能缺少与其归属代理或控制对外部网络的访问的外部代理的任何预先存在的移动安全关联。本文档中定义的扩展允许AAA实体向移动节点提供关键材料，作为其与移动代理的移动安全关联的基础。将对这些扩展进行操作的AAA实体是AAA基础设施的一部分，通常通过本规范范围外的方法在外部域中进行标识（见附录A）。
The key material may be requested by the mobile node in new extensions (defined below) to Mobile IP Registration Request messages, and supplied to the mobile node in extensions to the Mobile IP Registration Reply messages. Alternatively, the AAA server MAY provide unsolicited key material via mobility agents to mobile nodes; the mobile node MUST then calculate new keys and update or create its relevant Mobility Security Association. The method by which key material is supplied to the mobility agents themselves is out of scope for this document, and would depend on the particular details of the security architecture for the AAA servers in the foreign and home domains (see RFC 2977 and appendix A). For the purposes of this document, we assume that there is a suitable AAA infrastructure available to the home and foreign agents, and that the mobile node does have an AAA Security Association with at least one AAA server in its home domain.
关键材料可由移动节点在移动IP注册请求消息的新扩展（定义如下）中请求，并在移动IP注册回复消息的扩展中提供给移动节点。或者，AAA服务器可以经由移动代理向移动节点提供未经请求的密钥材料；然后，移动节点必须计算新密钥并更新或创建其相关的移动安全关联。向移动代理自身提供关键材料的方法不在本文件范围内，取决于国外和国内域AAA服务器安全体系结构的具体细节（见RFC 2977和附录A）。出于本文档的目的，我们假设有一个适合的AAA基础设施可供本地和外部代理使用，并且移动节点确实与其主域中的至少一个AAA服务器具有AAA安全关联。
When a mobile node travels away from home, it may not have a Mobility Security Association with its home agent, perhaps because it does not yet have a home address [5]. The protocol and messages in this document are intended to facilitate the following operations which may occur between the mobile node, foreign agent, home agent, and AAA servers in the visited (local) domain (Authentication, Authorization and Accounting Local or AAAL) and in the home domain (Authentication, Authorization, and Accounting Home or AAAH). In the following sequence of messages, the only message flows specified in this document are the Registration Request between the mobile node and the foreign agent, and Registration Reply between the foreign agent and the mobile node. The other messages described here result from the presumed action of the AAA entities as described in RFC 2977. See also appendix B.
当移动节点离家旅行时，它可能与其归属代理没有移动安全关联，这可能是因为它还没有归属地址[5]。本文档中的协议和消息旨在促进在访问（本地）域（认证、授权和记帐本地或AAAL）和归属域中的移动节点、外部代理、归属代理和AAA服务器之间可能发生的以下操作（认证、授权和记帐主页或AAAH）。在以下消息序列中，本文档中指定的唯一消息流是移动节点和外部代理之间的注册请求，以及外部代理和移动节点之间的注册回复。此处描述的其他消息来自RFC 2977中描述的AAA实体的假定操作。另见附录B。
1. If the mobile node does not have a Mobility Security Association with the foreign agent, it SHOULD include an MN-FA Key Generation Nonce Request extension (see Section 6.1) as part of its Registration Request that it sends to the Foreign Agent.
1. 如果移动节点不具有与外部代理的移动安全关联，则其应将MN-FA密钥生成Nonce请求扩展（参见第6.1节）作为其发送给外部代理的注册请求的一部分。
2. If the mobile node does not have a Mobility Security Association with the home agent, it MUST add an MN-HA Key Generation Nonce Request extension (see Section 6.3) as part of its Registration Request that it sends to the Foreign Agent.
2. 如果移动节点没有与归属代理的移动安全关联，则必须添加MN-HA密钥生成Nonce请求扩展（参见第6.3节），作为其发送给外部代理的注册请求的一部分。
3. If one or more AAA Key Generation Nonce Request extensions were added, the mobile node MUST add the MN-AAA Authentication extension to its Registration Request.
3. 如果添加了一个或多个AAA密钥生成Nonce请求扩展，则移动节点必须将MN-AAA认证扩展添加到其注册请求中。
4. By action of the foreign agent, which is presumed to be also a AAA entity, the mobile node's key requests and authentication data are transferred to the local AAA server (AAAL), typically after reformatting to fit into the appropriate AAA messages, which are out of scope for this document.
4. 通过假定也是AAA实体的外部代理的动作，移动节点的密钥请求和认证数据被传输到本地AAA服务器（AAAAL），通常在重新格式化以适合合适的AAA消息之后，这些消息不在本文档的范围内。
5. After the information within the MN-AAA Authentication extension is verified by the AAA server in the home domain (AAAH), it then also generates the key material that has been requested by the mobile node, for the necessary Mobility Security Associations.
5. 在归属域（AAAH）中的AAA服务器验证MN-AAA认证扩展中的信息之后，它还生成移动节点请求的密钥材料，用于必要的移动安全关联。
6. The respective keys for the Mobility Security Associations are distributed to the Home Agent and Foreign Agent via the AAA protocol.
6. 移动安全关联的相应密钥通过AAA协议分发给归属代理和外部代理。
7. The mobile node receives the Registration Reply message from the Foreign Agent.
7. 移动节点从外部代理接收注册回复消息。
8. If a MN-HA Key Generation Nonce Request From AAA extension is present in the Registration Request message, then the mobile node MUST create or update its Mobility Security Association with the Home Agent indicated in the corresponding Registration Reply, using the key computed from the key material in the MN-HA Key Generation Nonce From AAA extension. In this case, if no MN-HA Key Generation Nonce Reply extension is present, the mobile node MUST discard the Registration Reply.
8. 如果注册请求消息中存在来自AAA扩展的MN-HA密钥生成Nonce请求，则移动节点必须创建或更新其与相应注册回复中指示的归属代理的移动安全关联，使用从AAA扩展的MN-HA密钥生成Nonce中的密钥材料计算的密钥。在这种情况下，如果不存在MN-HA密钥生成Nonce-Reply扩展，则移动节点必须放弃注册应答。
9. Using its (perhaps newly created) Mobility Security Association with the home agent, the mobile node authenticates the Registration Reply message by checking the Authentication Data in the Mobile-Home Authentication extension. If the check fails, the MN MUST discard the Registration Reply and the new Mobility Security Association, reverting to the old Mobility Security Association with the home agent, if any.
9. 使用其（可能是新创建的）与归属代理的移动安全关联，移动节点通过检查移动归属认证扩展中的认证数据来认证注册回复消息。如果检查失败，MN必须放弃注册回复和新的移动安全关联，恢复到与归属代理的旧移动安全关联（如果有）。
10. If the Registration Reply passes authentication and contains a MN-FA Key Generation Nonce From AAA extension (see section 6.2), the mobile node generates the registration key using the Key Generation Nonce provided, according to its AAA Security Association with the AAA. The resulting registration key is used to establish the mobile node's Mobility Security Association with its foreign agent, and is used to compute the authentication data used in the Mobile-Foreign authentication extension.
10. 如果注册回复通过了身份验证，并且包含来自AAA扩展的MN-FA密钥生成Nonce（参见第6.2节），则移动节点根据其与AAA的AAA安全关联，使用提供的密钥生成Nonce生成注册密钥。生成的注册密钥用于建立移动节点与其外部代理的移动安全关联，并用于计算移动外部认证扩展中使用的认证数据。
If verification of the Mobile-Foreign authentication extension fails, and if the MN-FA Key Generation Nonce Reply extension was not protected by another, valid authentication extension, the MN MUST discard the new Mobility Security Association, reverting to the old Mobility Security Association with the foreign agent, if any.
如果移动外部身份验证扩展验证失败，并且如果MN-FA密钥生成Nonce-Reply扩展未受到另一个有效身份验证扩展的保护，则MN必须放弃新的移动安全关联，恢复到与外部代理的旧移动安全关联（如果有）。
Any registration reply containing the MN-HA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Home Authentication extension, created using the generated MN-HA key. Similarly, a reply containing the MN-FA Key Generation Nonce From AAA extension MUST also contain a subsequent Mobile Foreign Authentication extension, created using the registration key.
任何包含来自AAA扩展的MN-HA密钥生成Nonce的注册回复还必须包含使用生成的MN-HA密钥创建的后续移动家庭身份验证扩展。类似地，包含从AAA扩展生成MN-FA密钥的应答还必须包含使用注册密钥创建的后续移动外部身份验证扩展。
Mobility Security Associations between Mobile IP entities (mobile nodes, home agents, foreign agents) contain both the necessary cryptographic key information and a way to identify the cryptographic transform that uses the key to produce the authentication information that is present in the Mobile-Home Authentication extension or the Mobile-Foreign Authentication extension. In order for the mobile
移动IP实体（移动节点、本地代理、外部代理）之间的移动安全关联包含必要的加密密钥信息和标识加密转换的方法，该加密转换使用密钥生成移动家庭身份验证扩展或移动外部身份验证扩展中存在的身份验证信息。为了手机
node to make use of key material created by the AAA server, the mobile node also has to be able to identify and select the appropriate cryptographic transform that uses the key to produce the authentication.
要使用AAA服务器创建的密钥材料，移动节点还必须能够识别和选择使用密钥生成认证的适当加密转换。
The transform identifiers are the same as those used in IPsec. They are tabulated in the list of Authentication Algorithms allowable as values for the "Attribute Type" (5) (i.e., "Authentication Algorithm"), one of the classifications in the tabulated Attribute Types for "IPsec Security Association Attributes". See http://www.iana.org/assignments/isakmp-registry for the full listing of all Attribute Types and other Attributes for IPsec Security Associations.
转换标识符与IPsec中使用的标识符相同。在“属性类型”（5）（即“身份验证算法”）的允许值的身份验证算法列表中列出了它们，该属性类型是“IPsec安全关联属性”的列表属性类型中的分类之一。看见http://www.iana.org/assignments/isakmp-registry 获取IPsec安全关联的所有属性类型和其他属性的完整列表。
Mobility Security Associations shared between mobile nodes and home agents also require a replay protection method. The following table contains the supported replay detection methods.
移动节点和归属代理之间共享的移动安全关联也需要重播保护方法。下表包含支持的重播检测方法。
Replay Method Name Reference
-------------- ------------ --------------
0,1 Reserved
2 Timestamps RFC 3344 [1]
3 Nonces RFC 3344 [1]
4-65535 Unallocated
Replay Method Name Reference
-------------- ------------ --------------
0,1 Reserved
2 Timestamps RFC 3344 [1]
3 Nonces RFC 3344 [1]
4-65535 Unallocated
This section contains the procedures followed in the creation of the Key Generation Nonce by AAA servers, and the key derivation procedures used by mobile nodes. Note that the AAA servers will also deliver the keys to the mobility agents (home agent, foreign agent) via the AAA protocol. AAA servers that follow these procedures will produce results that can be understood by mobile nodes. The mobility agents will faithfully transcribe the results into the appropriate Mobile IP extensions.
本节包含AAA服务器创建密钥生成Nonce时遵循的过程，以及移动节点使用的密钥派生过程。请注意，AAA服务器还将通过AAA协议将密钥传递给移动代理（本地代理、外部代理）。遵循这些过程的AAA服务器将产生移动节点可以理解的结果。移动代理将忠实地将结果转录到适当的移动IP扩展中。
The following example uses HMAC-SHA1 [6]. All mobile nodes and mobility agents implementing Mobile IP [1] and implementing the extensions specified in this document MUST implement HMAC-SHA1 [1]. Other message authentication codes or keyed hash functions MAY also be used. The particular algorithm used is configured as part of the AAA Security Association between the MN and the AAAH server, which is in turn indexed by the AAA SPI.
以下示例使用HMAC-SHA1[6]。实现移动IP[1]和实现本文档中指定的扩展的所有移动节点和移动代理必须实现HMAC-SHA1[1]。也可使用其它消息认证码或键控散列函数。所使用的特定算法被配置为MN和AAAH服务器之间AAA安全关联的一部分，而AAA SPI又为AAA服务器编制索引。
The following steps are performed on the AAAH server:
在AAAH服务器上执行以下步骤：
1. The AAA server identifies the mobile node. If the NAI field is present in the Registration Request, then the NAI is used as the mobile node identifier. Otherwise, the Home Address field of the Registration Request is used.
1. AAA服务器识别移动节点。如果注册请求中存在NAI字段，则NAI被用作移动节点标识符。否则，将使用注册请求的“家庭地址”字段。
2. The AAA server generates a random [7] value of at least 128 bits to be used as the Key Generation Nonce.
2. AAA服务器生成至少128位的随机[7]值，用作密钥生成Nonce。
3. The AAA server inserts the random value into the Key Generation Nonce Reply extension in the "Key Generation Nonce" field.
3. AAA服务器将随机值插入“密钥生成Nonce”字段中的密钥生成Nonce应答扩展。
The following steps are performed by the mobile node (here || represents concatenation):
以下步骤由移动节点执行（此处| |表示连接）：
1. The mobile node calculates
1. 移动节点计算
key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || mobile node identifier})
key=HMAC-SHA1（AAA密钥，{密钥生成时刻| |移动节点标识符}）
Here the Key Generation Nonce is from the extension in the Registration Reply, and the mobile node identifier is the MN's NAI, if present in the Registration Request, or the Home Address from the Registration Request otherwise.
这里，密钥生成Nonce来自注册应答中的扩展，并且移动节点标识符是MN的NAI（如果存在于注册请求中），或者来自注册请求的归属地址（否则）。
2. The mobile node creates the Mobility Security Association(s), using the resulting key and the other relevant information in the Key Generation Nonce Extension.
2. 移动节点使用得到的密钥和密钥生成Nonce扩展中的其他相关信息创建移动安全关联。
The secret key used within the HMAC-SHA1 computation is indicated by the AAA Security Association indexed by the AAA SPI, which has been previously configured as the basis for the AAA Security Association between the mobile node and the AAA server creating the key material.
HMAC-SHA1计算中使用的密钥由AAA SPI索引的AAA安全关联表示，AAA SPI先前已配置为移动节点和创建密钥材料的AAA服务器之间AAA安全关联的基础。
This section defines new Extensions to Mobile IP Registration Requests and Replies [1].
本节定义了移动IP注册请求和回复的新扩展[1]。
Figure 1 illustrates the Generalized MN-FA Key Generation Nonce Request Extension (MN-FA KeyGen Request for short).
图1说明了广义MN-FA密钥生成Nonce请求扩展（简称MN-FA KeyGen请求）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Request Subtype 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Generalized Mobile IP MN-FA Key Generation Nonce Request Extension
图1：通用移动IP MN-FA密钥生成Nonce请求扩展
Type 40 (not skippable) (see [1] and section 8)
类型40（不可跳过）（参见[1]和第8节）
Subtype A number assigned to identify the way in which the MN-FA Key Generation Nonce Request Subtype Data is to be used when generating the registration key.
子类型指定的编号，用于标识生成注册密钥时MN-FA密钥生成Nonce请求子类型数据的使用方式。
Length The 16-bit Length field indicates the length of the extension. It is equal to the number of bytes in the MN-FA Key Generation Nonce Request Subtype Data plus 4 (for the Mobile Node SPI field).
长度16位长度字段指示扩展的长度。它等于MN-FA密钥生成Nonce请求子类型数据中的字节数加上4（对于移动节点SPI字段）。
Mobile Node SPI The Security Parameters Index that the mobile node will assign for the Mobility Security Association created for use with the registration key.
移动节点SPI移动节点将为与注册密钥一起使用而创建的移动安全关联分配的安全参数索引。
MN-FA Key Generation Nonce Request Subtype Data Data needed to carry out the creation of the registration key on behalf of the mobile node.
MN-FA密钥生成Nonce请求子类型数据需要代表移动节点创建注册密钥。
The MN-FA KeyGen Request defines a set of extensions, identified by subtype, which may be used by a mobile node in a Mobile IP Registration Request message to request that some other entity create a Registration Key for use by the mobile node with the mobile node's new foreign agent.
MN-FA KeyGen请求定义了一组由子类型标识的扩展，移动节点可以在移动IP注册请求消息中使用这些扩展来请求一些其他实体创建注册密钥，以供移动节点与移动节点的新外部代理一起使用。
This document defines the subtype 1 for the MN-FA Key Generation Nonce >From AAA Request (MN-FA AAA KeyGen Request for short). The MN-FA AAA KeyGen Request has a zero-length Subtype Data field and MUST appear in the Registration Request before the MN-AAA Authentication extension.
本文档定义了AAA请求（简称MN-FA AAA密钥生成请求）中MN-FA密钥生成Nonce>的子类型1。MN-FA AAA密钥生成请求具有零长度子类型数据字段，并且必须在MN-AAA身份验证扩展之前出现在注册请求中。
The Generalized MN-FA Key Generation Nonce Reply extension (MN-FA KeyGen Reply for short) supplies keying material requested by the MN-FA KeyGen Request extension. Figure 2 illustrates the format of the Generalized MN-FA Key Generation Nonce Reply Extension.
广义MN-FA密钥生成临时应答扩展（简称MN-FA KeyGen Reply）提供MN-FA KeyGen请求扩展所请求的密钥材料。图2说明了广义MN-FA密钥生成Nonce-Reply扩展的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Reply Subtype 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-FA Key Generation Nonce Reply Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Generalized Mobile IP MN-FA Key Generation Nonce Reply Extension
图2：通用移动IP MN-FA密钥生成临时应答扩展
Type 41 (not skippable) (see [1] and section 8)
类型41（不可跳过）（参见[1]和第8节）
Subtype A number assigned to identify the way in which the MN-FA Key Generation Nonce Reply Subtype Data is to be used to obtain the registration key.
子类型指定的编号，用于标识MN-FA密钥生成Nonce Reply子类型数据用于获取注册密钥的方式。
Length The 16-bit Length field is equal to the number of bytes in the MN-FA Key Generation Nonce Reply Subtype Data.
长度16位长度字段等于MN-FA密钥生成Nonce Reply子类型数据中的字节数。
MN-FA Key Generation Nonce Reply Subtype Data An encoded copy of the keying material, along with any other information needed by the recipient to create the designated Mobility Security Association.
MN-FA密钥生成Nonce Reply子类型数据密钥材料的编码副本，以及接收方创建指定移动安全关联所需的任何其他信息。
For each subtype, the format of the MN-FA Key Generation Nonce Reply Subtype Data has to be separately defined according to the particular method required to set up the Mobility Security Association.
对于每个子类型，必须根据建立移动性安全关联所需的特定方法分别定义MN-FA密钥生成Nonce Reply子类型数据的格式。
For the subtype defined in this document, the MN-FA Key Generation Nonce supplied in the data for a subtype of this extension may come as a result of a request which was sent using a subtype of the Generalized MN-FA Key Generation Nonce Request Extension. In such
对于本文档中定义的子类型，数据中为此扩展的子类型提供的MN-FA密钥生成Nonce可能是使用通用MN-FA密钥生成Nonce请求扩展的子类型发送的请求的结果。这样
cases, the SPI to be used when employing the Mobility Security Association defined by the registration key is the same as given in the original request.
在这些情况下，当采用由注册密钥定义的移动安全关联时要使用的SPI与原始请求中给出的相同。
Once the mobile node creates the Mobility Security Association with the foreign agent, by using the transform indexed by the AAA SPI, it stores that Mobility Security Association indexed by the FA SPI in its list of Mobile Security Associations.
一旦移动节点通过使用AAA-SPI索引的转换创建与外部代理的移动安全关联，它就会将FA-SPI索引的移动安全关联存储在其移动安全关联列表中。
If the foreign agent receives a Registration Reply that has no MN-FA Key Generation Nonce Reply extension, and if it has no existing Mobility Security Association with the mobile node, the foreign agent MAY change the Code value of the Registration Reply to MISSING_MN_FA (see section 7), effectively causing the registration to fail.
如果外部代理接收到没有MN-FA密钥生成临时应答扩展的注册应答，并且如果它与移动节点没有现有的移动安全关联，则外部代理可以将注册应答的代码值更改为MISSING_MN_FA（参见第7节），从而有效地导致注册失败。
This document defines subtype 1 of the MN-FA KeyGen Reply for the MN-FA Key Generation Nonce From AAA extension (MN-FA AAA KeyGen Reply for short), shown in figure 3.
本文档为AAA扩展的MN-FA密钥生成Nonce定义了MN-FA密钥生成应答的子类型1（简称MN-FA AAA密钥生成应答），如图3所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MN-FA Key Generation Nonce From AAA Subtype-Specific Data
图3:AAA子类型特定数据的MN-FA密钥生成Nonce
lifetime This field indicates the duration of time (in seconds) for which the keying material used to create the registration key is valid.
生存期此字段表示用于创建注册密钥的关键帧材质有效的持续时间（秒）。
AAA SPI A 32-bit opaque value, indicating the SPI that the mobile node must use to determine the transform to use for establishing the Mobility Security Association between the mobile node and its prospective foreign agent.
AAA SPI—32位不透明值，指示移动节点必须使用的SPI，以确定用于在移动节点及其预期外部代理之间建立移动性安全关联的转换。
FA SPI The SPI for the Mobility Security Association to the FA that the mobile node creates using the Key Generation Nonce.
FA-SPI移动节点使用密钥生成Nonce创建的FA的移动安全关联的SPI。
Algorithm Identifier This field indicates the transform to be used (stored as part of the Mobility Security Association with the foreign agent, and selected from among the values in the "Authentication Algorithm" table cited in section 4), for future computations of the Mobile-Foreign Authentication Extension.
算法标识符该字段指示用于未来移动外部认证扩展计算的转换（存储为与外部代理的移动安全关联的一部分，并从第4节引用的“认证算法”表中的值中选择）。
Key Generation Nonce A random [7] value of at least 128 bits.
密钥生成时间至少为128位的随机[7]值。
The MN-FA AAA KeyGen Reply extension MUST appear in the Registration Reply before the Mobile-Foreign Authentication extension.
MN-FA AAA KeyGen应答扩展必须出现在移动外部身份验证扩展之前的注册应答中。
The Key Generation Nonce is provided by the AAA server for use by the mobile node in creating the registration key, which is used to secure future Mobile IP registrations with the same foreign agent.
密钥生成Nonce由AAA服务器提供，供移动节点在创建注册密钥时使用，该注册密钥用于保护将来与同一外部代理的移动IP注册。
Figure 4 illustrates the Generalized MN-HA Key Generation Nonce Request Extension (MN-HA KeyGen Request for short).
图4说明了通用的MN-HA密钥生成Nonce请求扩展（简称MN-HA密钥生成请求）。
Type 42 (not skippable) (see [1] and section 8)
类型42（不可跳过）（参见[1]和第8节）
Subtype a number assigned to identify the way in which the MN-HA Key Generation Nonce Request Subtype Data is to be used when generating the registration key.
子类型指定的编号，用于标识生成注册密钥时MN-HA密钥生成Nonce请求子类型数据的使用方式。
Length The 16-bit Length field indicates the length of the extension. It is equal to the number of bytes in the MN-HA Key Generation Nonce Request.
长度16位长度字段指示扩展的长度。它等于MN-HA密钥生成Nonce请求中的字节数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Request Subtype 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Request Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Generalized Mobile IP MN-HA Key Generation Nonce Request Extension
图4：通用移动IP MN-HA密钥生成Nonce请求扩展
Subtype Data plus 4 (for the Mobile Node SPI field).
子类型数据加上4（用于移动节点SPI字段）。
Mobile Node SPI The Security Parameters Index that the mobile node will assign for the Mobility Security Association created for use with the registration key.
移动节点SPI移动节点将为与注册密钥一起使用而创建的移动安全关联分配的安全参数索引。
MN-HA Key Generation Nonce Request Subtype Data Data needed to carry out the creation of the MN-HA key on behalf of the mobile node.
代表移动节点创建MN-HA密钥所需的MN-HA密钥生成Nonce请求子类型数据。
The MN-HA KeyGen Request Extension defines a set of extensions, identified by subtype, which may be used by a mobile node in a Mobile IP Registration Request message to request that some other entity create an MN-HA key for use by the mobile node with the mobile node's new home agent.
MN-HA KeyGen请求扩展定义了一组由子类型标识的扩展，移动节点可以在移动IP注册请求消息中使用这些扩展来请求一些其他实体创建MN-HA密钥，以供移动节点与移动节点的新归属代理一起使用。
This document defines the subtype 1 for the MN-HA Key Generation Nonce from AAA Request (MN-HA AAA KeyGen Request for short). The MN-HA AAA KeyGen Request has a zero-length Subtype Data field and MUST appear in the Registration Request before the MN-AAA Authentication extension.
本文档定义了AAA请求中MN-HA密钥生成Nonce的子类型1（简称MN-HA AAA密钥生成请求）。MN-HA AAA密钥生成请求具有零长度子类型数据字段，并且必须在MN-AAA身份验证扩展之前出现在注册请求中。
The Generalized MN-HA Key Generation Nonce Reply extension (MN-HA KeyGen Reply for short) supplies keying material requested by the MN-HA KeyGen Request extension. Figure 5 illustrates the format of the Generalized MN-HA Key Generation Nonce Reply Extension.
广义MN-HA密钥生成Nonce-Reply扩展（简称MN-HA KeyGen-Reply）提供MN-HA KeyGen请求扩展请求的密钥材料。图5说明了通用MN-HA密钥生成Nonce-Reply扩展的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Reply Subtype 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-HA Key Generation Nonce Reply Subtype Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Generalized Mobile IP MN-HA Key Generation Nonce Reply Extension
图5：通用移动IP MN-HA密钥生成临时应答扩展
Type 43 (not skippable) (see [1] and section 8)
类型43（不可跳过）（参见[1]和第8节）
Subtype a number assigned to identify the way in which the MN-HA Key Generation Nonce Reply Subtype Data is to be used to obtain the MN-HA key.
子类型指定的编号，用于标识MN-HA密钥生成非应答子类型数据用于获取MN-HA密钥的方式。
Length The 16-bit Length field indicates the length of the extension. It is equal to the number of bytes in the MN-HA Key Generation Nonce Reply Subtype Data plus 4 (for the Lifetime field).
长度16位长度字段指示扩展的长度。它等于MN-HA密钥生成Nonce Reply子类型数据中的字节数加上4（对于生存期字段）。
Lifetime This field indicates the duration of time (in seconds) for which the MN-HA key is valid.
生存期此字段指示MN-HA密钥有效的持续时间（秒）。
MN-HA Key Generation Nonce Reply Subtype Data Data used to derive the MN-HA key, along with any other information needed by the mobile node to create the designated Mobility Security Association with the home agent.
MN-HA密钥生成Nonce应答子类型数据，用于导出MN-HA密钥，以及移动节点创建与归属代理的指定移动安全关联所需的任何其他信息。
For each subtype, the format of the MN-HA Key Generation Nonce Reply Subtype Data has to be separately defined according to the particular method required to set up the Mobility Security Association.
对于每个子类型，必须根据建立移动性安全关联所需的特定方法分别定义MN-HA密钥生成Nonce Reply子类型数据的格式。
This document defines subtype 1 of the MN-HA KeyGen Reply for the MN-HA Key Generation Nonce From AAA extension (MN-HA AAA KeyGen Reply for short), shown in figure 6.
本文档为AAA扩展的MN-HA密钥生成Nonce定义了MN-HA密钥生成应答的子类型1（简称MN-HA AAA密钥生成应答），如图6所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Replay Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Replay Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The MN-HA Key Generation Nonce From AAA Subtype-Specific Data
图6:AAA子类型特定数据的MN-HA密钥生成Nonce
AAA SPI A 32-bit opaque value, indicating the SPI that the mobile node must use to determine the transform to use for establishing the Mobility Security Association between the mobile node and its home agent.
AAA SPI—32位不透明值，指示移动节点必须使用的SPI，以确定用于在移动节点及其归属代理之间建立移动性安全关联的转换。
HA SPI The SPI for the Mobility Security Association to the HA that the mobile node creates using the Key Generation Nonce.
HA SPI移动节点使用密钥生成Nonce创建的移动安全关联到HA的SPI。
Algorithm Identifier This field indicates the transform to be used for future computations of the Mobile-Home Authentication Extension (see section 4).
算法标识符此字段指示用于移动家庭认证扩展的未来计算的转换（参见第4节）。
Replay Method This field contains the replay method to be used for future Registration messages (see section 4).
Replay Method此字段包含用于将来注册消息的Replay方法（请参阅第4节）。
Key Generation Nonce A random [7] value of at least 128 bits.
密钥生成时间至少为128位的随机[7]值。
The MN-HA AAA KeyGen Reply subtype-specific data is shown in figure 6. The Mobile Node calculates the MN-HA key using the Key Generation Nonce provided by the AAA server. The calculation proceeds by using the key shared between the mobile node and the AAA server that has previously been configured for securing all such communication requirements with the AAA server which will be contacted within the AAA infrastructure (see appendix A). The MN-HA key is intended for use by the mobile node to secure future Mobile IP registrations with its home agent. The MN-HA AAA KeyGen Reply extension MUST appear in the Registration Reply before the MN-HA Authentication extension.
MN-HA AAA密钥应答子类型特定数据如图6所示。移动节点使用AAA服务器提供的密钥生成Nonce计算MN-HA密钥。通过使用移动节点和AAA服务器之间共享的密钥进行计算，该密钥先前已被配置用于保护AAA服务器的所有此类通信需求，AAA服务器将在AAA基础设施内联系（参见附录A）。MN-HA密钥旨在由移动节点使用，以确保将来向其归属代理注册移动IP。MN-HA AAA密钥生成应答扩展必须出现在MN-HA身份验证扩展之前的注册应答中。
Once the mobile node creates the MN-HA Key, by using the transform specified in the AAA SPI, it stores the HA Security Information indexed by the HA SPI in its list of Mobile Security Associations. The mobile node uses the Identification field data from the Registration Reply as its initial synchronization data with the home agent.
一旦移动节点通过使用AAA SPI中指定的转换创建MN-HA密钥，它将HA SPI索引的HA安全信息存储在其移动安全关联列表中。移动节点使用来自注册应答的标识字段数据作为其与归属代理的初始同步数据。
Each entry in the following table contains the name of the Code [1] value to be returned in a Registration Reply, the value for that Code, and the section in which the error is first mentioned in this specification.
下表中的每个条目都包含注册回复中要返回的代码[1]值的名称、该代码的值以及本规范中首次提到错误的部分。
Error Name Value Section
---------------------- ----- ---------
MISSING_MN_FA 107 6.2
Error Name Value Section
---------------------- ----- ---------
MISSING_MN_FA 107 6.2
This document defines 4 new extensions (see Section 6) taken from the (non-skippable) numbering space defined for Mobile IP registration extensions defined in RFC 3344 [1] as extended in RFC 2356 [8]. The values for these extensions are:
本文件定义了4个新的扩展名（见第6节），这些扩展名取自RFC 3344[1]中定义的移动IP注册扩展名的（不可跳过的）编号空间，并在RFC 2356[8]中进行了扩展。这些扩展的值为：
Name Value Section
--------------------- ------- ---------
MN-FA-KeyGen Request 40 6.1
MN-FA-KeyGen Reply 41 6.2
MN-HA-KeyGen Request 42 6.3
MN-HA-KeyGen Reply 43 6.4
Name Value Section
--------------------- ------- ---------
MN-FA-KeyGen Request 40 6.1
MN-FA-KeyGen Reply 41 6.2
MN-HA-KeyGen Request 42 6.3
MN-HA-KeyGen Reply 43 6.4
IANA has created and will maintain a new registry for the KeyGen Request/Reply subtypes. The initial contents of the registry is a single entry for the subtypes defined in this document:
IANA已创建并将维护KeyGen请求/应答子类型的新注册表。注册表的初始内容是本文档中定义的子类型的单个条目：
Name Value Section
----------------------------- ------- ---------
KeyGen Request/Reply from AAA 1 6
Name Value Section
----------------------------- ------- ---------
KeyGen Request/Reply from AAA 1 6
New subtypes for these two registries are assigned through Standards Action as defined in [9].
这两个注册中心的新子类型通过[9]中定义的标准操作分配。
IANA has assigned a code value for error MISSING_MN_FA, listed in section 7. This value has been taken from the space of error values conventionally associated with rejection by the foreign agent (i.e., 64-127).
IANA已为第7节中列出的错误缺失指定了代码值。该值取自通常与外国代理拒绝相关的错误值空间（即64-127）。
IANA has created and will maintain a namespace for the Replay Method Identifier. This specification makes use of 2 and 3; all other values other than zero (0) and (1) are available for assignment, pending review and approval by a Designated Expert [9].
IANA已创建并将维护Replay方法标识符的命名空间。本规范使用2和3；除零（0）和（1）之外的所有其他值均可分配，有待指定专家审查和批准[9]。
The extensions in this document are intended to provide the appropriate level of security for Mobile IP entities (mobile node, foreign agent, and home agent) to calculate the Authentication Data needed by authentication extensions used with Mobile IP registration messages. The Mobility Security Associations resulting from use of these extensions do not offer any higher level of security than what is already implicit in use of the AAA Security Association between the mobile node and the AAAH. In order to deny any adversary the luxury of unbounded time to analyze and break the secrecy of the AAA Security Association between the mobile node and the AAA server, that AAA Security Association MUST be refreshed periodically.
本文档中的扩展旨在为移动IP实体（移动节点、外部代理和归属代理）提供适当级别的安全性，以计算与移动IP注册消息一起使用的认证扩展所需的认证数据。使用这些扩展产生的移动安全关联不提供比在移动节点和AAAH之间使用AAA安全关联已经隐含的更高级别的安全性。为了不让任何对手浪费无限的时间来分析和破坏移动节点和AAA服务器之间AAA安全关联的机密性，必须定期刷新AAA安全关联。
The provisioning and refreshing of the AAA key in the MN and AAA server is outside the scope of this document.
MN和AAA服务器中AAA密钥的设置和刷新超出了本文档的范围。
Since the Reply extensions defined in this specification only carry Key Generation Nonces, which are used to derive keys, they do not expose any data that could be used in an attack aimed at recovering
由于本规范中定义的应答扩展只携带用于派生密钥的密钥生成nonce，因此它们不公开任何可用于旨在恢复的攻击的数据
the key shared between the mobile node and the AAA. The authors do not believe this specification introduces any new security vulnerability.
移动节点和AAA之间共享的密钥。作者不认为该规范引入了任何新的安全漏洞。
Thanks to Fredrik Johansson, Tom Hiller, and the members of the IESG for their useful comments. Thanks especially to Tom Hiller who has contributed many textual improvements to later revisions of this document.
感谢Fredrik Johansson、Tom Hiller和IESG成员的有用评论。特别感谢Tom Hiller，他为本文档的后续修订做出了许多文本改进。
[1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[1] Perkins，C.，编辑，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[2] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[3] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extension", RFC 3012, November 2000.
[3] Perkins，C.和P.Calhoun，“移动IPv4挑战/响应扩展”，RFC3012，2000年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[5] Calhoun，P.和C.Perkins，“IPv4移动IP网络访问标识符扩展”，RFC 27942000年3月。
[6] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[6] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[7] Eastlake，D.，Crocker，S.，和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[8] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[8] 黑山，G.和V.Gupta，“Sun的移动IP跳过防火墙穿越”，RFC 2356，1998年6月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[9] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[10] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
[10] Mitton，D.，St.Johns，M.，Barkley，S.，Nelson，D.，Patil，B.，Stevens，M.，和B.Wolff，“认证，授权和会计：协议评估”，RFC 3127，2001年6月。
[11] Rigney, C., Willens, S., Rubens, A., and A. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[11] Rigney，C.，Willens，S.，Rubens，A.，和A.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[12] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[13] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[13] Glass，S.，Hiller，T.，Jacobs，S.，和C.Perkins，“移动IP认证，授权和记帐要求”，RFC 29772000年10月。
[14] Calhoun, P. and C. Perkins, "DIAMETER mobile IP extensions", Work in Progress, February 2004.
[14] Calhoun，P.和C.Perkins，“DIAMETER移动IP扩展”，正在进行的工作，2004年2月。
In this appendix, we attempt to capture the main features of a basic model for operation of AAA servers that is assumed for understanding of the use of the Mobile IP registration extensions described in this document. This information has been adapted from the discussion in RFC 2977 [13].
在本附录中，我们试图捕捉AAA服务器运行基本模型的主要特征，该模型是为了理解本文档中描述的移动IP注册扩展的使用而假设的。该信息根据RFC 2977[13]中的讨论进行了改编。
Within the Internet, a mobile node belonging to one administrative domain (called the home domain) often needs to use resources provided by another administrative domain (called the foreign domain). A foreign agent that handles the mobile node's Registration Request is likely to require that the mobile node provide some credentials that can be authenticated before access to the resources is permitted. These credentials may be provided as part of the Mobile-AAA Authentication extension [3], relying on the existence of an AAA infrastructure such as is described in this section, and also described in RFC 2977 and RFC 3012 [3]. Such credentials are typically managed by entities within the mobile node's home domain. They may be also used for setting up secure communications with the mobile node and the foreign agent, or between the mobile node and its home agent if necessary.
在因特网中，属于一个管理域（称为归属域）的移动节点通常需要使用另一个管理域（称为外域）提供的资源。处理移动节点的注册请求的外部代理可能会要求移动节点提供一些可以在允许访问资源之前进行身份验证的凭据。这些凭证可以作为移动AAA认证扩展[3]的一部分提供，这取决于AAA基础设施的存在，如本节所述，以及RFC 2977和RFC 3012[3]中所述。此类凭证通常由移动节点的主域内的实体管理。它们还可用于建立与移动节点和外部代理的安全通信，或在必要时在移动节点及其归属代理之间的安全通信。
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | MN = mobile node
| MN |- -|- -| FA | | FA = foreign agent
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | MN = mobile node
| MN |- -|- -| FA | | FA = foreign agent
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+
Figure 7: AAA Servers in Home and Local Domains
图7：家庭域和本地域中的AAA服务器
The foreign agent often does not have direct access to the data needed to verify the credentials. Instead, the foreign agent is expected to consult an authority (typically in the same foreign domain) in order to request proof that the mobile node has acceptable credentials. Since the foreign agent and the local authority (AAAL) are part of the same administrative domain, they are expected to have
外部代理通常无法直接访问验证凭据所需的数据。相反，期望外部代理咨询权威机构（通常在相同的外部域中），以请求证明移动节点具有可接受的凭据。由于外国代理人和地方当局（AAAL）是同一行政领域的一部分，因此他们应
established, or be able to establish for the necessary lifetime, a secure channel for the purposes of exchanging sensitive (access) information, and keeping it private from (at least) the visiting mobile node.
建立或能够在必要的生命周期内建立一个安全通道，用于交换敏感（访问）信息，并使其对（至少）访问的移动节点保持私有。
The local authority (AAAL) itself may not have enough information stored locally to carry out the verification for the credentials of the mobile node. In contrast to the foreign agent, however, the AAAL is expected to be configured with enough information to negotiate the verification of mobile node credentials with its home domain. The home and foreign domains should be configured with sufficient IP Security Associations (i.e., IPsec) and access controls so that they can negotiate the authorization, and also enable the mobile node to acquire Mobility Security Associations with the mobility agents within the foreign domain. For the purposes of the key exchanges specified within this document, the authorization is expected to depend only upon secure authentication of the mobile node's credentials.
本地机构（AAAL）本身可能没有足够的本地存储信息来执行移动节点凭据的验证。然而，与外部代理不同，AAAL需要配置足够的信息，以便与其主域协商移动节点凭据的验证。主域和外域应配置足够的IP安全关联（即IPsec）和访问控制，以便它们可以协商授权，并且还使移动节点能够获得与外域内的移动代理的移动安全关联。对于本文档中指定的密钥交换，授权预期仅取决于移动节点凭据的安全认证。
Once the authorization has been obtained by the local authority, and the authority has notified the foreign agent about the successful negotiation, the foreign agent can deliver the Registration Reply to the mobile node along with the key material.
一旦本地管理局获得授权，并且管理局已将协商成功通知外部代理，外部代理可以将注册回复连同密钥材料一起发送给移动节点。
In figure 7, there might be many mobile nodes from many different Home Domains. Each Home Domain provides a AAAH that can check credentials originating from mobile nodes administered by that Home Domain. There is a security model implicit in figure 7, and it is crucial to identify the specific security associations assumed in the security model. These IP Security Associations are illustrated in figure 8, and are considered to be relatively long-lived security associations.
在图7中，可能有许多来自许多不同家庭域的移动节点。每个主域提供一个AAAH，该AAAH可以检查来自该主域管理的移动节点的凭据。图7中隐含了一个安全模型，确定安全模型中假定的特定安全关联是至关重要的。这些IP安全关联如图8所示，被认为是相对长寿命的安全关联。
First, it is natural to assume that the mobile node has an AAA Security Association with the AAAH, since that is roughly what it means for the mobile node to belong to the home domain.
首先，假设移动节点与AAAH具有AAA安全关联是很自然的，因为这大致就是移动节点属于归属域的意思。
Second, from the model illustrated in figure 7 it is clear that AAAL and AAAH have to share an IP Security Association, because otherwise they could not rely on the authentication results, authorizations, nor even the accounting data which might be transacted between them. Requiring such bilateral IP Security Associations is, however, in the end not scalable; the AAA framework must provide for more scalable mechanisms, but the methods by which such a broker model is to be created are out of scope for this document. See RFC 2977 for more details.
其次，从图7所示的模型可以清楚地看出，AAAL和AAAH必须共享一个IP安全关联，因为否则它们就不能依赖身份验证结果、授权，甚至不能依赖可能在它们之间进行交易的记帐数据。然而，要求这种双边IP安全关联最终是不可扩展的；AAA框架必须提供更具可伸缩性的机制，但创建此类代理模型的方法不在本文档的范围之内。详见RFC 2977。
Finally, from figure 7, it is clear that the foreign agent can naturally share an IP Security Association with the AAAL. This is necessary in order for the model to work because the foreign agent has to have a way to find out that it is permissible to allocate the local resources to the mobile node, and further to transmit any successful Registration Reply to the mobile node.
最后，从图7可以看出，外部代理可以自然地与AAAL共享IP安全关联。为了使模型工作，这是必要的，因为外部代理必须有一种方法来确定允许将本地资源分配给移动节点，并进一步将任何成功的注册回复发送给移动节点。
Figure 8 illustrates the IP Security Associations we understand from our proposed model. Note that there may be, by mutual agreement between AAAL and AAAH, a third party inserted between AAAL and AAAH to help them arbitrate secure transactions in a more scalable fashion. The broker model which has been designed to enable such third-party processing should not have any effect on the Mobile IP extensions specified in this document, and so no description is provided here; see RFC 2977 [13] for more details.
图8说明了我们从提议的模型中了解到的IP安全关联。请注意，通过AAAL和AAAH之间的相互协议，AAAL和AAAH之间可能会插入第三方，以帮助他们以更可扩展的方式仲裁安全交易。为实现此类第三方处理而设计的代理模型不应对本文档中指定的移动IP扩展产生任何影响，因此此处不提供任何说明；详见RFC 2977[13]。
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
MN = mobile node | | | |
FA = foreign agent | FA | | MN |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
MN = mobile node | | | |
FA = foreign agent | FA | | MN |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+
Figure 8: IP Security Associations
图8：IP安全关联
Nodes in two separate administrative domains (for instance, AAAH and AAAL) often must take additional steps to verify the identity of their communication partners, or alternatively to guarantee the privacy of the data making up the communication. While these considerations lead to important security requirements, as mentioned above in the context of security between servers, we consider the exact choice of IP Security Associations between the AAA servers to be beyond the scope of this document. The choices are unlikely to depend upon Mobile IP, or any specific features of the general model illustrated in figure 7. On the other hand, the Mobility Security Associations needed between Mobile IP entities are of central importance in the design of the key derivation extensions in this document.
两个独立管理域（例如，AAAH和AAAL）中的节点通常必须采取额外的步骤来验证其通信伙伴的身份，或者保证构成通信的数据的隐私。虽然这些考虑导致了重要的安全性要求，如上所述，在服务器之间的安全上下文中，我们考虑AAA服务器之间的IP安全关联的精确选择超出本文档的范围。这些选择不太可能取决于移动IP或图7所示的通用模型的任何特定功能。另一方面，移动IP实体之间所需的移动安全关联在本文中密钥派生扩展的设计中至关重要。
One further detail deserves mention. The Mobility Security Association to be established between the mobile node and the foreign agent has to be communicated to the foreign agent as well as to the mobile node. The following requirements are placed on the mechanism used by the AAA infrastructure to effect key distribution:
还有一个细节值得一提。要在移动节点和外部代理之间建立的移动安全关联必须与外部代理以及移动节点通信。AAA基础设施用于实现密钥分发的机制有以下要求：
- The AAAH must establish strong, fresh session keys.
- AAAH必须建立强大、新的会话密钥。
- The mechanism must maintain algorithm independence, allowing for the distribution of authentication algorithm identification along with the keys.
- 该机制必须保持算法独立性，允许身份验证算法标识与密钥一起分发。
- The mechanism must include replay detection.
- 该机制必须包括重播检测。
- The mechanism must authenticate all parties, including the AAA servers and the FA and HA.
- 该机制必须对所有各方进行身份验证，包括AAA服务器以及FA和HA。
- The mechanism must provide for authorization of the client, FA, and HA.
- 该机制必须提供客户、FA和HA的授权。
- The mechanism must not rely on plaintext passwords.
- 该机制不得依赖明文密码。
- The mechanism must maintain confidentiality of session keys.
- 该机制必须保持会话密钥的机密性。
- The mechanism must uniquely name session keys.
- 该机制必须唯一地命名会话密钥。
- The mechanism must be such that the compromise of a single FA and HA cannot compromise any other part of the system, including session keys and long-term keys
- 该机制必须确保单个FA和HA的折衷不会影响系统的任何其他部分，包括会话密钥和长期密钥
- The mechanism must bind key(s) to an appropriate context
- 该机制必须将密钥绑定到适当的上下文
- The mechanism must not expose the keys to entities other than the AAAH and FA (or HA in the case of key distribution to the HA).
- 该机制不得将密钥公开给AAAH和FA以外的实体（或者在密钥分发给HA的情况下为HA）。
The way that the key is distributed to the foreign agent (or home agent) is expected to be handled as part of the AAA protocol processing between the AAAH and AAAL, and the further AAA protocol processing between the AAAL and the foreign agent. Such processing is outside the scope of this document, but must satisfy the above requirements.
将密钥分发给外部代理（或归属代理）的方式预计将作为AAAH和AAAL之间的AAA协议处理以及AAAL和外部代理之间的进一步AAA协议处理的一部分来处理。此类处理不在本文件范围内，但必须满足上述要求。
In this section, we show message flows for requesting and receiving a registration key from the AAA infrastructure, described in section A. Challenge values, as specified in [3], might be added to the Advertisement and Registration messages for additional replay protection, but are not illustrated here.
在本节中，我们展示了用于从AAA基础设施请求和接收注册密钥的消息流，如第a节所述。如[3]中所述，可以将质询值添加到播发和注册消息中，以获得额外的重播保护，但此处未说明。
Diagram 9 illustrates the message flow for the case when the mobile node explicitly requests keying material to create registration keys.
图9说明了当移动节点明确请求密钥材料以创建注册密钥时的消息流。
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
|-- RReq+AAA Key Req.-->| |
| |--- RReq + AAA Key Req.--->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
|-- RReq+AAA Key Req.-->| |
| |--- RReq + AAA Key Req.--->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 9: Message Flows for Requesting and Receiving Key Generation Nonce
图9：请求和接收密钥生成Nonce的消息流
In diagram 9, the following message flow is illustrated:
在图9中，说明了以下消息流：
1. The foreign agent disseminates an Agent Advertisement. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram).
1. 外国代理商发布代理商广告。该广告可能是在从移动节点（图中未示出）接收到代理请求之后产生的。
2. The mobile node creates a Registration Request including the MN-HA AAA KeyGen Request and/or MN-FA AAA KeyGen Request, as needed, along with an authorization-enabling authentication extension as required by Mobile IP [1].
2. 移动节点根据需要创建一个注册请求，包括MN-HA AAA密钥根请求和/或MN-FA AAA密钥根请求，以及移动IP所需的授权授权认证扩展[1]。
3. The foreign agent relays the Registration Request and/or Key Request(s) to its locally configured AAA Infrastructure (see appendix A), according to local policy.
3. 根据当地政策，外国代理将注册请求和/或密钥请求转发至其本地配置的AAA基础设施（见附录A）。
4. The foreign agent receives a AAA Response with the appropriate indications for authorizing connectivity for the mobile node. Along with this AAA Response, the foreign agent may also receive key material by some secure method appropriate for communications between it and its local AAA infrastructure. At this point if the
4. 外部代理接收具有用于授权移动节点的连接的适当指示的AAA响应。除了此AAA响应外，外国代理还可以通过某种适合于其与其本地AAA基础设施之间通信的安全方法接收关键材料。此时，如果
foreign agent has not relayed the Registration Request, it forwards it directly to the Home Agent and waits for a Registration Reply (not shown in the figure).
外部代理尚未转发注册请求，它将其直接转发给本地代理，并等待注册回复（图中未显示）。
5. The foreign agent relays the Registration Reply to the mobile node, along with the new AAA KeyGen Reply extensions to be used by the mobile node to establish Mobility Security Associations with the relevant mobility agents (foreign agent and/or home agent).
5. 外部代理将注册应答转发给移动节点，以及移动节点将使用的新AAA密钥根应答扩展来建立与相关移动代理（外部代理和/或归属代理）的移动安全关联。
Diagram 10 illustrates the message flow for the case when the mobile node receives unsolicited keying material from the AAA Infrastructure.
图10示出了当移动节点从AAA基础设施接收到未经请求的密钥材料时的消息流。
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
| ------ RReq --------->| |
| |------- RReq ------------->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
MN FA AAA Infrastructure
| | |
|<--- Advertisement-----| |
| (if needed) | |
| | |
| ------ RReq --------->| |
| |------- RReq ------------->|
| | |
| |<--- RRep + AAA Key Rep.---|
|<-- RRep+AAA Key Rep.--| |
| | |
Figure 10: Message Flow for Receiving Unsolicited Key Generation Nonce
图10：用于接收未经请求的密钥生成Nonce的消息流
In diagram 10, the following message flow is illustrated:
在图10中，说明了以下消息流：
1. The foreign agent disseminates an Agent Advertisement. This advertisement MAY have been produced after receiving an Agent Solicitation from the mobile node (not shown in the diagram).
1. 外国代理商发布代理商广告。该广告可能是在从移动节点（图中未示出）接收到代理请求之后产生的。
2. The mobile node creates a Registration Request including an authorization-enabling authentication extension as required by Mobile IP [1].
2. 移动节点创建注册请求，该注册请求包括根据移动IP[1]的要求启用认证扩展的授权。
3. The foreign agent sends a AAA Request (possibly containing the Registration Request) to its locally configured AAA Infrastructure (see appendix A), according to local policy.
3. 根据本地政策，外部代理将AAA请求（可能包含注册请求）发送到其本地配置的AAA基础设施（见附录a）。
4. The foreign agent receives a AAA Response with the appropriate indications for authorizing connectivity for the mobile node. Along with this AAA Response, the foreign agent may also receive key material by some secure method appropriate for communications between it and its local AAA infrastructure. At this point, if the foreign agent has not relayed the Registration Request, it
4. 外部代理接收具有用于授权移动节点的连接的适当指示的AAA响应。除了此AAA响应外，外国代理还可以通过某种适合于其与其本地AAA基础设施之间通信的安全方法接收关键材料。此时，如果外国代理未转发注册请求，则
forwards it directly to the Home Agent and waits for a Registration Reply (not shown in the figure).
将其直接转发给归属代理并等待注册回复（图中未显示）。
5. The foreign agent relays the Registration Reply to the mobile node, along with the new KeyGen Reply extensions to be used by the mobile node to establish Mobility Security Associations with the relevant mobility agents (foreign agent and/or home agent).
5. 外部代理将注册应答转发给移动节点，以及移动节点用于建立与相关移动代理（外部代理和/或归属代理）的移动安全关联的新的KeyGen应答扩展。
Authors' Addresses
作者地址
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
查尔斯·E·珀金斯诺基亚研究中心美国加利福尼亚州山景镇飞兆半导体大道313号，邮编94043
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Phone: +1 650 625-2986
Fax: +1 650 625-2502
EMail: charles.perkins@nokia.com
Pat R. Calhoun Airespace, Inc. 110 Nortech Parkway San Jose, CA 95134 USA
Pat R.Calhoun Airespace，Inc.美国加利福尼亚州圣何塞诺特公园路110号，邮编95134
Phone: +1 408 635 2000
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.com
Phone: +1 408 635 2000
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。