1 2 3 4 5

3GPP2 X.S0028-200-0 Version 1.0 Date: March 2007

6 7 8

cdma2000 Packet Data Services; Wireless Local Area Network (WLAN) Interworking; Access to Operator Service and Mobility

10

11

12

COPYRIGHT
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information. 13

X.S0028-200-0 v1.0

3GPP2

1 2 3

Access to Operator Services and Mobility for WLAN Interworking

REVISION HISTORY
Revision X.S0028-200-0 v1.0 Date March 2007 Comments Initial publication

200 - i

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

CONTENTS
1 Introduction ..............................................................................................................................................1 1.1 2 Scope..........................................................................................................................................1

References ................................................................................................................................................2 2.1 2.2 Normative References................................................................................................................2 Informative References ..............................................................................................................3

Definitions, Symbols and Abbreviations..................................................................................................4 3.1 3.2 Definitions..................................................................................................................................4 Symbols and Abbreviations .......................................................................................................4

Architecture..............................................................................................................................................6 4.1 4.2 4.3 Reference Model........................................................................................................................6 Network Entities ........................................................................................................................7 Interfaces....................................................................................................................................8

IP Connectivity for WLAN cdma2000 IP Access....................................................................................9 5.1 5.2 5.3 General.......................................................................................................................................9 Authentication and Authorization ..............................................................................................9 Tunnel Management Procedures..............................................................................................10 5.3.1 Discovery and Selection of a Remote Tunnel Endpoint ............................................10 5.3.2 Tunnel Establishment ................................................................................................10 5.3.3 Tunnel Disconnection................................................................................................14 Authentication Procedures .......................................................................................................19 5.4.1 General.......................................................................................................................19 5.4.2 EAP AKA ..................................................................................................................19 5.4.3 EAP TLS....................................................................................................................22 Mobility Management Procedures ...........................................................................................25 5.5.1 General.......................................................................................................................25 5.5.2 Usage of Mobile IPv4 ................................................................................................25 5.5.3 Usage of Mobile IPv6 ................................................................................................28 5.5.4 Bootstrapping Mechanisms........................................................................................30 cdma2000 Packet Data Service Provision................................................................................32 5.6.1 General.......................................................................................................................32 5.6.2 MMD Service Provision Considerations ...................................................................32 Timers ......................................................................................................................................32 IPv4-IPv6 Dual Stack Operation..............................................................................................32 Diameter Considerations..........................................................................................................33 5.9.1 AVPs..........................................................................................................................33 5.9.2 Result-Code AVP Values ..........................................................................................36 5.9.3 Diameter AVPs for Authentication and Authorization..............................................36 5.9.4 Diameter AVPs for Session Termination and Abort..................................................37 RADIUS Considerations..........................................................................................................37
200 - ii

5.4

5.5

5.6

5.7 5.8 5.9

5.10

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 7 6

5.10.1 5.10.2

3GPP2 Vendor-Specific Attributes (VSA) ................................................................37 RADIUS Attributes for Authentication and Authorization .......................................39

Accounting .............................................................................................................................................41 6.1 6.2 General.....................................................................................................................................41 PDIF Procedures ......................................................................................................................41 6.2.1 RADIUS Support.......................................................................................................41 6.2.2 Diameter Support.......................................................................................................41 RADIUS Attributes for Accounting.........................................................................................42 Diameter AVPs for Accounting...............................................................................................43

6.3 6.4

Appendix Call Flow Examples (Informative) .....................................................................................45 7.1 7.2 MIPv4 FA CoA with Dynamic HA and HoA Assignment ......................................................45 MIPv4 Collocated CoA with Dynamic HA and HoA Assignment..........................................47

200 - iii

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13

LIST OF FIGURES
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Reference model for WLAN Interworking Scenario 3 ............................................................. 6 Reference model for WLAN Interworking Scenario 4 ............................................................. 7 Tunnel establishment flow ...................................................................................................... 11 Tunnel Disconnection Flow .................................................................................................... 15 Tunnel Establishment Flow for EAP AKA............................................................................. 20 Tunnel Establishment Flow for EAP TLS .............................................................................. 23 HA-Request VSA.................................................................................................................... 37 HA-Authorized VSA............................................................................................................... 38 IP-Version-Authorized VSA................................................................................................... 38 MIPv4-Mesg-ID VSA............................................................................................................. 39 MIPv4 MS using FA CoA and requesting for dynamic HA and HoA.................................... 45 MIPv4 using Collocated CoA mode and requesting for dynamic HA and HoA..................... 47

200 - iv

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7

LIST OF TABLES
Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. New IKEv2 CP attributes for MIP .......................................................................................... 30 Diameter cdma2000 WLAN Interworking AVPs................................................................... 35 List of Diameter for Authentication and Authorization .......................................................... 36 List of RADIUS Attributes for Authentication and Authorization ......................................... 39 Supported RADIUS Attributes for Accounting ...................................................................... 42 Supported Diameter AVPs for Accounting............................................................................. 43

200 - v

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

FOREWORD
(This foreword is not part of this Standard.) This document was prepared by 3GPP2 TSG-X. This document is a new specification. This document is part of a multi-part document consisting of multiple parts that together describes cdma2000 Wireless Local Area Network Interworking. This document is subject to change following formal approval. Should this document be modified, it will be re-released with a change of release date and an identifying change in version number as follows: X.S0028-200-X version n.0 where: X an uppercase numerical or alphabetic character [0, A, B, C, ] that represents the revision level. n a numeric string [1, 2, 3, ] that indicates a point release level.

This document uses the following conventions: Shall and shall not identify requirements to be followed strictly to conform to this document and from which no deviation is permitted. Should and should not indicate that one of several possibilities is recommended as particularly suitable, without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. May and need not indicate a course of action permissible within the limits of the document. Can and cannot are used for statements of possibility and capability, whether material, physical or causal.

200 - vi

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10

Introduction
This document defines the procedures for the support of cdma2000 1 IP data connectivity and mobility in Wireless Local Area Network (WLAN) Interworking for cdma2000networks. These procedures correspond to scenarios 3 and 4 as described in WLAN Interworking Stage 1 Requirements [20].

1.1

Scope
The main objective of this document is to provide secure access to the cdma2000 packet data services and inter/intra access mobility to cdma2000 users via a WLAN system operated by a cdma2000 operator or by a WLAN System operator who has a business relationship with one or more cdma2000 operators.

1 cdma2000 is the trademark for the technical nomenclature for certain specifications and standards of

the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States. 200 -1

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

2
2.1

References
Normative References
This section provides references to other specifications and standards that are necessary to implement this document. [1] IEEE 802.11: IEEE Std 802.11 (1999): "Standard for Information Technology Telecommunications and information exchange between systems - Local and Metropolitan Area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications". IETF: RFC 2002, Perkins, IPv4 Mobility, May 1995. IETF: RFC 3775, D. Johnson, C.Perkins, J. Arkko, Mobility Support in IPv6, June 2004. IETF: RFC 1035, P. Mockapetris, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION, November 1987. IETF: RFC 1123, R. Braden, Requirements for Internet Hosts -- Application and Support, October 1989. IETF: RFC 2865, C. Rigney, Remote Authentication Dial In User Service (RADIUS), June 2000. IETF: RFC 2866, C. Rigney, RADIUS Accounting, June 2000. IETF: RFC 3576, M. Chiba, G. Dommety, M. Eklund, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 2003. IETF: RFC 3579, B. Aboba, RADIUS (Remote Authentication Dial In User Service), Support For Extensible Authentication Protocol (EAP), September 2003. IETF: RFC 3588, P. Calhoun, Diameter Base Protocol, September 2003. IETF: RFC 4072, P. Eronen, Diameter Extensible Authentication Protocol (EAP) Application, August 2005. IETF: RFC 4005, P. Calhoun, G. Zorn, Diameter Network Access Server Application, August 2005. IETF: RFC 3948, A. Huttunen, et. al., UDP Encapsulation of IPsec ESP Packets, January 2005. IETF: RFC 2716, B. Aboba, et. al., PPP EAP TSL Authentication Protocol, October 1999. 3GPP2: S.S0055-A v3.0, Enhanced Cryptographic Algorithm, October 2005. IETF: RFC 4306, Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol. December 2005. IETF: RFC 2406, S. Kent, IP Encapsulating Security Payload (ESP), November 1998. IETF: RFC4555, P. Eronen, IKEv2 Mobility and Multihoming Protocol (MOBIKE), June 2006.

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]

200 - 2

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

[19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34]

IETF: RFC 4187, J. Arko, Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), January 2006. 3GPP2: S.R0087-A v1.0, cdma2000 WLAN Interworking, 3GPP2, March 2006. IETF: RFC 2181, R. Elz, R. Bush, Clarifications to the DNS Specification, July 1997. 3GPP2: X.S0028-100-0, Wireless Local Area Network (WLAN) Interworking, March 2007. 3GPP2: X.S0013-004 -A v1.0, All-IP Core Network Multimedia Domain: IP Multimedia Call Control Protocol Based on SIP and SDP Stage 3, November 2005. 3GPP2: X.S0011-D v1.0, cdma2000 Wireless IP Network Standard, March 2006. IETF: RFC 2246, T. Dierks, C. Allen, The TLS Protocol Version 1.0, January 1999. Void. IETF: RFC 4718, P. Eronen, P. Hoffman, IKEv2 Clarifications and Implementation Guidelines, Oct. 2006. IETF: RFC 3162, B. Aboba, G. Zorn, D. Mitton, RADIUS and IPv6, August 2001. Void. 3GPP2: S.S0086-B v1.0, IMS Security Framework, December 2005. Void. Void. IETF: RFC 2548, Microsoft Vendor-specific RADIUS Attributes, March 1999. IETF: RFC 4279, P. Eronen, Pre-Shared Key Ciphersuites for Transport Layer Security (TLS), Dec. 2005.

2.2

Informative References
This section provides references to other documents that may be useful for the reader of this document. No informative reference is identified in this document.

200 - 3

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

Definitions, Symbols and Abbreviations

This section contains definitions, symbols and abbreviations that are used throughout the document.

3.1

Definitions
The following definitions apply for the purposes of this document: cdma2000 packet switched based services: cdma2000 packet switched based services are access independent services provided by the cdma2000 packet switched domain. home cdma2000 network: cdma2000 network managed by the operator with whom the subscriber has a business relationship (subscription). serving cdma2000 network: cdma2000 network that provides IP based data services to the user. The serving cdma2000 network may be a cdma2000 home network or a visited cdma2000 network. visited cdma2000 network: cdma2000 network managed by an operator other than the subscribers cdma2000 home operator and in which the subscriber is receiving service.

3.2

Symbols and Abbreviations

The following definitions apply for the purposes of this document: AAA AN B-AAA DEA DER DNS EAP FQDN H-AAA IKE MAC MIP MS MSK NAI NAT PDIF PRF PS RRQ RRP SA SPI Authentication, Authorization, Accounting Access Network Broker AAA Diameter EAP Answer Diameter EAP Request Domain Name System Extensible Authentication Protocol Fully Qualified Domain Name Home AAA Internet Key Exchange Message Authentication Codes Mobile IP Mobile Station Master Session Key Network Access Identifier Network Address Translation Packet Data Interworking Function Pseudorandom Function Packet Switched Registration Request Registration Reply Security Association Security Parameter Index
200 - 4

X.S0028-200-0 v1.0

3GPP2

1 2 3 4

TIA V-AAA WLAN

Tunnel Inner Address Visited AAA Wireless Local Area Network

200 - 5

X.S0028-200-0 v1.0

3GPP2

1 2 3

4
4.1

Architecture
Reference Model
Serving cdma2000 Network 2 V-AAA B-AAA 2 H-AAA Optional 6 Packet Data Service (Including Internet) 7 PDIF Home cdma2000 Network

Database

HLR/ AC

WLAN 3

5 Internet

4 5

Figure 1

Reference model for WLAN Interworking Scenario 3

200 - 6

X.S0028-200-0 v1.0

3GPP2

Serving cdma2000 Network 2 V-AAA B-AAA 2

Database

Home cdma2000 Network

4 H-AAA Optional

HLR/ AC

9 Packet Data Service (Including Internet) 10

HA 6 8

PDIF

WLAN 3

5 Internet

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Figure 2

Reference model for WLAN Interworking Scenario 4

4.2

Network Entities
The MS, WLAN, V-AAA, B-AAA, H-AAA, Database, and HLR/AC are as described in [22]. In addition to the definitions in [22], the MS and the AAAs perform new functions in order to support tunnel management procedures and mobility procedures. These are described throughout this document. This document defines one additional entity: PDIF: The Packet Data Interworking Function acts as a security gateway protecting resources and packet data services in a serving cdma2000 network from unauthorized access. The PDIF is located in the serving cdma2000 network.

The HA is always located in the serving cdma2000 network. Packet Data Services are higher layer services (e.g., the IMS services) offered by the serving
cdma2000 network.

The serving cdma2000 network may be the cdma2000 home network or a visited cdma2000 network. The PDIF functional entity provides access to packet data services by providing IP connectivity to a cdma2000 operator's network. It supports secure tunnel management procedures between itself and the MS, including establishment and release of the tunnel, allocation of an IP address to the MS from the serving cdma2000 network, and encapsulation and de-capsulation of traffic to and from the MS. It also enforces the serving cdma2000
200 - 7

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

