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

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

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

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Sunday, August 20, 2006 12:23 AM
> To: Hannes Tschofenig; [email-masked]
> Subject: Re: [Emu] EAP-GPSK: Ciphersuites
> 
> 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,
> >
> >the current version of the document
> >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           |
> >    
> > 
> +-----------+----+-------------+---------------+--------------------+
> >
> >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
> 
> 
> _______________________________________________
> 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: Charles Clancy <[email-masked]>
Date: Mon, 28 Aug 2006 23:26:51 -0400

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.

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 28 Aug 2006 20:53:21 -0700

Hi Joe,

Since we are talking about a Authentication and Key establishment 
protocol, any optimizations that come with combined modes are not 
really crucial.  On the other hand, it is not too difficult to use 
them without multiple integrity checksums.  If there is interest, 
sure I can help specify that.

We started with EAX and I was curious about why and did some 
investigation.  Others did too and suggested CCM perhaps to reuse the 
802.11i choice of algorithm.  When the discussion about two integrity 
checksums started, we were quick to move off of combined modes.

I submit that we don't need to rule them out.  Let's specify how to 
use them properly.  We don't need to belabor the topic so much 
really.  As I noted, I am willing to put the time to write the text.

thanks,
Lakshminath

---

From: David McGrew <[email-masked]>
Date: Tue, 29 Aug 2006 10:22:12 -0700

Hi Joe,

> modifications are needed?

the simplest way to add an AEAD mode would be to replace Sections  
6.1.1 and 6.1.2 with something like the following adaptation:

<new>
6.1.1.  Encryption and Integrity

    With this ciphersuite all cryptography is built around a single
    cryptographic primitive, AES-128.  Within the protected data frames,
    AES-128 is used in EAX mode of operation.  Ciphersuite 1 makes  
use of
    the EAX mode of encryption.  EAX is an Authenticated-Encryption- 
With-
    Associated-Data (AEAD) scheme.  It has as input a plaintext M, a
    header H and a nonce N and is keyed with a key K. The idea is that
    both M and H are integrity protected, but only M is encrypted.
    Therefore, EAX encryption returns the ciphertext, which consists  
of H
    and encrypted M, and a cryptographic checksum Tag T.

    We use EAX with a 128-bit nonce that is generated uniformly at
    random for each invocation of the encryption function.  The nonce
    is returned by the Encrypt operation, along with the ciphertext and
    tag, in that order.  During the decryption operation, these fields
    are parsed; since N and T have fixed widths, this procedure is
    simple.  The decryption uses N and T in its processing, then
    returns the plaintext.  Symbolically,

    N || C || T = EAX.Encrypt (K; N, H, M)

              M = EAX.Decrypt (K; N, H, C, T).

    The use of EAX in GPSK is defined by the mapping of the protocol
    messages to its inputs, as follows.

      Message GPSK-2:
        o M is the Value of PD_Payload_1
        o H is the Value of SEC_SK

      Message GPSK-3:
        o M is the Value of PD_Payload_2
        o H is the Value of SEC_SK

      Message GPSK-4:
        o M is the Value of PD_Payload_3
        o H is the Value of SEC_SK

</new>

Here I've tried to minimize changes from the existing document.

David