4 SWa Description

29.2733GPP3GPP EPS AAA interfacesEvolved Packet System (EPS)Release 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Functionality

4.1.1 General

The SWa reference point is defined between the untrusted non-3GPP IP access and the 3GPP AAA Server or Proxy in EPS. The definition of the reference point and its functionality is given in 3GPP TS 23.402 [3].

The SWa reference point is optionally used to authenticate and authorize the UE for the access to the EPS. It is up to the non-3GPP operator’s policy whether this interface and the procedures defined in this clause are used.

NOTE: From the EPS operator’s view, the tunnel authentication and authorization procedures described in clause 7 (SWm description) and clause 9 are required to ensure the user’s authentication and authorization when the UE is attached to an untrusted non-3GPP IP access.

The same procedures as defined for STa reference points are used also in the SWa, but with reduced message content. As an exception, the service authorization information update procedure is not applicable for the SWa reference point.

The SWa reference point is also defined between the non-3GPP WLAN access and the NSWOF in 5GS. The definition of the reference point and its functionality is given in clause 4.2.15 of 3GPP TS 23.501 [59] and Annex S of 3GPP TS 33.501 [60]. It reuses the same stage 3 protocol definition as defined for SWa in EPC, with specific requirements for NSWO in 5GS specified in clause 4.1.2.5.

4.1.2 Procedure Descriptions

4.1.2.1 SWa Authentication and Authorization procedure

4.1.2.1.1 General

This procedure follows the STa Authentication and Authorization procedure, with the following differences:

– Information elements that would reflect information about the user’s service request and about the access network are not included or are optional in the authentication and authorization request.

– The information elements that describe the user’s subscription profile are not downloaded to the non-3GPP access network.

NOTE: The information elements related to the IP Mobility Mode Selection function are not supported over this interface.

Table 4.1.2.1/1: SWa Authentication and Authorization Request

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	User-Name	M	This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in the IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes.
EAP payload	EAP-payload	M	This IE shall contain the Encapsulated EAP payload used for the UE – 3GPP AAA Server mutual authentication
Authentication Request Type	Auth-Request-Type	M	This IE shall define whether the user is to be authenticated only, authorized only or both. AUTHORIZE_AUTHENTICATE shall be used in this case.
UE Layer-2 address	Calling-Station-ID	M	This IE shall carry the Layer-2 address of the UE.
Access Type	RAT-Type	C	If present, this IE shall contain the untrusted non-3GPP access network technology type that is serving the UE.
Access Network Identity	ANID	O	If present, this IE shall contain the access network identifier used for key derivation at the HSS. (See 3GPP TS 24.302 [26] for all possible values) It shall be included if the non-3GPP access network selects the EAP-AKA’ authentication method.
Full Name for Network	Full-Network-Name	O	If present, this IE shall contain the full name for network as specified in 3GPP TS 24.302 [26]. This AVP may be inserted by the non-3GPP access network depending on its local policy and only when it is not connected to the UE’s Home Network
Short Name for Network	Short-Network-Name	O	If present, this IE shall contain the short name for network as specified in 3GPP TS 24.302 [26]. This AVP may be inserted by the non-3GPP access network depending on its local policy and only when it is not connected to the UE’s Home Network
Transport Access Type	Transport-Access-Type	C	For interworking with Fixed Broadband access networks (see 3GPP TS 23.139 [39]), if the access network needs to receive the IMSI of the UE in the authentication response, then this information element shall be present, and it shall contain the value "BBF" (see clause 5.2.3.19).
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host for the lifetime of the Diameter session.
AAA Failure Indication	AAA-Failure-Indication	O	If present, this information element shall indicate that the request is sent after the non-3GPP access network has determined that a previously assigned 3GPP AAA Server is unavailable.
WLAN Location Information	Access-Network-Info	O	If present, this IE shall contain the location information of the WLAN Access Network where the UE is attached.
WLAN Location Timestamp	User-Location-Info-Time	O	This IE may be present if the WLAN Location Information IE is present. When present, this IE shall contain the NTP time at which the UE was last known to be in the location reported in the WLAN Location Information.

