MIPSHOP Working Group Souhwan Jung
Internet Draft Jaeduck Choi
Expires: August 25, 2008 Soongsil University
February 25, 2008
A Secure and Efficient Handover Authentication in FMIP6
draft-jung-mipshop-secure-efficient-handover-01.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 August 25, 2008.
Jung, et al. Expires August 25, 2008 [Page 1]
Internet-Draft FMIPv6 Authentication February 2008
Abstract
This document describes a secure and efficient handover
authentication (SEHA) protocol in FMIP6. The main idea is using the
Diffie-Hellman (DH) algorithm to enhance security aspects, and is
modifying the DH key exchange to reduce computational cost at the
Mobile Node (MN) by delegating exponential operation to the Access
Router (AR). The MN and NAR establish the handover key HK_NAR through
the PAR instead of the AAA server at any convenient time while the MN
belongs to the NAR domain. The HK_NAR is used for handover
authentication when the MN moves from the NAR to the next NAR. The
main advantage of this document is more secure and suitable to a
light-weight mobile terminal than the existing handover
authentication scheme using SEND.
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................3
3. Protocol Overview.............................................4
4. Protocol Details..............................................6
4.1. MN Behavior..............................................8
4.2. PAR Behavior.............................................9
4.3. NAR Behavior.............................................9
5. Message Formats..............................................10
5.1. Handover Authentication Request (HAReq).................10
5.2. Handover Authentication Response (HAResp)...............11
5.3. Options.................................................12
6. Security Considerations......................................13
7. IANA Considerations..........................................14
8. References...................................................14
8.1. Normative References....................................14
Author's Addresses..............................................15
Intellectual Property Statement.................................15
Disclaimer of Validity..........................................16
Copyright Statement.............................................16
Acknowledgment..................................................16
Jung, et al. Expires August 25, 2008 [Page 2]
Internet-Draft FMIPv6 Authentication February 2008
1. Introduction
In the mobile IP networks [2],[3], the handover authentication should
be provided to protect signaling messages against security
vulnerabilities such as the Denial of Service (DoS) attack or the
intercept attack by packet redirection. Also, it should require less
computing power to be suitable for a light-weight mobile terminal.
The distributing handover key scheme using SEND [4] provides good
security features without resorting to the AAA server. However, there
are potential problems such as a Sybil attack (forging identities)
and DoS attack due to using self-generated private/public key pairs.
The Secure Neighbor Discovery (SEND) [5] based on Cryptographically
Generated Addresses (CGA) [6] is weak against the Sybil attack, in
which the attacker uses several invented addresses so that a
legitimate node can believe many other nodes to be around. This Sybil
attack also causes the AR to be vulnerable to the DoS attack. For
example, if the AR receives a number of forged requests, it should
perform many verification and encryption operations based on public
key algorithm to distribute handover keys. Also, this scheme requires
computational overhead at the MN such as RSA signature and decryption
for distributing a symmetric FMIPv6 handover key.
This document describes a secure and efficient handover
authentication (SEHA) based on a light-weight DH key exchange without
the AAA server. The MN and the NAR (AR_i+1) establish the handover
key HK_NAR (HK_i+1) through the PAR (AR_i) after exchanging both the
RtSolPr and PrRtAdv messages while the MN belongs to the NAR domain.
The SEHA also supports a robust security feature against DoS attack
than the existing handover authentication scheme using SEND. Also, it
requires less computation at the MN by delegating the DH half-key
generation to the AR.
This document defines two messages HAResq and HAResp, and new options
to carry out handover authentication.
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 RFC-2119 [1].
New terminologies are defined in this memo.
Jung, et al. Expires August 25, 2008 [Page 3]
Internet-Draft FMIPv6 Authentication February 2008
Handover Authentication Request (HAReq):
HAReq is a message to deliver parameters for the handover
authentication to the AR.
Handover Authentication Response (HAResp):
HAResp is a message to deliver parameters for the handover
authentication to the MN, and notify the MN of the success or
failure of the handover authentication.
HK_i :
Handover key between the MN and AR_i for securing FBU message
3. Protocol Overview
In our scheme, there are two assumptions. First, the MN and AAA
server perform an initial full EAP authentication [7][8] during a
bootstrapping resulting that a master key is established between
them. Hence, the MN and AR share a Handover Key (HK) that is derived
from the master key. The second assumption is that a secure channel
exists among the ARs using the TLS or IPSec to protect handover
authentication messages among them.
The basic idea of our scheme is using the DH key exchange to enhance
security aspects, and is modifying the DH algorithm to reduce
computational cost at the MN by delegating exponential operation to
the AR. This feature is more secure and suitable to a light-weight
mobile terminal than the existing schemes. The other idea is that the
MN and the NAR (AR_i+1) establish the handover key HK_NAR (HK_i+1)
through the PAR (AR_i) instead of the AAA server after exchanging
both RtSolPr and PrRtAdv messages with the NAR while the MN belongs
to the NAR domain. In other words, the MN establishes the new
Security Association (SA) between the MN and the NAR using the old SA
between the MN and the PAR. The HK_NAR (HK_i+1) is used for handover
authentication when the MN moves from the NAR (AR_i+1) to the next
NAR (AR_i+2).
Figure 1 shows the sequential steps of a proposed SEHA scheme in
FMIPv6. The AAA server takes part only in the bootstrapping
authentication procedure. The MN and the AR_1 share the key HK_1
after the bootstrapping authentication. When the MN moves from the
AR_1 to the AR_2, the MN protects the FBU message using the HK_1. The
MN in the AR_2 domain may exchange the HK_2 with the AR_2 to protect
the FBU message for the next handover. This key exchange procedure is
achieved among the AR_1, AR_2, and MN without the AAA server. The
Jung, et al. Expires August 25, 2008 [Page 4]
Internet-Draft FMIPv6 Authentication February 2008
AR_1 authenticates the MN using the Message Authentication Code (MAC)
with the HK_1. If the validation is successful, the MN and AR_2
generate a new handover key HK_2 using the DH key exchange. The MN
and AR_2 SHOULD cache the HK_2 during their lifetime. The HK_2 is
used for handover authentication when the MN moves from the AR_2 to
the next AR (AR_3). The MN repeats the same procedure whenever it
handovers.
Step 1
- Bootstrapping authentication
Step 2
- FBU procedure protected by HK_1 when MN moves from AR_1 to AR_2
Step 3
- Handover from AR_1 to AR_2
Step 4
- Authentication procedure between AR_1 and MN using HK_1
- Key exchange (HK_2) based on DH key exchange
Step 5
- FBU procedure protected by HK_2 when MN moves from AR_2 to AR_3
Step 6
- Handover from AR_2 to AR_3
Jung, et al. Expires August 25, 2008 [Page 5]
Internet-Draft FMIPv6 Authentication February 2008
_ +-----+
+--------------------->| AAA |
| +-----+
|
|1
|
|
|HK_1 HK_2 HK_i HK_i+1
+------+ 4 +------+ +------+ +------+
| AR_1 |<------| AR_2 | ... | AR_i | |AR_i+1|
+------+ +------+ +------+ +------+
| ^ | ^
| | | |
| |2 |4 |5
| | | |
| | | |
V V V V
+------+ 3 +------+ 6 +------+
| MN |------>| MN |----->| MN |
+------+ +------+ +------+
HK_1 HK_1, HK_2 HK_2, HK_3
Figure 1 Protocol Overview.
4. Protocol Details
Figure 2 shows the protocol of the handover authentication. In Figure
2, the MN SHOULD generate and store a random number r and value g^r
after a bootstrapping authentication.
The MN with the HK_PAR (HK_i) moves from the PAR (AR_i) to the NAR
(AR_i+1) at the time T_1. Note that the MN currently belongs to the
NAR domain. The MN and the NAR MUST exchange a handover key HK_i+1 to
protect the FBU message for the next handover after exchanging both
RtSolPr and PrRtAdv messages with the NAR when the MN belongs to the
NAR domain as shown in the following figure.
Jung, et al. Expires August 25, 2008 [Page 6]
Internet-Draft FMIPv6 Authentication February 2008
MN NAR (AR_i+1) PAR (AR_i)
| | |
r,g^r, HK_i | |HK_i
| | |
--- T_1 : MN handovers to NAR | |
| | |
| RtSolPr | |
|---------------------------->| |
| PrRtAdv | |
|<----------------------------| |
| | |
x| HAReq (M_1, r+x, g^r) | |
|---------------------------->| |(g^(r+x)
| |g^y | /g^r)
| | HAReq (M_1, r+x, g^r, g^y | =g^x
| |--------------------------->|
| | |
| | HAResp (M_2, g^x) |
| HAResp (M_2, M_3, g^x, g^y) |<---------------------------|
|<----------------------------| |
| | |
HK_i+1 = g^(xy) HK_i+1 = g^(xy)
Figure 2 Procedure of Handover Authentication.
The MN generates a new random value x and computes the message M_1.
And then, the MN sends the HAReq message to the NAR. The HAReq
message contains following values.
M_1=H(HK_i, ID_MN||ID_PAR||ID_NAR||r+x||g^r)
HAReq [M_1, ID_MN, ID_PAR, ID_NAR, r+x, g^r]
Upon receiving the messages, the NAR generates a random number y and
computes its DH public key g^y. The NAR forwards the receiving
messages with the g^y to the PAR, which means that the integrity of
g^y is guaranteed by the PAR establishing the security association
with the MN. The HAReq message contains following values.
HAReq [M_1, ID_MN, ID_PAR, ID_NAR, r+x, g^r, g^y]
The PAR caching the MN's HK_i verifies the message M_1. If the
validation is successful, the PAR computes a value g^(r+x), and then
extracts the value g^x by computing g^(r+x)/g^r. The PAR computes the
M_2, and then replies with the HAResp message to the NAR. The PAR
Jung, et al. Expires August 25, 2008 [Page 7]
Internet-Draft FMIPv6 Authentication February 2008
also notifies the success of authentication to the NAR. The HAResp
message contains following values.
M_2=H(HK_i, ID_MN||ID_PAR||ID_NAR||g^(r+x)||g^x||g^y)
HAResp ["Success", M_2, ID_MN, ID_PAR, ID_NAR, g^x]
If the NAR receives the messages including the failure notification
from the PAR, the NAR notifies the MN of the failure of the handover
authentication. Otherwise, the NAR computes the new handover
authentication key HK_i+1=(g^x)^y= g^(xy) using the private key y and
the received value g^x from the PAR. The NAR computes M_3, and sends
the message HAResp to the MN. Note that the NAR SHOULD cache the
HK_i+1 and ID_MN for securing FBU procedure when the MN will move
from the NAR (AR_i+1) to the next NAR (AR_i+2). The HAResp message
contains following values.
M_3=H(g^(xy), M_2||ID_MN||ID_PAR||ID_NAR)
HAResp ["Success", M_2, M_3, ID_MN, ID_PAR, ID_NAR, g^x, g^y]
The MN computes the g^(r+x) by computing (g^r)x(g^x), and then
verifies the M_2. If a success, the MN computes the new handover
authentication key HK_i+1=(g^y)^x=g^(yx) using the private key x and
the public key g^y, and then verifies the M_3. If the MN fails to
verify the M_2 or M_3, the authentication fails. In the future, the
MN MUST perform securing FBU using the HK_i+1 when it moves from the
NAR (AR_i+1) to the next NAR (AR_i+2).
- Securing FBU procedure : FBU, H(HK_i+1, FBU)
4.1. MN Behavior
The MN MUST share the HK_1 with the AR_1 after initial bootstrapping
authentication. Also, the MN SHOULD store a random value r and value
g^r, and compute the exponent operation g^x by computing g^(r+x)/g^r
to reduce computational overhead.
The MN MUST use the HK_PAR (HK_i) for protecting the FBU message when
the MN handovers to the NAR (AR_i+1). After moving to the NAR, the MN
MUST initiate a HAReq message to exchange the HK_NAR (HK_i+1) with
the NAR. The authentication procedure MUST be performed after
receiving the PrRtAdv message from the NAR while the MN belongs to
the NAR domain.
If the MN receives the HAResp message including the success
notification from the NAR, the MN MUST generate the HK_i+1 and cache
Jung, et al. Expires August 25, 2008 [Page 8]
Internet-Draft FMIPv6 Authentication February 2008
it for next handover authentication. In the future, the MN MUST use
HK_i+1 for securing FBU between the MN and NAR when the MN moves from
the NAR (AR_i+1) to the next NAR (AR_i+2).
The MN that belongs to the NAR (AR_i+1) domain MUST store the HK_PAR
(HK_i) until the MN and AR_i+1 exchange the HK_NAR (HK_i+1). Also,
the MN SHOULD cache HK_i for its life time. If the MN comes back to
the PAR domain, the MN SHOULD reuse its HK_i.
4.2. PAR Behavior
The channels among the ARs SHOULD be established by the IPsec or TLS.
Upon receiving a HAReq message from the NAR (AR_i+1), the PAR (AR_i)
MUST verify the value M_1 in the HAReq message using the HK_i shared
with the MN. If the PAR fails to verify the M_1, the PAR MUST send a
HAResp message including the failure of authentication to the NAR,
and ignore the received HAReq message. Otherwise, the PAR MUST
compute a g^x by computing g^(r+x)/g^r. And then the PAR MUST
generate the message M_2. The PAR MUST send the HAResp message with
the result of M_1 verification to the NAR.
The PAR SHOULD store the HK_PAR (HK_i) until the MN request handover
authentication. Also, the PAR SHOULD cache HK_i for its life time. If
the MN returns to the PAR domain, the PAR SHOULD reuse the MN's HK_i.
4.3. NAR Behavior
Upon receiving the message HAReq from the MN, the NAR MUST generate a
random number y and a value g^y. Also, the NAR MUST forward the
received message HAReq with the value g^y to the PAR, and create
cache table including the MN_ID, NAR_ID, PAR_ID, y, and g^y.
The NAR MUST compute the new handover authentication key HK_i+1 using
its DH private key y in cache table and the received value g^x from
the PAR, when the NAR receives the message HAResp including the
success notification. Also, the NAR MUST compute the message M_3 to
confirm the handover key HK_i+1 with the MN. The NAR MUST send the
message HAResp including the life time of the HK_i+1 to the MN. If
the NAR receives the failure of authentication from the PAR, the NAR
MUST delete the MN's cache table except the DH parameters y and g^y
that are not used for generating handover key. The NAR SHOULD reuse
the stored value y and g^y without computing new DH public keys.
The NAR MUST verify a FBU message using the HK_i+1 when the MN moves
from the NAR (AR_i+1) to the next NAR (AR_i+2).
Jung, et al. Expires August 25, 2008 [Page 9]
Internet-Draft FMIPv6 Authentication February 2008
5. Message Formats
This document defines two messages HAReq and HAResp, and new options
to carry out handover authentication.
5.1. Handover Authentication Request (HAReq)
The HAReq MUST be sent from the MN to the AR for the handover
authentication. Receiving the HAReq message from the MN, the AR MUST
forward it to another AR. The HAReq message SHOULD use Options to
deliver extra variables for authentication (to be assigned by IANA).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Code | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Handover Authentication Request (HAReq) Message.
HAReq Fields
Message Code
8-bit field indicate the handover authentication protocol, the
value of which is taken from the IANA. A value of '1' (to be
assigned by IANA) indicates the HAReq message.
Length
8-bit field is the length of the HAReq message.
Reserved
16-bit field reserved for future use. This field is unused. It
MUST be initialized to zero by the sender and MUST be ignored by
the receiver.
Jung, et al. Expires August 25, 2008 [Page 10]
Internet-Draft FMIPv6 Authentication February 2008
Options
Options field includes extra variables for handover
authentication.
5.2. Handover Authentication Response (HAResp)
The HAResp MUST be sent to the AR and MN in responding to a HAReq
message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Code | Length | Result Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Handover Authentication Response (HAResp) Message.
HAResp Fields
Message Code
8-bit field indicates the handover authentication protocol, the
value of which is taken from the IANA. A value of '2' (to be
assigned by IANA) indicates the HAResp message.
Length
8-bit field is the length of the HAResp message.
Result Code
8-bit field indicates the result of authentication. A value of
'200' (to be assigned by IANA) indicates the "Success", and
'400' (to be assigned by IANA) indicates the "Fail"
Jung, et al. Expires August 25, 2008 [Page 11]
Internet-Draft FMIPv6 Authentication February 2008
Reserved
16-bit field reserved for future use. This field is unused. It
MUST be initialized to zero by the sender and MUST be ignored by
the receiver.
Options
Options field includes extra variables for handover
authentication.
5.3. Options
The HAReq and HAResp messages SHOULD accommodate various options as
follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Option Length | Option Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Option Message.
Option Fields
Option Code
8-bit field indicates extra variables as follows.
M_1 (Code number: to be assigned by IANA)
M_2 (Code number: to be assigned by IANA)
M_3 (Code number: to be assigned by IANA)
ID_MN (Code number: to be assigned by IANA)
ID_PAR (Code number: to be assigned by IANA)
ID_NAR (Code number: to be assigned by IANA)
Jung, et al. Expires August 25, 2008 [Page 12]
Internet-Draft FMIPv6 Authentication February 2008
Random_1 (Code number: to be assigned by IANA)
: This value is r+x.
Random_2 (Code number: to be assigned by IANA)
: This value is g^r
DH_MN (Code number: to be assigned by IANA)
: This value is g^x.
DH_AR (Code number: to be assigned by IANA)
: This value is g^y.
HK_LifeTime (Code number: to be assigned by IANA)
Option Length
8-bit field is the length of the Options field.
6. Security Considerations
The proposed scheme assumes that there are secure channels among ARs
and no secure channel between the MN and the AR. Therefore,
communications between the ARs are secure against the MITM (Man-in-
the-Middle) attack. When communicating with the AR, the MN secures
the messages using the MAC with the HK shared with the AR. This can
also protect the MN and the AR against MITM attack.
The DoS attack for exhausting resource has become a major security
threat. The DoS attack considered on our scheme is the CPU exhaustion
attack such as exponent operation when an attacker sends a number of
fake requests to the AR. In the proposed scheme, by reusing unused DH
public keys, ARs protect themselves against malicious attackers who
will try to exhaust their computing power. The AR_i+1 requires two
exponent operations per handover procedure: a DH public value g^y and
handover key (g^x)^y. Upon receiving the fake requests, the AR_i+1
will generate DH public keys and forward the fake requests with the
DH public keys to the AR_i. However, the AR_i may fail to verify the
fake requests due to unknown HK_i, and then it notifies the failure
of authentication to the AR_i+1. For the resistance against DoS
attack, if the AR_i+1 receives the failure of authentication from the
AR_i, the AR_i+1 should keep the generated DH public key (g^y) to be
Jung, et al. Expires August 25, 2008 [Page 13]
Internet-Draft FMIPv6 Authentication February 2008
reused for the next request. The SEHA can also protect the nodes
against replay attack by using a random number and caching the MN's
ID and HK_i.
The SEHA scheme provides the PFS, but does not provide the PBS in
case of exposed HK_i. The PFS and PBS mean that even if a handover
key HK_i is compromised by some reasons, it never reveals all the
previous and next handover keys. We use the DH key agreement protocol
to provide the PFS and PBS. In case of the PFS, if the HK_i is
exposed by some attacks, an attacker gives no clues to guess the
previous handover key. The reason is that the MN and AR generate the
handover key HK_i using new DH private key x_i and y_i whenever the
MN performs the handover authentication. If, however, the HK_i is
exposed by some reasons, the SEHA does not provide the PBS since
then. Note that the HK stored at the MN has the same security
strength as the master handover key or private key used in the
existing schemes.
The SEHA scheme is robust to the ping-pong problem. If the MN quickly
changes its position between the ARs, there may be the ping-pong
problem. When the MN frequently moves between the AR_i and AR_i+1,
the handover key HK_i and HK_i+1 should be changed according to its
movement area. The SEHA scheme securely caches the MN's HK at the MN
and the AR. Hence, the MN can securely reuse the HK without
disclosing it and performing redundant handover authentication
procedure.
7. IANA Considerations
The IANA will allocate the numbers to the HAReq, HAResp, and options.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] C Koodli, R., "Mobile Ipv6 Fast Handovers", draft-ietf-mipshop-
fmipv6-rfc4068bis-05, February 2008.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Jung, et al. Expires August 25, 2008 [Page 14]
Internet-Draft FMIPv6 Authentication February 2008
[4] Kempf, J. and Koodli, R, "Distributing a Symmetric FMIPv6
Handover Key using SEND", draft-ietf-mipshop-handover-key-03,
November 2007.
[5] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "Secure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Aura, T., "Cryptographically Generated Addresses", RFC 3972,
March 2005.
[7] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[8] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-22 (work in
progress), October 2006.
Author's Addresses
Souhwan Jung
Soongsil University
511, Sangdo-dong, Dongjak-gu
Seoul 156-743
KOREA
Phone: +82-2-820-0714
Email: souhwanj@ssu.ac.kr
Jaeduck Choi
Soongsil University
511, Sangdo-dong, Dongjak-gu
Seoul 156-743
KOREA
Phone: +82-2-824-1807
Email: cjduck@cns.ssu.ac.kr
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
Jung, et al. Expires August 25, 2008 [Page 15]
Internet-Draft FMIPv6 Authentication February 2008
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, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jung, et al. Expires August 25, 2008 [Page 16]