| Re: methods and expert reviews | <– Date –> <– Thread –> |
|
From: Thomas Otto (t.otto |
|
| 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).
- Future of EAP-PSK, (continued)
-
Future of EAP-PSK Thomas Otto, June 30 2005
- Re: Future of EAP-PSK Charles Clancy, June 30 2005
- RE: methods and expert reviews Pasi.Eronen, June 13 2005
- RE: methods and expert reviews Walker, Jesse, June 15 2005
- Re: methods and expert reviews Thomas Otto, June 24 2005
-
Future of EAP-PSK Thomas Otto, June 30 2005
Results generated by Tiger Technologies using MHonArc.