policies such as packet filtering and routing. Through the interface to the H-AAA, the PDIF supports user authentication and transfer of authorization policy information. The PDIF also collects and reports accounting information. The V-AAA is present only when the serving network is a visited cdma2000 operator network. It interacts with the MSs H-AAA and the PDIF, possibly through one or more broker networks, to authenticate and authorize the MS WLAN access services. It also participates in the collection of accounting information and tunnel termination procedures when visited cdma2000 operator policies apply.

4.3

Interfaces
Interfaces 1, 3 and 4 are as described in [22]. This document defines the following new interfaces: Interface 5 between the MS and the PDIF: This is the secure tunnel interface between the MS and the PDIF. This interface supports the MS-initiated tunnel establishment, the transmission of data packets within the tunnel, and tear down of the tunnel. Interface 6 between the PDIF and H-AAA if the PDIF is in the home network or between the PDIF and V-AAA if the PDIF is in the visited network: This interface supports retrieval of configuration parameters from the AAA server to the PDIF, user authentication and authorization at the time of tunnel establishment at the PDIF, accounting data transaction etc. In addition, this document modifies the function of interface 2 as defined in [22] such that, in the case where the PDIF is in the visited network, interface 2 extends interface 6 to the home network. In this case, the VAAA acts as a proxy AAA agent, and relays authentication, tunnel management, and accounting information between the PDIF and H-AAA (possibly via a B-AAA). Mechanisms and requirements for protecting the data over interface 2 are beyond the scope of this document. Interface 7 between the PDIF and Packet Data Services for Simple IP: This interface provides access to cdma2000 packet data services (e.g., IMS). Interface 8 between the PDIF and the HA: In the forward direction, packets received at the HA addressed to the MS roaming in the WLAN are sent toward the MS over this interface. In the reverse direction, packets received from the MS currently roaming in the WLAN and tunneled to the HA are sent across this interface. Interface 9 between the HA and the H-AAA or V-AAA: This interface supports user authentication and authorization parameters from the AAA to the HA. For MIPv4 and MIP6, the HA authentication is defined in [24]. Interface 10 between the HA and Packet Data Services for Mobile IP: This interface provides access to cdma2000 packet data services (e.g., IMS).

200 - 8

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

IP Connectivity for WLAN cdma2000 IP Access

General
Before accessing cdma2000 packet data services, the MS shall gain access to the IP access network. In the case of IEEE 802.11 WLANs, the MS shall perform network selection and association as specified in [22] and [1], respectively. The MS may offer to the subscriber the ability to select between cdma2000 access and WLAN access when both access systems are available. In order to gain access to cdma2000 packet data services, the MS shall initiate the establishment of tunnels as specified in section 5.3. The IPsec tunnel(s) shall be established between the MS and the PDIF. The PDIF may be located either in the home or visited network.

5.1

5.2

Authentication and Authorization

The authentication and authorization to access cdma2000 packet data services is performed when the MS attempts to access cdma2000 packet data services (e.g., IMS). Service authorization is typically independent of WLAN scenario 2 authentication and authorization, see [22]. The H-AAA is the entity that performs authentication and authorization for scenario 3. For authentication and authorization for scenario 3, either RADIUS or Diameter shall be used. For RADIUS, the following RFCs apply: RADIUS [6] RADIUS extensions to support transport of EAP frames over RADIUS [9] Change of Authorization [8]

For Diameter, the following RFCs apply: Diameter Base Protocol [10] Diameter Network Access Server Application [12] Support for transport of EAP frames over Diameter [11]

Detailed authentication and authorization procedures are defined in subsequent sections of this document.

200 - 9

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

5.3

Tunnel Management Procedures

5.3.1

Discovery and Selection of a Remote Tunnel Endpoint

The MS shall either be pre-provisioned with the IP address of the PDIF or use DNS mechanisms to retrieve the IP address (es) of the remote tunnel endpoint, i.e. the PDIF. When building an FQDN for the DNS request, the MS shall identify the operators network. The MS may be pre-provisioned with the FQDNs of one or more PDIFs. If the MS is preprovisioned with more than one FQDN, the selection of using which FQDN is outside the scope of this document. Upon reception of a DNS response containing one or more PDIF IP addresses, the MS shall select a PDIF IP address with the same IP version as its local IP address (i.e. the IP address allocated by the WLAN at successful association). This selection may be performed by the user (MS implementation option) or may be performed automatically by the MS. In the latter case, the criteria for automatic selection are implementation dependent. There are several mechanisms to acquire the IP address of the DNS server that the MS can use in order to discover the PDIF. For IPv4, DHCP may be used. For IPv6, DHCPv6, Anycast address or Router advertisements may be used. The use of any of these mechanisms is an implementation option.

5.3.2

Tunnel Establishment
The tunnel establishment message exchange to setup the IPsec tunnel between the MS and the PDIF is shown in Figure 3

200 - 10

X.S0028-200-0 v1.0

3GPP2

MS

WLAN AN
Access Authentication and Authorization

PDIF

H- AAA

1 2

Access Authentication and Authorization

Obtain Access IP Addr & DNS Addr PDIF Discovery IKE_SA_INIT Exchange IKE_AUTH, CFG_REQUEST RADIUS Access-Request or Diameter EAP-Request

3 4 5 6

7 8

IKE_AUTH, CFG_REPLY (EAP message) IKE_AUTH, CFG_REQUEST (EAP message)

RADIUS Access-Challenge or Diameter EAP-Answer RADIUS Access-Request or Diameter EAP-Request

9 10 11
IKE_AUTH, CFG_REPLY (EAP-Success) IKE_AUTH, CFG_REQUEST (AUTH)

RADIUS Access-Accept or Diameter EAP-Answer

IKE_AUTH, CFG_REPLY (AUTH, TIA)

12
IPsec tunnel

13 14 15
RADIUS Accounting-Request (start) / Accounting-Request (ACR) RADIUS Accounting-Response / Accounting-Answer (ACA)

1 2 3 4 5 6 7 8 9 10 11 12 13 1. 2. 3. Figure 3

Tunnel establishment flow

The MS authenticates to the WLAN Access Network and gets access to the Internet. This might involve the WLAN AN checking with the H-AAA for authorization [22]. The MS obtains an IP address from the Access Network. It also discovers the default router and the DNS server address(es). The MS performs PDIF discovery. If DNS is used, the MS selects one PDIF IP address from the DNS response. The PDIF IP address will always be a global, publicly routable IP address. The MS initiates the IKEv2 exchange with the PDIF. The first set of messages is the IKE_SA_INIT exchange. The MS and PDIF support NAT Traversal as outlined in Section 2.23 of [16], which implies that both the initiator and responder include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP

4.

200 - 11

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 5.

payloads in the first round of messages and support the negotiation of UDP encapsulation. The MS initiates the IKE_AUTH exchange with the PDIF. These messages are encrypted and integrity protected with the keys established through the IKE_SA_INIT exchange. The MS requests a tunnel inner IP address (TIA), by setting the CONFIGURATION payload (CFG_REQ attribute value set to INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS depending on the IP version the MS supports) in the IKE_AUTH request. The MS includes its NAI in the IDi payload. When the MS wants to use EAP, it does not include the AUTH payload in the IKE_AUTH message. When the PDIF receives the IKE_AUTH request without the AUTH payload it contacts the H-AAA to request service authorization and user authentication information by sending the EAP-Response/Identity message in the RADIUS AccessRequest message [9], or Diameter-EAP-Request (DER) Command [11]. EAP messages are exchanged between the MS and the H-AAA for mutual authentication. The H-AAA sends an EAP request message in the RADIUS AccessChallenge or a Diameter-EAP-Answer (DEA) Command to the PDIF. The PDIF sends the IKE_AUTH reply message including the EAP request message to the MS. The MS responds with the IKE_AUTH request message including the EAP response message. The PDIF sends the EAP response message in the RADIUS AccessRequest message or the Diameter-EAP-Request Command to the H-AAA. Steps 7 and 8 can occur multiple times. In case of successful authentication the H-AAA sends the EAP Success in the RADIUS Access-Accept message, or a Diameter-EAP-Answer (DEA) Command with a Result-Code AVP indicating success.

6.

7.

8.

9.

10. Upon reception of a RADIUS Access-Accept message or a Diameter-EAP-Answer (DEA) Command with a Result-Code AVP indicating success, the PDIF sends an IKE_AUTH response message including the EAP Success. If the PDIF receives a RADIUS Access-Reject message or a Diameter-EAP-Answer (DEA) Command with a Result-Code AVP indicating failure, the PDIF rejects the tunnel establishment towards the MS by sending an IKE_AUTH response message with the Notify payload set to AUTHENTICATION FAILED. 11. The MS sends the IKE_AUTH request message including the AUTH payload calculated from the MSK which is generated upon successful EAP authentication. 12. The PDIF replies with the IKE_AUTH response message including an assigned TIA, AUTH payload, security associations, etc. The PDIF uses the MSK to compute the AUTH payload. The PDIF obtains the MSK from H-AAA in step 9. 13. When the IKE_AUTH exchange completes, an IPsec tunnel is established between the MS and the PDIF. The MS and PDIF also support UDP encapsulation of IPsec ESP packets [13] for the case when a NAT is detected in step 3. 14. If RADIUS is used, the PDIF sends RADIUS Accounting Request (Start) to the HAAA; if Diameter is used, the PDIF sends ACR (Start) to the H-AAA. 15. The RADIUS or Diameter H-AAA responds back to the PDIF with RADIUS Accounting Response or Accounting-Answer (ACA) respectively.

200 - 12

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

5.3.2.1

MS Procedures
The MS shall support the NAT traversal per IKEv2 [16] and the UDP encapsulation of IPsec ESP packets [13]. Upon selection of the remote tunnel endpoint, the MS shall initiate Internet Key Exchange [16] in order to establish trusted relationships (i.e., mutual authentication with the PDIF). The MS shall initiate the EAP based authentication procedures as specified in section 5.4 of this document. The MS shall send its NAI in the IDi payload with ID type set to ID_RFC822_ADDR within the IKE_AUTH request. Upon completion of the IKEv2 procedures, the MS shall establish an IPsec ESP tunnel to the PDIF according to [17]. The MS may request a DHCP or DHCPv6 servers IP address by including the INTERNAL_IP4_DHCP or INTERNAL_IP6_DHCP attribute in the CP(CFG_REQUEST) of the IKE_AUTH request.

5.3.2.2

PDIF Procedures
The PDIF IP address shall always be a global, publicly routable IP address. The PDIF shall support the NAT traversal per IKEv2 [16] and the UDP encapsulation of IPsec ESP packets [13]. As initiated by the MS, the PDIF shall perform IKEv2 procedures [16] in order to establish trusted relationships (i.e., mutual authentication) with the MS. The PDIF shall extract the EAP messages received from the MS over IKEv2, and send them to the H-AAA via the RADIUS Access-Request or the DER command. The PDIF shall extract EAP messages received from the H-AAA and send them to the MS over IKEv2. Upon completion of the IKEv2 procedures, the PDIF shall establish an IPsec ESP tunnel between itself and the MS [17]. In case of IPv6 access, the PDIF shall assign either a unique /64 prefix or a full 128-bit IP address to the MS via IKEv2 exchanges. If the MS requests for a DHCP or DHCPv6 servers IP address via the IKE_AUTH request, the PDIF shall convey a DHCP or DHCPv6 servers IP address if available in the INTERNAL_IP4_DHCP or INTERNAL_IP6 DHCP attribute in the CP (CFG_REPLY) of the IKE_AUTH response.

5.3.2.3

H-AAA Procedures
The H-AAA shall authenticate the users credentials identified by the NAI and NAI to perform service authorization.

5.3.2.3.1

Diameter Authentication and Authorization Procedures Upon receipt of a DER command, the H-AAA shall check for the users WLAN subscription information. If there is no subscription information for the user (identified by NAI), the HAAA shall return the DEA command with the Experimental-Result-Code set to DIAMETER_ERROR_USER_ NO_WLAN_SUBSCRIPTION. If the H-AAA has subscription information for the user, the H-AAA shall execute the EAP method with the EAP
200 - 13

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 5.3.2.3.2

