Hi Joe,
Joseph Salowey (jsalowey) schrieb:
-----Original Message-----
From: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
Sent: Monday, August 28, 2006 11:37 AM
To: Joseph Salowey (jsalowey)
Cc: Charles Clancy; Lakshminath Dondeti; [email protected]
Subject: Re: [Emu] EAP-GPSK: Ciphersuites
Hi Joe,
I don't think that we on-the-fly want to use new algorithms
as they come available.
[Joe] Not sure what you mean by on the fly, but I think it would be bad
to have to rewrite large portions of EAP-GPSK to make use of a new
algorithm.
That wouldn't have to be done.
But you need to specify a new document that describes the ciphersuites.
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.
[Joe] However, new algorithms are implemented and requirements for
algorithm agility exist.
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.
[Joe] True, but an analysis of the cost and benefits should be done. It
is also not good to end up with a protocol that is obsolete when a new
algorithm is required.
Sure. I don't think we are doing this.
Ciao
Hannes
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
