> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David A. McGrew > Sent: Friday, August 18, 2006 11:48 AM > To: [EMAIL PROTECTED]; Hannes Tschofenig; Charles Clancy > Subject: [Emudt] new authenticated encryption draft and a > proposed use inEMU GPSK > > Hi Hannes, Charles, and others, > > I've recently submitted an ID that defines a set of > application- independent authenticated encryption algorithms, > and I'd like to propose that it be used in > draft-clancy-emu-eap-shared-secret-01 and/ or in other work > in this area. It is online at http:// > www.mindspring.com/~dmcgrew/draft-mcgrew-auth-enc-00.html, > and the "Introduction" section explains its benefits. It is > a very natural fit to the EMU work. > > Here is how to use this new spec for the EMU shared secret method. > Below I've adapted the EAP-GPSK protocol notation from > Section 3 of draft-clancy-emu-eap-shared-secret, and defined > how the fields of the messages relate to the inputs and > outputs of an authenticated encryption algorithm (defined at > http://www.mindspring.com/~dmcgrew/ > draft-mcgrew-auth-enc-00.html#anchor3): > > Authenticated encryption inputs: > K = secret key > AAD = additional authenticated (but not encrypted) data > P = plaintext > > Authenticated encryption outputs: > C = ciphertext > IV = initialization vector > T = authentication tag > > GPSK using the authenticated encryption interface: > > GPSK-1 := ID_Server, RAND_Server, CSuite_List > > GPSK-2 := ID_Client, ID_Server, RAND_Client, RAND_Server, > CSuite_List, CSuite_Sel [, Ciphertext1, ... ], ICV1 > > AAD := HDR2, ID_Client, ID_Server, RAND_Client, > RAND_Server, CSuite_List, CSuite_Sel > P := PD_Payload_1 > Ciphertext1 := IV || C > ICV1 := T > > GPSK-3 := RAND_Client, RAND_Server, CSuite_Sel [, Ciphertext2 ], > ICV2 > > AAD := HDR3, RAND_Client, RAND_Server, CSuite_Sel > P := PD_Payload_2 > Ciphertext2 := IV || C > ICV2 := T > > GPSK-4 := [ Ciphertext_3, ] ICV > > AAD := HDR4 > P := PD_Payload_3 > Ciphertext3 := IV || C > ICV3 := T > > > To leverage the authenticated encryption spec, large parts of > Sections 5 and 6 in the GPSK draft would be replaced by > references to the former document. This would have the > effect of replacing the > currently defined ciphersuites with slightly different ones. > However, there are problems with the current definitions, so > changes are needed in this area anyway. (Ciphersuite #1 is > defined to use > AES-EAX-128 for encryption and AES-CMAC-128 for integrity, and > includes a key derivation function to derive keys for each mode. > This is a serious misuse of EAX, or a faulty explanation of > the intended use of EAX, because that mode of operation can provide > *both* encryption and integrity, without the need for > AES-CMAC or a key derivation function.) If no confidentiality > is needed, this is indicated by providing a zero-length > plaintext to the authenticated encryption algorithm, so there > is no need for a separate authentication-only ciphersuite. > > The authenticated encryption draft uses AES CCM instead of AES EAX, > because CCM is widely supported and is approved for use in > FIPS-140. > Of course, the really important thing about the authenticated > encryption draft is the interface that it defines, and if > there is a need for a different authenticated encryption > algorithm, it would be easy to add. FWIW I do think that the > AE algorithms that are currently defined meet the EMU requirements. > > Comments welcome. I'll be traveling over the next week, so > my response time might lag a bit. > > Best regards, > > David > _______________________________________________ > Emu mailing list > [EMAIL PROTECTED] > https://www.machshav.com/mailman/listinfo.cgi/emu >
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
