cr for recirc CID4002
Date: 2024-4-30
Author(s):
Name	Affiliation	Address	Phone	email
Yan Li	ZTE Corporation	Yan.li16@zte.com.cn
Jay Yang	ZTE Corporation

Abstract

This submission proposes resolutions for the following CID:

4002

R0: comments resolution for CID 4002 and more changes for PASN ID because of missing incorporation to the D5.0

Interpretation of a Motion to Adopt

A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGbh D5.0 Draft. This introduction is not part of the adopted material.

Editing instructions formatted like this are intended to be copied into the TGbh D5.0 Draft. (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents).

TGbh Editor: Editing instructions preceded by “TGbh Editor” are instructions to the TGbh editor to modify existing material in the TGbh draft. As a result of adopting the changes, the TGbh editor will execute the instructions rather than copy them to the TGbh Draft.

CID	Comment	Proposed Change	Resolution
4002	[On behalf of Yan Li]the notes of PASN ID indicate PASN ID is only present if Device ID present,which can be interpreted as PASN ID should be mandatory if Device ID present.However, in clause 12 both of Device ID and PASN ID would be provided only in the case of initial connection and 'not recognized'case. There is no similar requirement for 'recognized'case. Please clarify it	as the comments	Revised— If a new device ID(long-term parameter) is provided by the network, a new PASN ID(short-term parameter) shall also be provided along with the new device ID. Therefore, the relevant text in clause 12 should be modified to keep consistent with the notes cited in the comment for FILS authentication and 4-HS. TGbh editor to make the changes with tag #4002 in 11-24/1294r0

P21L25	Please note changes of PASN ID are related to MLME-ASSOCIATION.confirm and .response primitive based on the CR doc 24/789r9, while the changes occur in the MLME-ASSOCIATION.request and .response primitive of D5.0(Please check it,Carol)

6.5 MLME SAP primitives

6.5.7 Associate

6.5.7.2 MLME-ASSOCIATE.request

6.5.7.2.2 Semantics of the service primitive

Change the primitive parameters list as follows (not all parameters are shown):

The primitive parameters are as follows:

MLME-ASSOCIATE.request(

...

Device ID,

IRM,

VendorSpecificInfo

)

Name	Type	Valid Range	Description
Device ID	Device ID element	As defined in 9.4.2.316 (Device ID element)	Specifies the device ID for the requesting STA. Optionally present if dot11FILSActivated is true and dot11DeviceIDActivated is true, otherwise not present.
IRM	IRM element	As defined in 9.4.2.317 (IRM element)	Specifies the IRM for the requesting STA. Optionally present if dot11FIL- SActivated is true and dot11IRMActi- vated is true, otherwise not present.

6.5.7.3 MLME-ASSOCIATE.confirm

6.5.7.3.2 Semantics of the service primitive

Change the primitive parameters list as follows (not all parameters are shown):

The primitive parameters are as follows:

MLME-ASSOCIATE.confirm(

...

Device ID,

IRM,

PASN ID,

VendorSpecificInfo

)

Add the following rows to the parameter description table before the VendorSpecificInfo row (header row

shown for convenience):

Name	Type	Valid Range	Description
Device ID	Device ID element	As defined in 9.4.2.316 (Device ID element)	Specifies the device ID for the requesting STA. Optionally present if dot11FILSActivated is true and dot11DeviceIDActivated is true, otherwise not present.
IRM	IRM element	As defined in 9.4.2.317 (IRM element)	Specifies the IRM for the requesting STA. Optionally present if dot11FIL- SActivated is true and dot11IRMActi- vated is true, otherwise not present.
PASN ID	PASN ID element	As defined in 9.4.2.xxx (PASN ID element)	Specifies the PASN ID for the requesting STA.PASN ID is only present if Device ID is present.

P32L40 please note this is a typo

9.4.2.320 PASN ID element

The PASN ID element contains a PASN ID. The format of the PASN ID element is shown in Figure 9-

