[Emu] Fwd: new authenticated encryption draft and a proposed use in EMU GPSK

[David McGrew <[e-mail]>]

re-sending from the mail account that's subscribed to the EMU list,  
sorry for the confusion

Begin forwarded message:

> From: David A. McGrew <[e-mail]>
> Date: August 24, 2006 10:09:07 AM PDT
> To: Hannes Tschofenig <[e-mail]>
> Cc: Charles Clancy <[e-mail]>, [e-mail]
> Subject: Re: new authenticated encryption draft and a proposed use  
> in EMU GPSK
>
> Hi Hannes,
>
> On Aug 24, 2006, at 1:23 AM, Hannes Tschofenig wrote:
>
>> Hi David,
>>
>> I have a problem with the suggested approach for a couple of reasons:
>>
>> * There is no problem with the currently defined cipher suites. The
>> design team has just picked something; Different cipher suites got  
>> proposed during
>> the design team discussions and almost all of them got removed  
>> from the
>> document. As you saw from the discussions and my previous mail to the
>> EMU mailing list it seems that there is a shift towards AES CBC.  
>> That's
>> fine with me.
>
> That's a tangent; the choice of cipher suite is not the issue here.
>
>>
>> Whatever you propose there will be someone that does not like your
>> selection for whatever reason.
>>
>> This is, btw, a very natural way to progressing document. You will  
>> not
>> get things right the first time.
>>
>> * I don't like the split into two documents since it makes a simple
>> protocol complicated. For EAP-GPSK I don't think that we will see 10+
>> cipher suites being proposed.
>>
>
> True enough, but EAP-GPSK will need to reference one or more  
> external algorithms anyway, CCM or EAX or both AES-CBC and a MAC  
> like HMAC-SHA1, if the preference towards CBC continues.
>
> It's worth noting that, if CBC encryption is included in GPSK,  
> there will be a need to design and review a 'generic composition'  
> algorithm of that mode with a MAC, and there will be the issue of  
> defining the interface(s) between the protocol and that algorithm  
> and the AEAD method(s) of CCM and/or EAX.  The latter two  
> algorithms *already* use an interface that is nearly identical to  
> the one defined in the AEAD draft.  Why not do all this work once  
> in a reusable way?
>
>> * I don't see how the document is useful to other areas.
>
> Why do you think the AEAD draft is not generally useful?  Do you  
> think that the interface that it defines is too restrictive?   Or  
> do you think that there is a scarcity of new applications for  
> symmetric encryption and authentication?
>
> AFAICT, new applications of crypto are defined all the time; for  
> example, there's now a motivation to put AES GCM into TLS.   
> Defining a uniform interface that these new applications can use  
> makes sense, and the AEAD model is a perfect fit.  If the AEAD  
> interface definition isn't perfect, let's fix it.
>
>> The example
>> section points to IPsec ESP; this is confusing for someone that only
>> wants to implement a simple EAP method.
>>
>
> Perhaps the specification didn't make clear enough that the  
> "Example Usage" section was informative and not normative.  Also,  
> IMO it would be good to add a subsection showing an example usage  
> in a TLV-based protocol.
>
>> Recall that we started with the goal to produce a simple EAP  
>> method as a
>> replacement for EAP-MD5.
>>
>> Your document is unfortunately years too late.
>>
>> * Currently, we have the idea of putting 1 BIT!!!!! into the  
>> protected
>> payload part of the message (and that's not yet even there in the
>> document). Note, that it does not require encryption for this 1 bit.
>> There is currently nothing in the document that requires encryption.
>
> The security goals of GPSK line up with those of AEAD since  
> encryption is an option.  For sure it adds complexity to the  
> protocol to have that option; that complexity is going to be there  
> regardless of how the encryption gets provided.
>
>>
>> We are wasting time on problems that do not exist.
>>
>> * This document will help to delay the work on EAP-GPSK for a year
>> making it impossible to get EAP-GPSK deployed anytime in the near  
>> future.
>
> That's a valid concern and I'm very sympathetic to it.
>
> One way to use some of the AEAD benefits while keeping the AEAD  
> specification off of the critical path of GPSK would be to have  
> GPSK be as compatible as possible with the AEAD draft, and have it  
> reference the AEAD draft as being informative.   This wouldn't be  
> much effort, and it wouldn't hold up the GPSK draft.  Heck, if CCM  
> or EAX is included in GPSK, then the work would need to be done  
> anyway.
>
>>
>> * IANA consideration: If your document is applicable to other
>> environments then we might see plenty of cipher suites being  
>> specified.
>> That's fine but does not really help us a lot to realize a simple EAP
>> methods. What methods should folks implement? Should we have a simple
>> document that says "These are the cipher suites applicable for EAP  
>> GPSK? "
>
> If GPSK were written in terms of the AEAD specification, I'd expect  
> that it would indicate which algorithm was mandatory to implement.   
> It could also include SHOULD or MUST NOT guidance on algorithms, if  
> that seemed appropriate.
>
>>
>> You are essentially asking us to rewrite the entire draft to make  
>> it fit to your document just because you had the idea for a common  
>> registry?
>
> Nonsense.  I'm trying to bring the benefits (outlined in Section 1  
> of the draft) of the AEAD idea from the theoretical crypto  
> community into the standards community.
>
> David
>
>>
>> Sorry for my lack of excitement.
>>
>> Ciao
>> Hannes
>>
>> David A. McGrew schrieb:
>>> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/emu