Cisco Cisco Packet Data Gateway (PDG)
Evolved Packet Data Gateway Overview
How the ePDG Works ▀
ePDG Administration Guide, StarOS Release 17 ▄
73
Step Description
3.
The UE sends the user identity (in the IDi payload) and the APN information (in the IDr payload) in this first message of
the IKE_AUTH phase, and begins negotiation of child security associations. The UE omits the AUTH parameter in order to
indicate to the ePDG that it wants to use EAP over IKEv2. The user identity shall be compliant with Network Access
Identifier (NAI) format specified in TS 23.003 containing the IMSI, as defined for EAP-AKA in RFC 4187. The UE shall
send the configuration payload (CFG_REQUEST) within the IKE_AUTH request message with the preserved IP
address(es) from the LTE session so that ePDG knows its handoff case and communicates same IP address to P-GW. When
the MAC ULI feature is enabled the root NAI used will be of the form
“0<IMSI>@AP_MAC_ADDR:nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org”.
the IKE_AUTH phase, and begins negotiation of child security associations. The UE omits the AUTH parameter in order to
indicate to the ePDG that it wants to use EAP over IKEv2. The user identity shall be compliant with Network Access
Identifier (NAI) format specified in TS 23.003 containing the IMSI, as defined for EAP-AKA in RFC 4187. The UE shall
send the configuration payload (CFG_REQUEST) within the IKE_AUTH request message with the preserved IP
address(es) from the LTE session so that ePDG knows its handoff case and communicates same IP address to P-GW. When
the MAC ULI feature is enabled the root NAI used will be of the form
“0<IMSI>@AP_MAC_ADDR:nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org”.
4.
The ePDG sends the Authentication and Authorization Request message to the 3GPP AAA Server, containing the user
identity and APN.
identity and APN.
5.
The 3GPP AAA Server shall fetch the user profile and authentication vectors from HSS/HLR (if these parameters are not
available in the 3GPP AAA Server). The 3GPP AAA Server shall lookup the IMSI of the authenticated user based on the
received user identity (root NAI) and include the EAP-AKA as requested authentication method in the request sent to the
HSS. The HSS shall then generate authentication vectors with AMF separation bit = 0 and send them back to the 3GPP
AAA server. The 3GPP AAA Server checks in user's subscription if he/she is authorized for non-3GPP access. The counter
of IKE SAs for that APN is stepped up. If the maximum number of IKE SAs for that APN is exceeded, the 3GPP AAA
Server shall send an indication to the ePDG that established the oldest active IKE SA (it could be the same ePDG or a
different one) to delete the oldest established IKE SA. The 3GPP AAA Server shall update accordingly the information of
IKE SAs active for the APN.
The 3GPP AAA Server initiates the authentication challenge. The user identity is not requested again.
available in the 3GPP AAA Server). The 3GPP AAA Server shall lookup the IMSI of the authenticated user based on the
received user identity (root NAI) and include the EAP-AKA as requested authentication method in the request sent to the
HSS. The HSS shall then generate authentication vectors with AMF separation bit = 0 and send them back to the 3GPP
AAA server. The 3GPP AAA Server checks in user's subscription if he/she is authorized for non-3GPP access. The counter
of IKE SAs for that APN is stepped up. If the maximum number of IKE SAs for that APN is exceeded, the 3GPP AAA
Server shall send an indication to the ePDG that established the oldest active IKE SA (it could be the same ePDG or a
different one) to delete the oldest established IKE SA. The 3GPP AAA Server shall update accordingly the information of
IKE SAs active for the APN.
The 3GPP AAA Server initiates the authentication challenge. The user identity is not requested again.
6.
The ePDG responds with its identity, a certificate, and sends the AUTH parameter to protect the previous message it sent to
the UE (in the IKE_SA_INIT exchange). It completes the negotiation of the child security associations if any. The EAP
message received from the 3GPP AAA Server (EAP-Request/AKA-Challenge) is included in order to start the EAP
procedure over IKEv2.
the UE (in the IKE_SA_INIT exchange). It completes the negotiation of the child security associations if any. The EAP
message received from the 3GPP AAA Server (EAP-Request/AKA-Challenge) is included in order to start the EAP
procedure over IKEv2.
7.
The UE checks the authentication parameters and responds to the authentication challenge. The only payload (apart from
the header) in the IKEv2 message is the EAP message.
the header) in the IKEv2 message is the EAP message.
8.
The ePDG forwards the EAP-Response/AKA-Challenge message to the 3GPP AAA Server.
8a.
The AAA checks, if the authentication response is correct.
9.
When all checks are successful, the 3GPP AAA Server sends the final Authentication and Authorization Answer (with a
result code indicating success) including the relevant service authorization information, an EAP success and the key
material to the ePDG. This key material shall consist of the MSK generated during the authentication process. When the
SWm and SWd interfaces between ePDG and 3GPP AAA Server are implemented using Diameter, the MSK shall be
encapsulated in the EAP-Master-Session-Key-AVP, as defined in RFC 4072.
result code indicating success) including the relevant service authorization information, an EAP success and the key
material to the ePDG. This key material shall consist of the MSK generated during the authentication process. When the
SWm and SWd interfaces between ePDG and 3GPP AAA Server are implemented using Diameter, the MSK shall be
encapsulated in the EAP-Master-Session-Key-AVP, as defined in RFC 4072.
10.
The MSK shall be used by the ePDG to generate the AUTH parameters in order to authenticate the IKE_SA_INIT phase
messages, as specified for IKEv2 in RFC 4306. These two first messages had not been authenticated before as there was no
key material available yet. According to RFC 4306 [3], the shared secret generated in an EAP exchange (the MSK), when
used over IKEv2, shall be used to generated the AUTH parameters.
messages, as specified for IKEv2 in RFC 4306. These two first messages had not been authenticated before as there was no
key material available yet. According to RFC 4306 [3], the shared secret generated in an EAP exchange (the MSK), when
used over IKEv2, shall be used to generated the AUTH parameters.
11.
The EAP Success/Failure message is forwarded to the UE over IKEv2.
12.
UE -> ePDG: IKEv2 AUTH_REQUEST - The UE sends Auth_Request (IDi, [CERT] | [CERTREQ], IDr (CP), SA
(CFQ_REQUEST (INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK INTERNAL_IP6_ADDRESS,
INTERNAL_IP6_SUBNET, INTERNAL_IP4_DNS, INTERNAL_IP6_DNS, TSi, TSr, P-CSCF)
(CFQ_REQUEST (INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK INTERNAL_IP6_ADDRESS,
INTERNAL_IP6_SUBNET, INTERNAL_IP4_DNS, INTERNAL_IP6_DNS, TSi, TSr, P-CSCF)