Table 4.1.2.1/2: SWa Authentication and Authorization Answer

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	User-Name	M	This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes.
EAP payload	EAP payload	M	This IE shall contain the Encapsulated EAP payload used for UE- 3GPP AAA Server mutual authentication.
Authentication Request Type	Auth-Request-Type	M	It shall contain the value AUTHORIZE_AUTHENTICATE. See IETF RFC 4072 [5].
Result code	Result-Code / Experimental- Result	M	This IE shall contain the result of the operation. Result codes are as in Diameter base protocol (see IETF RFC 6733 [58]). Experimental-Result AVP shall be used for SWa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Session Alive Time	Session-Timeout	O	This AVP may be present if the Result-Code AVP is set to DIAMETER _SUCCESS. If present, it shall contain the maximum number of seconds the user session is allowed to remain active.
Accounting Interim Interval	Accounting Interim-Interval	O	If present, this IE shall contain the Charging duration
Pairwise Master Key	EAP-Master-Session-Key	C	This IE shall be present if the Result-Code AVP is set to DIAMETER_SUCCESS.
3GPP AAA Server URI	Redirect-Host	C	This information element shall be present if the Result-Code value is set to DIAMETER_REDIRECT_INDICATION. When the user has previously been authenticated by another 3GPP AAA Server, it shall contain the Diameter URI of the 3GPP AAA Server currently serving the user. The node receiving this IE shall behave as defined in the Diameter base protocol (see IETF RFC 6733 [58]). The command shall contain zero or more occurrences of this information element. When choosing a destination for the redirected message from multiple Redirect-Host AVPs, the receiver shall send the Diameter request to the first 3GPP AAA Server in the ordered list received in the Diameter response. If no successful response to the Diameter request is received, the receiver shall send the Diameter request to the next 3GPP AAA Server in the ordered list. This procedure shall be repeated until a successful response is received from a 3GPP AAA Server.
Trust Relationship Indicator	AN-Trusted	M	This AVP shall contain the 3GPP AAA Server’s decision on handling the non-3GPP access network, i.e. trusted or untrusted. For the SWa case, the value "UNTRUSTED" shall be used.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host for the lifetime of the Diameter session.
Permanent User Identity	Mobile-Node-Identifier	C	This information element shall only be sent if the Result-Code AVP is set to DIAMETER_SUCCESS and if the Transport Access Type in the request command indicated that the UE is accessing the EPC from a Fixed Broadband access network (i.e., the Transport-Access-Type AVP takes the value "BBF"); it shall contain an AAA/HSS assigned permanent user identity (i.e. an IMSI in root NAI format as defined in clause 19 of 3GPP TS 23.003 [14]) to be used by the non-3GPP access network in subsequent PCC procedure for identifying the user in the EPS network. This IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

4.1.2.1.2 3GPP AAA Server Detailed Behaviour

The detailed behaviour of the 3GPP AAA Server follows the behaviour defined for the STa Authentication and Authorization procedure (refer to clause 5.1.2.1.2), with the following deviations:

– The 3GPP AAA Server shall handle the non-3GPP access network as untrusted.

– The 3GPP AAA Server marks the trust relationship as "untrusted" with the User Identity.

– The authentication method shall be selected based on the presence of the Access Network Identity as specified in 3GPP TS 33.402 [19]: if this information element is present, the EAP-AKA’ method as specified in IETF RFC 5448 [27] is used; otherwise, the EAP-AKA method as specified in IETF RFC 4187 [44] is used.

When a WLAN Access Network provides WLAN Location Information to the 3GPP AAA Server that it considers as network provided location, the 3GPP AAA Server should store this information for the duration of the WLAN session of the UE, along with the WLAN Location Timestamp if received from the WLAN Access Network, or with the timestamp at which the WLAN Location Information is received from the WLAN Access Network, and provide it to the ePDG during a subsequent Authentication and Authorization procedure or Authorization procedure over the SWm reference point (see clauses 7.1.2.1.2 and 7.1.2.2.2).

