July 2010doc.: IEEE 802.11-10/0751r2
IEEE P802.11
Wireless LANs
Date: 2010-07-06
Author(s):
Name / Affiliation / Address / Phone / email
Dan Harkins / Aruba Networks / 1322 Crossman ave, Sunnyvale, CA / +1 408 227 4500 / dharkins at aruba networks dot com
8.2a.3 Representation of a password
Passwords are used in SAE to deterministically compute a secret element in the negotiated group, called a “password element”. The input to this process must be in the form of a binary string. For the protocol to successfully terminate, it is necessary for each side to produce identical binary strings for a given password, even if that password is in character format. There is no canonical binary representation of a character and ambiguity exists when the password is a character string. To eliminate this ambiguity a compliant STA shall represent a character-based password as an ASCII string. Representation of a character-based password in another character set or use of a password pre-processing technique (to map a character string to a binary string) may be agreed upon, in an out-of-band fashion, prior to beginning SAE. If the password is already in binary form (e.g. it is a binary pre-shared key) no character set representation is assumed. The binary representation of the password, after being transformed from a character representation or directly if it is already in binary form, is stored in the dot11RSNASAEPasswordValueTable. When a “password” is called for in the description of SAE that follows the credential from the dot11RSNASAEPasswordValueTable shall be used.
Modify section 8.2a.4 as indicated
8.2a.4 Finite cyclic groups
SAE uses discrete logarithm cryptography to achieve authentication and key agreement. Each party to the exchange derives ephemeral public and private keys with respect to a particular set of domain parameters that define a finite cyclic group. Groups can be based on either Finite Field Cryptography (FFC) or on Elliptic Curve Cryptography (ECC). Each component of a group is referred to as an “element”. Groups are negotiated using an identifying number from a repository maintained by IANA as “Group Description” attributes for RFC 2409 (IKE). The repository maps an identifying number to a complete set of domain parameters for the particular group. For the purpose of interoperability, conformant STAs shall support group nineteen (19), an ECC group defined over a 256-bit prime order field.
More than one group can be configured on a STA for use with SAE by using the dot11RSNAConfigDLCGroup table. Configured groups are prioritized in ascending order of preference. If only one group is configured it is, by definition, the most preferred group. Note: the preference of one group over another is a local policy issue.
Modify section 8.2a.6 as indicated
8.2a.6 Anti-Clogging Tokens
A STA is required to do a considerable amount of work upon receipt of a Commit Message. This opens up the possibility of a distributed denial-of-service attack by flooding a STA with bogus Commit Messages from forged MAC addresses. To prevent this from happening, a STA shall maintain a counter in its SAE state machine indicating the number of open and unfinished protocol instances. When that counter hits or exceeds dot11RSNASAEAntiCloggingThreshold the STA shall respond to each Commit Message with a rejection that includes an Anti-Clogging Token statelessly bound to the sender of the Commit Message. The sender of the Commit Message must then include this Anti-Clogging Token in a subsequent Commit Message.
The Anti-Clogging Token is a variable length value that statelessly binds the MAC address of the sender of a Commit Message. The length of the Anti-Clogging Token needs not be specified because the generation and processing of the Anti-Clogging Token is solely up to one peer. To the other peer in the SAE protocol, the Anti-Clogging Token is merely an opaque blob whose length is insignificant. It is suggested that an Anti-Clogging Token not exceed 256 octets.
NOTE— A suggested method for producing Anti-Clogging Tokens is to generate a random secret value each time the state machine variable hits dot11RSNASAEAntiCloggingThreshold and pass that secret and the MAC address of the sender of the Commit Message to the random function H to generate the token.
As long as the state machine variable is greater than dot11RSNASAEAntiCloggingThreshold all Commit Messages that do not include an Anti-Clogging Token must be rejected with a request to repeat the Commit Message and include the token.
.
Modify section 8.2a.7.2.4 as indicated
8.2a.7.2.4 Element to octet string conversion
For elliptic curve ECC groups the element is a point on the elliptic curve and consists of two components: an x-coordinate followed by a y-coordinate. To convert a point on a curve to an octet string, each component shall be treated as an integer and converted into an octet string whose length is the smallest length m such that 28m p, where p is the bit length of the prime of the group, according to 8.2a.7.2.2 (Integer to octet string conversion). The point shall be represented as two octet strings concatenated together, the x-coordinate as an octet string followed by the y-coordinate as an octet string, and is 2m octets long.
For prime modulusFFC groups the element is an integer less than the prime of the group. To convert such an element into an octet string the element shall be treated directly as an integer and converted into an octet string whose length is the smallest length m such that 28mp, where p is the bit length of the prime of the group, according to 8.2a.7.2.2 (Integer to octet string conversion).
Modify the title of section 8.2a.7.4 as indicated
8.2a.7.4 Encoding and decoding of Commit Messages
Modify section 8.2a.7.4 as indicated
8.2a.7.4 Status codes
A Commit Message with a non-zero status code shall indicate that a peer rejects a previously sent Commit Message. An unsupported finite cyclic group is indicated with a status code of <ANA 18>, “Requested aAuthentication algorithmis rejected because the offered finite cyclic group is not supported”. An Anti-Clogging Token is requested by transmitting a Commit Message with a status code of <ANA 17>, “Anti-Clogging Token Requested”, with the Anti-Clogging Token occupying the Token field of the Authentication frame.
A Confirm Message, with a non-zero status code, shall indicate that a peer rejects a previously sent Confirm Message. A Confirm Message that was not successfully verified is indicated with a status code of fifteen (15), “Authentication rejected; the response to the challenge failed”.
Modify section 8.2a.8.6.1 as indicated
8.2a.8.6.1 Parent process behavior
Upon receipt of a Commit Message, the parent process checks whether a protocol instance for the peer MAC address exists in the database. If one does, and it is in either Committed state or Confirmed state the frame shall be passed to the protocol instance. If one does and it is in Authenticated state, the scalar in the received frame is checked against the peer-scalar used in authentication of the existing protocol instance (in Authenticated state). If it is identical the frame shall be dropped. If not the parent process checks the value of Open. If Open is greater than dot11RNSASAEAntiCloggingThreshold the parent process shall check for the presence of an Anti-Clogging Token. If an Anti-Clogging Token exists, and is correct, the parent process shall create a protocol instance. If the Anti-Clogging Token is incorrect the frame shall be silently discarded. If Open is greater than dot11RSNASAEAntiCloggingThreshold and there is no Anti-Clogging Token in the received frame, the parent process shall construct a response as an 802.11 Authentication frame with Authentication sequence number one (1), status <ANA 17> and the body of the frame consisting of an Anti-Clogging Token (see 8.2a.6 (Anti-Clogging Tokens)). If Open is not greater than dot11RSNASAEAntiCloggingThreshold the parent process shall create a protocol instance and the frame shall be sent to the protocol instance as a Com event.
Upon receipt of a Confirm Message the parent process checks whether a protocol instance for the peer MAC address (as indicated by the SA in the received frame) exists in the database. If there is a single protocol instance the frame shall be passed to it as a Con event. If there are two (2) protocol instances indexed by that peer MAC address the frame shall be passed, as a Con event, to the protocol instance that is not in Accepted state. If there are no protocol instances indexed by that peer MAC address the frame shall be dropped.
Modify section 8.2a.8.6.2a as indicated
8.2a.8.6.2a General
When the state machine calls for the t0 (retransmission) timer to be set, it shall be set to the value of dot11RSNASAERetransPeriod. When the state machine calls for the t1 (key expiry) timer to be set, it shall be set to the value of dot11RSNAConfigPMKLifetime.
Modify section 8.2a.8.6.2c as indicated
8.2a.8.6.2c Committed state
Upon receipt of a Com event the t0 (retransmission) timer shall be cancelled. Then the following is performed:
—The protocol instance shall check the Status of the Authentication frame. If the Status is <ANA 17> a new Commit Message shall be constructed with the Anti-Clogging Token from the received Authentication frame, and the commit-scalar and commit-element previously sent. The new Commit Message shall be transmitted to the peer, Sync shall be zeroed, and the t0 (retransmission) timer shall be set.
—If the Status is <ANA 18> the protocol instance shall check the finite cyclic group field being rejected. If the rejected group matches the last offered group the protocol instance shall choose a different group, it then generates and transmits a new Commit Message to the peer, zeros Sync, sets the t0 (retransmission) timer, and remains in Committed state. If there are no other groups to choose the protocol instance shall send a Del event to the parent process and transitions back to Nothing.
—If the Status is some other non-zero value the frame shall be silently discarded and the t0 (retransmission) timer shall be set.
—If the Status is zero the finite cyclic group field is checked. If the group is not supported BadGrp shall be set and the value of Sync shall be checked.
—If Sync is greater than dot11RSNASAESync the protocol instance shall send a Del event to the parent process and transitions back to Nothing.
—If Sync is not greater than dot11RSNASAESync, Sync shall be incremented, a Commit Message with Status equal to <ANA 18> indicating rejection, and the Algorithm identifier set to the rejected algorithm, shall be sent to the peer, the t0 (retransmission) timer shall be set and the protocol instance shall remain in Committed state.
—If the group is supported but does not match that used when the protocol instance constructed its Commit Message, DiffGrp shall be set and the local identity and peer identity shall be checked.
—The mesh STA, with the numerically greater of the two MAC addresses, drops the received Commit Message, retransmits its last Commit Message, and shall set the t0 (retransmission) timer and remain in Committed state.
—The mesh STA, with the numerically lesser of the two MAC addresses, zeros Sync, shall increment Sc, choose the group from the received Commit Message, process the received Confirm Message according to 8.2a.5.5 (Processing of a peer’s Confirm
—Message), generate a new Commit Message and Confirm Message, and shall transmit the new Commit and Confirm to the peer. It shall then transition to Confirmed state.
—If the group is supported and matches that used when the protocol instance constructed its Commit Message, the protocol instance checks the peer-commit-scalar and peer-commit-element from the message. If they match those sent as part of the protocol instance’s own Commit Message the frame shall be silently discarded (because it is evidence of a reflection attack) and the t0 (retransmission) timer shall be set. If the received element and scalar differ from the element and scalar offered the received Commit Message shall be processed according to 8.2a.5.3 (Processing of a peer’s Commit
—Message), the Sc counter shall be incremented (thereby setting its value to one), the protocol instance shall then construct a Confirm Message, transmit it to the peer, and set the t0 (retransmission) timer. It shall then transition to Confirmed state.
If the t0 (retransmission) timer fires the value of the Sync counter is checked. If Sync is greater than dot11RSNASAESync the protocol instance shall send a Del event to the parent process and transition back to Nothing. If Sync is not greater than dot11RSNASAESync the Sync counter shall be incremented, the last message sent shall be sent again, and the t0 (retransmission) timer shall be set.
Upon receipt of a Con event the t0 (retransmission) timer shall be cancelled. Then the protocol instance checks the value of Sync. If it is greater than dot11RSNASAESync the protocol instance shall send a Del event to the parent process and transition back to Nothing. If Sync is not greater than dot11RSNASAESync the protocol instance shall increment Sync, transmit the last Commit Message sent to the peer, and set the t0 (retransmission) timer.
Modify section 8.2a.8.6.2d as indicated
8.2a.8.6.2d Confirmed state
Upon receipt of a Com event the t0 (retransmission) timer shall be cancelled. If the Status is non-zero the frame shall be silently discarded, the t0 (retransmission) timer set, and the protocol instance shall remain in the Confirmed state. If Sync is greater than dot11RSNASAESync the protocol instance shall send the parent process a Del event and transitions back to Nothing. If Sync is not greater than dot11RSNASAESync the protocol instance shall verify that the finite cyclic group is the same as the previously received Commit frame. If not the frame shall be silently discarded. If so, the protocol instance shall increment Sync, increment Sc, and transmit its Commit and Confirm (with the new Sc value) messages. It then shall set the t0 (retransmission) timer.
Upon receipt of a Con event the t0 (retransmission) timer shall be cancelled and the Confirm Message shall be processed according to 8.2a.5.5 (Processing of a peer’s Confirm
Message). If processing is successful and the Confirm Message has been verified, the Rc variable shall be set to the send-confirm portion of the frame, Sc shall be set to the value 216 – 1, the t1 (key expiry) timer shall be set, and the protocol instance shall transition to Accepted state.
If the t0 (retransmission) timer fires the value of the Sync counter shall be checked. If Sync is greater than dot11RSNASAESync the protocol instance shall send a Del event to the parent process and transition back to Nothing. If Sync is not greater than dot11RSNASAESync, the Sync counter shall be incremented, Sc shall be incremented, and the protocol instance shall create a new Confirm (with the new Sc value) Message, transmit it to the peer and set the t0 (retransmission) timer.
Modify section 8.2a.8.6.2e as indicated
8.2a.8.6.2e Accepted state
In Accepted state a protocol instance has sent a Commit Message and a Confirm Message to its peer and received a Commit Message and Confirm Message from the peer. Unfortunately, there is no guarantee that the final Confirm Message was received by the peer.
Upon receipt of a Con event, the Sync counter shall be checked. If the value is greater than dot11RSNASAESync the protocol instance shall send a Del event to the parent process and shall transition to Nothing state. If the value of Sync is not greater than dot11RSNASAESync, the value of send-confirm shall be checked. If the value is not greater than Rc or is equal to 216 - 1, the received frame shall be silently discarded. Otherwise the Confirm portion of the frame shall be checked according to 8.2a.5.5 (Processing of a peer’s Confirm Message). If the verification fails, the received frame shall be silently discarded. If the verification succeeds, the Rc variable shall be set to the send-confirm portion of the frame, the Sync shall be incremented and a new Confirm Message shall be constructed (with Sc set to 216–1) and sent to the peer. The protocol instance shall remain in Accepted state.
D.3 MIB Detail
Modify dot11smt as indicated
dot11smt OBJECT IDENTIFIER ::= { ieee802dot11 1 }
-- dot11smt GROUPS
-- dot11StationConfigTable ::= { dot11smt 1 }
-- dot11AuthenticationAlgorithmsTable ::= { dot11smt 2 }
-- dot11WEPDefaultKeysTable ::= { dot11smt 3 }
-- dot11WEPKeyMappingsTable ::= { dot11smt 4 }
-- dot11PrivacyTable ::= { dot11smt 5 }
-- dot11SMTnotification ::= { dot11smt 6 }
-- dot11MultiDomainCapabilityTable ::= { dot11smt 7 }
-- dot11SpectrumManagementTable ::= { dot11smt 8 }
-- dot11RSNAConfigTable ::= { dot11smt 9 }
-- dot11RSNAConfigPairwiseCiphersTable ::= { dot11smt 10 }
-- dot11RSNAConfigAuthenticationSuitesTable ::= { dot11smt 11 }
-- dot11RSNAStatsTable ::= { dot11smt 12 }
-- dot11OperatingClassesTable ::= { dot11smt 13 }
-- dot11RadioResourceMeasurement ::= { dot11smt 14 }
-- dot11FastBSSTransitionConfigTable ::= { dot11smt 15 }
-- dot11LCIDSETable ::= { dot11smt 16 }
-- dot11HTStationConfigTable ::= { dot11smt 17 }
-- dot11MeshStationConfigTable::= { dot11smt 18 }
-- dot11MeshHWMPConfigTable::= { dot11smt 19 }
-- dot11RSNAConfigPasswordValueTable::= { dot11smt 20 }
-- dot11RSNAConfigDLCGroupTable::= { dot11smt 21 }
Modify dot11AuthenticationAlgorithm and corresponding algorithms as indicated:
dot11AuthenticationAlgorithmsTable OBJECT-TYPE
SYNTAX SEQUENCE of Dot11AuthenticationAlgorithmsEntry
MAC-ACCESS not-accessible
STATUS current
DESCRIPTION
“This (conceptual) table of attributes is a set of all the
authentication algorithms supported by stations. The fol-
lowing are the default values and the associated algorithm:
Value = 1: Open System
Value = 2: Shared Key
Value = 3: Fast BSS Transition (FT)
Value = <ANA 1>: Simultaneous Authentication of Equals (SAE)”
REFERENCE “IEEE Std 802.11-<year>, 7.3.1.1 (Authentication Algorithm Number
field)”
::= { dot11smt 2 }
dot11AuthenticationAlgorithm OBJECT-TYPE
SYNTAX INTEGER { openSystem(1), sharedKey(2), fastBSSTransition(3),
simultaneousAuthEquals(<ANA 1>) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
“This is a control variable.
It is written by an external management entity.
Changes take effect as soon as practical in the implementation.
This attribute is the authentication algorithm described by this
entry in the table. The following values can be used here
Value = 1: Open System
Value = 2: Shared Key
Value = 3: Fast BSS Transition (FT)
Value = <ANA 1>: Simultaneous Authentication of Equals (SAE)”
::= { dot11AuthenticationAlgorithmsEntry 2 }
Remove changes made to “Dot11OperationEntry” and the dot11SAERetransPeriod, dot11SAEAntiCloggingThreshhold, and dot11SAESync.
Modify “Dot11RSNAConfigEntry” and add the following 3 components to the end of dot11RSNAConfig TABLE
Dot11RSNAConfigEntry ::=
SEQUENCE {
dot11RSNAConfigVersion Unsigned32,
dot11RSNAConfigPairwiseKeysImplemented Unsigned32,
dot11RSNAConfigGroupCipher OCTET STRING,
dot11RSNAConfigGroupRekeyMethod INTEGER,
dot11RSNAConfigGroupRekeyTime Unsigned32,
dot11RSNAConfigGroupRekeyPackets Unsigned32,
dot11RSNAConfigGroupRekeyStrict TruthValue,
dot11RSNAConfigPSKValue OCTET STRING,
dot11RSNAConfigPSKPassPhrase DisplayString,
dot11RSNAConfigGroupUpdateCount Unsigned32,
dot11RSNAConfigPairwiseUpdateCount Unsigned32,
dot11RSNAConfigGroupCipherSize Unsigned32,
dot11RSNAConfigPMKLifetime Unsigned32,
dot11RSNAConfigPMKReauthThreshold Unsigned32,
dot11RSNAConfigNumberOfPTKSAReplayCountersImplemented
Unsigned32,
dot11RSNAConfigSATimeout Unsigned32,
dot11RSNAAuthenticationSuiteSelected OCTET STRING,
dot11RSNAPairwiseCipherSelected OCTET STRING,
dot11RSNAGroupCipherSelected OCTET STRING,
dot11RSNAPMKIDUsed OCTET STRING,
dot11RSNAAuthenticationSuiteRequested OCTET STRING,
dot11RSNAPairwiseCipherRequested OCTET STRING,
dot11RSNAGroupCipherRequested OCTET STRING,
dot11RSNATKIPCounterMeasuresInvoked Unsigned32,
dot11RSNA4WayHandshakeFailures Unsigned32,
dot11RSNAConfigNumberOfGTKSAReplayCountersImplemented
Unsigned32,
dot11RSNAConfigSTKKeysImplemented Unsigned32,
dot11RSNAConfigSTKCipher OCTET STRING,
dot11RSNAConfigSTKRekeyTime Unsigned32,