JunHyuk Song
INTERNET DRAFT ChaeYong Chong
29 June
04 July 2001 Emfro Kim
Samsung Elec.
Dongkie Leigh
SK telecom
Raymond Hsu
Qualcomm Inc.
Mobile IPv4 Authentication Shared key Generation
draft-song-mobile-ipv4-auth-secgeneration-00.txt
draft-song-mobile-ipv4-auth-secgeneration-01.txt
Status of This Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
Mobile Node and Home Agent servers used in nowadays can provide
authentication and authorization services mostly by the MN-HA and
MN-AAA Authentication. However, this kind of Security Association is only possible if Mobile Node
previously share the same shared secrets with Home Agent and AAA.
Based on the assumption that the SA between Mobile Node and Home AAA
is strong, it and the FAC issued from a Foreign Agent can provide
reasonable randomness. It is possible to use that security
association to dynamically update MN-AAA Authentication
shared secret and the FAC to create a security associations between the
Mobile Node and foreign agent and its home agent. Home Agent. This document specifies
the a method
to dynamically update the shared secret used for MN-AAA
extension and create a shared secret used for MN-HA extension among
between Mobile Node, Foreign Agent Node and Home Agent, based on MN-AAA shared secret,
NAI, Foreign Agent IP address and Foreign Agent Challenge.
Contents
Status of This Memo 1
Abstract 1
1. Introduction.......................................................3
1.2 Acronym.......................................................3
2. The parameters used for Dynamic MN-HA shared secret generation ....3 ....4
2.1 Mobile IP Agent Advertisement Challenge Extension.............3 Extension.............4
2.2 Network Access Identifier (NAI)...............................4
2.3 Master MN-AAA shared secret..........................................4 secret...................................5
3. MN-AAA shared secret update........................................4
3.1 MN-AAA key update by Mobile Node..............................4
3.2 MN-AAA key update by AAA......................................5
4. MN-HA shared secret creation.......................................5
4.1
3.1 MN-HA shared key creation by Mobile Node.............................5
4.2 Node......................5
3.2 MN-HA shared key creation by AAA..............................5
5
4. Key Management.....................................................6
4.1 MN-HA key management.........................................7
4.2 DIAMETER consideration........................................8
5. Operation description...............................................6
6 description..............................................9
6. Security Considerations.............................................6 Considerations............................................9
Appendix A - 3G Wireless example......................................7 example......................................9
Appendix B - MN-FA shared key consideration...........................8
References............................................................8
Addresses.............................................................9 consideration..........................11
References...........................................................11
Addresses............................................................12
1. Introduction
In Mobile IP, AAA servers is in use nowadays to identify and
authenticate the mobile node by the Network Access Identifier (NAI)
[1] and MN-AAA authenticator [3]. Besides In addition, the mobile node is
required to have a security association with its home agent [2].
Mobile IP defines an MN-HA authentication extension by which a mobile
node can authenticate itself to a home agent. However it is not
currently defined how Mobile Node, Home Agent and AAA obtain and update
the shared secret secrets used in computing MN-AAA and MN-HA
authenticator. Based on the assumption that the SA between Mobile
Node and Home AAA is strong, it and the FAC issued from a Foreign Agent
can provide reasonable randomness. It is possible to use that
security association and FAC to create security associations between
the Mobile Node and its Home Agent. This document specifies the a
method to dynamically update the shared
secret used for MN-AAA extension and a create shared secret used for MN-HA extension among
between Mobile Node, Foreign Agent Node and Home Agent, based on the MN-AAA shared
secret, NAI, and Foreign Agent IP address Challenge.
1.1 Acronym
MN : Mobile Node
FA : Foreign Agent
HA : Home Agent
AAA : Authentication, Authorization , and Accounting
AAAH : Home AAA
AAAF : Foreign AAA
AR : Access Request
AA : Access Accept
FAC : Foreign Agent Challenge. Challenge
RRQ : Mobile IP Registration Request
RRP : Mobile IP Registration Reply
SPI : Security Parameter Index
Key : Shared Secret
PDSN : Packet Data Serving Node
2. The parameters used for Dynamic MN-HA shared secret generation
This section defines the parameters used for MN-HA the session MN-AAA
shared secret
generation and MN-AAA MN-HA shared secret update. generation.
2.1 Mobile IP Agent Advertisement Challenge Extension
Currently Foreign Agent Challenge extension [3] is defined and in use
for 3G wireless system. That challenge extension is sent with the
Agent Advertisement by the Foreign Agent, in order to be used by
Mobile Node to create the MN-AAA authentication extension for its
Mobile IP Registration Request.
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 | Length | Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Challenge Extension [3]
Type 24
Length The length of the Challenge value in bytes; SHOULD be
at least 4
Challenge A random value that SHOULD be at least 32 bits.
The challenge extension is used to give the randomness for dynamic
MN-HA shared secret to avoid possible replay attack.
2.2 Network Access Identifier (NAI)
The Network Access Identifier (NAI) is the userID.
The Mobile NAI extension in Mobile IP registration request is used
for AAA to identify the clients.
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 | Length | MN-NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Mobile Node NAI Extension [9]
Type 131 (skippable)
Length The length in bytes of the MN-NAI field
MN-NAI A string in the NAI format defined in [1]
2.3 MN-AAA shared secret
The MN-AAA shared secret is the key used to compute the MN-AAA
authentication extension.
3. MN-AAA MN-HA shared secret update creation
This section describes how the current MN-AAA MN-HA shared secret is
updated creation by Mobile Node and AAA. How the initial MN-AAA shared secret
is distributed to the Mobile
Node and AAA is out of scope of this
document AAA.
3.1 MN-AAA MN-HA key update creation by Mobile Node
1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent
Advertisement.
Advertisement [3].
2. The mobile node uses the FA Challenge, its own NAI, and the
previously assigned
MN-AAA shared secret to calculate:
Current MN-AAA
MN-HA shared key =
HMAC-MD5(Initial MN-AAA-key HMAC-MD5(MN-AAA-key | FA Challenge |
MN NAI |
Initial MN-AAA-key)
3.2 MN-AAA MN-HA shared key update creation by AAA
1. AAA identifies Foreign Agent Challenge and the MN's NAI from the
AAA
message message.
2. AAA uses the FA Challenge, MN's NAI NAI, and the initially assigned MN-AAA shared
secret to calculate:
Current MN-AAA
MN-HA shared key =
HMAC-MD5(Initial MN-AAA-key HMAC-MD5(MN-AAA-key | FA Challenge |
MN NAI |
Initial MN-AAA-key)
4. Key Management
MN-HA shared secret creation
This section describes key lifetime management is OPTIONAL. It MAY be used to
increase the entropy of MN-HA shared key, or reduce the MN-HA
shared key fetching between the HA and the AAA server if RADIUS is
used.
(Note: In real time, it in not likely MN-HA shared secret creation by is ever
refreshed during MIP session, because MN-HA shared secret is
session specific, and MN-HA shared secret lifetime must be
reasonably greater than MIP re-registration lifetime.
The lifetime of MN-HA shared secret is operator configurable.
MN-HA shared secret may be refreshed on every re-registration
or used for until user terminate the session.)
Mobile Node MAY optionally configured with a lifetime of MN-HA shared
secret. Home Agent MAY optionally have a lifetime of MN-HA shared
key, as received from AAAH along with MN-HA shared key, according to
a user profile.
The length of the lifetime is operator configurable and AAA.
4.1 it SHOULD be
greater than the MIP re-registration time. Home Agent MUST fetch the
pre-fixed MN-HA key creation by Mobile Node
1. shared secret lifetime and MN-HA shared secret from
AAAH.
The Identification field in Mobile Node identifies Foreign Agent Challenge IP Registration Request is used
for preventing possible replay attack and delayed duplicate message
to arrive at the home agent. It contains mandatory timestamp and
optional nonce [2]. This Identification field in Mobile IP
Registration Request is used to let Home Agent
Advertisement.
2. to check the validity
of MN-HA shared secret.
Below is 64 bits Identification field of MIP RRQ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When MN creates MN-HA shared secret, the timestamp is issued.
The mobile node uses timestamp of MN-HA shared key is placed in the FA Challenge, its high-order 32 bits
of MIP RRQ Identification field. This high order bit of
Identification field is from MN's own NAI, and time of day [2].
The high-order 32 bits of MIP RRQ Identification field is used for
the
currently generated MN-AAA shared secret HA to calculate: configure the expiration time for the MN-HA shared key = HMAC-MD5(Current MN-AAA-key | key.
The low-order 32 bits of MIP RRQ Identification field MAY be
optionally used to enable FA Challenge |
MN NAI | Current MN-AAA-key)
4.2 and HA to refresh shared key.
4.1 MN-HA shared key creation by lifetime Management for Dynamic Mobile IP Home
Agent Allocation case with RADIUS based AAA
1. (see Appendix A)
When HA receives RRQ, the HA fetches MN-HA shared secret from AAA identifies Foreign Agent Challenge in
the following case 1 and 3
1. New MIP registration case.
In this case, there is no previously assigned MN-HA shared secret
for the MN's matching NAI or MN IP address. Even if there is a
previously assigned MN-HA shared secret for the matching NAI or MN
IP address, HA should not use that MN-HA shared key, because it is
new Mobile IP session.
The HA SHOULD use the home agent field or the home address field in
the MIP RRQ to differentiate the new MIP registration case from the
MIP re-registration case. If the home agent field or home address
field of MIP RRQ is equal to "0.0.0.0", the HA identifies this as a
new MIP registration.
Mobile Node MAY optionally use the low-order 32 bits of MIP RRQ
Identification field as the indicator whether MN-HA shared secret
is refreshed. If the low-order 32 bits of MIP RRQ Identification
field is equal to current MN-HA shared secret's timestamp, HA MAY
identify this as a new MIP registration or MN-HA shared secret is
currently refreshed.
Upon identifying MIP RRQ as a new registration message, HA MUST
send AAA message. message to fetch MN-HA shared secret and its lifetime.
2. Re-registration case with valid MN-HA shared key.
In this case, there is a previously assigned MN-HA shared secret
for the matching NAI or MN IP address and the lifetime of MN-HA
shared key is valid.
Upon the receipt of an MIP RRQ, if there is previously assigned
MN-HA shared key and it is not new MIP registration case, the Home
Agent MUST check the validity of the lifetime of MN-HA shared key.
If the high order bit of Identification field is smaller than
the expected lifetime of MN-HA shared secret, Home Agent
shall authenticate RRQ with stored MN-HA shared secret, and send RRP
after necessary MIP processing. The expected lifetime of
MN-HA is derived by adding a lifetime of MN-HA shared key and the
timestamp of MN-HA shared key.
3. Re-registration case with expired MN-HA shared key lifetime.
In this case, there is previously assigned MN-HA shared secret for
matching NAI or MN IP address. But the lifetime of stored MN-HA
shared key is already expired.
Upon the receipt of an MIP RRQ, the HA MUST check if it is an
initial MIP registration or MIP re-registration. In the case of
MIP re-registration, the HA shall check whether or not the lifetime
of MN-HA shared key is expired. If the high order bit of
Identification field is greater than the expected lifetime of MN-HA
shared secret, HA shall send AAA calculates uses message to fetch MN-HA shared
secret and its lifetime. After the FA Challenge, MN's NAI, receipt of MN-HA shared secret and
lifetime, Home Agent MUST authenticate the currently
generated MN-AAA MIP RRQ, and the HA shall
set the timer for MN-HA shared secret according to calculate: the timestamp in
the high-order 32 bits of the MIP RRQ Identification field.
4.2 DIAMETER consideration
For DIAMETER based AAA, the MN-HA shared secret key = HMAC-MD5(Current MN-AAA-key | FA Challenge | management
described in section 4.1 may not be needed for home agent. Because
MN NAI | Current MN-AAA-key) will decide the lifetime of updating MN-HA shared secret, and the
updated MN-HA shared key will be delivered to HA by DIAMETER HAR
message.
5. Operation description
Home Agent shall MUST obtain MN-HA shared secret from AAA. The MN-HA
shared key is session specific, and shall be used until termination
of MIP session or MIP re-registration.
The home agent MAY optionally set the lifetime of MN-HA shared
secret. The lifetime of MN-HA shared key is operator configurable.
The key fetching method varies from RADIUS [7] to DIAMETER [8] and it
is out of outside the scope of this document.
6. Security Considerations
The key generation method described in this document provides the
reasonable level of security by dynamically creating and updating the
shared secrets. Since this key generation method depends on already
available the
key materials used materials(i.e., NAI, FAC, MN-AAA shared secret) that are
available already in Mobile IP, it does not require any new key
materials.
Foreign Agent Challenge is used to avoid replay attack and enhance
entropy. It is the security. Therefore the weakest point same FAC that used for MN-AAA authentication
extension generation. The randomness of this scheme is FAC depends on random
number generator in the security of Foreign Agent. However, if FA is malicious
and is sending static FAC continuously rather than random FAC,
"chosen cipher text attack" is possible. Although the shared secret for MN-AAA.
Since cost and time
to reverse engineering the MN-AAA shared secret value generated by MD5 is dynamically updated for every MIP
registration after not practical,
it assigned first time, therefore is not impossible. Therefore in order to counter this potential
attack, FAC extension sent from the risk of
exposing FA to AAAF SHOULD be
authenticated by the MN-AAA shared secret between the FA and AAAF.
Furthermore, it is assumed that the communication between AAAF and
AAAH is secured.
Based on the assumptions, the randomness of FAC is guaranteed;
therefore, the security of this method is minimal. as good as the MN-AAA
authentication based on RFC-3012
Appendix A - 3G Wireless Example
In 3GPP2 Wireless system, both RADIUS and DIAMETER is supported as
the AAA protocols. This document suggests a method of dynamically
creating and maintaining the shared secrets for MN-AAA and MN-HA
authentication. shared secret. This scheme is
especially beneficial for the case of dynamic HA allocation.
In 3G wireless systems, if each Mobile Node and Home Agent has the
same static shared secret for MN-HA authentication, it would be
problematic for dynamic HA allocation because each HA generally has
no knowledge of all the MN-HA shared secrets. On the other hand,
configuring all the HAs with all the MN-HA shared secrets in an
administration domain raises concerns in security and scalability.
+--------------+ AR +--------------+
| |------------------->| |------------------>| |
| AAAF | | AAAH |
| |<-------------------| RADIUS |<------------------| RADIUS |
+--------------+ AA +--------------+
^ | ^ |
| | | |
AR | | AA AR | | AA
| v | v
+-----+ +--------------+ +--------------+
| | RRQ | | RRQ | |
| MS |----->| |-------->| PDSN/FA |------------------->| |------------------>| Home Agent |
| |<-----| |<-------------------| |<--------| |<------------------| |
+-----+ RRP +--------------+ RRP +--------------+
Figure 3 (3G Wireless Network)
If this scheme applied to the 3GPP2 Wireless Network in figure 3, the
Mobile station (MS)
MS shall update its pre-assigned MN-AAA create the MN-HA shared secret by running HMAC-MD5 with
input of its NAI, Foreign Agent
Challenge, challenge, and the MN-AAA key. Then MS shall
In the case of RADIUS based AAA, two scenarios MAY be possible
depends on how PDSN is configured. Currently IS-835 only optionally
support MN-AAA authentication in case of MIP re-registration.
1. PDSN configured to send Access Request message extension to AAAH
for MN-AAA authentication
2. PDSN configured not to send Access Request message to AAAH for
MN-HA authentication
In the first case, the mobile will create the MN-HA shared
secret by running HMAC-MD5 key with
input of its NAI, Foreign Agent
challenge, FAC, and newly generated MN-AAA shared key. When AAAH receives the
AAA message, relayed from AAAF, AAAH The mobile shall update the MN-AAA shared
secret for that MS by using the same parameters from send RRQ
with "0.0.0.0" in the AAA message. Home Agent Address field. Upon successfully
completing the MN-AAA authentication, AAAH shall generate the MN-HA
shared secret by using the same parameters that the MS used.
How Home
Agent obtain that MAY fetch MN-HA shared secret key for each re-registration happens
or MAY cache MN-HA is up to AAA
protocol. shared key during certain period of time defined
in the lifetime of MN-HA shared secret.
In the case second case, MIP re-registration totally depends on the MN-HA
authentication, since MN-AAA authentication shall only performed for
the first MIP registration. The mobile will create the MN-HA shared
key with input of using NAI, FAC, and MN-AAA shared key. The mobile shall
send RRQ with "0.0.0.0" in the RADIUS protocol, Home Agent Address field. After
successful MN-AAA authentication by AAAH, HA shall receive RRQ from
PDSN. When HA receives RRQ, HA SHOULD send the RADIUS Access Request
message to fetch with NAI and FAC. Upon receiving the Access Request, AAA
SHOULD generate the MN-HA shared key by using the same parameters
that the MS used. HA will receive MN-HA shared key along with
lifetime. HA MAY optionally sends fetching message along with FAC
and NAI upon every re-registration happens or MAY cache MN-HA shared
key during certain period of time defined in the lifetime of MN-HA
shared secret. The main difference from the first case is that HA
identifies FAC from RRQ and sends Access Request with FAC to AAAH.
In the case of using DIAMETER protocol, the MN-HA Shared Secret will
be sent to HA by the HAR message. [10]
Appendix B - MN-FA shared key consideration
Mobile Node and AAA now can easily derive MN-FA shared key by running
the HMAC-MD5 with input of MN-AAA MN-HA shared secret, FA's IP address, FAC
and MN's NAI. This method has better scalability and less
administrative effort than provisioning MN-FA shared secrets.
In face it is administrative prohibitive to provision all MNs and FAs
with static shared secrets.
References
[1] B. Aboba and M. Beadles. The Network Access Identifier.
Request for Comments (Proposed Standard) 2486, Internet
Engineering Task Force, December January 1999.
[2] C. Perkins. IP Mobility Support. Request for Comments
(Proposed Standard) 2002, Internet Engineering Task Force,
October 1996.
[3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
Challenge/Response Extension. Request for Comments (Proposed
Standard) 3012, Internet Engineering Task Force, December January 2000.
[4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication. Request for Comments
(Informational) 2104, Internet Engineering Task Force,
February 1997.
[5] P. Calhoun and C. E. Perkins. AAA Registration Keys for
Mobile IP Internet Draft, Internet Engineering Task Force.
draft-ietf-mobileip-aaa-key-06.txt (work in progress)
December
January 2001.
[6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication. Request for Comments
(Informational) 2104, Internet Engineering Task Force,
February 1997.
[7] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote
Authentication Dial In User Service (RADIUS). Request for
Comments (Proposed Standard) 2865, Internet Engineering Task
Force, June 2000.
[8] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER
Base Protocol (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-ietf-aaa-diameter-03.txt, May 2001.
[9] P. Calhoun and C. E. Perkins. Mobile IP Network Access
Identifier Extension for IPv4. Request for Comments
(Proposed Standard) 2794, Internet Engineering Task
Force, March 2000
[10] P. Calhoun and C. E. Perkins. Diamter Mobile IP Extensions
Internet Draft, Internet Engineering Task Force.
draft-ietf-aaa-diameter-mobileip-01.txt
Addresses
Questions about this memo can be directed to the authors:
JUNHYUK SONG DongKie Leigh
SAMSUNG ELECTRONICS. SK TELECOM
Mobile Development Team Core Network Development Team
Network Systems Division Network R&D Center
Phone: +82-31-779-6822 Phone +82-2-829-4640
Email: santajun@lycos.co.kr Email: galahad@netsgo.com
FAX: +82-31-7798769 FAX:+82-2-829-4612
Raymond Hsu CHAE YONG CHONG
Qualcomm Inc. SAMSUNG ELECTRONICS.
Corporate R&D Mobile Development Team
Phone: 1-858-651-3623 Network Systems Division
Email: rhsu@qualcomm.com Phone: +82-31-779-6822
FAX: 1-858-658-5006 Email:cychong@samsung.com
Emfro ZuYong Kim
SAMSUNG ELECTRONICS.
Mobile Development Team
Phone: +82-31-779-6764
emfro@samsung.co.kr