The 3GPP AAA Server shall delete any stored WLAN Location Information and WLAN Location Timestamp associated with the UE when a WLAN Access Network provides WLAN Location Information to the 3GPP AAA Server that it does not consider as network provided location.

NOTE: It is up to local 3GPP AAA Server policies to decide whether the location information received from the WLAN access network can be considered as network provided location.

4.1.2.1.3 3GPP AAA Proxy Detailed Behaviour

The detailed behaviour of the 3GPP AAA Proxy follows the behaviour defined for the STa Authentication and Authorization procedure (refer to clause 5.1.2.1.3), with the following exception:

– The 3GPP AAA Proxy shall insert or overwrite Visited-Network-Identifier AVP before forwarding the request to the 3GPP AAA Server.

NOTE: If the untrusted WLAN is operated by the VPLMN’s equivalent PLMN, the 3GPP AAA proxy can receive the Visited-Network-Identifier AVP from the Authentication and Authorization Request message.

– The 3GPP AAA Proxy shall handle the non-3GPP access network as untrusted and marks the trust relationship as "untrusted".

On receipt of the authentication and authorization answer that completes a successful authentication, the 3GPP AAA Proxy shall record the authentication state of the user.

4.1.2.2 SWa HSS/AAA Initiated Detach

This procedure equals with the STa HSS/AAA Initiated Detach procedure, refer to clause 5.1.2.2.

The 3GPP AAA Server shall delete any stored WLAN Location Information and WLAN Location Timestamp associated with the UE when it becomes aware that the WLAN session of the UE is terminated.

4.1.2.3 SWa Non-3GPP Access Network Initiated Detach

This procedure equals with the STa Non-3GPP Access Network Initiated Detach procedure, refer to clause 5.1.2.4.

The 3GPP AAA Server shall delete any stored WLAN Location Information and WLAN Location Timestamp associated with the UE when it becomes aware that the WLAN session of the UE is terminated.

4.1.2.4 SWa Re-Authentication and Re-Authorization Procedure

4.1.2.4.1 General

This procedure is optional and it may be invoked by the 3GPP AAA Server, if the operator policies require that the re-authentication of the user for the SWa is to be renewed and the untrusted non-3GPP access network supports the re-authentication.

This procedure shall be performed in two steps:

– The 3GPP AAA server shall issue an unsolicited re-auth request towards the untrusted non-3GPP access, indicating that both re-authentication and re-authorization of the user is needed. Upon receipt of such a request, the untrusted non-3GPP access shall respond to the request and shall indicate the disposition of the request. This procedure is mapped to the Diameter command codes Re-Auth-Request and Re-Auth-Answer specified in IETF RFC 6733 [58]. Information element contents for these messages shall be as shown in tables 4.1.2.4.1/1 and 4.1.2.4.1/2.

– Upon receiving the re-auth request, the untrusted non-3GPP access shall immediately invoke the SWa authentication and authorization procedure requesting the identity of the user via EAP and using DER/DEA commands, with the same session-ID but the content adapted to the needs of a re-authentication. Information element contents for these messages shall be as shown in tables 4.1.2.4.1/3 and 4.1.2.4.1/4.

If the re-authentication of the user is not successful, the untrusted non-3GPP access shall detach the user.

Table 4.1.2.4.1/1: SWa Re-auth request

Information element name	Mapping to Diameter AVP	Cat.	Description
Permanent User Identity	User-Name	M	This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15], and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]; this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.
Re-Auth Request Type	Re-Auth–Request-Type	M	This information element shall define whether the user is to be authorized only or authenticated and authorized. AUTHORIZE_AUTHENTICATE shall be used in this case.
Routing Information	Destination-Host	M	This information element shall be obtained from the Origin-Host AVP, which was included in a previous command received from the untrusted non-3GPP access.

Table 4.1.2.4.1/2: SWa Re-auth response

Information element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]; this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Result

Result-Code / Experimental-Result

This IE shall contain the result of the operation.

The Result-Code AVP shall be used for errors defined in the Diameter Base Protocol (see IETF RFC 6733 [58]).

