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

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

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-masked]] 
> Sent: Monday, August 28, 2006 11:32 AM
> To: Joseph Salowey (jsalowey)
> Cc: M. Vanderveen; [email-masked]
> 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-masked]]
> >> Sent: Tuesday, August 22, 2006 2:20 AM
> >> To: M. Vanderveen
> >> Cc: [email-masked]
> >> 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-masked]>/* 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-masked]
> >>>     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-masked]
> >> https://www1.ietf.org/mailman/listinfo/emu
> >>
> > 
> > 
> 

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

---

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

> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Monday, August 28, 2006 8:27 PM
> To: [email-masked]
> Lots of interesting conversation...
> 
> Being ciphersuite-modular doesn't mean we have to give up all 
> control or write a protocol that would work in every possible 
> case.  I don't see any reason to add optimizations to support 
> CCM/EAX-like primitives when there's no reason to use them in 
> the first place.  Both supporting them and using them adds 
> unnecessary complexity.
> 
> IMHO, the ciphersuites should be AES-CBC with a suitable MAC 
> (I'm flexible here) and HMAC-256, with HMAC-256 mandatory to 
> implement because it would most easily achieve FIPS140-2 
> certification.
> 
> Is there general consensus on this part?  There seems to be 
> more contention on which MAC should be used with an AES-based 
> ciphersuite.

[Joe] I personally would prefer to have a mandatory to implement
encrypting ciphersuite.  I'm also flexible when it comes to which AES
MAC is used, either XCBC or OMAC is fine.

> 
> --
> t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy
> 
> Joseph Salowey (jsalowey) wrote:
> > Hi Lakshminath,
> > 
> > I have not seen a lot of support for use of CCM/EAX with or without 
> > the optimization of eliminating additional MAC algorithm on 
> the list.  
> > I think it would be useful to understand what the impact is on the 
> > current specification to support ciphers that provide both 
> integrity 
> > protection and encryption without requiring additional MAC 
> algorithms.  
> > Would the current spec need to be modified to support this?  If so, 
> > what modifications are needed?
> > 
> > Thanks,
> > Joe
> > 
> > 
> >>From: Lakshminath Dondeti [mailto:[email-masked]]
> >>Sent: Sunday, August 20, 2006 12:23 AM
> >>To: Hannes Tschofenig; [email-masked]
> >>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 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,
> >>>
> >>>http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secr
> >>
> >>et-01.txt
> >>
> >>>still supports AES-EAX:
> >>>
> >>>   
> >>
> >>>   | CSuite/   | KS | Encryption  | Integrity     | Key 
> >>
> >>Derivation     |
> >>
> >>>   | Specifier |    |             |               | 
> >>
> >>Function           |
> >>
> >>>   
> >>
> >>>   | 0x000001  | 16 | AES-EAX-128 | AES-CMAC-128  |
> >>
> >>GKDF-128           |
> >>
> >>>   
> >>>
> >>
> >>>Later, it got the impression that AES-CBC was more appreciated. 
> >>>Should we update the draft with AES-CBC?
> >>>
> >>>Ciao
> >>>Hannes
> >>>
> >>>