IKEv2 has been designed for a different environment which already had 3DES deployed, I'm not sure that this is the case with EAP-GPSK.
> -----Original Message----- > From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] > Sent: Monday, August 28, 2006 11:32 AM > To: Joseph Salowey (jsalowey) > Cc: M. Vanderveen; [email protected] > Subject: Re: [Emu] EAP-GPSK: Ciphersuites > > Hi Joe, > > we might want to ask ourself why IKEv2 guys have chosen the > indicated list of algorithms and why we decide to use different onces. > > If we think that their list represents a problem we might > want to convince them to submit an updated version of RFC 4307. > > Ciao > Hannes > > Joseph Salowey (jsalowey) schrieb: > > Is the proposal to make 3DES mandatory and AES optional? > > It seems that we should be moving toward AES. Since this is a new > > method it may be better to make AES mandatory and 3DES optional. > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, August 22, 2006 2:20 AM > >> To: M. Vanderveen > >> Cc: [email protected] > >> 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- > >> > >> (Key Derivation) > >> PRF_HMAC_SHA1 2 [RFC2104] MUST > >> > >> (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+ > >> > >> (Key Derivation) > >> PRF_AES128_CBC 4 [AESPRF] SHOULD+ > >> > >> 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 <[EMAIL PROTECTED]>/* wrote: > >>> > >>> Hi all, > >>> > >>> the current version of the document > >>> > >> > http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.tx > >> t > >>> 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 protected] > >>> 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 > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/emu > >> > > > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
