TGs Authenticated Encryption Function

1. TGs Authenticated Encryption Function Authors: Date: 2009-07 Russ Housley (Vigil Security), et. al.

2. Abstract This submission proposes: • Replacing the required use of AES-SIV in P802.11s draft with AES-CCM Russ Housley (Vigil Security), et. al.

3. Current situation • P802.11s D3.0, Mar 2009, Section 11.B.3.2.3 GTK Distribution: • “… The deterministic authenticated encryption mode of AES-SIV, defined in IETF RFC 5297, shall be used to protect the GTK field using the AKEK derived from the chosen PMK…” • Requirement to use AES-SIV for 802.11s GTK protection has been in draft since D2.02, Sep 2008 • AES-CCM is the mandatory authenticated encryption algorithm for Robust Security Network compliance throughout the existing 802.11 universe Russ Housley (Vigil Security), et. al.

4. Why consider AES-CCM for 11s? • Con • Late in the game: AES-SIV is already in D3.0 (ref given above) • AES-SIV is more “misuse resistant” than AES-CCM • Pro • AES-CCM is the established Authenticated-Encryption standard for WPA2 and 802.11 Robust Security Network applications • CCM is the NIST approved block cipher mode for authenticated encryption, NIST SP800-38C • 11s is a component of the much larger 802.11 universe, as such it should re-use established 802.11 methods wherever possible Russ Housley (Vigil Security), et. al.

5. Primary reason for (re)consideration • Yes, it is late in the game. • AES-SIV is in the document that has gone through initial voting/approval • - The core engine of AES-SIV is the approved and well known AES • - AES-SIV has received significant academic scrutiny • But, was this feature carefully considered by all concerned • Cost of implementing a new variation: learning and properly building • H/W & S/W cost of supporting an additional cipher – still must support 11i • Risks of implementing a non-NIST approved algorithm • 802.11s is a part of the larger 802.11 universe • - Is it the place to introduce a new cipher mode when one is already • in place and widely implemented? • - Would it be better to expend a bit more effort now in carefully weighing • the consequences rather than being unpleasantly surprised later? Russ Housley (Vigil Security), et. al.

6. SIV – CCM Comparison • Differences are minor • Both use CMAC mode of AES to compute MAC • Both use AES in counter (CTR) mode to encrypt data • Nonce vs. “Synthetic Initialization Vector” (SIV) • CTR mode requires a 128-bit initialization vector (IV) • CCM uses a random nonce for IV, SIV uses the MAC for IV • 802.11i uses the packet number for the nonce in CCM • Constraint on nonce is that it not be reused for a given encryption key • At bit level, packaging and padding, differences are more evident – the devil resides in the details Russ Housley (Vigil Security), et. al.

7. So, what’s the big deal? • Precisely because the CCM – SIV differences are not significant, it begs the question, “Why change at all from the widely implemented and established method?” • SIV appears to offer better nonce misuse protections in general • But, for 802.11s application being considered here this is easily solved • The bit level differences will entail significant effort in designing, coding, implementing and testing • Is this effort worth the gain? • Where else within 802.11 can the SIV block of code (or piece of hardware) be applied to amortize the expense of building? Russ Housley (Vigil Security), et. al.

8. Whither AES-SIV • AES-SIV is a sound algorithm with some good features • It should be given serious consideration for use in new protocols and technologies or for major security service upgrades • But neither AES-SIV, nor any other new authenticated or encryption mode, should be introduced for confidentiality and integrity of a single 802.11 sub-element Russ Housley (Vigil Security), et. al.

9. Conclusion • A proven, approved, already designed, built and widely employed solution exists to solve the secure GTK transport problem in 802.11s • The secure GTK transport problem is too minor an application to warrant developing a new solution • Requiring a new solution for a single sub-element within 802.11s should be carefully considered • To determine if the advantage gained justifies the expense of implementation • To determine if a single application within 802.11s is the place to introduce new security mode Russ Housley (Vigil Security), et. al.

10. Summary • The purpose of 802.11s is to develop acceptable standards for wireless mesh networking within the 802.11 framework • 802.11s is not the place to introduce new security algorithms if accepted and adequate security algorithms already exist in 802.11 • New algorithms impose added implementation cost • Additional algorithms impose added maintenance/support cost • Algorithms that are not yet approved by NIST or other security standards bodies have additional risk • 802.11s should not be burdened with these costs and risk Russ Housley (Vigil Security), et. al.

11. Recommendation • Recommend that P802.11s D3.0, Mar 2009, Section 11.B.3.2.3 GTK Distribution: “… The deterministic authenticated encryption mode of AES-SIV, defined in IETF RFC 5297, shall be used to protect the GTK field using the AKEK derived from the chosen PMK…” be amended* to replace “AES-SIV defined in IETF RFC 5297” with “AES-CCM defined in IETF RFC 3610” *This change will have a modest ripple effect of changes elsewhere in the draft where this requirement is referenced and applied Russ Housley (Vigil Security), et. al.

12. Comments? Russ Housley (Vigil Security), et. al.

13. Acronyms AKEK – Abbreviated Handshake Key Encryption Key AAD – Additional Authenticated Data PMK – Pairwise Master Key GTK – Group Temporal Key SIV – Synthetic Initialization Vector CCM – Counter with Cipher Block Chaining-MAC MAC – Message Authentication Code RSN – Robust Security Network Russ Housley (Vigil Security), et. al.