JunHyuk Song INTERNET DRAFT ChaeYong Chong 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-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 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, and the FAC issued from a Foreign Agent can provide reasonable randomness. It is possible to use that security association and the FAC to create a security associations between the Mobile Node and its Home Agent. This document specifies a method to dynamically create a shared secret used for MN-HA extension between Mobile Node and Home Agent, based on MN-AAA shared secret, NAI, and Foreign Agent Challenge. Song et al. Expires 04 January 2002 [Page 1]
Internet Draft Mobile IP MN-HA Authentication 04 July 2001 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 ....4 2.1 Mobile IP Agent Advertisement Challenge Extension.............4 2.2 Network Access Identifier (NAI)...............................4 2.3 Master MN-AAA shared secret...................................5 3. MN-HA shared secret creation.......................................5 3.1 MN-HA shared key creation by Mobile Node......................5 3.2 MN-HA shared key creation by AAA..............................5 4. Key Management.....................................................6 4.1 MN-HA key management.........................................7 4.2 DIAMETER consideration........................................8 5. Operation description..............................................9 6. Security Considerations............................................9 Appendix A - 3G Wireless example......................................9 Appendix B - MN-FA shared key consideration..........................11 References...........................................................11 Addresses............................................................12 Song et al. Expires 04 January 2002 [Page 2]
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]. 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 the shared 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, 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 a method to dynamically a create shared secret used for MN-HA extension between Mobile Node and Home Agent, based on the MN-AAA shared secret, NAI, and Foreign Agent 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 RRQ : Mobile IP Registration Request RRP : Mobile IP Registration Reply SPI : Security Parameter Index Key : Shared Secret PDSN : Packet Data Serving Node Song et al. Expires 04 January 2002 [Page 3]
2. The parameters used for Dynamic MN-HA shared secret generation This section defines the parameters used for the session MN-AAA shared secret and MN-HA shared secret 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] Song et al. Expires 04 January 2002 [Page 4]
2.3 MN-AAA shared secret The MN-AAA shared secret is the key used to compute the MN-AAA authentication extension. 3. MN-HA shared secret creation This section describes the MN-HA shared secret creation by the Mobile Node and AAA. 3.1 MN-HA key creation by Mobile Node 1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent Advertisement [3]. 2. The mobile node uses the FA Challenge, its own NAI, and the MN-AAA shared secret to calculate: MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | MN NAI | MN-AAA-key) 3.2 MN-HA shared key creation by AAA 1. AAA identifies Foreign Agent Challenge and the MN's NAI from the AAA message. 2. AAA uses the FA Challenge, MN's NAI, and MN-AAA shared secret to calculate: MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge | MN NAI | MN-AAA-key) Song et al. Expires 04 January 2002 [Page 5]
4. Key Management MN-HA shared 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 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 it SHOULD be greater than the MIP re-registration time. Home Agent MUST fetch the pre-fixed MN-HA shared secret lifetime and MN-HA shared secret from AAAH. The Identification field in Mobile 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 to check the validity of MN-HA shared secret. Song et al. Expires 04 January 2002 [Page 6]
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 timestamp of MN-HA shared key is placed in the high-order 32 bits of MIP RRQ Identification field. This high order bit of Identification field is from MN's own time of day [2]. The high-order 32 bits of MIP RRQ Identification field is used for the HA to configure the expiration time for the MN-HA shared key. The low-order 32 bits of MIP RRQ Identification field MAY be optionally used to enable FA and HA to refresh shared key. 4.1 MN-HA shared key lifetime Management for Dynamic Mobile IP Home Agent Allocation case with RADIUS based AAA (see Appendix A) When HA receives RRQ, the HA fetches MN-HA shared secret from AAA 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 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 to fetch MN-HA shared secret and its lifetime. Song et al. Expires 04 January 2002 [Page 7]
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 message to fetch MN-HA shared secret and its lifetime. After the receipt of MN-HA shared secret and lifetime, Home Agent MUST authenticate the MIP RRQ, and the HA shall set the timer for MN-HA shared secret according to 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 management described in section 4.1 may not be needed for home agent. Because MN 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. Song et al. Expires 04 January 2002 [Page 8]
5. Operation description Home Agent 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 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 the shared secrets. Since this key generation method depends on the key 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 same FAC that used for MN-AAA authentication extension generation. The randomness of FAC depends on random number generator in the 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 cost and time to reverse engineering the value generated by MD5 is not practical, it is not impossible. Therefore in order to counter this potential attack, FAC extension sent from the FA to AAAF SHOULD be authenticated by the 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 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 MN-HA shared secret. This scheme is especially beneficial for the case of dynamic HA allocation. Song et al. Expires 04 January 2002 [Page 9]
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, MS shall create the MN-HA shared secret by running HMAC-MD5 with input of its NAI, Foreign Agent challenge, and MN-AAA key. 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 key with input of NAI, FAC, and MN-AAA shared key. The mobile shall send RRQ with "0.0.0.0" in the 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. Home Agent MAY fetch MN-HA shared key for each re-registration happens or MAY cache MN-HA shared key during certain period of time defined in the lifetime of MN-HA shared secret. Song et al. Expires 04 January 2002 [Page 10]
In the 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 NAI, FAC, and MN-AAA shared key. The mobile shall send RRQ with "0.0.0.0" in the Home Agent Address field. After successful MN-AAA authentication by AAAH, HA shall receive RRQ from PDSN. When HA receives RRQ, HA SHOULD send RADIUS Access Request message 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-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, 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, 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. Song et al. Expires 04 January 2002 [Page 11]
[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) 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 Song et al. Expires 04 January 2002 [Page 12]