RE: [Emu] EAP-GPSK: Ciphersuites

"Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com> Mon, 28 August 2006 18:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmBv-0004IG-6P; Mon, 28 Aug 2006 14:50:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmBu-0004IB-I8 for emu@ietf.org; Mon, 28 Aug 2006 14:50:34 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmBs-0007UO-U0 for emu@ietf.org; Mon, 28 Aug 2006 14:50:34 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Aug 2006 11:50:32 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SIoWah002797; Mon, 28 Aug 2006 11:50:32 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7SIoS1O006536; Mon, 28 Aug 2006 11:50:32 -0700 (PDT)
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 11:50:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Emu] EAP-GPSK: Ciphersuites
Date: Mon, 28 Aug 2006 11:50:27 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50258049C@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Emu] EAP-GPSK: Ciphersuites
Thread-Index: AcbK0PS61Y4GjeRGRVGBBiynpJ/nrQAAPJVQ
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 28 Aug 2006 18:50:29.0673 (UTC) FILETIME=[D5463990:01C6CAD2]
DKIM-Signature: a=rsa-sha1; q=dns; l=6075; t=1156791032; x=1157655032; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20<jsalowey@cisco.com> |Subject:RE=3A=20[Emu]=20EAP-GPSK=3A=20Ciphersuites; X=v=3Dcisco.com=3B=20h=3D2dulrjaYeLr0EwCAImBrFO70zqA=3D; b=nKZf3/u51ktMrIPv54qe5Jy1RjIxZmDlKKJ71CFApBHDQCQ2zUdUwMESZDyxqOU+iB3sGpAV ldoLH3YlTxeYo4O6fQ7zEdcN+pyuV5oa+3YZojgkYXTyC7WSeXNtV6vI;
Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
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

 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Monday, August 28, 2006 11:37 AM
> To: Joseph Salowey (jsalowey)
> Cc: Charles Clancy; Lakshminath Dondeti; emu@ietf.org
> 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. 

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. 


> 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:clancy@cs.umd.edu]
> >> Sent: Tuesday, August 22, 2006 4:05 AM
> >> To: Lakshminath Dondeti
> >> Cc: emu@ietf.org
> >> 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.  |  tcc@umd.edu  |  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
> >>>>>> 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
> >>
> > 
> > _______________________________________________
> > 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