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

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

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.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
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 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: David McGrew <[email-masked]>
Date: Mon, 28 Aug 2006 11:14:56 -0700

Hi Hannes,

> would produce something like:

I agree with Joe that AES is preferable to 3DES, barring some strong  
legacy considerations.

>        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

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).

>        PRF_AES128_CBC      4          [AESPRF]     SHOULD+

Same KDF considerations as above.

David

---

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

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.

Ciao
Hannes

David McGrew schrieb:
> 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.)
> 
>>

---

From: David McGrew <[email-masked]>
Date: Mon, 28 Aug 2006 12:07:41 -0700

Hi Hannes,

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

> 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

>> I agree with Joe that AES is preferable to 3DES, barring some  
>> strong legacy considerations.
>>>
>>> (Key Derivation)
>> 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.)
>>>
>> 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

---

From: David McGrew <[email-masked]>
Date: Mon, 28 Aug 2006 12:23:16 -0700

Hi again Hannes,

On Aug 28, 2006, at 12:07 PM, David McGrew wrote:

> 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.

OK, I think I get my wish :-)  The most recent version of SP800-56  
says in Sec. 5.8.3 that "the IKEv2 KDF of Section 5.8.3 and the PRF  
TLS KDF of Section 5.8.4 are allowed; the use of one of these allowed  
KDFs is to be used only when both parties agree on its use."  Sounds  
to me like the HMAC-based IKEv2 key derivation could be used in  
applications like GPSK and get a FIPS-140 certification, which is  
great news.

David

---

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

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