Hi Joe,
I don't think that we on-the-fly want to use new algorithms as they come
available. Based on Bernhard's experience with EAP-TLS I got the
impression that most EAP implementers and users are not really excited
about updating their implementation whenever a new algorithm becomes
available.
Furthermore, if new algorithms become available we need to specify a
ciphersuite that makes sense for the given environment.
The most difficult part with protocol design is to sometimes say NO when
features and optimizations are proposed.
Ciao
Hannes
Joseph Salowey (jsalowey) schrieb:
We want to define GPSK as a framework that can accommodate new
algorithms when they are available. I believe that Lakshminath is
looking to allow optimizations within this framework in the case where a
combined mode cipher is used. At this point I'm not sure how much
complexity this would add to the specification. If it can be done
simply then it might be worthwhile pursuing, perhaps David McGrew's
AEAD specification would help here.
-----Original Message-----
From: Charles Clancy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 4:05 AM
To: Lakshminath Dondeti
Cc: [email protected]
Subject: Re: [Emu] EAP-GPSK: Ciphersuites
Interesting idea, but what does it gain you? Why not just
use an AES-CBC and CMAC ciphersuite?
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Lakshminath Dondeti wrote:
I guess we agree to disagree. The addition integrity checksum is
spurious in my view and I believe we can define things so that
combined modes can be employed without encrypting anything, so I am
somewhat confused here. What's your opinion on the latter
part of my email?
thanks,
Lakshminath
At 05:12 PM 8/22/2006, Hannes Tschofenig wrote:
Hi Lakshminath,
Lakshminath Dondeti schrieb:
At the expense of generating some confusion, here is my
take on this:
The objection is to having to carry multiple integrity
checksums in
GPSK, if we used the combined mode *and* an integrity algorithm.
I don't agree with you. There is no reason to optimize a
few bits in
a pre-shared secret method.
Note that we are not talking about a protocol for data transfer.
We wanted the flexibility to use different cipher suites.
We do not
only want to use cipher suites that provide authenticated
encryption
(since we almost have nothing to encrypt; currently 1 bit
and almost
no EAP method provides this functionality).
Ciao
Hannes
I think CCM is fine for instance, the only catch is that
we need to
make sure and define AAD for CCM carefully to include appropriate
data into the integrity checksum calculation. So, once we define
CCM as the mode, we shouldn't need AES-CMAC-128 if
encryption is being used.
I would suggest using CCM and specifying the use of it
fully so it
can be used without misunderstandings. If you want me to
put some
time into writing that up, let me know.
cheers,
Lakshminath
At 10:55 PM 8/20/2006, Hannes Tschofenig wrote:
Hi all,
the current version of the document
http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.
txt
still supports AES-EAX:
+-----------+----+-------------+---------------+--------------------+
| CSuite/ | KS | Encryption | Integrity | Key
Derivation |
| Specifier | | | |
Function |
+-----------+----+-------------+---------------+--------------------+
| 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 |
GKDF-128 |
+-----------+----+-------------+---------------+--------------------+
At the IETF#66 EMU meeting AES CCM was suggested.
Later, it got the impression that AES-CBC was more appreciated.
Should we update the draft with AES-CBC?
Ciao
Hannes
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
