Subject: RE: [Emu] EAP-GPSK: Ciphersuites

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 28 Aug 2006 11:50:27 -0700

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Monday, August 28, 2006 11:37 AM
> To: Joseph Salowey (jsalowey)
> Cc: Charles Clancy; Lakshminath Dondeti; [email-masked]
> 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:[email-masked]]
> >> Sent: Tuesday, August 22, 2006 4:05 AM
> >> To: Lakshminath Dondeti
> >> Cc: [email-masked]
> >> 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-masked]  |  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-masked]
> >>>>>> https://www1.ietf.org/mailman/listinfo/emu
> >>>
> >>> _______________________________________________
> >>> Emu mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/emu
> >> _______________________________________________
> >> Emu mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/emu
> >>
> > 
> > _______________________________________________
> > Emu mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/emu
> > 
> > 
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Aug 2006 21:05:20 +0200

Hi Joe,

> to have to rewrite large portions of EAP-GPSK to make use of a new

That wouldn't have to be done.
But you need to specify a new document that describes the ciphersuites.

> is also not good to end up with a protocol that is obsolete when a new

Sure. I don't think we are doing this.

Ciao
Hannes