Network Working Group M. Nakhjiri
Internet-Draft Huawei USA
Expires: April 16, 2007 C. Wan, Ed.
Huawei Technologies
October 13, 2006
Specification for use of EAP EMSK in deriving Mobile IP root keys
draft-nakhjiri-eap-mip-usrk-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
[USRK] proposes a new mechanism for deriving cryptographically
separate usage specific root keys (USRK) from the EAP extended master
session key (EMSK). This document follows the procedure suggested in
[USRK] to derive root keys for Mobile IPv4, Mobile IPv6, and proxy
Mobile IP.
Nakhjiri & Wan Expires April 16, 2007 [Page 1]
Internet-Draft MIP root key October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Key Distribution function (KDF) . . . . . . . . . . . . . . . 7
4. Mobile IPv6 USRK derivation . . . . . . . . . . . . . . . . . 9
5. Mobile IPv4 USRK derivation . . . . . . . . . . . . . . . . . 12
6. security considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Nakhjiri & Wan Expires April 16, 2007 [Page 2]
Internet-Draft MIP root key October 2006
1. Introduction
Many network protocols require keys for supporting various security
mechanisms associated with these protocols. With the growing number
of users and devices, manual configuration of such keys is no longer
feasible due to system scalability and cost requirements set for
networks today. This calls for dynamic key management mechanisms for
most of these protocols so that the administrative burden of
configuring devices with the required keys is reduced. However, with
the increasing number of protocols needing short term keys and
employing dynamic key management, both the implementation burden of
deploying various key management mechanisms and the amount of real
time spent executing these mechanisms during a power up are becoming
issues.
Extensible authentication protocol authentication [RFC3748] and key
management framework [EAPkeying] provide a powerful tool for key
management by authenticating an end client to a central AAA/ EAP
server and establishing a master session key (MSK) and an extended
master session key (EMSK).
However, EAP documentations [RFC3748] and [EAPkeying] do not provide
any specification for use of EMSK. There has been several proposals
within and outside IETF to use EMSK to arrive at the so called
application master session keys (AMSK) for various applications or
later called as usage specific root keys (USRK) [USRK]. There has
been a growing tendency to use EMSK resulting from the EAP exchange
to derive keys for other network protocols and thereby reduce the
need for multiple key management mechanisms. Different
specifications have been using arbitrary key derivation functions
(KDF), arbitrary KDF inputs, and arbitrary key labels, legitimizing
the following imminent concerns:
1) At no circumstance should the compromise of an USRK for an
application lead to the compromise of the parent EMSK, since this
would lead to jeopardizing all other applications. This is called
cryptographic separation of EMSK from the child-USRKs for all the
application that have used that EMSK. This means a strong key
derivation function should be used. For instance deriving an EMSK
from a known USRK should be as complex as reversing a hash function.
2) Deriving USRK-1 for usage 1 (application 1) from an EMSK, should
not jeopardize the integrity of keys for other usages that have used
the same EMSK to derive their USRKs. This would not only mean strong
KDF functions should be used, but also that different derivations
using the same EMSK do not arrive at the same USRKs. Therefore, to
assure cryptographic separation between different USRKs and to reduce
the over all key management implementation burden in a system, it is
Nakhjiri & Wan Expires April 16, 2007 [Page 3]
Internet-Draft MIP root key October 2006
desired that all the usages within the system use the same default
KDF. Furthermore, since a KDF always produces the same output for
the same input, various usages need to follow a standardized
procedure in using the KDF.
[USRK] is the latest attempt towards specific keys for various usages
in a coordinated manner to address the aforementioned concerns. This
draft discusses the use of procedures in [USRK] to specify USRK
derivations for both Mobile IPv4 and Mobile IPv6 security needs.
Note that the draft may not go into the details of using the USRK in
deriving all the keys within the Mobile IPv4 and Mobile IPv6 key
hierarchy.
Nakhjiri & Wan Expires April 16, 2007 [Page 4]
Internet-Draft MIP root key October 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The following terms are taken from [RFC3748]: EAP Server, peer,
authenticator, Extended Master Session Key (EMSK).
HA
Home agent. It is defeined in Mobile IPv4 [RFC3344] and Mobile IPv6
[RFC3775] specifications.
FA
Foreign Agent, It is defined in Mobile IPv4 [RFC3344] specification.
MSA
Mobility Service Authorizer. It is defined in mip6 bootstrapping
problem statement [RFC4640] specification.
MSP
Mobility Service Provider. It is defined in mip6 bootstrapping
problem statement [RFC4640] specification.
USRK
Usage specific root key. It is keying material derived from the EMSK
for a particular usage definition. It is used to derive child keys
in a way defined by its usage definition.
MIP4_USRK
MIP4_USRK is the root key for mip4 protocol usages. It is derived
from the EMSK, while other child keys for mip4 usage are derived from
MIP4_USRK.
MIP6_USRK
MIP6_USRK is the root key for mip6 protocol usages. It is derived
from the EMSK , while other child keys for mip6 usage are derived
from MIP6_USRK.
KDF
Nakhjiri & Wan Expires April 16, 2007 [Page 5]
Internet-Draft MIP root key October 2006
KDF is the abbreviation of key derivation function. The USRK key
derivation function (KDF) derives an USRK from the Extended Master
Session Key (EMSK) . The USRK KDF is expected to give the same
output for the same input.
PRF/PRF+
Pseudo random function. PRF and PRF+ are defined in [RFC4306].
MIP6_MN_HA_key
MIP6_MN_HA_key is used for protecting Mobile IPv6 signaling between
MN and HA.
MIP6_IKEv2_key
MIP6_IKEv2_key is the IKEv2 pre-shared key which is used in the IKEv2
exchange needed for establishment of an MN-HA IPsec SA.
MN_HA_MIP4_key
MN_HA_MIP4_key is used for protecting Mobile IPv4 signaling between
MN and HA.
PMN_HA_MIP4_key
PMN_HA_MIP4_key is used for protecting proxy MIP4 signaling between
proxy mobile node and HA.
MN_FA_MIP4_key
MN_FA_MIP4_key is used for protecting Mobile IPv4 signaling between
MN and FA.
Nakhjiri & Wan Expires April 16, 2007 [Page 6]
Internet-Draft MIP root key October 2006
3. Key Distribution function (KDF)
We are following the [USRK] recommendation on KDF.
KDF = PRF(key, US_data)
[USRK] suggests the use of PRF+ from IKEv2 specification [RFC4306] as
a default PRF for derivation of USRK for derivations of root keys for
all usage definitions, unless otherwise specifically stated.
"US_data" stands for usage specific data and will be defined shortly.
The PRF+ is defined as follows:
prf+ (Key, US_Data) = T1 | T2 | T3 | T4 | ...
Where:
T1 = PRF (Key, US_Data | 0x01)
T2 = PRF (Key, T1 | US_Data | 0x02)
T3 = PRF (Key, T2 | US_Data | 0x03)
T4 = PRF (Key, T3 | US_Data | 0x04)
The notion of PRF+ means the same PRF will be executed over and over
to provide as long keying material as needed (T1, T2, T3, etc). In
deriving Mobile IP usage specific root keys (MIP4_USRK, MIP6_USRK),
we will follow this recommendation and suggest the use of HMAC_SHA-
256 as PRF (defined in [SHA256]). for deriving USRKs from the EMSK.
Furthermore, the "key" above is the extended master session key
(EMSK) derived from execution of an EAP method. So the expression
for PRF+ used in Mobile IP USRK derivations is defined as follows
prf+ (EMSK, US_Data) = T1 | T2 | T3 | T4 | ...
Where:
T1 = HMAC-SHA-256 (EMSK, US_Data | 0x01)
T2 = HMAC-SHA-256 (EMSK, T1 | US_Data | 0x02)
T3 = HMAC-SHA-256 (EMSK, T2 | US_Data | 0x03)
T4 = HMAC-SHA-256 (EMSK, T3 | US_Data | 0x04)
The usage_specific data (US_Data) is defined as follows.
US_data=Key label + "\0" + op-data + length
Nakhjiri & Wan Expires April 16, 2007 [Page 7]
Internet-Draft MIP root key October 2006
Key label = ASCII key label
The ASCII key label will be defined for each usage (Mobile IPv4 and
Mobile IPv6) in the relevant sections of this document later on.
op-data = optional data
The "optional data" will be defined for each usage (Mobile IPv4 and
Mobile IPv6) later in this document.
length = 2 byte unsigned integer in network byte order
'\0' = is a NUL byte (0x00 in hex)
+ denotes concatenation
It should be noted that only the USRKs for Mobile IPv4 and Mobile
IPv6 (MIP4_USRK, MIP6_USRK) need to follow this procedure; it is not
required for each of these applications to use the same PRF+ in
creating further child keys from the USRKs. For instance, the Mobile
IPv4 function may use a different PRF when deriving MN-HA-key from
MIP4_USRK, if necessary. The mandate on use of PRF+ for the Mobile
IP USRK, while allowing for use of weaker PRFs for usage specific
child keys, assures the EMSK and the USRK for other non-Mobile IP
usages are not compromised unnecessarily.
Nakhjiri & Wan Expires April 16, 2007 [Page 8]
Internet-Draft MIP root key October 2006
4. Mobile IPv6 USRK derivation
Section 3 defines the USRK formula. This section will explain the
mip6 usage specific data according to the USRK formula. The MIP6-
USRK is generated below:
MIP6_T1 = HMAC-SHA-256 (EMSK, "MIP6 USRK derivation"|<MSA_ID>|
<MSP_ID> |EAP session ID| MN_ID| 128 | 0x01 )
MIP6_T2 = HMAC-SHA-256 (EMSK, MIP6_T1 | "MIP6 USRK derivation" |
<MSA_ID>|<MSP_ID>| EAP session ID| MN_ID|128 | 0x02)
MIP6_USRK=MIP6_T1 | MIP6_T2
The details are explained as follows:
-The MIP6_USRK is generated from EMSK.
-We assume a key length of 256 bits is sufficient for MIP6_USRK.
-SHA256 [SHA256] creates 128 security bits and hence we will create
both MIP6_T1 and MIP6_T2 to have a total of 256 security bits, even
though the result of the hash after running PRF twice would be 512.
-The key label of MIP6_USRK is "MIP6 USRK derivation"
-op-data = <MSA_ID>|<MSP_ID> |EAP session ID| MN_ID
<> indicates that an attribute is optional.
MSA is Mobility service authorizer (can be AAA server authorizing MN
for MIP6 service) and MSP is mobility service provider providing MIP6
service to the MN. So it is up to deployment scenario and operators
policy to include these identifiers in the key generation data.
MN_ID is an identifier for the MN, so that the MN is recognizable by
the entity that generates the MIP6_USRK. Depending on the MIP6
bootstrapping scenario and instance and entity at which the MIP6_USRK
is being generated and the MIP6 service to MN is being authorized at,
the MN_ID may be different. A number of alternatives for MN_ID is as
follows:
-FQDN for the MN.
-NAI for the MN.
-IPv6 HoA address for MN.
Nakhjiri & Wan Expires April 16, 2007 [Page 9]
Internet-Draft MIP root key October 2006
EAP session ID is used for identifying the EAP session.
The MIP6-USRK key name is defined below:
MIP6 USRK key name = HMAC-SHA-256( EAP Session-ID, "MIP6_USRK
derivation"| 64)
All other MIP6 related keys, including MN-HA key and IKEv2 pre-shared
key are derived as child keys of the MIP6-USRK. Even though, it is
not required to use the same KDF in derviation of these child keys,
for simplicity, we use HMAC_SHA_256 in those derivation.
MN-HA key is required in [RFC4285] which is used for building
security association between mobile node and Home Agent.
IKEv2 pre-shared key is required in [RFC3776] which is used for
generating AUTH value.
Figure 1 shows the key hierarchy of the mip6 key:
---------
|MIP6_USRK|
---------
|
+---------------------------------+
| | |
| | |
| | |
-------------- -------------- ---------------
|MIP6_MN_HA_key| |MIP6_IKEv2_key| |other MIP6 keys|
-------------- -------------- ---------------
Figure 1 Mip6 key hierarchy
The MIP6_MN_HA_key key generation formula is shown below:
MIP6_MN_HA_key = HMAC-SHA-256(MIP6_USRK, "MN-HA key derivation"|
<HA_ID> | MN_ID | 128)
The details are explained as follows:
- [RFC4285] requires the MIP6_MN_HA_key length must be 16 octets.
-The key label of MIP6_MN_HA_key is "MN-HA key derivation"
-op-data = <HA_ID> | MN_ID
<> indicates that an attribute is optional.
Nakhjiri & Wan Expires April 16, 2007 [Page 10]
Internet-Draft MIP root key October 2006
MN_ID and HA_ID is used for identifying the two entities who share
the key. The MN_ID should match that used in Mobile IPv6 signaling
or bootstrapping. Depending on whether at the time of the key
derivation an HA is assigned to the MN, The HA_ID may be left out.
It is however recommended that MN_HA_keys are derived including HA_ID
and after the HA is assigned to assure proper key scoping.
The MIP6_IKEv2_key key generation formula is shown below:
MIP6_IKEv2_key=HMAC-SHA-256(MIP6_USRK, "IKEv2 pre-shared key
derivation" | MN_ID| HA_ID | 128)
The details are explained as follows:
- [RFC4306] requires the length of the IKEv2 pre-shared key to rely
on the length requirement of the negotiated prf. If the pre-shared
key length does not match the requirement of prf, the key will be
truncated or padded with zeros as necessary. So we set the default
length of the IKEv2 pre-shared key to 128 bits.
-The key label is "IKEv2 pre-shared key derivation"
-op-data = MN_ID| HA_ID
MN_ID and HA_ID are used for identifying the two entities who share
the key. The MN_ID should match that used in Mobile IPv6 signaling
or bootstrapping. MN_ID and HA_ID are both important, since they are
used for IKEv2.
It is possible that MIP6 application or its related protocols, such
as fast Mobile IPv6 will require other keys for their operation.
Such keys can be generated in a similar manner from the MIP6_USRK as
shown in figure 1.
Nakhjiri & Wan Expires April 16, 2007 [Page 11]
Internet-Draft MIP root key October 2006
5. Mobile IPv4 USRK derivation
The mobile ipv4 key generation is similar to mip6 key generation.
This section explains the mip4 usage specific data according to the
USRK formula defined in section 3. The MIP4_USRK is generated below:
MIP4_T1 = HMAC-SHA-256 (EMSK, "MIP4 USRK derivation"|AAAH_ID |MN_ID|
EAP session ID| 128 | 0x01 )
MIP4_T2 = HMAC-SHA-256 (EMSK, MIP4_T1 | "MIP4 USRK derivation" |
AAAH_ID| MN_ID|EAP session ID| 128 | 0x02)
MIP4_USRK=MIP4_T1 | MIP4_T2
The details are explained as follows:
-The MIP4_USRK is generated from EMSK.
-We assume a key length of 256 bits is sufficient for MIP6_USRK.
-SHA256 [SHA256] creates 128 security bits and hence we will create
both MIP4_T1 and MIP4_T2 to have a total of 256 security bits, even
though the result of the hash after running PRF twice would be 512.
-The key label of MIP4_USRK is "MIP4 USRK derivation".
-op-data = AAAH_ID |MN_ID|EAP session ID
AAAH_ID is used for identifying the operator attributes. So it is up
to deployment scenario and operators policy to include these
identifiers in the key generation data.
MN_ID is an identifier for the MN, so that the MN is recognizable by
the entity that generates the MIP4_USRK. Depending on the MIP4
bootstrapping scenario and instance and entity at which the MIP4_USRK
is being generated and the MIP4 service to MN is being authorized at,
the MN_ID may be different. A number of alternatives for MN_ID is as
follows:
-FQDN for the MN
-NAI for the MN
-IPv4 HoA address for MN
EAP session ID is used for identifying the EAP session.
The MIP4-USRK key name is defined below:
Nakhjiri & Wan Expires April 16, 2007 [Page 12]
Internet-Draft MIP root key October 2006
MIP4 USRK key name = HMAC-SHA-256( EAP Session-ID, "MIP4 USRK
derivation"| 64)
All other MIP4 related keys including MN-HA-MIP4-key, MN-HA-PMIP4-
key,FA-MIP4-root-key and MN-FA-MIP4-key are derived as child keys of
the MIP4-USRK. Figure 2 shows the MIP4 key hierarchy.
---------
|MIP4_USRK|
---------
|
+----------------------------------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
-------------- --------------- -------------- ---------------
|MN_HA_MIP4_key| |FA_HA_MIP4_Root| |MN_FA_MIP4_key| |PMN_HA_MIP4_key|
-------------- --------------- -------------- ---------------
Figure 2 Mip4 key hierarchy
The MN_HA_MIP4_key key generation formula is shown below:
MN_HA_MIP4_key = HMAC-SHA-256(MIP4_USRK, "MN-HA key derivation"|
<HA_ID> | MN_ID | AAAH_ID |128)
The details are explained as follows:
-The length of MN_HA_MIP4_key is set default to 128 bits.
-The key label of MN_HA_MIP4_key is "MN-HA key derivation".
-op-data = <HA_ID> | MN_ID | AAAH_ID
<> indicates that an attribute is optional.
AAAH_ID is used for identifying the operator attributes. So it is up
to deployment scenario and operators policy to include these
identifiers in the key generation data.
MN_ID and HA_ID is used for identifying the two entities who share
the key. The MN_ID should match that used in Mobile IPv4 signaling
or bootstrapping. Depending on whether at the time of the key
derivation an HA is assigned to the MN, The HA_ID may be left out.
It is however recommended that MN_HA_keys are derived including HA_ID
Nakhjiri & Wan Expires April 16, 2007 [Page 13]
Internet-Draft MIP root key October 2006
and after the HA is assigned to assure proper key scoping.
The PMN_HA_MIP4_key key generation formula is shown below:
PMN_HA_MIP4_key = HMAC-SHA-256(MIP4_USRK, "PMN-HA key derivation"|
<HA_ID> | PMN_ID | AAAH_ID |128)
The details are explained as follows:
-The length of PMN_HA_MIP4_key is set default to 128 bits.
-The key label of MN_HA_PMIP4_key is "PMN-HA key derivation".
-op-data = <HA_ID> | PMN_ID | AAAH_ID
AAAH_ID is used for identifying the operator attributes. So it is up
to deployment scenario and operators policy to include these
identifiers in the key generation data.
PMN_ID and HA_ID is used for identifying the two entities who share
the key. The PMN_ID should match that used in proxy Mobile IPv4
signaling.
The MN_FA_MIP4_key key generation formula is shown below:
MN_FA_MIP4_key = HMAC-SHA-256(MIP4_USRK , "MN-HA MIP4 key
derivation"| FA_ID | MN_ID | AAAH_ID |128)
The details are explained as follows:
-The key label of MN_FA_MIP4_key is "MN-HA MIP4 key derivation".
-The length of MN_FA_MIP4_key is set default to 128 bits.
-op-data = FA_ID | MN_ID | AAAH_ID
AAAH_ID is used for identifying the operator attributes. So it is up
to deployment scenario and operators policy to include these
identifiers in the key generation data.
MN_ID and FA_ID is used for identifying the two entities who share
the key. The MN_ID should match that used in Mobile IPv4 signaling
or bootstrapping.
The FA_HA_MIP4_Root key generation formula is shown below:
FA_HA_MIP4_Root = HMAC-SHA-256(MIP4_USRK, "FA-MIP4 root key
derivation"| HA_ID|FA_ID | AAAH_ID |128)
Nakhjiri & Wan Expires April 16, 2007 [Page 14]
Internet-Draft MIP root key October 2006
The details are explained as follows:
-The length of FA_HA_MIP4_Root is set default to 128 bits.
-The key label of FA_HA_MIP4_Root is "FA-MIP4 root key derivation".
-op-data = HA_ID| FA_ID | AAAH_ID
AAAH_ID is used for identifying the operator attributes. So it is up
to deployment scenario and operators policy to include these
identifiers in the key generation data.
FA_ID and HA_ID is used for identifying the two entities who share
the key. This key be used as is, or as a pre-shared key for an FA-HA
IKE. So FA_ID and HA_ID are both important.
Nakhjiri & Wan Expires April 16, 2007 [Page 15]
Internet-Draft MIP root key October 2006
6. security considerations
This draft recommends the use of a default PRF (PRF+) according to
[RFC4306] for deriving all USRKs from an EMSK. There may be cases
where a system operator has specified a policy and/or configured
devices within a system to use a different system-wide PRF. The
other exception to this rule would be if Mobile IPv4 or Mobile IPv6
had specific messaging process for PRF negotation, but this is not
the case.
Nakhjiri & Wan Expires April 16, 2007 [Page 16]
Internet-Draft MIP root key October 2006
7. IANA considerations
This document does not require actions by the IANA.
Nakhjiri & Wan Expires April 16, 2007 [Page 17]
Internet-Draft MIP root key October 2006
8. Acknowledgement
Thank Joe Salowey for his valuable input.
Nakhjiri & Wan Expires April 16, 2007 [Page 18]
Internet-Draft MIP root key October 2006
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", August 2002.
[RFC3748] Aboba , B. and Et. Al., "Extensible Authentication
Protocol (EAP)", June 2004.
[RFC3775] Johnson, D. and Et. Al., "Mobility Support in IPv6",
June 2004.
[RFC3776] Arkko, J. and Et. Al., "Using IPsec to Protect Mobile IPv6
Signaling Between Mobile Nodes and Home Agents",
June 2004.
[RFC4285] Patel, A. and Et. Al., "Authentication Protocol for Mobile
IPv6", January 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
December 2005.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
Bootstrapping Mobile IPv6 (MIPv6)", September 2006.
[SHA256] , National Institute of Standards and Technology., "Secure
Hash Standard", August 2002.
9.2. Informative References
[EAPkeying]
Aboba, B. and Et. Al., "Extensible Authentication Protocol
(EAP) Key Management Framework", May 2006.
[USRK] Salowey, J. and Et. Al., "Specification for the Derivation
of Usage Specific Root Keys (USRK) from an Extended Master
Session Key (EMSK)", June 2006.
Nakhjiri & Wan Expires April 16, 2007 [Page 19]
Internet-Draft MIP root key October 2006
Authors' Addresses
Madjid Nakhjiri
Huawei USA
12040, 98th AVE NE, suite 200B,
Kirkland, WA 98033
USA
Email: mnakhjiri@huawei.com
Changsheng Wan (editor)
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, Jiangsu 210001
China
Phone: 86-25-84565415
Email: wanchangsheng@huawei.com
Nakhjiri & Wan Expires April 16, 2007 [Page 20]
Internet-Draft MIP root key October 2006
Intellectual Property Statement
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.
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.
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nakhjiri & Wan Expires April 16, 2007 [Page 21]