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

[Hannes Tschofenig <[e-mail]>]

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.

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.

* I don't see how the document is useful to other areas. The example
section points to IPsec ESP; this is confusing for someone that only
wants to implement a simple EAP method.

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.

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.

* 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
method. What cipher suites should folks implement? Should we then have 
an additional document that says "These are the cipher suites applicable 
for EAP GPSK? "

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?

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