1074h (PASN ID element format).

Element ID	Length	Element ID Extension	PASN ID Length	PASN ID Status	PASN ID

Octets: 1 1 1 1 0 or 1 variable

Figure 9-1074h -PASN ID element format

The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General).

The PASN ID Length field contains the length of the PASN ID field.

When the element is sent from an AP, the PASN ID Status field is defined in Table 9-417d (PASN ID Status field values).

When the element is sent from a non-AP STA, the PASN ID Status field is not present.

12.2.12.1 Device ID mechanism

P37L56

If a non-AP STA has been provided a device ID and a PASN ID by an ESS, then it may provide that device ID when returning to that ESS. It provides the device ID as follows:

1) When using FILS authentication, in a Device ID element in the Association Request frame.

2) When not using PASN or FILS authentication, in a Device ID KDE in message 2 of the 4-way handshake.

(#4002)Then an AP shall provide both a device ID and a PASN ID as follows:

1) When using FILS authentication, the AP shall provide a device ID in a Device ID element and a PASN ID in a PASN ID element in the Association Response frame.

2) When not using PASN or FILS authentication, the AP shall provide a device ID in a Device ID KDE and a PASN ID in a PASN ID KDE in message 3 of the 4-way handshake.

12.7.2 EAPOL-Key frames

P42L1 please note cited sentence(P38L12) :the value of PASN ID shall be random and not shorter than 6 octets.

The format of the PASN ID KDE is shown in Figure 12-50c (PASN ID KDE format).

PASN ID Status	PASN ID

Octets:	0 or 1 variable

The PASN ID Status field is defined in 9.4.2.320 (PASN ID element).

The PASN ID field contains a PASN ID.

Please note PASN ID KDE may carried in the message 3 of 4-way handshake based on the CR doc 24/789r9, (Please check it,Carol)

12.7.6 4-way handshake

12.7.6.1 General

Modify the following text as shown.

RSNA defines a protocol using EAPOL-Key frames called the 4-way handshake. The handshake completes the IEEE 802.1X authentication process. The information flow of the 4-way handshake is as follows:

Message 1:Authenticator  Supplicant: EAPOL-Key(0 or 1,0,1,0,P,0,0,ANonce,0,{[PMKID]})

Message 2:Supplicant  Authenticator: EAPOL-Key(0 or 1,1,0,0,P,0,0,SNonce,MIC,{RSNE [,RSNXE]

[,OCI] [, Device ID KDE]})

Message 3:AuthenticatorSupplicant:

EAPOL-Key(1,1,1,1,P,0,RSC,ANonce,MIC,{RSNE [, RSNXE] [, OCI], GTK(N) [, IGTK(M,

IPN)] [, BIGTK(Q, BIPN)] [, WIGTK(R. WIPN)] [, SSID] [, Device ID KDE] [, IRM KDE] [, PASN ID KDE]})

Message 4:Supplicant  Authenticator: EAPOL-Key(1,1,0,0,P,0,0,0,MIC, {[IRM KDE]}).

Please note PASN ID KDE may also carried in the message 3 of FT 4-way handshake

13.4.2 FT initial mobility domain association in an RSN

Change the following text as shown.

The R1KH and S1KH then perform an FT 4-way handshake. The EAPOL-Key PDU notation is defined in

12.7.4 (EAPOL-Key PDU notation).

R1KH->S1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0, {})

S1KH->R1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, {RSNE(PMKR1Name) [, RSNXE], MDE,

FTE [, Device ID KDE]})

R1KH->S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, {RSNE(PMKR1Name) [, RSNXE], [,

OCI], MDE, FTE, TIE(ReassociationDeadline), TIE(KeyLifetime), GTK(N) [, IGTK(M, IPN)] [,

BIGTK(Q, BIPN)] [, WIGTK(R, WIPN)] [, Device ID KDE] [, IRM KDE] [, PASN ID KDE]})

S1KH->R1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, {[IRM KDE]})