peer (in the MS) and exchange EAP messages per [11] with the EAP authenticator (in the PDIF). If the MSs credentials are authenticated successfully, DIAMETER_SUCCESS shall be returned in the Result code AVP via DEA to indicate successful authentication procedure. If the authentication fails, DIAMETER_AUTHENTICATION_REJECTED shall be returned in the Result code AVP via DEA. If the user is roaming (indicated by the presence of the Visited-Network-Identifier AVP), the H-AAA shall check if the user is allowed to access that visited network. If not, ExperimentalResult-Code shall be set to DIAMETER_ERROR_ROAMING_NOT_ALLOWED. RADIUS Authentication and Authorization Procedures Upon receipt of an Access-Request message from the PDIF, the H-AAA shall check for the users WLAN subscription information. If there is no WLAN subscription information for the user (identified by NAI), the H-AAA shall return the RADIUS Access-Reject message. If the H-AAA has WLAN subscription information for the user, and the H-AAA receives an Access-Request containing an EAP-message and Message Authenticator (80), the H-AAA shall execute the EAP method with the EAP peer (i.e., MS) and exchange EAP messages per [9] with the EAP authenticator (i.e., PDIF). If the user has authenticated successfully, the H-AAA shall check to see if the user is roaming. If the user is roaming (for example, indicated by the NAS-IP-Address attribute or NAS-Identifier attribute), the H-AAA shall check whether the user is allowed to access that visited network based on the Home and Visited Networks roaming agreement. If not, the HAAA shall return the RADIUS Access-Reject message. Otherwise, if the user is not roaming or is roaming and is allowed to access that visited network, the H-AAA shall respond with an Access-Accept message containing the EAP message indicating EAP-Success, Message Authenticator (80) and authorization attributes. If user authentication fails, the H-AAA shall respond with an Access-Reject message containing the EAP message indicating EAP-Failure, and Message Authenticator (80).

5.3.2.4

Subsequent Tunnel Establishment

The establishment of multiple tunnels to the same PDIF shall be possible. Once the IKE_SA has been authenticated, more than one child SAs can be negotiated inside the IKE_SA. The CREATE_CHILD_SA exchange is protected using the cryptographic algorithms and keys negotiated in the first two messages of the IKE exchange. Therefore, creation of additional CHILD_SA between the MS and PDIF does not need to trigger further authentication messaging to the H-AAA.

5.3.3

Tunnel Disconnection
Tunnel disconnection may be initiated from the MS or from the PDIF, e.g., because of a timeout of the tunnel connection or a request from the AAA server or other network entities. The tunnel disconnection message exchanges between the MS and the PDIF are performed via IKEv2.

200 - 14

X.S0028-200-0 v1.0

3GPP2

MS

PDIF

H-AAA

INFORMATIONAL request message (DELETE payload) INFORMATIONAL response message (DELETE payload)

MS initiated tunnel disconnection

RADIUS Accounting-Request (stop) /Session-Termination-Request (STR), Accounting Request (ACR) RADIUS Accounting-Response (stop) /Session-Termination-Answer (STA), Accounting-Answer (ACA)

1 PDIF initiated tunnel disconnection

INFORMATIONAL request message (DELETE payload) INFORMATIONAL response message (DELETE payload)

RADIUS Accounting-Request (stop) /Session-Termination-Request (STR), Accounting-Request (ACR) RADIUS Accounting-Response (stop) /Session-Termination-Answer (STA), Accounting-Answer (ACR)

RADIUS Disconnect-Request /Abort-Session -Request (ASR) RADIUS Disconnect-Response /Abort-Session -Answer (ASA)

3 H-AAA initiated tunnel disconnection

INFORMATIONAL request message (DELETE payload)

INFORMATIONAL response message 4

RADIUS Accounting-Request (stop) /Session-Termination-Request (STR), Accounting-Request (ACR) RADIUS Accounting-Response (stop) /Session-Termination-Answer (STA), Accounting-Answer (ACA)

1 2 3 Figure 4 Tunnel Disconnection Flow 2

The RADIUS Accounting Request (stop) message or Diameter STR command is sent when IKE_SA is deleted.
200 - 15

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