The Experimental-Result AVP shall be used for SWa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP and the error code in the Experimental-Result-Code AVP.

Table 4.1.2.4.1/3: SWa Authentication and Authorization Request

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	User-Name	M	This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes.
EAP payload	EAP-payload	M	This IE shall contain the Encapsulated EAP payload used for the UE – 3GPP AAA Server mutual authentication.
Authentication Request Type	Auth-Request-Type	M	This IE shall define whether the user is to be authenticated only, authorized only or both. AUTHORIZE_AUTHENTICATE shall be used in this case.

Table 4.1.2.4.1/4: SWa Authentication and Authorization Answer

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	User-Name	M	This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes.
EAP payload	EAP payload	O	If present, this IE shall contain the Encapsulated EAP payload used for UE- 3GPP AAA Server mutual authentication.
Authentication Request Type	Auth-Request-Type	M	It shall contain the value AUTHORIZE_AUTHENTICATE. See IETF RFC 4072 [5].
Result code	Result-Code / Experimental- Result	M	This IE shall contain the result of the operation. Result codes are defined in the Diameter base protocol (see IETF RFC 6733 [58]). The Experimental-Result AVP shall be used for SWa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Session Alive Time	Session-Timeout	O	If present, this IE shall contain the maximum number of seconds the user session should remain active.
Accounting Interim Interval	Accounting Interim-Interval	O	If present, this IE shall contain the Charging duration.
Pairwise Master Key	EAP-Master-Session-Key	C	This IE shall be sent if Result-Code AVP is set to DIAMETER_SUCCESS.

4.1.2.4.2 3GPP AAA Server Detailed Behaviour

The 3GPP AAA Server shall trigger this procedure according to the local policies configured by the operator.

The 3GPP AAA Server shall use the same authentication method that was used during the full authentication executed at the UE’s attach. If EAP-AKA’ is used, the 3GPP AAA Server shall use the ANID parameter received during the authentication and authorization executed at the UE attach (refer to clause 4.1.2.1.1).

4.1.2.4.3 3GPP AAA Proxy Detailed Behaviour

The detailed behaviour of the 3GPP AAA Proxy follows the behaviour defined for the STa Re-Authorization and Re-Authentication Procedures (refer to clause 5.1.2.3.3), with the following addition:

– When forwarding the authorization answer or the authentication and authorization answer, the 3GPP AAA Proxy shall record the authentication state of the user.

4.1.2.5 SWa procedures for NSWO in 5GS

The SWa interface between the non-3GPP WLAN access and the NSWOF shall use the same stage 3 protocol definition as for the SWa interface in EPS, with the following modifications:

– SWa Authentication and Authorization procedure:

– The User Identity IE in the SWa Authentication and Authorization Request and in the SWa Authentication and Authorization Response shall contain the SUCI in NAI form as defined in clause 28.7.3 of 3GPP TS 23.003 [14]. In NSWO roaming scenario with a 3GPP AAA Proxy in the VPLMN (see clause 4.2.15 of 3GPP TS 23.501 [59]), the SUCI in NAI form shall be decorated as defined in clause 28.7.9 of 3GPP TS 23.003 [14] to enable the routing of SWa signalling towards the 3GPP AAA Proxy in the VPLMN.

NOTE 1: This IE does not contain any leading digit to differentiate between authentication schemes.

NOTE 2: The realm in the SUCI in NAI form (starting by the first label "5gc-nswo") enables to route the signaling towards an NSWOF, as opposed to sending it to a 3GPP AAA Server, if the non-3GPP WLAN access also supports SWa signaling with a 3GPP AAA Server e.g. for a 4G subscriber.

– EAP-AKA’ as specified in RFC 5448 [27] shall be used as the authentication method.

– The NSWOF shall behave as specified in Annex S of 3GPP TS 33.501 [60]. The NSWOF shall send the MSK received from the AUSF in the Pairwise Master Key IE in the SWa Authentication and Authorization Answer.

