doc.: IEEE /770r0 Submission July 2009 Slide 1 TGs Authenticated Encryption Function Date: Authors: Russ Housley (Vigil Security), et. al.

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.

doc.: IEEE /770r0 Submission July 2009 Slide 12 Comments? Russ Housley (Vigil Security), et. al.

doc.: IEEE /770r0 Submission July 2009 Slide 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.