Re: [Emu] EAP-GPSK: Ciphersuites

Hi Hannes,

On Aug 28, 2006, at 11:43 AM, Hannes Tschofenig wrote:

> Hi David,
>
> thanks for your feedback.
>
> If I read through it I get the impression that the IKEv2 selected  
> algorithms (as defined in RFC 4307) would not be allowed to go  
> forward. I wonder whether we put the bar a bit high here.
>
> One might even get the impression that nobody read RFC 4307 before  
> it was published.
>

I think that it comes down to unfortunate timing.  XCBC was proposed  
to NIST but not adopted by them when it got picked up by IKEv2;  
afterwards, XCBC got improved into OMAC.   I believe that IKEv2 re- 
used HMAC as a KDF out of a desire for compatibility with IKEv1.    
NIST SP 800-56 Sec. 5.3 mandates a hash-based KDF; NIST has made an  
exception for IKE and TLS, allowing their use in FIPS-140 certified  
crypto modules, but AFAICT this exception is specific to those  
protocols, and would not apply to GPSK.  (I would be happy to be  
wrong on this point.  If it is important, then let's ask the NIST  
crypto folks.)

David

> Ciao
> Hannes
>
> David McGrew schrieb:
>> Hi Hannes,
>> a few comments inline:
>>> -----Original Message-----
>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>> Sent: Tuesday, August 22, 2006 2:20 AM
>>> To: M. Vanderveen
>>> Cc: emu@ietf.org
>>> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
>>>
>>> Hi
>>>
>>> let us for a moment assume that RFC 4307 makes some
>>> reasonable algorithm choices (we are talking about IKEv2
>>> here). If we take the text and apply it to EAP-GPSK then we
>>> would produce something like:
>>>
>>> Conservative Choice:
>>> -----------------------
>>>
>>> (Integrity)
>>>        AUTH_HMAC_SHA1_96        2            [RFC2404]             
>>> MUST
>>>
>>> (Encryption)
>>>        ENCR_3DES                3         [RFC2451]       MUST-
>> I agree with Joe that AES is preferable to 3DES, barring some  
>> strong legacy considerations.
>>>
>>> (Key Derivation)
>>>        PRF_HMAC_SHA1       2          [RFC2104]    MUST
>> If it is a goal to conform to FIPS-140-2, that goal will probably  
>> drive the key derivation function choice in the direction of  
>> http://www.ietf.org/internet-drafts/draft-dang-nistkdf-01.txt.     
>> (I like HMAC as a KDF, but I am not confident that it is going to  
>> be approved for that purpose within FIPS-140-2.)
>>>
>>> (Note that there is no MUST for encryption algorithms specified  
>>> in RFC
>>> 4307.)
>>>
>>>
>>> Choice for the Future:
>>> -----------------------
>>>
>>> (Encryption)
>>>       ENCR_AES_CBC             12        [AES-CBC]       SHOULD+
>>>
>>> (Integrity)
>>>       AUTH_AES_XCBC_96         5         [AES-MAC]       SHOULD+
>> OMAC is a better choice than XCBC, since it is FIPS-140 approved,  
>> and has some minor advantages (it's a refinement of XCBC that is  
>> unfortunately not backwards compatible with it).
>>>
>>> (Key Derivation)
>>>        PRF_AES128_CBC      4          [AESPRF]     SHOULD+
>>>
>> Same KDF considerations as above.
>> David
>>> Does this sound like a terrible bad idea?
>>>
>>> Ciao
>>> Hannes
>>>
>>> M. Vanderveen schrieb:
>>>> Both are pretty popular. Why not list them both? As for
>>> which one to be
>>>> mandatory to implement, someone should to a search through
>>> other systems
>>>> (e.g. IEEE, IPSec) and see which one is most popular.
>>>>
>>>> */Hannes Tschofenig <Hannes.Tschofenig@gmx.net>/* 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
>>>>
>>>>
>>>>
>>> --------------------------------------------------------------
>>> ----------
>>>> Do you Yahoo!?
>>>> Get on board. You're invited
>>>>
>>> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.y
>>> ahoo.com/handraisers>
>>>> to try the new Yahoo! Mail Beta.
>>>
>>>
>>> _______________________________________________
>>> 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