– The SWa HSS/AAA Initiated Detach, SWa Non-3GPP Access Network Initiated Detach and SWa Re-authentication and Re-Authorization are not supported.

Editor’s note: it is FFS if this clause needs to be updated, pending SA2 reply to CT4 LS on NAI format for 5G NSWO.

4.2 Protocol Specification

4.2.1 General

The SWa reference point shall use the same Diameter application as the STa reference point. The first authentication command exchange (DER/DEA) is common between the SWa and STa reference points. During this initial exchange, the 3GPP AAA Server determines the HPLMN’s trust relationship with the non-3GPP access network and communicates it to the non-3GPP access network and the UE as described in clause 5.1.2.1.2. The contents of the subsequent commands are dependent on this trust relationship determination and are specific to the SWa or STa reference points.

4.2.2 Commands

4.2.2.1 Commands for SWa authentication and authorization procedures

4.2.2.1.1 Diameter-EAP-Request (DER) Command

The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the ‘R’ bit set in the Command Flags field, is sent from a trusted non-3GPP access network to a 3GPP AAA Server.

< Diameter-EAP-Request > ::= < Diameter Header: 268, REQ, PXY >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Request-Type }

{ EAP-Payload }

[ User-Name ]

[ Calling-Station-Id ]

[ RAT-Type ]

…

[ ANID ]

[ Full-Network-Name ]

[ Short-Network-Name ]

*[ Supported-Features ]

[ AAA-Failure-Indication ]

[ Transport-Access-Type ]

[ OC-Supported-Features ]

[ Access-Network-Info ]

[ User-Location-Info-Time ]

…

*[ AVP ]

4.2.2.1.2 Diameter-EAP-Answer (DEA) Command

The Diameter-EAP-Answer (DEA) command, indicated by the Command-Code field set to 268 and the ‘R’ bit cleared in the Command Flags field, is sent from a 3GPP AAA Server to a trusted non-3GPP access network NAS.

< Diameter-EAP-Answer > ::= < Diameter Header: 268, PXY >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

{ Auth-Request-Type }

[ EAP-Payload ]

[ User-Name ]

[ Session-Timeout ]

[ Accounting-Interim-Interval ]

[ EAP-Master-Session-Key ]

*[ Redirect-Host ]

[ AN-Trusted ]

*[ Supported-Features ]

[Mobile-Node-Identifier]

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

…

*[ AVP ]

4.2.2.2 Commands for SWa HSS/AAA Initiated Detach

Refer to clause 5.2.2.2.

4.2.2.3 Commands for Untrusted non-3GPP Access network Initiated Session Termination

Refer to clause 5.2.2.4.

4.2.2.4 Commands for SWa Re-Authentication and Re-Authorization Procedures

4.2.2.4.1 Re-Auth-Request (RAR) Command

The Diameter Re-Auth-Request (RAR) command, indicated by the Command-Code field set to 258 and the "R" bit set in the Command Flags field, shall be sent from a 3GPP AAA server to an untrusted non-3GPP access network NAS. ABNF for the RAR command shall be as follows:

< Re-Auth-Request > ::= < Diameter Header: 258, REQ, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ User-Name ]

…

*[ AVP ]

4.2.2.4.2 Re-Auth-Answer (RAA) Command

The Diameter Re-Auth-Answer (RAA) command, indicated by the Command-Code field set to 258 and the "R" bit cleared in the Command Flags field, shall be sent from an untrusted non-3GPP access network NAS to a 3GPP AAA server. ABNF for the RAA command shall be as follows:

< Re-Auth-Answer > ::= < Diameter Header: 258, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

…

*[ AVP ]

4.2.2.4.3 Diameter-EAP-Request (DER) Command

Refer to clause 4.2.2.1.1.

4.2.2.4.4 Diameter-EAP-Answer (DEA) Command

Refer to clause 4.2.2.1.2

4.2.3 Information Elements

The information elements of SWa are the same as the IEs defined for the STa interface described in the clause 5.2.3.

4.2.4 Session Handling

The session handling for the SWa interface is the same as the STa session handling described in the clause 5.2.4.