Re: methods and expert reviews
From: Thomas Otto (t.ottosharevolution.de)
Date: Fri, 24 Jun 2005 11:15:37 -0400 (EDT)
Comments on the review of EAP-PSK - third (=last) part


> Point (c). Neither Figure 3 nor the accompanying text spells out
> explicitly how message 4 is protected. Message 4 could be protected by
> either the AK (and an OMAC1) or by the TEK (used with EAX). 

The format of message 4 is  Flags||RAND_S||PCHANNEL_P_1 , 

with a 1-byte Flags field, 16 byte server random of message 1, and the 
PCHANNEL field. 

I assume that RAND_S is sent in plaintext. Since it is sent plain in 
message 4, and since it serves in this context only as a session identifier, 
an encryption makes IMHO no sense.



In section 3.3 of EAP-PSK, the format of PCHANNEL is explained. PCHANNEL 
contains three or four flags, in case of the mode (no extension, extension). 

* 2-bit R (result indication flag), 
* 1-bit E (extension flag)
* 5-bit Reserved
* variable length EXT (extension)

which are sent encrypted by the protected channel. A reference is given to
section 2.2.3, The Protected Channel. 

Thus, the format of message 4 is more detailed

Flags || RAND_S || Nonce || Tag || R || 0 || Reserved
                                  xxxxxxxxxxxxxxxxxxx

and, for the extended mode, 

Flags || RAND_S || Nonce || Tag || R || 1 || Reserved || EXT
                                  xxxxxxxxxxxxxxxxxxxxxxxxxx

where the "x" highlight the part to be encrypted.


Now, EAX mode keyed with the TEK encrypts the payload like
follows:


4 bytes  22 bytes  var.length L        16 bytes

                     R 0 Reserved *or* 
Nonce N  Header H    R 1 Reserved EXT   TEK
  |         |             |              |
  v         v             v              v 
+-------------------------------------------+
+              EAX                          +
+-------------------------------------------+
  |             |
  v             v 
ciphertext     Tag
payload     16 bytes
xxxxxxxxxx
   
              
In the
> latter case, we need to know which bits are encrypted and which merely
> forgery protected. 

R, 0, Reserved (,EXT)

So, we talk about 8 bits in standard mode and 8+|EXT| bits 
in the extended mode of operation. 

[snip]

> Here are a number of miscellaneous comments:
>
> It would be worth considering replacing OMAC1 by CMAC. NIST SP800-38B
> [2] defines CMAC as the "approved" CBC-MAC variant.
>

This leads to an analysis whether EAX must be replaced as a consequence.
The authors' argument to take EAX was that it strongly relies on OMAC 
(see, for instance, figure 2 and 3 in 
http://www.cs.ucdavis.edu/~rogaway/papers/eax.html). 



Results generated by Tiger Technologies using MHonArc.