AW: [Emu] EAP-GPSK: Ciphersuites

"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> Tue, 22 August 2006 11:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFUMo-0002Vd-QL; Tue, 22 Aug 2006 07:24:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFUMn-0002VL-EQ for emu@ietf.org; Tue, 22 Aug 2006 07:24:21 -0400
Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFUK9-0003k5-4d for emu@ietf.org; Tue, 22 Aug 2006 07:21:40 -0400
Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k7MBLVx6026980; Tue, 22 Aug 2006 13:21:31 +0200
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k7MBLV9v007161; Tue, 22 Aug 2006 13:21:31 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 13:21:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Emu] EAP-GPSK: Ciphersuites
Date: Tue, 22 Aug 2006 13:21:30 +0200
Message-ID: <A5D2BD54850CCA4AA3B93227205D8A30898C5D@MCHP7IEA.ww002.siemens.net>
In-Reply-To: <7.0.1.0.2.20060822174100.042f0df8@qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Emu] EAP-GPSK: Ciphersuites
Thread-Index: AcbF0DIyame7nrMuSNe9sPJCCer4fAAAXCaw
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: Lakshminath Dondeti <ldondeti@qualcomm.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 22 Aug 2006 11:21:30.0912 (UTC) FILETIME=[1E0B0200:01C6C5DD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc: emu@ietf.org
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Errors-To: emu-bounces@ietf.org

Hi Lakshminath, 

I am not sure that the group wants to use CCM. 
(If you are referring to this part of your mail.)

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] 
> Gesendet: Dienstag, 22. August 2006 11:44
> An: Hannes Tschofenig
> Cc: emu@ietf.org
> Betreff: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> 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-se
cret-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
> >>>Emu@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu