Subject: [Emu] EAP-GPSK: Ciphersuites

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Aug 2006 16:55:59 +0200

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 20 Aug 2006 15:23:02 +0800

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:
>Later, it got the impression that AES-CBC was more appreciated. 
>Should we update the draft with AES-CBC?
>
>Ciao
>Hannes
>
>

---

From: "M. Vanderveen" <[email-masked]>
Date: Mon, 21 Aug 2006 09:06:16 -0700 (PDT)

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,

Ciao
Hannes

 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail Beta.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Aug 2006 11:12:32 +0200

Hi Lakshminath,

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Aug 2006 11:20:01 +0200

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,
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Get on board. You're invited 
> <http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.yahoo.com/handraisers> 
> to try the new Yahoo! Mail Beta.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 22 Aug 2006 17:44:21 +0800

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:
>I don't agree with you. There is no reason to optimize a few bits in 
>a pre-shared secret method.
>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
>
>>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.

---

From: Charles Clancy <[email-masked]>
Date: Tue, 22 Aug 2006 07:04:36 -0400

Interesting idea, but what does it gain you?  Why not just use an 
AES-CBC and CMAC ciphersuite?

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

Lakshminath Dondeti wrote:
> 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
>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 22 Aug 2006 13:21:30 +0200

Hi Lakshminath, 

I am not sure that the group wants to use CCM. 
(If you are referring to this part of your mail.)

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Lakshminath Dondeti [mailto:[email-masked]] 
> Gesendet: Dienstag, 22. August 2006 11:44
> An: Hannes Tschofenig
> Cc: [email-masked]
> Betreff: Re: [Emu] EAP-GPSK: Ciphersuites
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 22 Aug 2006 09:29:40 -0700

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

Actually, it sounds reasonable to me.

---

From: "Ray Bell" <[email-masked]>
Date: Tue, 22 Aug 2006 14:43:37 -0700

(Encryption)
ENCR_3DES

Comment: In October 1999, FIPS 64-3 the former specification for 3DES was
withdrawn, so it would be better to cite "National Institute of Standards
and Technology, Recommendation for the Triple Data Encryption Algorithm
(TDEA) Block Cipher, Special Publication 800-67, May 2004" than RFC2451

(Integrity)
AUTH_HMAC_SHA1_96
  and
(Key Derivation)
PRF_HMAC_SHA1

Comment:  With respect to requiring SHA1, consideration should be given to
the following NIST guidelines that were issued on March 15, 2006:

"The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and
SHA-512) may be used by Federal agencies for all applications using secure
hash algorithms. Federal agencies should stop using SHA-1 for digital
signatures, digital time stamping and other applications that require
collision resistance as soon as practical, and must use the SHA-2 family of
hash functions for these applications after 2010."

Ray Bell
Grid Net, Inc.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Aug 2006 10:03:42 +0200

Hi Ray,

thanks for your thoughts on this subject.

> (TDEA) Block Cipher, Special Publication 800-67, May 2004" than RFC2451

Maybe someone should also update RFC 4307 to add a MUST for encryption 
pointing to the changed reference or to add something else there.

For EAP-GPSK: A good hint.

> hash functions for these applications after 2010."

That's inline with the two sets of cipher suites where one aims for a 
usage in the future (denoted as SHOULD+) and the other one for a more 
near-time usage (MUST).

RFC 4307 says that AES128_CBC is a SHOULD+ as a pseudo random function.

Ciao
Hannes

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 23 Aug 2006 17:13:02 -0700

At IETF 66, we discussed a number of issues, including:

o Optional privacy support
o Ciphersuite support
o Changes from RFC 2716

I've updated RFC 2716bis to include a new section 2.7 on privacy, have 
clarified the ciphersuite requirements, and have included an Appendix A on 
changes from RFC 2716.  I have also updated the examples to include one on 
privacy and fix some mistakes.  I also found a problem in Section 2.2 where 
the EAP server is being said to handle retransmissions rather than the EAP 
authenticator.

The strawman -03 document is available here:

http://www.drizzle.com/~aboba/EAP/draft-simon-emu-rfc2716bis-03.txt