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
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