MS Initiated Tunnel Disconnection 1. To disconnect one or more IPsec tunnels (SA(s)), the MS sends an IKEv2 INFORMATIONAL request message containing a DELETE payload including the SA(s) to be deleted (# of SPIs attribute set to the number of SAs to be deleted and SPI(s) attribute identifying the SA(s) to be deleted) if it wants to delete SA for a single protocol e.g. ESP. If the MS wants to delete SAs for more than one protocol (e.g. IKE and ESP), the MS includes multiple delete payloads each containing SPIs corresponding to each of the protocols. The PDIF sends an IKEv2 INFORMATIONAL response message to the MS containing a DELETE payload including the SA(s) deleted in step 1 (# of SPIs attribute set to the number of SAs deleted and SPI(s) attribute identifying the SA(s) deleted) if it wants to delete SA for a single protocol e.g. ESP. If the PDIF wants to delete SAs for more than one protocol (e.g. IKE and ESP), the PDIF includes multiple delete payloads each containing SPIs corresponding to each of the protocols. The PDIF updates the related service information and/or status of the subscriber. When the IKE_SA with the MS is deleted, the PDIF informs the H-AAA that the session is being terminated by sending an Accounting-Request message with AcctStatus-Type set to Stop when RADIUS protocol [7] is used, or a SessionTermination-Request (STR) Command and an Accounting-Request (ACR) Command when Diameter protocol [10] is used. The H-AAA checks whether the user is known and whether it has an active session, if the check is successful it sends an Accounting-Response message with AcctStatus-Type set to Stop when RADIUS protocol [7] is used, or a SessionTermination-Answer (STA) Command and an Accounting-Answer (ACA) Command when Diameter protocol [10] is used.

2.

3.

4.

Note that steps 2 and 3 in the call flow may happen in parallel. PDIF Initiated Tunnel Disconnection 1. The PDIF sends an IKEv2 INFORMATIONAL request message to the MS containing a DELETE payload including the SA(s) to be deleted (# of SPIs attribute set to the number of SAs to be deleted and SPI(s) attribute identifying the SA(s) to be deleted) if it wants to delete SA for a single protocol e.g. ESP. If the PDIF wants to delete SAs for more than one protocol (e.g. IKE and ESP), the PDIF includes multiple delete payloads each containing SPIs corresponding to each of the protocols. The MS sends an IKEv2 INFORMATIONAL response message to the PDIF containing a DELETE payload including the SA(s) deleted in step 3 (# of SPIs attribute set to the number of SAs deleted and SPI(s) attribute identifying the SA(s) deleted) if it received a request to delete SA for a single protocol e.g. ESP. If it received a request to delete SAs for more than one protocol (e.g. IKE and ESP), the MS includes multiple delete payloads each containing SPIs corresponding to each of the protocols. The PDIF updates the related service information and/or status of the subscriber. When the IKE_SA with the MS is deleted, the PDIF initiates a session termination exchange with the H-AAA. The PDIF informs the H-AAA that the session is being terminated by sending an Accounting-Request message with Acct-Status-Type set to Stop when RADIUS protocol [7] is used, or a Session-Termination-Request (STR) Command and an Accounting-Request (ACR) Command when Diameter protocol [10] is used.
200 - 16

2.

3.

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

4.

The H-AAA checks whether the user is known and whether it has an active session, if the check is successful it sends an Accounting-Response message with AcctStatus-Type set to Stop when RADIUS protocol [7] is used, or a SessionTermination-Answer (STA) Command and an Accounting-Answer (ACA) Command when Diameter protocol [10] is used.

Note that steps 1 and 3 in the call flow may happen in parallel. H-AAA Initiated Tunnel Disconnection 1. The H-AAA initiates a session termination exchange with the PDIF to disconnect all IPsec tunnels (SA(s)) [8]. The H-AAA informs the PDIF that the session is terminated by sending a Disconnect-Request message [8] when RADIUS protocol is used, or an Abort-SessionRequest (ASR) Command when Diameter protocol [10] is used. The PDIF checks whether the user is known and whether it has an active session, if the check is successful it sends to the H-AAA a Disconnect-ACK message [8] when RADIUS protocol is used, or an Abort-SessionAnswer (ASA) Command when Diameter protocol [10] is used. The PDIF sends an IKEv2 INFORMATIONAL request message to the MS containing a DELETE payload with protocol ID set to 1 (IKE). The MS sends an IKEv2 INFORMATIONAL response message without a DELETE payload [27]. The PDIF updates the related service information and/or status of the subscriber. Upon reception of the IKEv2 INFORMATIONAL response message, the PDIF informs the H-AAA that the IPsec tunnel has been terminated by sending an Accounting-Request message with Acct-Status-Type set to Stop when RADIUS protocol [7] is used, or a Session-Termination-Request (STR) Command and an Accounting-Request (ACR) Command when Diameter protocol [10] is used. The H-AAA sends an Accounting-Response message with Acct-Status-Type set to Stopwhen RADIUS protocol [7] is used, or a Session-Termination-Answer (STA) Command and an Accounting-Answer (ACA) Command when Diameter protocol [10] is used.

2.

3. 4.

5.

6.

Note that steps 2, 3, and 5 in the call flow may happen in parallel.

5.3.3.1

MS Procedures
The MS shall use the procedures defined in IKEv2 [16] to delete one or more IPsec tunnel (s) to the PDIF.

5.3.3.2

PDIF Procedures
PDIF shall use the procedures defined in IKEv2 [16] to delete one or more IPsec tunnel(s) to the MS. Upon reception of an IKEv2 INFORMATIONAL request message from the MS including "DELETE" payload to delete IKE_SA, the PDIF shall treat this as a request to delete all SAs (IKE and child IPsec SAs) and send a RADIUS Accounting-Request (Stop) message or the Diameter Session-Termination-Request and Accounting-Request commands to the H-AAA. If the PDIF receives an IKEv2 INFORMATIONAL request message that includes DELETE
200 - 17

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

payload to delete the last IPsec SA without deleting IKE_SA, the PDIF shall delete the IKE_SA in addition to the last IPsec SA, and the PDIF shall send the RADIUS AccountingRequest (Stop) message or the Diameter Session-Termination-Request command to the HAAA. If the DELETE payload does not contain a SPI corresponding to the IKE protocol, the PDIF shall not send the RADIUS Accounting-Request (Stop) message or the Diameter Session-Termination-Request command. In this case, the PDIF shall only initiate removal of the SA that is identified by the SPI in the DELETE payload. Regardless of the response of the H-AAA, the PDIF shall delete the incoming and outgoing SAs corresponding to the SPIs in the received DELETE payload and it shall send an IKEv2 INFORMATIONAL response message to the MS. This message shall contain a DELETE payload listing the Security Associations that are deleted in the outgoing direction (i.e. PDIF to MS). In the case of a simultaneous INFORMATIONAL exchange for SA removal by both the MS and the PDIF, the INFORMATIONAL message responses from both the MS and the PDIF shall not contain any DELETE payload (ref section 1.4 of [16]). Upon reception of either the RADIUS Disconnect-Request message or Diameter AbortSession-Request command from the H-AAA (for the H-AAA initiated tunnel disconnection), the PDIF shall check whether the subscriber has any active SA(s). If the check indicates that the referenced SAs exist, the PDIF shall send the RADIUS Disconnect-Response message or Diameter Abort-Session-Answer command with Result-Code AVP set to DIAMETER_SUCCESS to the H-AAA and perform tunnel disconnection procedures for all the IPsec SA(s) and IKE_SA by sending the IKEv2 INFORMATIONAL request message with Protocol ID set to 1 (IKE) in the DELETE payload to the MS. Otherwise, the PDIF shall send a RADIUS Disconnect-NAK or Diameter Abort-Session-Answer with Result-Code AVP set to DIAMETER_UNKNOWN_SESSION_ID or DIAMETER_UNABLE_TO_COMPLY to the H-AAA. Upon receiving IKEv2 INFORMATIONAL response from the MS with DELETE payloads, the PDIF shall send a RADIUS Accounting-Request (Stop) message or a Diameter Session-Termination-Request and Accounting-Request commands to the H-AAA. If the PDIF does not receive IKEv2 INFORMATIONAL response from the MS, it shall resend the INFORMATIONAL message with the same DELETE payloads that it sent before. After resending the INFORMATIONAL message to the MS for configurable number of times (e.g., using exponential backoff algorithm), if the PDIF still does not receive any response from the MS, the PDIF assumes that the MS has disconnected and remove all incoming and outgoing SAs for the MS. If the PDIF receives IKEv2 INFORMATIONAL response from the MS without any DELETE payload, the PDIF shall remove all the SAs corresponding for the MS.

5.3.3.3

H-AAA Procedures
The H-AAA initiated tunnel disconnection is used by the H-AAA when the WLAN subscription for the user to access cdma2000 packet data services has been deleted/prohibited or if the particular session needs to be terminated for any reason and the PDIF needs to be updated with respect to these changes. In this case, the H-AAA shall instruct the PDIF to disconnect a particular session for a specific user by sending the RADIUS DisconnectRequest or Diameter Abort-Session-Request message. If the H-AAA receives the RADIUS Accounting-Request (Stop) message or the Diameter Session-Termination-Request and Accounting-Request commands from the PDIF indicating successful tunnel termination for that service and subscriber, it shall send the RADIUS Accounting-Response (Stop) message or the Diameter Session-Termination-Answer and Accounting-Answer commands to the PDIF. The H-AAA shall update the related service information and/or status of the subscriber.

200 - 18

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10

5.4

Authentication Procedures

5.4.1

General
The MS shall support either EAP-AKA or EAP-TLS with pre-shared key for IKEv2 authentication. The H-AAA shall support EAP-AKA and EAP-TLS with pre-shared key. (The EAP method is transparent to the PDIF.) The V-AAA shall act as a stateful proxy between the PDIF and H-AAA.

5.4.2

EAP AKA
This section illustrates the mechanism for authenticating the MS using EAP-AKA [19] during IPsec tunnel establishment.

200 - 19

X.S0028-200-0 v1.0

3GPP2

MS

PDIF

H-AAA

0 1 2

IKE_SA_INIT IKE_AUTH Request [IDi, IDr, SAs, Traffic selectors] EAP Response Identity Generate AUTN, RAND EAP-Request/AKA- Challenge [RAND, AUTN and AT_MAC] IKE_AUTH Response [EAP-Request/AKA- Challenge] IKE_AUTH Request [EAP-Response/AKA-Challenge] EAP-Response/AKA-Challenge [AT_RES and AT_MAC] EAP Success [MSK] AUTH computed from MSK

4 5 6 7 8

9 10

IKE_AUTH Response [EAP Success] IKE_AUTH Request [AUTH] IKE_AUTH Response [Header, AUTH, Sec. Associations, Traffic selectors] Figure 5 0. 1. Tunnel Establishment Flow for EAP AKA

11 1 2 3 4 5 6 7 8 9 10 11 12 13

The MS and the PDIF exchange IKE_SA_INIT messages. The MS initiates IKE_AUTH exchange with the PDIF. The MS omits the AUTH payload in order to indicate to the PDIF that it wants to use EAP over IKEv2. The MS includes its identity in the IDi payload of the IKE_AUTH request. When the PDIF receives the IKE_AUTH request, it sends the EAP Response Identity (containing the user identity) to the H-AAA, via the Diameter-EAP-Request (DER) Command [11]or RADIUS Access-Request message [9]. The H-AAA decides whether EAP-AKA authentication is suitable based on the user profile or on the indication from the MS on the preferred authentication mechanism (see [19], section 4.1.1.6). The PDIF generates a random value RAND and AUTN based on the shared WKEY and a sequence number.
200 - 20

2.

3.

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

4.

The H-AAA sends the EAP-Request/AKA Challenge to the PDIF, via the DIAMETER-EAP-Answer command or RADIUS Access-Challenge. The EAPRequest/AKA Challenge contains the AT_RAND, AT_AUTN and the AT_MAC attribute to protect the integrity of the EAP message. The PDIF sends an IKE_AUTH Response to the MS that contains the EAPRequest/AKA-Challenge message received from the H-AAA. The MS verifies the authentication parameters in the EAP-Request/AKA-Challenge message and if the verification is successful, it responds to the challenge with an IKE_AUTH Request message to the PDIF. The main payload of this message is the EAP-Response/AKA-Challenge message. If the verification is not successful, the MS re-initiates the IKEV2 AUTH or aborts the IKEv2 exchange. The PDIF forwards the EAPResponse/AKA-Challenge message to the H-AAA via either RADIUS Access-Request message or Diameter DER command. In case of successful authentication the H-AAA sends a RADIUS Access-Accept message with EAP-Message attribute containing EAP Success when the RADIUS protocol is used or a DiameterEAP-Answer command with a Result-Code AVP indicating success when Diameter is used. The H-AAA sends to the PDIF the EAP Success and the MSK generated during the EAP-AKA authentication process [19]. In the case of RADIUS, as per EAP AKA [19], the 64-byte MSK is split into two 32byte parts with the first 32-bytes sent in the MS-MPPE-REC-KEY [33] and the reaming 32-bytes sent in the MS-MPEE-SEND-KEY [33]. Both of these attributes are needed to construct the 64-byte MSK at the PDIF. If any of those are missing, the PDIF rejects the session. In the case of Diameter, the entire MSK 64-byte key is transmitted in the EAP-Master-Session-Key AVP. The PDIF forwards the EAP success message to the MS in an IKE_AUTH Response message.

5. 6.

7. 8.

9.

10. The MS calculates the MSK according to [19] and uses it as an input to generate the AUTH payload to authenticate the first IKE_SA_INIT message. The MS sends to the PDIF the AUTH payload in an IKE_AUTH Request message. 11. The PDIF uses the MSK to check the correctness of the AUTH payload received from the MS and calculates its own AUTH payload for the MS to verify [16]. The PDIF sends the AUTH payload to the MS together with the configuration payload containing security associations and the rest of the IKEv2 parameters in the IKE_AUTH Response message, and the IKEv2 negotiation terminates.

5.4.2.1

Tunnel Re-authentication
EAP fast re-authentication is specified in [19] and it is an optional mechanism for both the MS and the H-AAA. If the MS or the H-AAA wish to use EAP fast re-authentication and they support it, they shall proceed as follows: In step 1 above, the MS shall include the re-authentication ID in IKE_AUTH request instead of the permanent identity. The H-AAA shall use the presence of the re-authentication ID in this message as an indication that the MS wishes to perform fast re-authentication. In step 4 above, the H-AAA shall initiate the fast re-authentication challenge by sending the EAP-Request/AKA-Reauthentication message to the PDIF.

200 - 21

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Steps 5, 6 and 7 above are the same except that the EAP-Request (or Response)/AKAReauthentication messages are passed instead of the EAP-Request (or Response)/AKAChallenge messages as used in full authentication.

5.4.3

EAP TLS
This section illustrates the mechanism for authenticating the MS using TLS-PSK [34]and EAP-TLS as defined in [14] over EAP during IPsec tunnel establishment. In the flow given in the following figure, the MS (the EAP supplicant) and the H-AAA (the authentication server), will establish a 64-bytes long Master Session Key (MSK) that the MS calculates and the H-AAA distributes to the PDIF (the authenticator) to perform IKEv2 authentication. 1. 2. A master_secret is calculated from a pre-shared secret known by the MS and the HAAA according to [34]. The master_secret along with other data exchanged between the MS and the H-AAA is then used by the MS and H-AAA to calculate the MSK according to [22] section 7.1.2.3 and 7.1.2.4 with the following additional consideration. The MSK to be used for IKEv2 authentication is derived by truncating the first 64 bytes of the PRF output defined in the specification for the version of TLS in use for key generation. Note that [34] does not define MSK generation for authentication between EAP supplicant (peer) and the EAP authenticator. This additional requirement is added in this document on the EAP server and the EAP supplicant. 3. 4. Upon successful EAP authentication, the H-AAA distributes the 64-bytes long MSK to the PDIF. The MSK is then used by the PDIF and the MS to complete IKEv2 authentication.

200 - 22

X.S0028-200-0 v1.0

3GPP2

MS

PDIF

H-AAA

0 1 2 3 4 5 6 7 8

IKE_SA_INIT IKE_AUTH Request [IDi, IDr, SAs, Traffic selectors] EAP Response Identity EAP Request [EAP-Type = EAP-TLS, TLS Start]

IKE_AUTH Response EAP_Request[EAP-Type = EAP-TLS, TLS Start] IKE_AUTH Request EAP_Response[TLS client_hello]

EAP-Response [TLS client_hello] EAP Request [TLS server_hello, TLS_server_key_exchange, TLS_server_hello_done]

IKE_AUTH Response [TLS server_hello, TLS_server_key_exchange, TLS_server_hello_done] IKE_AUTH Request EAP_Respone [TLS_client_key_exchange, TLS_change_cipher_spec, TLS finished]

9 10

EAP Response [TLS_client_key_exchange, TLS_change_cipher_spec, TLS finished] EAP Request [TLS_change_cipher_spec, TLS finished]

11 12 13 14 15 16 17 18 1 2 3 0. Figure 6
IKE_AUTH Response [EAP Success] IKE_AUTH Request [AUTH] IKE_AUTH Response [Header, AUTH, SAs, Traffic selectors] IKE_AUTH Response [TLS_change_cipher_spec, TLS finished] IKE_AUTH Request EAP Response

EAP-Response EAP Success [MSK]

Tunnel Establishment Flow for EAP TLS

The MS and the PDIF exchange IKE_SA_INIT messages.

200 - 23

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

1.

The MS initiates IKE_AUTH exchange with the PDIF. The MS omits the AUTH parameter in order to indicate to the PDIF that it wants to use EAP over IKEv2. The MS includes its identity in the IDi payload of in an IKE_AUTH request. When the PDIF receives the IKE_AUTH request, it sends the EAP Response Identity (containing the user identity) to the H-AAA, via the Diameter-EAP-Request (DER) Command [11]or RADIUS Access-Request message including the EAP-Message attribute and the Message-Authenticator attribute[9]. The H-AAA verifies the identity and decides what type of authentication is suitable based on the user profile. If it determines that EAP-TLS is the preferred method, the H-AAA sends a TLS-Start as an indication that the client begins the TLS negotiation process. If Diameter is used, Diameter-EAP-Answer (DEA) Command [11] is used. If RADIUS is used, a RADIUS Access-Challenge message including a RADIUS EAP-Message [9] is used. The PDIF sends an IKE_AUTH Response that contains the EAP-Request/TLS-Start message received from the H-AAA, to the MS. The MS responds by sending the TLS EAP Response containing a ClientHello message to the PDIF via an IKE_AUTH Request. The ClientHello message includes a NULL session identifier (to be set by the server). The MS indicates its willingness to use pre-shared key authentication by including one or more of the supported PSK cipher-suites [34] in the Client Hello TLS record. The PDIF forwards the EAP response to the H-AAA in the appropriate Diameter or RADIUS message. The H-AAA examines the parameters sent by the MS. In response it sends an EAP Response containing a TLS ServerHello message. This message indicates that the HAAA was able to identify an acceptable (set of) algorithms from the set sent by the MS, the highest mutually acceptable TLS version, its own set of random bytes, a session_id to identify the new session, a single cipher-suite from the list sent in the ClientHello, and the single compression method from the list in the ClientHello. The H-AAA may also send a TLS Server_Key_Exchange message with a PSK identity hint providing a hint to the client about which identity to use in selecting the Preshared secret. Finally, the H-AAA sends the server hello done message to indicate the end of the server hello and associated messages. The PDIF sends an IKE_AUTH Response that contains the EAP-Request/TLS ServerHello and associated messages received from the H-AAA, to the MS. The MS calculates the master secret, according to [34], using the random values from the calculated premaster secret, and the client.hello and server.hello messages. The MS responds by sending an IKE_AUTH Request containing an EAP Response message. The EAP Response message contains the identity of the Pre-shared Secret in the TLS ClientKeyExchange message. The MS also includes the change_cipher_spec message indicating that subsequent data will be sent using the agreed upon key and cipher suites. Finally the MS includes the TLS finished message. The finished message is protected with the just-negotiated algorithms, key, and secrets. Recipients of finished messages must verify that the contents are correct.

2.

3.

4. 5.

6. 7.

8.

9.

10. The PDIF forwards the EAP response to the H-AAA in the appropriate Diameter or RADIUS message. 11. The H-AAA verifies the TLS finished message from the MS. If it verifies correctly, the H-AAA sends an EAP Request containing the change_cipher_spec message and a finished message.

200 - 24

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

12. The PDIF encapsulates the EAP Request in an IKE_AUTH Response message and forwards the message to the MS. 13. The MS verifies the TLS Finished message from the server and if it is correct will send an EAP Response message to the server containing no data. 14. The PDIF sends the EAP response to the H-AAA. 15. The H-AAA calculates the MSK according to 5.4.3. The H-AAA sends an EAP Success message along with the MSK to the PDIF. If RADIUS is used, a RADIUS Access-Accept message is used and the first 32 bytes of the MSK (PRF(0,31)) is sent in the MS-MPPE-Recv-Key attribute and the second 32 bytes of the MSK (PRF(32,63) is sent in the MS-MPPE-Send-Key attribute. If Diameter is used, a DIAMETER-EAP-Answer (DEA) command is used and the MSK is sent in the EAP-Master-Session-Key AVP. 16. PDIF sends the EAP-Success message in the IKE AUTH response. 17. The MS calculates the MSK according to 5.4.3 and uses it as an input to generate the AUTH payload to authenticate the first IKE_SA_INIT message. The MS sends to the PDIF the AUTH payload in an IKE_AUTH Request message. 18. The PDIF uses the MSK to check the correctness of the AUTH payload received from the MS and then calculates its own the AUTH payload for the MS to verify. The PDIF sends the AUTH payload together with the configuration payload for the IPsec security association and the rest of the IKEv2 parameters in the IKE_AUTH Response message, and the IKEv2 negotiation ends here if the MS only needs one child SA.

5.5

Mobility Management Procedures

5.5.1

General
MOBIKE [18] shall be used to provide mobility for the IPsec tunnel within WLAN ANs. For mobility to/from other ANs of a different access technology, Mobile IP [2], [3] shall be supported. Handoff between and within access technologies (i.e. WLAN, cdma2000) shall be possible in automatic and manual mode. In automatic mode the trigger for the handoff might be, for example, loss/decrease of signal strength. In this case the MS automatically executes the transition between WLAN and cdma2000 access technologies (based for example, on operator preferences). In the manual mode case the trigger could be, for example, different service charges or better QoS. In this case, a list of available access technologies shall be provided upon users request.

5.5.2

Usage of Mobile IPv4

5.5.2.1

MS Procedures
For Mobile IPv4 (MIPv4) access, the MS shall either use Foreign Agent Care-of-Address (FA CoA) mode or use Collocated Care-of-Address (CCoA) mode.

200 - 25

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 5.5.2.1.2 5.5.2.1.1

The MS shall support [18]. Initial MIPv4 Session Establishment with MIPv4 Bootstrap For the FA CoA mode, during the IKEv2 exchange, the MS shall include the INTERNAL_IP4_ADDRESS attribute (with length set to zero) and the 3GPP2_MIP4_MODE attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message. For the CCoA mode, during the IKEv2 exchange, the MS shall include the INTERNAL_IP4_ADDRESS attribute (with length set to zero) in the CP(CFG_REQUEST) in the IKE-AUTH message. The MS shall not include the 3GPP2_MIP4_MODE attribute. For the FA CoA mode and CCoA mode, if the MS wants to bootstrap HA, the MS shall include the 3GPP2_MIP4_HA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message. If the MS receives the 3GPP2_MIP4_HA attribute (set to a nonzero value) in the CP(CFG_REPLY) of the IKE_AUTH message, the MS shall use this value in the Home Agent field of the RRQ regardless of whether it sent a request to bootstrap HA with a different HA address or whether it did not send a request to bootstrap HA. If the MS receives the 3GPP2_MIP4_HA attribute (with length set to zero) in the CP(CFG_REPLY) or if the 3GPP2_MIP4_HA attribute is missing in the CP (CFG_REPLY) and the MS does not have preconfigured HA information, the MS may fallback to the Simple IPv4 access mode using the assigned TIA received in the INTERNAL_IP4_ADDRESS attribute of the CP(CFG_REPLY). For the CCoA mode, if the MS obtains an assigned HA address in the 3GPP2_MIP4_HA attribute of the CP(CFG_REPLY), the MS shall perform MIPv4 registration using the assigned TIA as the CoA, which is received in the INTERNAL_IP4_ADDRESS attribute of the CP(CFG_REPLY). If the MS wants to bootstrap HoA, the MS shall set the Home Address field of the RRQ to zero during MIPv4 registration and obtain a HoA in RRP as specified in [24]. For the FA CoA mode, upon receiving Agent Advertisements from the PDIF, the MS shall perform MIPv4 registration as specified in [24]. If the MS wants to bootstrap HoA, the MS shall set the Home Address field of the RRQ to zero during MIPv4 registration. After the MS obtains a HoA in the RRP, the MS shall send the CREATE_CHILD_SA message with the Traffic Selector payload for initiator (TSi) equal to the HoA. This IKEv2 exchange creates a new IPsec SA for the HoA. Initial MIPv4 Session Establishment with Static HoA and HA When the MS initiates a MIPv4 session with static HoA and HA, the MS shall not request for MIP bootstrap information. If the MS wants a specific HA to be assigned to it for MIPv4 registration, the MS shall include the 3GPP2_MIP4_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message and set the value of the attribute to that HA address. If the MS wants to use the FA CoA mode, during the IKEv2 exchange, the MS shall include the INTERNAL_IP4_ADDRESS attribute (set to HoA) and the 3GPP2_MIP4_MODE attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message. Upon receiving Agent Advertisements from the PDIF, the MS shall perform MIPv4 registration as specified in[24]. If the MS wants to use the CCoA mode, during the IKEv2 exchange, the MS shall include the INTERNAL_IP4_ADDRESS attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message. Upon IKEv2 completion, the MS shall perform MIPv4
200 - 26

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 5.5.2.1.3

registration using the assigned TIA as the CoA, which is received in the INTERNAL_IP4_ADDRESS attribute of the CP(CFG_REPLY). MIPv4 Session Handoff When the MS performs handoff from cdma2000 access to WLAN access (i.e. vertical handoff from PDSN to PDIF), the MS shall not request for MIP bootstrap information. The MS behaviors are the same as section 5.5.2.1.2. When the MS performs handoff from WLAN to cdma2000 access, the MS is not required to use the IPsec tunnel over cdma2000 access with the PDIF. When the MS performs handoff between two WLAN systems, the MS shall use [18] to update the IPsec SA(s) with the PDIF.

5.5.2.2

PDIF Procedures
For Mobile IPv4 access, the PDIF shall support FA CoA mode. The operator shall be able to enable and disable FA CoA mode of operation in the PDIF. If the PDIF receives the 3GPP2_MIP4_MODE attribute while the operator has disabled the FA CoA mode of operation in the PDIF, the PDIF shall send the Notify Payload with Notify Message Type set to 8192 (Private Use Errors) in the IKE_AUTH Response message. The Notify Message Type 8192 is specific to 3GPP2 to indicate that the FA CoA mode of operation in the PDIF is disabled. Upon receiving the Notify Message Type 8192, the MS may use the CCoA mode or may fallback to the Simple IP access mode using the assigned TIA received in the INTERNAL_IP4_ADDRESS attribute of the CP(CFG_REPLY). During the IKEv2 exchange, if the PDIF receives the INTERNAL_IP4_ADDRESS attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message, the PDIF shall assign a TIA from the address pool managed locally by the PDIF and shall convey the TIA in the INTERNAL_IP4_ADDRESS attribute of the CP(CFG_REPLY) of the IKEAUTH message. During the IKEv2 exchange, if the PDIF receives the INTERNAL_IP4_ADDRESS attribute (set to a non-zero IPv4 address) and the 3GPP2_MIP4_MODE attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message, the PDIF shall accept this address 3 as the TIA and shall convey the TIA in the INTERNAL_IP4_ADDRESS attribute of the CP(CFG_REPLY) of the IKE-AUTH message. During the IKEv2 exchange, if the PDIF receives the 3GPP2_MIP4_MODE attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message, after the IKEv2 is completed with the MS, the PDIF shall send Agent Advertisements to the MS according to [24]. If the PDIF does not receive the 3GPP2_MIP4_MODE attribute from the MS, the PDIF shall not send Agent Advertisements to the MS, unless the PDIF receives Agent Solicitation from the MS. During the IKEv2 exchange, if the PDIF receives from the H-AAA an HA address in the Home-Agent VSA of the RADIUS Access-Accept or in the Home-Agent AVP of the DEA command, the PDIF shall convey that address in the 3GPP2_MIP4_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message, regardless of whether the PDIF has received from the MS the 3GPP2_MIP4_HA attribute (with length set to zero or non-zero) in the CP(CFG_REQUEST) of the IKE_AUTH message. During the IKEv2 exchange, if the PDIF receives the 3GPP2_MIP4_HA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message, the PDIF shall perform

3 How the PDIF supports this address is for further study.

200 - 27

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 5.5.3.2.1

the dynamic HA assignment as specified in section 5.5.4.2. If the PDIF receives the 3GPP2_MIP4_HA attribute with a non-zero length, the PDIF shall convey the information to the H-AAA. For the FA CoA mode, if the PDIF receives the RRQ from the MS, the PDIF shall request the H-AAA to authenticate the MN-AAA authenticator as specified in [24]. Before successful completion of the Mobile IP registration, the PDIF shall allow only the corresponding RRP to be sent to the MS and shall discard all other packets destined for the MS. After successful completion of the Mobile IP registration, when the MS uses the CREATE_CHILD_SA message exchange to create a new IPsec SA for the HoA, the PDIF should send the Delete payload in the IKEv2 INFORMATIONAL message to delete the old IPsec SA associated with the previously assigned TIA. The PDIF shall support [18].

5.5.3

Usage of Mobile IPv6

The MS may obtain the Home Agent and Home addresses in one of two fashions. One, the MS may use MIP6 bootstrapping (as defined in section 5.5.3.2.1), or two, the MS may be preprovisioned with static HA and Home addresses (as defined in section 5.5.3.2.2). Once the MS obtains the HA address and HoA, upon IKEv2 completion, the MS shall perform MIP6 registration using the assigned TIA as the CoA, which is received in the INTERNAL_IP6_ADDRESS attribute of the CP(CFG_REPLY).

5.5.3.1

MIP6 Session Establishment when PDIF and HA are Collocated

When the PDIF and HA are collocated the MS shall establish an IPsec tunnel with the PDIF/HA via IKEv2, as specified in section 5.3.2. The MS does not need to establish an additional IPsec tunnel to the HA because the MIP6 signaling messages are protected by the IPsec tunnel between the MS and PDIF. All traffic in this single IPsec tunnel shall be protected by IPsec ESP in tunnel mode with a non-null encryption algorithm.

5.5.3.2

MS Procedures

Initial MIP6 Session Establishment with MIP6 Bootstrap During the IKEv2 exchange, the MS shall include the INTERNAL_IP6_ADDRESS attribute (with length set to zero) in a CP(CFG_Request) payload of the IKE-AUTH message. If the MS wants to bootstrap HA, the MS shall include the 3GPP2_MIP6_HA attribute (with length set to zero) in the CP(CFG_REQUEST) regardless of whether it requested the same info in the CP (CFG_REQUEST) of the IKE_AUTH message. If the MS receives the 3GPP2_MIP6_HA attribute (set to a non-zero value) in the CP(CFG_REPLY) of the IKE_AUTH message, the MS shall use this value as the assigned HA address in MIP6 registration. If the MS receives the 3GPP2_MIP6_HA attribute (with length set to zero) or if this attribute is missing in the CP(CFG_REPLY), the MS may use DHCPv6 to bootstrap HA [24] or fallback to the Simple IP access mode using the assigned TIA received in the INTERNAL_IP6_ADDRESS attribute of the CP(CFG_REPLY). If the MS wants to bootstrap HoA, the MS shall include the 3GPP2_MIP6_HOA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message. If the MS receives the 3GPP2_MIP6_HOA attribute (set to a non-zero value) in the CP(CFG_REPLY) regardless of whether it requested the same info in the CP (CFG_REQUEST) of the IKE_AUTH message, the MS shall verify whether the binary format of the non-zero value has 64 leading 0s. If the binary format has 64 leading 0s, the MS shall use the trailing 64 bits as
200 - 28

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 5.5.3.2.3 5.5.3.2.2

the assigned home link prefix and auto-configure the HoA with this prefix. Otherwise, the MS shall use the 128-bit value of the 3GPP2_MIP6_HOA attribute as the HoA in the MIP6 registration. If the MS receives the 3GPP2_MIP6_HOA attribute (with length set to zero) in the CP(CFG_REPLY), the MS may auto-configure the HoA using the prefix of the assigned HA address if the MS is pre-configured with the length of the home link prefix or assumes /64 prefix length. Otherwise the MS may fallback to the Simple IP access mode using the assigned TIA received in the INTERNAL_IP6_ADDRESS attribute of the CP(CFG_REPLY). Initial MIP6 Session Establishment with Static HoA and HA When the MS initiates a MIP6 session with static HoA and HA, the MS shall not request for MIP bootstrap information. However, the MS may still receive from the PDIF the HA info and the home link prefix info in the 3GPP2_MIP6_HA and 3GPP2_MIP6_HOA attributes of the CP (CFG_REPLY), respectively. In such a case, the MS shall use the HA info included in the CP (CFG_REPLY) rather than the provisioned one. Also, instead of using the statically provisioned HoA, the MS shall auto-configure a HoA using the home link prefix info (64 trailing bits in the 3GPP2_MIP_HOA attribute) and include it in the Binding Update message. During the IKEv2 exchange, the MS shall include the INTERNAL_IP6_ADDRESS attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message. MIP6 Session Handoff When the MS performs handoff from cdma2000 access to WLAN access (i.e. vertical handoff from PDSN to PDIF), the MS shall not request for MIP bootstrap information. The MS behaviors are the same as section 5.5.3.2.2. When the MS performs handoff from WLAN to cdma2000 access, the MS is not required to use the IPsec tunnel over cdma2000 access with the PDIF. When the MS performs handoff between two WLAN systems, the MS shall use MOBIKE to update the IPsec SA(s) with the PDIF.

5.5.3.3

PDIF Procedures
During the IKEv2 exchange, if the PDIF receives the INTERNAL_IP6_ADDRESS attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE-AUTH message, the PDIF shall assign a TIA from the address pool managed locally by the PDIF and shall convey the TIA in the INTERNAL_IP6_ADDRESS attribute of the CP(CFG_REPLY) of the IKEAUTH message. During the IKEv2 exchange, if the PDIF receives from the H-AAA the provisioned HoA in the MIP6-Home-Address VSA of the RADIUS Access-Accept or in the MIP6-Home-Address AVP of the Diameter DEA command, the PDIF shall convey the provisioned HoA in the 3GPP2_MIP6_HOA attribute in the CP(CFG_REPLY) of the IKE_AUTH message, regardless of whether the PDIF has received from the MS the 3GPP2_MIP6_HOA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message. During the IKEv2 exchange, if the PDIF receives from the MS the 3GPP2_MIP6_HOA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message, but the PDIF does not receive the HoA from the H-AAA and the PDIF has no other means of fetching the HoA info, the PDIF shall either omit the 3GPP2_MIP6_HOA attribute or send the 3GPP2_MIP6_HOA attribute (with length set to zero) in the CP(CFG_REPLY) of the IKE_AUTH message. During the IKEv2 exchange, if the PDIF receives from the H-AAA the provisioned HA in the MIP6-Home-Agent VSA of the RADIUS Access-Accept or in the MIP6-Home-Agent AVP of the Diameter DEA command, the PDIF shall convey the provisioned HA in the
200 - 29

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12

3GPP2_MIP6_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message, regardless of whether the PDIF has received from the MS the 3GPP2_MIP6_HA attribute (with length set to zero or non-zero) in the CP(CFG_REQUEST) of the IKE_AUTH message. During the IKEv2 exchange, if the PDIF receives the 3GPP2_MIP6_HA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message, the PDIF shall support the dynamic HA assignment as specified in section 5.5.4.2.

5.5.4

Bootstrapping Mechanisms

5.5.4.1

3GPP2-Specific Attributes of IKEv2 Configuration Payload for MIP

3GPP2-specific attributes are defined in the table below for IKEv2 Configuration Payload (CP) to indicate MIPv4 operation mode and bootstrap MIP parameters. Table 1. New IKEv2 CP attributes for MIP Value MultiValued NO Length Description Used by the MS to indicate the usage of Mobile IPv4 with FA CoA mode. Used by the MS to request and obtain a MIPv4 HA address. Used by the MS to request and obtain a MIP6 HA address. Used by the MS to request and obtain a MIP6 home address.

Attribute Type

3GPP2_MIP4_MODE

16384

3GPP2_MIP4_HA 3GPP2_MIP6_HA 3GPP2_MIP6_HOA 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

16385 16387 16388

YES* YES* NO

0 or 4 octets 0 or 16 octets 0 or 16 octets

* may be multi-valued in the response only (Multi-valued means that multiple attribute values of the same type are sent and/or returned [16].)

5.5.4.2

Dynamic HA Assignment
If the MS uses the 3GPP2_MIP4_HA attribute (with length set to zero) or 3GPP2_MIP6_HA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message to request dynamic MIPv4 or MIP6 HA assignment, the mechanisms defined in this section shall be used. In this case, the PDIF shall include the HA-Request VSA in the RADIUS AccessRequest. If the H-AAA successfully authenticates the MS and authorizes the PDIF to assign a HA for the MS, the H-AAA shall include the HA-Authorized VSA in the RADIUS AccessAccept. If the HA-Request VSA is absent in the RADIUS Access-Request, the H-AAA shall not include the HA-Authorized VSA in the RADIUS Access-Accept. If the H-AAA successfully authenticates the MS and decides to assign a HA for the MS, the H-AAA shall not include the HA-Authorized VSA and shall return the assigned HA address in the HA VSA or MIP6-Home-Agent VSA in the RADIUS Access-Accept. If the HA-Authorized VSA is included in the RADIUS Access-Accept, the PDIF shall assign a HA within the serving cdma2000 network and convey the assigned HA address to the MS via the 3GPP2_MIP4_HA attribute or 3GPP2_MIP6_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message.

200 - 30

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 5.5.4.2.2 5.5.4.2.1

If the HA VSA or MIP6-Home-Agent VSA is included in the RADIUS Access-Accept, the PDIF shall convey the assigned HA address to the MS via the 3GPP2_MIP4_HA attribute or 3GPP2_MIP6_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message. If the HA-Authorized VSA, HA VSA, and MIP6-Home-Agent VSA are absent in the RADIUS Access-Accept, the PDIF shall not perform dynamic HA assignment and shall include the 3GPP2_MIP4_HA attribute (with length set to zero) or 3GPP2_MIP6_HA attribute (with length set to zero) or omit these attributes in the CP(CFG_REPLY) of the IKE_AUTH message sent to the MS; in this case, the MS may use DHCPv6 to obtain a HA address. For dynamic HA assignment when Diameter protocol is used between the PDIF and the HAAA, the procedures specified in this section apply. The correspondent messages would be Diameter-EAP-Request (DER) Command (for RADIUS Access-Request) and Diameter-EAPAnswer (DEA) Command (for RADIUS Access-Accept). And Diameter AVPs are HARequest, HA-Authorized, Home-Agent and MIP6-Home-Agent. MN-HA Key Generation and Distribution for MIP6 During initial MIP6 registration, the assigned HA shall obtain the MN-HA shared key from the H-AAA as specified in [24]. Both the H-AAA and MS derive the MN-HA shared key from the MN-AAA shared secret. The H-AAA distributes the MN-HA shared key to the HA via the MIP6-Session Key VSA in the RADIUS Access-Accept. The H-AAA encrypts this VSA. If the RADIUS Access-Accept traverses through the V-AAA in the visited cdma2000 network, the V-AAA decrypts and encrypts the MIP6-Session Key VSA according to [24]. MN-HA Key Generation and Distribution for MIPv4 During initial MIPv4 registration, if the MS does not have a valid MN-HA key, the MS shall include the MN-AAA authentication extension in the RRQ. Upon receiving the RRQ from the MS with MN-AAA authentication extension, HA shall send a RADIUS Access-Request message to the H-AAA as per chapter 2, section 4.3.2 of reference [24]. In addition, the HA shall include the Home Agent VSA [24] and the MIP4Mesg-ID VSA (section 5.10.1) in the RADIUS Access-Request message. The HA shall copy the 64-bits value from the Identification field of the RRQ to the MIP4-Mesg-ID VSA. The H-AAA authenticates the user based on MN-AAA Shared Secret. If the MS is authenticated and authorized, the H-AAA shall generate the MN-HA key as follows: The Home RADIUS server generates the MN-HA key based on MN-AAA shared secret and other parameters with a keying material derivation function. In this document this keying material derivation function is f4 as defined in [15]. The keys can be derived as follows: IK = f4 (Subscriber Authentication Key, Type Identifier, Random Number, Family Key) The input parameters for the f4 function shall be set to: Subscriber Authentication Key (K) (128 bits) = MN-AAA Shared Secret Type Identifier (f4) (8-bits) = 0x46 Random Number (RAND) (128-bits) = MIP4| Identification field value of the RRQ | Home Agents Address Family Key (Fmk) (32-bits) = 0x41484147
200 - 31

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 5.5.4.2.3

The output of f4 is a 128-bit long IK that can be used as the MN-HA shared secret for the MIP4 session. The MS also uses the same function (f4) with the same inputs to generate IK at this stage or earlier. The H-AAA shall send to the HA a RADIUS Access-Accept that includes the MN-HAShared-Key VSA and Message Authenticator attribute. The RRP includes the MN-HA authentication extension computed from using the MN-HA key. The MS shall generate the MN-HA key and shall authenticate the RRP by verifying the MNHA authentication extension. IP Reachability Service The dynamic DNS update procedure is defined in [24].

5.6

cdma2000 Packet Data Service Provision

5.6.1

General
The cdma2000 Packet Data Services to be provided over WLAN comprise such services that are currently provided over the cdma2000 packet data domain.

5.6.2

MMD Service Provision Considerations

MMD (IMS) services require separate authentication and authorization mechanisms. These shall be performed after successful authentication and authorization with the PDIF and successful IPsec tunnel set-up between the MS and PDIF. The MS and PDIF shall support the P-CSCF discovery as specified in [23]. The PDIF shall support DHCP Relay Agent and DHCPv6 Relay Agent functions as specified in [24] for PCSCF discovery.

5.7

Timers
There is a set of timers that may be used in WLAN Interworking. These are, IKE_SA lifetime, ESP SA lifetime, EAP re-authentication timer and IKE retransmission timer. The PDIF and MS shall implement retransmission timers for the IKEv2 SA as specified in IKEv2 [16]. MIP timers are defined in [3] and [2]. The Mobile IP binding lifetime (see [3] and [2]) should be smaller than or equal to the IKE_SA and ESP SA timers. The MS should request Mobile IP binding lifetime shorter than its IKE_SA and ESP SA timers.

5.8

IPv4-IPv6 Dual Stack Operation

The MS may support IPv4 (Simple IPv4 or Mobile IPv4) and IPv6 (Simple IPv6 or Mobile IPv6) simultaneously. The PDIF shall support IPv4 (Simple IPv4 and Mobile IPv4) and IPv6 (Simple IPv6 and Mobile IPv6) simultaneously.

200 - 32

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

During the secure tunnel establishment procedures, if the EAP authentication is successful, the H-AAA may return the IP-Version-Authorized VSA in the RADIUS Access-Accept message or the IP-Version-Authorized AVP in the Diameter-EAP-Answer command, to indicate whether the IPv4 and/or IPv6 are authorized. If the IP-Version-Authorized VSA or AVP is not present, the PDIF shall apply its local policy for the authorization of dual stack operation. If the MS wants to use IPv4 and IPv6 simultaneously and is authorized to use both, the MS and PDIF should establish separate CHILD_SAs under the same IKE_SA for IPv4 and IPv6. If the MS wants to use IPv4 and IPv6 simultaneously but is authorized only for IPv4, only the IPsec tunnel for IPv4 shall be established. In order to prevent the MS from establishing an IPv6 session with the network, if the MS sets the INTERNAL_IP6_ADDRESS attribute to 0::0 in the CP(CFG_REQUEST) payload, the PDIF shall set the length of the INTERNAL_IP6_ADDRESS attribute to zero in the CP(CFG_REPLY) payload. The PDIF may notify the MS that it is not authorized for IPv6 access, by sending a Notify Payload with the Notify Message Type 8193 (specific to 3GPP2). If the MS sends a Router Solicitation to acquire an IPv6 prefix from the PDIF, the PDIF shall silently discard the message. The PDIF shall discard DHCPv6 messages from the MS. If the MS wants to use IPv4 and IPv6 simultaneously but is authorized only for IPv6, then only the IPsec tunnel for IPv6 shall be established. In order to prevent the MS from establishing an IPv4 session with the network, if the MS sets the INTERNAL_IP4_ADDRESS attribute to 0.0.0.0 in the CP(CFG_REQUEST) payload, the PDIF shall set the length of the INTERNAL_IP4_ADDRESS attribute to zero in the CP(CFG_REPLY) payload. The PDIF may notify the MS that it is not authorized for IPv4 access, by sending a Notify Payload with the Notify Message Type 8194 (specific to 3GPP2). If the MS sends an Agent Solicitation to acquire an IPv4 FA-CoA from the PDIF/FA, the PDIF shall silently discard the message. The PDIF shall discard DHCP messages from the MS.

5.9

Diameter Considerations

5.9.1

AVPs
Table 2 describes the Diameter AVPs defined for the WLAN reference point, their AVP Code values, types, possible flag values and whether or not the AVP is encrypted. The Vendor-Id shall be set to 5535 only if the AVPs are defined by 3GPP2. If the AVPs are standard attributes, the Vendor-Id shall be set to 0 as required in [10]. HA-Request The HA-Request AVP is 3GPP2-specific and indicates that the MS requests dynamic MIPv4 or MIP6 HA assignment. This AVP is included in the DER command from the PDIF to the H-AAA only when the MS indicates dynamic HA assignment request via IKEv2. AVP code: 1 HA-Authorized The HA-Authorized AVP is 3GPP2-specific and indicates that the H-AAA authorizes the serving cdma2000 network to assign a HA for the MS. This AVP is included in the DEA command from the H-AAA to the PDIF. AVP code: 2
200 - 33

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Home-Agent AVP The Home-Agent AVP is 3GPP2-specific and is used to convey the HA IPv4 address that the MS requests or the HA IPv4 address that the H-AAA assigns. This AVP may be included in the DEA command. AVP code: 3 MIP6-Home-Agent AVP The MIP6-Home-Agent AVP is 3GPP2-specific and is used to convey the HA IPv6 address that the MS requests or the HA IPv6 address that the H-AAA assigns. This AVP may be included in the DEA command. AVP code: 4 MIP6-Home-Address AVP The MIP6-Home-Address AVP is 3GPP2-specific and is used to convey the MSs home IPv6 address that the MS requests or the H-AAA assigns. This AVP may be included in the DEA command. AVP code: 5 IP-Technology The IP-Technology AVP is 3GPP2-spedific and is used to identify the IP technology for access (Simple IP = 1 or MIP = 2). AVP code: 6 Inbound-MIP-Signaling Octet Count The Inbound-MIP-Signaling Octet Count AVP is 3GPP2-spedific and is used to identify the
total number of octets in registration requests and solicitations sent by the MS.

AVP code: 7 Outbound-MIP-Signaling Octet Count The Outbound-MIP-Signaling Octet Count AVP is 3GPP2-spedific and is used to identify the
total number of octets in registration replies and agent advertisements sent to the MS prior to any compression and/or fragmentation.

AVP code: 8 Carrier-ID The Carrier-ID AVP is 3GPP2-spedific and is used to identify a string that uniquely identifies the
carrier that generated this UDR

AVP code: 9 GMT-Time-Zone-Offset The GMT-Time-Zone-Offset AVP is 3GPP2-spedific and is used to identify s signed integer
indicating the offset in seconds from GMT time.

AVP code: 10
200 - 34

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

IP-Version-Authorized AVP The IP-Version-Authorized AVP is 3GPP2-specific and is used to indicate whether the MS is authorized for using IPv4 and/or IPv6. AVP code: 11 Visited-Network-Identifier The Visited-Network-Identifier AVP is 3GPP2-specific and is used to indicate the visited network where the user is roaming. This AVP is present in the Authorization Request (when Auth-Request-Type AVP is set to AUTHORIZE_AUTHENTICATE), if the PDIF is not in the MSs home network. AVP code: 12 User Name The User-Name AVP is defined in [10] and contains the NAI format User Identity. This AVP is present in the Authentication Request and in the Authorization Request. AVP Code: 1 NAS-Port-Type The NAS-Port-Type AVP shall contain the value 5 (Virtual) according to [6]. AVP Code: 61 Table 2. Attribute Name HA-Request HA-Authorized Home-Agent MIP6-Home-Agent MIP6-Home-Address IP-Technology
Inbound-MIP-Signaling-OctetCount Outbound-MIP-Signaling-OctetCount Carrier-ID GMT-Time-Zone-Offset

Diameter cdma2000 WLAN Interworking AVPs AVP Code 5335/1 5335/2 5335/3 5335/4 5335/5 5335/6 5335/7 5335/8 Value Type Enumerated Enumerated Address Address Address Enumerated Unsigned32 Unsigned32 AVP Flag rules Shall May Should Must not not M, V M, V M, V M, V M, V M, V M, V M,V May Encr. No No Yes Yes Yes No No No

5335/9 OctetString M, V Yes 5335/10 Integer32 M,V No IP-Version-Authorized 5335/11 Enumerated M, V No Visited-Network-Identifier 5335/12 OctetString M, V No User name 1 UTF8String M Yes NAS-Port-Type 61 Enumerated M Yes NOTE: The AVP header bit denoted as M, indicates whether support of the AVP is required. The AVP header bit denoted as V, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see[10]. 19

200 - 35

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

5.9.2

Result-Code AVP Values

This section defines new result code values that shall be supported by all Diameter implementations that conform to this document. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent.

5.9.2.1

Permanent Failures
Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. The following Diameter Experimental Result Codes are 3GPP2 specific. DIAMETER_ERROR_USER_NO_WLAN_SUBSCRIPTION (5001) A command was received for a user with no WLAN IW subscription.
DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5002)

The user is not allowed to roam in the visited network.

5.9.3

Diameter AVPs for Authentication and Authorization

The following table summarizes the IETF Diameter AVPs and 3GPP2-specific AVPs in the Diameter commands exchanged between the PDIF and H-AAA for authentication and authorization. The entries in the table are defined as follows:

0 0+ 0-1 1 19 Attribute User-Name NAS-IP Address SessionTimeout Idle-Timeout AuthorizationLifetime NAS-Identifier NAS-Port-Type EAP-Payload Acct-InterimInterval

This attribute shall not be present. Zero or more instances of this attribute may be present. Zero or one instance of this attribute may be present. Exactly one instance of this attribute shall be present. List of Diameter for Authentication and Authorization Value Type UTF8S tring Addres s Unsign ed32 Unsign ed32 Unsign ed32 UTF8S tring Enume rated OctetS tring Unsign ed32 DER 1 0-1 0 DEA 0-1 0 0-1 Comments User's NAI, Case Sensitive IP Addr of NAS in PDIF Seconds until forced session termination and reauthentication required Seconds of idle time before auto-termination of session 0-Immediate reauthentication Alternative to NASIP_Address to identify NAS 5 = virtual [RFC 4072] Interval in seconds between Acct updates

Table 3.

Type 1 4 27

28 291 32 61 462 85

0 0-1 0-1 0-1 1 0

0-1 0-1 0 0 0-1 0-1

200 - 36

X.S0028-200-0 v1.0

3GPP2

EAP-MasterSession-Key HA-Request HA-Authorized Home Agent MIP6-HomeAgent MIP6-HomeAddress IP-VersionAuthorized 1 2 3 4 5 6 7 8 9 10 11

464 5335 /1 5335 /2 5335 /3 5335 /4 5335 /5 5335 /11

String Enume rated Enume rated Addres s Addres s Addres s Enume rated

0 0-1 0 0-1 0-1 0-1 0

0-1 0 0-1 0-1 0-1 0-1 0-1

[RFC 4072] Section 5.9.1 Section 5.9.1 Section 5.9.1 Section 5.9.1 Section 5.9.1 Section 5.9.1

5.9.4

Diameter AVPs for Session Termination and Abort

The AVPs to be included in STR, STA, ASR, and ASA are according to [12], section 3.5 to 3.8.

5.10

RADIUS Considerations

5.10.1

3GPP2 Vendor-Specific Attributes (VSA)

HA-Request VSA: The HA-Request VSA indicates that the MS requests dynamic MIPv4 or MIP6 HA assignment. This VSA is included in the RADIUS Access-Request from the PDIF to the HAAA only when the MS indicates dynamic HA assignment request via IKEv2. 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 Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Vendor-Value

12 13 14 15 16 17 18 19 20 21 Type: 26 Length: 12 Vendor ID: 5535 Vendor-Type: 168 Vendor-Length: 6 Vendor-Value:

Figure 7

HA-Request VSA

1: MS requests dynamic MIPv4 HA assignment 2: MS requests dynamic MIP6 HA assignment 3: MS request dynamic MIPv4 and MIP6 HA assignment

200 - 37

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6

All other values reserved for future use.

HA-Authorized VSA: The HA-Authorized VSA indicates that the H-AAA authorizes the serving cdma2000 network to assign a HA for the MS. This VSA may be included in the RADIUS Access-Accept from the H-AAA to the PDIF. 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 Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Vendor-Value

7 8 9 10 11 12 13 14 15 16 17 18 19 Type: 26 Length: 12 Vendor ID: 5535 Vendor-Type: 169 Vendor-Length: 6 Vendor-Value:

Figure 8

HA-Authorized VSA

1: Serving cdma2000 network is authorized for dynamic HA assignment All other values reserved for future use.

IP-Version-Authorized VSA: The IP-Version-Authorized VSA indicates whether the MS is authorized for using IPv4 and/or IPv6. 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 Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Vendor-Value

20 21 22 23 24 25 26 27 28 Type: 26 Length: 12

Figure 9

IP-Version-Authorized VSA

Vendor ID: 5535 Vendor-Type: 172 Vendor-Length: 6 Vendor-Value: 0: MS is authorized for both IPv4 and IPv6 1: MS is authorized only for IPv4
200 - 38

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7

2: MS is authorized only for IPv6 All other values reserved for future use.

MIP4-Mesg-ID: This 3GPP2-specific VSA carries the 64-bits value in the Identification field of the RRQ received from the MS. This VSA may be included in the RADIUS Access-Request message from the HA to the H-AAA. 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 Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Vendor-Value Vendor-Value

8 9 10 11 12 13 14 15 16 17 18 19 20 0 0+ 0-1 1 21 Attribute User-Name NAS-IP Address SessionTimeout Idle-Timeout TerminationAction Type: 26 Length: 16 Vendor ID: 5535

Figure 10 MIPv4-Mesg-ID VSA

Vendor-Type: 173 Vendor-Length: 10 Vendor-Value: 64-bits value copied from the Identification field of the RRQ

5.10.2

RADIUS Attributes for Authentication and Authorization

The following table summarizes the IETF RADIUS attributes and 3GPP2-specific VSAs in the RADIUS messages exchanged between the PDIF and H-AAA for authentication and authorization. The entries in the table are defined as follows:

This attribute shall not be present. Zero or more instances of this attribute may be present. Zero or one instance of this attribute may be present. Exactly one instance of this attribute shall be present. List of RADIUS Attributes for Authentication and Authorization Request 1 0-1 0 Accept 0-1 0 0-1 Reject 0 0 0 Challenge 0 0 0-1 Comments User's NAI, Case Sensitive IP Addr of NAS in PDIF Seconds until forced session termination and reauthentication required Seconds of idle time before auto-termination of session 0-Default (end of session) 1RADIUS re-authentication

Table 4. Type 1 4 27 Format String IP Addr Integer

28 29

Integer Integer

0 0

0-1 0-1

0 0

0-1 0

200 - 39

X.S0028-200-0 v1.0

3GPP2

NAS-Identifier Event-TimeStamp NAS-Port-Type EAP-Message MessageAuthenticator Acct-InterimInterval MS-MPPERecv-Key (Microsoft VSA)

32 55 61 79 80 85 26

String Integer Integer String String Integer String

0-1 0 0-1 0-1 0-1 0 0

0 0

0 0-1

0 0-1

0-1 0-1 0-1 0-1

0-1 0-1 0 0

1 1 0 0

Alternative to NASIP_Address to identify NAS Seconds since Jan 1 1970 UTC 5 = virtual [9] [9] Interval in seconds between Acct updates See [33]. If MS-MPPE-RECSEND-KEY is included then this attribute shall also be included; otherwise the PDIF shall treat the Access-Accept as an Access-Reject. See [33]. If MS-MPPE-RECREC-KEY is included then this attribute shall also be included; otherwise the PDIF shall treat the Access-Accept as an Access-Reject. For supporting FA challenge authentication when MIPv4 is used For supporting FA challenge authentication when MIPv4 is used [24] Section 5.10.1 Section 5.10.1 [24] Section 5.10.1 Section 5.10.1 Section 5.10.1 Section 5.10.1

MS-MPPESend-Key (Microsoft VSA)

26

String

0-1

CHAPPassword CHAPChallenge MN-HA SPI HA-Request HA-Authorized Home-Agent MIP6-HomeAddress MIP6-HomeAgent IP-VersionAuthorized MIP4-Mesg-ID 1 2

String

0-1

60

String

0-1

26/5 7 26/1 68 26/1 69 26/7 26/1 29 26/1 40 26/1 72 26/1 73

Integer String String IPaddr IPaddr IPAddr String String

0-1 0-1 0 0-1 0-1 0-1 0 0-1

0 0 0-1 0-1 0-1 0-1 0-1 0-1

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

200 - 40

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

6
6.1 6.2

Accounting
General
This section describes the PDIF accounting procedures and attributes.

PDIF Procedures

6.2.1

RADIUS Support
If RADIUS is used between PDIF and H-AAA/V-AAA, this section shall apply. The Usage Data Record (UDR) contains values of the supported RADIUS attributes listed in Table 5. The PDIF shall use RADIUS accounting message to send UDR to the visited RADIUS Server. The PDIF maintains the UDRs until it receives positive acknowledgment from the RADIUS server that it has correctly received the RADIUS message. If the MS is not using MIPv4 FA CoA mode, upon completion of the IPsec tunnel establishment with the MS i.e. the first child SA establishment along with the initial IKE_AUTH_SA exchange, the PDIF shall create a UDR and send a RADIUS Accounting Request (Start) message based on the UDR. If the MS uses MIPv4 FA CoA mode, upon completion of the MIPv4 registration by the MS, the PDIF shall create a UDR and send a RADIUS Accounting Request (Start) message based on the UDR. Note that in this case, the PDIF shall not create UDR based on the first IPsec child SA that is established at the time of the initial IKE_AUTH_SA exchange with a temporary TIA. This is because; the PDIF deletes this temporary SA soon after the MS performs successful MIPv4 registration. The PDIF shall aggregate all accounting data under a single UDR that is tied to the IKE_SA. The PDIF shall not create UDR per child SA. The creation of separate UDR per CHILD_SA or flow is further study. Upon removal of the IKE_SA with the MS, the PDIF shall send a RADIUS Accounting Request (Stop) message based on the latest UDR. The PDIF may support Interim-Update RADIUS accounting.

6.2.2

Diameter Support
If Diameter [10] is used between PDIF and H-AAA/V-AAA, this section shall apply. The Usage Data Record (UDR) contains values of the supported Diameter AVPs listed in Table 6. The PDIF shall use Diameter accounting commands to send UDRs to the visited Diameter Server. The PDIF maintains the UDR until it receives positive acknowledgment from the Diameter server that it has correctly received the Diameter command. If the MS is not using MIPv4 FA CoA mode, upon completion of the IPsec tunnel establishment with the MS i.e. the first child SA establishment along with the initial IKE_AUTH_SA exchange, the PDIF shall create a UDR and send an ACR (Start) command based on the UDR. If the MS uses MIPv4 FA CoA mode, upon completion of MIP registration by the MS, the PDIF shall create a UDR and send a ACR (Start) command based on the UDR. Note that in this case, the PDIF shall not create UDR based on the first IPsec
200 - 41

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11

child SA that is established at the time of the initial IKE_AUTH_SA exchange with a temporary TIA. This is because; the PDIF deletes this temporary SA soon after the MS performs successful MIPv4 registration. The PDIF shall aggregate all accounting data under a single UDR that is tied to the IKE_SA. The PDIF shall not create UDR per child SA. The creation of separate UDR per CHILD_SA or flow is further study. Upon removal of the IKE_SA with the MS, the PDIF shall send an ACR (Stop) command based on the latest UDR. This action is taken regardless of the status of STR and STA between the PDIF and the H-AAA.

6.3

RADIUS Attributes for Accounting

The entries in the table are defined as follows: 0 0+ 0-1 1 This attribute shall not be present. Zero or more instances of this attribute may be present. Zero or one instance of this attribute may be present. Exactly one instance of this attribute shall be present. Supported RADIUS Attributes for Accounting
Format String IP Addr IP Addr Acct Start 1 0-1 1 Acct Intrim 1 0-1 1 Acct Stop 1 0-1 1 Comments Users NAI, Case Sensitive IPv4 Address of RADIUS client TIA for Simple IPv4 or MIPv4 CCOA mode. Home Address for MIPv4 FA mode. Alternative to NAS-IP Address to identify NAS 1=Start 2=Stop 3=Interim update per [7] per [7] per [7] NAS unique ID to correlate all accounting records in a session; May be used to correlate with Auth Records. Session duration in seconds per [7] per [7] Number of times the Acct-Input-Octets counter has wrapped around. Number of times the Acct-OutputOctets counter has wrapped around. Seconds since Jan 1 1970 UTC 5 = Virtual Per [28] The prefix portion of TIA The IID portion of TIA

12
Attribute User Name NAS-IP Address Framed IP Address NAS Identifier Acct Status Type Acct-Delay-Time Acct Input Octets Acct Output Octets Acct Session ID

Table 5.
Type 1 4 8 Payload Length < 72 4 4

32 40 41 42 43 44 4 4 4 4 8

String Integer Integer Integer Integer String

0-1 1 1 0 0 1

0-1 1 1 1 1 1

0-1 1 1 1 1 1

Acct Session Time Acct Termination Cause Acct-InputGigawords Acct-OuputGigawords EventTimestamp NAS Port Type NAS-IPv6Address FramedInterface-ID Framed-IPv6-

46 49 52 53 55 61 95 96 97

4 4 4 4 4 4 16 4~20 10

Integer Integer Integer Integer Integer Integer Integer String IPv6-

0 0 0 0 1 0-1 0-1 0-1 0-1 200 - 42

0 0 1 1 1 0-1 0-1 0-1 0-1

0-1 1 1 1 1 0-1 0-1 0-1 0-1

X.S0028-200-0 v1.0

3GPP2

Prefix Home Agent IP Technology Inbound MIP Signaling Octet Count Outbound MIP Signaling Octet Count MIP6-HomeAgent Carrier ID GMT-Time-Zone Offset

26/07 26/22 26/46

4 4 4

Prefix IP-Addr Integer Integer

0-1 1 0

0-1 1 0-1

0-1 1 0-1

MIPv4 HA address 1=Simple IP 2=Mobile IP Per [24]

26/47

Integer

0-1

0-1

Per [24]

26/14 0 26/14 2 26/14 3

18 4 4

Integer string Signed integer

0-1 0-1 0-1

0-1 0-1 0-1

0-1 0-1 0-1

Per [24] A string that uniquely identifies the carrier that generated this UDR A signed integer indicating the offset in seconds from GMT time.

1 2 3

Note 1: The length of the AVP payload is determined per [10].

6.4

Diameter AVPs for Accounting

The entries in the table are defined as follows: 0 0+ 0-1 1 This AVP shall not be present. Zero or more instances of this AVP may be present. Zero or one instance of this AVP may be present. Exactly one instance of this AVP shall be present. Supported Diameter AVPs for Accounting
Value Type UTF8St ring Address Address ACR Start 1 0-1 1 ACR Intrim 1 0-1 1 ACR Stop 1 0-1 1 Comments Users NAI, Case Sensitive IPv4 Address of RADIUS client TIA for Simple IPv4 or MIPv4 CCOA mode. Home Address for MIPv4 FA mode. Identification of the session. Identification of endpoint that originated the Diameter command Identification of realm of the originator of any Diameter command 1=Event_Record 2=Start_Record 3=Interim_Record, 4=Stop_Record Accounting record identifier per [12] per [12] per [12] Session duration in seconds per [12] Per [10] In seconds since January 1, 1900 00:00

4
AVP User Name NAS-IP Address Framed IP Address Session ID Origin Host Origin Realm Accounting Record Type Accounting Record Number Acct-Delay-Time AccountingInput-Octets AccountingOutput-Octets Acct Session Time TerminationCause Event-

Table 6.
Type 1 4 8 Payload Length < 72 4 4

263 264 296 480 485 41 363 364 46 295 55

Note 1 Note 1 Note 1 4 4 4 8 8 4 4 4

UTF8St ring DiamId ent DiamId ent Enumer ated Unsigne d32 Unsigne d32 Unsigne d64 Unsigne d64 Unsigne d32 Enumer ated Time

1 1 1 1 1 1 0 0 0 0 0 200 - 43

1 1 1 1 1 1 1 1 0 0 0

1 1 1 1 1 1 1 1 0-1 1 0-1

X.S0028-200-0 v1.0

3GPP2

Timestamp NAS-Port-Type FramedInterface-ID Framed-IPv6Prefix Home Agent IP Technology Inbound MIP Signaling Octet Count Outbound MIP Signaling Octet Count MIP6-HomeAgent Carrier ID GMT-Time-Zone Offset

61 96 97 5335/ 3 5335/ 6 5335/ 7 5335/ 8 5335/ 4 5335/ 9 5335/ 10

4 8 8 4 4 4

Enumer ated Unsigne d64 OctetStr ing Address Enumer ated Unsigne d32 Unsigne d32 Address OctetStr ing Integer3 2

0-1 0-1 0-1 0-1 1 0

0-1 0-1 0-1 0-1 1 0-1

0-1 0-1 0-1 0-1 1 0-1

UTC Per [12] Per [12] Per [12] MIPv4 HA address 1=Simple IP 2=Mobile IP See section 5.9.1.

0-1

0-1

See section 5.9.1.

16 4 4

0-1 0-1 0-1

0-1 0-1 0-1

0-1 0-1 0-1

See section 5.9.1. See section 5.9.1. See section 5.9.1

1 2

Note 1: The length of the AVP payload is determined per [10].

200 - 44

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8

7
7.1

Appendix Call Flow Examples (Informative)

MIPv4 FA CoA with Dynamic HA and HoA Assignment
This section depicts a scenario where the MS uses MIPv4 (in FA CoA mode) to access a visited cdma2000 system from a WLAN system. The MS requests and obtains a dynamic HA address via IKEv2, and the HA is assigned by the visited cdma2000 system authorized by the MSs home cdma2000 system. Moreover, the MS requests and obtains a dynamic HoA via MIPv4 registration, and the HoA is assigned by the HA in the visited cdma2000 system.
MS PDIF/FA HA V-AAA H-AAA

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Generate MN-HA Key

IKE_SA_INIT IKE_AUTH Request (3GPP2_MIP4_HA, 3GPP2_MIP4_MODE)

RADIUS Access Request (HA-Request) EAP Exchange RADIUS Access Accept (HA-Authorized) HA Assignment

IKE_AUTH Response (3GPP2_MIP4_HA) Agent Advertisements RRQ RADIUS Access Request RADIUS Access Accept RRQ RADIUS Access Request (MN-HA SPI, HA Addr, MIP4-Mesg-ID) Generate MN-HA Key RADIUS Access Accept (MN-HA Key, Msg Auth.)

RRP

CREATE_CHILD_SA (Traffic Selector) INFORMATIONAL (Delete)

9 10 Figure 11 MIPv4 MS using FA CoA and requesting for dynamic HA and HoA

200 - 45

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

1. 2.

The MS and PDIF exchange the IKE_SA_INIT messages to negotiate cryptographic algorithms, exchange nonces, and perform a Diffie_Hellman exchange. The MS uses the 3GPP2_MIP4_HA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message to request dynamic MIPv4 HA assignment. The MS also includes the 3GPP2_MIP4_MODE attribute to indicate that it is using the FA CoA mode of operation. The MS does not include the Auth parameter. Not including it indicates that the MS wants to use EAP. The PDIF sends the RADIUS Access-Request with the HA-Request VSA to request the H-AAA to authorize the PDIF to assign a HA for the MS. EAP messages are exchanged between the MS and H-AAA to authenticate the MS. The EAP messages are exchanged via PDIF and V-AAA. The H-AAA authenticates the MS successfully and sends the RADIUS AccessAccept with the HA-Authorized VSA to permit the PDIF to assign a HA for the MS. The PDIF selects a HA for the MS. The PDIF conveys the HA address in the 3GPP2_MIP4_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message sent to the MS. The PDIF also assigns a temporary TIA to the MS, and the established IPsec SA is associated with that TIA. The PDIF sends Agent Advertisements to the MS. The MS sends MIP RRQ including the NAI Extension, MN-AAA Authentication Extension, etc. The Home Address (HoA) field of the RRQ is set to zero to request for a dynamic HoA.

3. 4. 5. 6. 7.

8. 9.

10. The PDIF sends RADIUS Access-Request to the H-AAA to authenticate the MSs credential conveyed in the MN-AAA Authentication Extension. 11. The H-AAA authenticates the MS successfully and sends the RADIUS AccessAccept. 12. The PDIF forwards the RRQ to the HA. 13. The HA in the visited cdma2000 system assigns an HoA for the MS and sends RADIUS Access-Request to the H-AAA via V-AAA. The RADIUS Access-Request contains the MN-HA SPI VSA to request an MN-HA key, Home Agent VSA [24] and MIP4-Mesg-ID VSA (section 5.10.1). 14. The H-AAA picks a nonce randomly and generates the MN-HA key per 5.5.4.2.2. 15. The H-AAA sends RADIUS Access-Accept with the MN-HA-Key VSA (contains the MN-HA key). The attribute is protected by the Message Authentication attribute. 16. The HA sends the MIP RRP including the MN-HA Authentication Extension computed based on the MN-HA key. The PDIF forwards the RRP to the MS 17. The MS generates the MN-HA key and uses it to verify the MN-HA Authentication Extension in the RRP. 18. After the MS obtains the HoA in the RRP, the MS sends the CREATE_CHILD_SA message with the Traffic Selector payload for initiator (TSi) equal to the HoA. This IKEv2 exchange creates a new IPsec SA for the HoA. 19. PDIF sends the Delete payload in the Informational message to delete the old IPsec SA associated with the previously assigned TIA in step 7.
200 - 46

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7

7.2

MIPv4 Collocated CoA with Dynamic HA and HoA Assignment

This section depicts a scenario where the MS uses MIPv4 (in Collocated CoA mode) to access a visited cdma2000 system from a WLAN system. The MS requests and obtains a dynamic HA address via IKEv2, and the HA is assigned by the visited cdma2000 system authorized by the MSs home cdma2000 system. Moreover, the MS requests and obtains a dynamic HoA via MIPv4 registration, and the HoA is assigned by the HA in the visited cdma2000 system.
MS PDIF/FA HA V-AAA H-AAA

1 2 3 4 5 6 7 8 9

IKE_SA_INIT IKE_AUTH Request (3GPP2_MIP4_HA) RADIUS Access Request (HA-Request) EAP Exchange RADIUS Access Accept (HA-Authorized) HA Assignment IKE_AUTH Response (3GPP2_MIP4_HA) RRQ RADIUS Access Request (MN-HA SPI, HA Addr, MIP4-Mesg-ID) Authenticate the MS, Generate MN-HA Key RADIUS Access Accept (MN-HA Key, Msg Auth.) RRP

10

11 12 13
Generate MN-HA Key

8 9 10 11 12 13 14 15 16 17 Figure 12 MIPv4 using Collocated CoA mode and requesting for dynamic HA and HoA 1. 2. The MS and PDIF exchange the IKE_SA_INIT messages to negotiate cryptographic algorithms, exchange nonces, and perform a Diffie_Hellman exchange. The MS uses the 3GPP2_MIP4_HA attribute (with length set to zero) in the CP(CFG_REQUEST) of the IKE_AUTH message to request dynamic MIPv4 HA assignment. The MS does not include the Auth parameter. Not including it indicates that the MS wants to use EAP. The PDIF sends the RADIUS Access-Request with the HA-Request VSA to request the H-AAA to authorize the PDIF to assign a HA for the MS.

3.

200 - 47

X.S0028-200-0 v1.0

3GPP2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

4. 5. 6. 7.

EAP messages are exchanged between the MS and H-AAA to authenticate the MS. The EAP messages are exchanged via PDIF and V-AAA. The H-AAA authenticates the MS successfully and sends the RADIUS AccessAccept with the HA-Authorized VSA to permit the PDIF to assign a HA for the MS. The PDIF selects a HA for the MS. The PDIF conveys the HA address in the 3GPP2_MIP4_HA attribute in the CP(CFG_REPLY) of the IKE_AUTH message sent to the MS. The PDIF also assigns a TIA to the MS, and the established IPsec SA is associated with that TIA. The MS sends MIP RRQ including the NAI Extension, MN-AAA Authentication Extension, etc. The Home Address (HoA) field of the RRQ is set to zero to request for a dynamic HoA. The HA in the visited cdma2000 system assigns an HoA for the MS and sends RADIUS Access-Request to the H-AAA via V-AAA. The RADIUS Access-Request contains the MN-HA SPI VSA to request a MN-HA key, Home Agent VSA [24] and MIP4-Mesg-ID VSA (section 5.10.1). The MSs credential conveyed in the MNAAA Authentication Extension.

8.

9.

10. The H-AAA authenticates the MS successfully and picks a nonce randomly and generates the MN-HA key per section 5.5.4.2.2. 11. The H-AAA sends RADIUS Access-Accept with the MN-HA-Key VSA (contains the MN-HA key). The attributes are protected by the Message Authentication attribute. 12. The HA sends the MIP RRP including the MN-HA Authentication Extension computed based on the MN-HA key. 13. The MS generates the MN-HA key and uses it to verify the MN-HA Authentication Extension in the RRP.

200 - 48