re-sending from the mail account that's subscribed to the EMU list,
sorry for the confusion
Begin forwarded message:
From: David A. McGrew <[EMAIL PROTECTED]>
Date: August 24, 2006 10:09:07 AM PDT
To: Hannes Tschofenig <[EMAIL PROTECTED]>
Cc: Charles Clancy <[EMAIL PROTECTED]>, [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
