Notes on post-quantum considerations for 802.1 security standards

Quantum attacks generally relate to public key (i.e. asymmetric cryptography) and not to private key (symmetric cryptography). Quantum attacks on symmetric cryptography are addressed by increasing key length. From the NSA FAQ (hyperlink below) "Q: What about the symmetric algorithms in the CNSA Suite A: The CNSA Suite mandates symmetric algorithms with sufficient strength to resist anticipated quantum computing threats. The intent is to only update the public key components of the suite with quantum-resistant components." See also below.

802.1AE MAC Security uses symmetric cryptography (not public key), and is already structured to make the addition of additional Cipher Suites (e.g. for longer key lengths) an easy activity when required. Typically, as in the past, we have done that in response to requests from our most security conscious customers/contributors (NIST/NA). Currently (in 802.1AE) we support GCM-AES-128 and GCM-AES-256 (128 and 256 bit key lengths), we discussed the adequacy of the 256 bit key length re quantum when we added that and it was believed adequate. This aligns with the current recommendations in the NSA FAQ on Quantum Computing and Post-Quantum Cryptography:

https://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.PDF

(see third page, second question on the CNSA - ..suite of algorithms identified in the Committee on National Security Systems Policy 15 for protecting NSS [National Security Systems], including classified information ..)

802.1X specifies MACsec Key Agreement (MKA) for discovering (previously) authenticated peer(s) and distributing the keys actually used to protect data to those systems. MKA itself only uses symmetric key cryptography to protect the messages it sends and to further key-wrap data keys distributed in those messages. The symmetric keys that MKA uses are derived from (as per normal security practice individual keys are not used for multiple purposes) the symmetric CAK (Connectivity Association Key). The CAK itself is either pre-shared (often described as pre-placed) out of band or is derived from the MSK (Master Session Key) provided as the result of successful authentication by EAP.

Authentication protocols such as EAP generally rely on assymetric cryptography and in particular on the use of Diffie-Helman key exchanges. The 802.11 investment in 802.1X/EAP is substantial and it would seem to me that 802.11 should lead any proposed changes to EAP resulting from changes to public key use in credentials, with 802.1 supporting changes as and when necessary. Existing provisions for algorithm agility should enable us to move quickly when appropriate (see below). Note that end to end cryptography may additionally protect content, and the major short-term consideration might be the future recovery of confidential infomation from current communications.

So, from the 802.1 perspective and in alignment with NSA/NIST recommendations, no changes to MACsec (802.1AE) or change to MACsec Key Agreement (MKA in 802.1X) are necessary, and we should follow 802.11's lead for the timing of any future changes to 802.1 EAP related text (if any are desirable, as it may well be all necessary changes are within 802.11 scope).

802.1AR Secure Device Identity **is** based on public-key usage. 802.1AR-2018 was a significant revision which not only added the ECDSA P384/SHA-384 signature suite on NIST (I think NIST not NSA in this case, but Karen might correct me) but also restructured the document to make the addition of one or more future signature suites much easier (basically add a new subclause to the existing Clause 9). However a very important user of 802.1AR DevIDs is BRSKI (pronounced "brewski", Bootstrapping Remote Secure Key Infrastructure, RFC 8995). The lead author for BRSKI is Max Pritikin who was the editor (and principal technical light) for 802.1AR-2009. The ISO/IEC 6802 Joint Project currently plans to use BRSKI. BRSKI is an important and non-trivial undertaking and we should not independently disturb its foundations. 

In general we need to be appropriately cautious before starting work that may directly overlap/contradict/duplicate IETF work, and conduct appropriate liaison.

While current NIST post-quantum work has entered the third (and presumed final) round, past experience is that with similar efforts is that this could take some time. Moreover it is not the case that this round will pick a "winner". See

https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs

The three NIST contacts provided include Lily Chen who has attended 802.1 Security TG meetings in the past and helped us with a number of points and subsequent approvals.

Some very security conscious user of MACsec use pre-shared keys (PSKs, one of the alternatives for the 802.1AE/802.1X MKA CAK syymetric key) rather than protocol exchanges using public key technology to agree a CAK. The NSA FAQ page referenced above has this to say on that subject:

"Q: I have long data life concerns and want to adopt CSfC solutions. How can I ensure my communications and data remain secure against an adversary with a quantum computer?
A: Some CSfC solutions may be implemented using symmetric, pre-shared keys that protect against the long- term quantum computing threat. NSA considers the use of pre-shared symmetric keys in a standards- compliant fashion to be a better near-term post-quantum solution than implementation of experimental post- quantum asymmetric algorithms that may or may not be proven secure and which will not be compatible with NIST standards. For more info, contact the CSfC program office."

That's a heads-up that we be careful in this space. It's not a roll-your-own opportunity. The IETF has work going on and we should defer to that rather than pollute the transition to post-quantum space with other variants - even if those variants are no more than a novel assembly of soon to be standardized kit of parts . Any post quantum effort would leave 802.1AE and 802.1X MKA untouched, should align with IETF work on BRSKI in the case of 802.1AR, and should be within 802.11 jurisdiction for any EAP changes.

Mick