doc.: IEEE /770r0 Submission July 2009 Slide 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.
doc.: IEEE /770r0 Submission July 2009 Slide 3 Current situation P802.11s D3.0, Mar 2009, Section 11.B 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 s 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 universe Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission July 2009 Slide 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 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 universe, as such it should re-use established methods wherever possible Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission Primary reason for (re)consideration July 2009 Slide 5 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 s is a part of the larger 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.
doc.: IEEE /770r0 Submission 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 i 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 July 2009 Slide 6 Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission 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 s 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 can the SIV block of code (or piece of hardware) be applied to amortize the expense of building? July 2009 Slide 7 Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission 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 sub-element July 2009 Slide 8 Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission Conclusion A proven, approved, already designed, built and widely employed solution exists to solve the secure GTK transport problem in s 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 s should be carefully considered To determine if the advantage gained justifies the expense of implementation To determine if a single application within s is the place to introduce new security mode July 2009 Slide 9 Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission Summary The purpose of s is to develop acceptable standards for wireless mesh networking within the framework s is not the place to introduce new security algorithms if accepted and adequate security algorithms already exist in –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 July 2009 Slide 10 Russ Housley (Vigil Security), et. al.
doc.: IEEE /770r0 Submission Recommendation Recommend that P802.11s D3.0, Mar 2009, Section 11.B 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 July 2009 Slide 11 Russ Housley (Vigil Security), et. al.