Re: [Emu] EAP-GPSK: Ciphersuites

[Hannes Tschofenig <[e-mail]>]

Hi Joe,

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


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