eap Mailing List: RE: methods and expert reviews

[Walker, Jesse (jesse.walker]

Jari,

My security review of EAP-PSK is below.

=============================================================

EAP Type Code Allocation Review Template: EAP-PSK

As noted in RFC 3748, for EAP methods to obtain a Type Code, Expert
Review with Specification is required.  The following list of issues is
provided as a guideline to potential expert reviewers and method
authors.  

1. Does the method document its security properties in sufficient
manner, as required by Section 7.2 of RFC 3748?

1a. Mechanism. Is the mechanism explained?
>> YES

1b. Security claims. Are the claimed and not claimed properties listed?
>> YES

1c. Justifications for the claims? Is an explanation or reference
provided to each of the claims?
>> YES, the claims are justified. However, below I note several claims
that are false and whose justification therefore should be updated.

1d. Key strength. Is the key strength documented?
>> YES, but more discussion is required. See detailed comments below.

1e. Description of key hierarchy. Is the key hierarchy documented?
>> YES

[Optional, at least for now: does it conform to EAP keying framework?]:
>> YES

1f. Indication of vulnerabilities. Are the known vulnerabilities
documented?
>> NO. There are undocumented vulnerabilities.

[Note: it seems unreasonable to require the documentation of unknown
vulnerabilities :-) The "known" may of course be "known to reviewer" or
"known to author" or "known to the community", but that appears to be
best we can do.]

2. Compliance with EAP packet formats

2a. Does the method comply with the packet formats defined in Section 4
of RFC 3748?
>> YES

3. Compliance with EAP behaviour

3a. Does the method comply with Success/Failure usage as defined in
Sections 2, 2.2, and 4.2?
>> YES

3b. Does the method comply with sequence usage as defined in Section 2.1
of RFC 3748?
>> YES

3c. Does the method comply with request/response processing rules as
defined in Section 4.1 of RFC 3748?
>> YES

3d. Does the method comply with retransmission rules as defined in
Section 4.3 of RFC 3748?
>> Retransmission does not appear to be discussed adequately. The
document needs further work here.

3e. Does the method comply with the usage defined for Identity, as
defined in Section 5.1 of RFC 3748?
>> YES

3f. Does the method comply with the usage defined for Notification, as
defined in Section 5.2 of RFC 3748?
>> The document fails to describe its use of notification. This
oversight should be corrected.

3g. Does the method comply with the usage defined for Nak and
Expanded-Nak as defined in Section 5.3 of RFC 3748?
>> The document fails to describe its use of Nak and Expanded-Nak. This
should be corrected.

3h. Does the method comply with the MIC usage requirements from Sections
3.1, 7.5, and 7.8 of RFC 3748?
>> YES

4. Compliance with IANA requirements

4a. Does the method comply with EAP-based IANA requirements defined in
Section 6 of RFC 3748? That is, if it requests the allocation of new
numbers in the EAP namespace [not applicable if the numbers have already
been allocated], is the type of the document and process appropriate for
the desired action?
>> YES

4b. Does the method comply with other IANA requirements in the IETF
standards track RFCs? For instance, does the method attempt to allocate
TLS extensions (which would only be possible for standards track RFCs)?
>> YES; it complies with IANA requirements for standards track documents


Detailed comments

This is a wonderfully written document, a joy to read, bristling with
beautiful ideas, and addressing an urgent problem. The document has
issues, identified below, that should be addressed before it progresses.
Included in the review are some suggestions for how the issues might be
addressed, but the authors and the working group can certainly
constructively formulate other solutions instead.

The issues identified fall into the following categories:

1. AKA and KDK issues,
2. TEK, MSK, and EMSK issues,
3. Protocol issues,
4. Retries, Replays, and Failures
5. Security bounds, and
6. Odds and ends.

1. AKA and KDK issues

The text should point out more explicitly that AK and KDK are static
long-lived keys, i.e., not session oriented.

The key naming should be made explicit, as the key names used are a
fundamental aspect of this protocol. The usage in the text assumes the
EAP peer name for this key pair is <EAP-PSK, Server-NAI>, and it assumes
EAP server name for this key pair is <EAP-PSK, Peer-NAI>. Including
EAP-PSK as part of the key identifier is critical, as the protocol
design assumes AK and KDK are never used outside of EAP-PSK.

To help us understand the implications of this, it is useful to spell
out the details of any algorithm in pseudo-code. In this case, the
resulting text for this instance of "modified counter mode" used for the
derivation would look something like:

        IV := 00000000000000000000000000000000 
        T1 := AES-128-Encrypt(PSK, IV)
        T2 := T1 XOR 00000000000000000000000000000001
        AK := AES-128-Encrypt(PSK, T2)
        T2 := T1 XOR 00000000000000000000000000000002
        KDK := AES-128-Encrypt(PSK, T2)
        Securely delete T1 and T2
        if forward secrecy is required, delete PSK securely
        Identify <EAP-PSK, id> by the identifier <AK, KDK>, where id is
                the name of the other party

Here AES-128-Encrypt(.,.) means to encrypt its second argument using the
first argument the encryption key, and ":=" denotes assignment. The IV
and counter values are expressed in hex.

The identification step at the end is not a nice frill; it is central to
the protocol design and should be made explicit. The reason is the
configured id receives its meaning as the distinguisher of this key pair
<AK, KDK> by being placed in the context of EAP-PSK. This context and
name then distinguishes this key pair from all other keys in all other
contexts. The security claims made in the specification depend on this
being true.

Note also that the PSK is deleted whenever forward secrecy is required.
Deleting the PSK SHOULD be a SHOULD and the default action.

Since none of these derived keys depend on either the EAP peer or server
NAI, these identities must get bound to the keys in some other way.
However, there is no protocol defined to bind the identities to the
derived AK or the KDK, implying that a different and independent PSK
must be configured between each <peer, server> pair. This is a usability
issue. In particular, the derivation for AK and KDK does not lead to
different keys if the administrator spreads the same PSK across multiple
devices. The reality is that many administrative domains will configure
the same PSK on each and every device, while all the security claims of
the protocol assume that different keys are configured between each pair
of devices. Including the NAIs for the EAP peer and server in the
derivation of the AK and KDK would afford an increase in security in the
normal case by separating the <AK, KDK> pairs between different devices
in every case, and by explicitly binding the identities to these keys.
It would also indirectly bind the identities to the TEK, MSK, and EMSK.

There is a second problem with the <AK, KDK> derivation, in that it is
subject to prefix attacks. This is not a problem in the overall protocol
design, but you never know when implementations will have bugs that
might allow an attacker to somehow exploit this kind of weakness. The
derivation should take into account the number of bits derived, and
derive different keys if the same information is presented to the
algorithm using the same parameters otherwise.

So are there any plausible ways to include the NAIs and the derived key
lengths into the derivation without discarding the entire key derivation
procedure? Let us try to suggest some.

The most obvious thing to try is to somehow use AES to "hash" the
identities and then use this "hashed" value as the initialization vector
IV presented to modified counter mode, instead of the IV
00000000000000000000000000000000. We want to use AES for this in order
to preserve the lovely property that AES encrypt is the only
cryptographic primitive required by the design.

A procedure for constructing such an IV would start by concatenating the
identities and padding them with the derived key length in some
well-defined manner, e.g.,

        L := length(ID_S) + length(ID_P)
        M := ID_S || 0x00 || ID_P || 0^(128 - (L + 17) mod 128) || 0x100

Here "length(.)" gives the length of its argument "." in bits, "ID_S" is
the identity of the EAP server, "ID_P" the identity of the EAP peer,
"||" means concatenation, and a^b means to concatenate b copies of bit
a. This makes the concatenated string a multiple of 128 bits. The magic
number "0x100" is the number of bits derived (256), represented as a hex
value. The magic number 17 is the number of bits required to encode
0x100 and the "0x00" sitting between ID_S and ID_P. The 0x00 is inserted
between ID_S and ID_P to prevent sliding window attacks, but this
presupposes that 0x00 is not a valid character in an NAI. 

By encoding the number of derived bits into the string to be hashed, we
can defeat the prefix attack problem if we can find a collision
resistant hashing scheme. So such a scheme will be the next thing to
search for. Two plausible AES-based hashing schemes immediately come to
mind for producing IV from M.

The first is to try to use AES in CBC-MAC mode, but for that we need a
key; one idea for a key is the PSK:

        IV := AES-128-CBC-MAC(PSK, M)

This is not ideal, however, because PSK would be used in two different
ways --once for hashing and a second time for key derivation--and
multiple usages of a single key is almost always a bad idea. While reuse
in this case may appear benign on first glance, why should we bother
with an approach that will require a tricky analysis to confirm that it
is indeed safe? A variant would be to use some "well-known" key as the
CBC-MAC key, although this key would always be block cipher dependent:

        K := 00000000000000000000000000000000 (* AES dependent key! *)
        IV := AES-128-CBC-MAC(K, M)

In either case, the "hashing" scheme relies on the assumption that a
block cipher in CBC-MAC mode is a pseudo-random function, so the
resulting output should be collision resistant for each pair of
identities and length (at least if we construct M properly). If you
prefer, use OMAC1 mode instead of CBC-MAC. Relying on CBC-MAC for
hashing is an egregious but probably effective hack.

A second way to compute IV might be to Davies-Meyer hash M under
AES-128:

        Partition M = M1 M2 ... Mn into 128 bit blocks
        H := 00000000000000000000000000000000
        for i = 1 to n do
                H := AES-128-Encrypt(Mi, H) XOR H
        IV := H

This is a genuine hashing algorithm. The Davies-Meyer construction is
collision resistant when the block cipher behaves like a pseudo-random
permutation, so again including the length in the hashed IV solves the
prefix attack problem. This construction also relies only on public
information; there is no key required as with the CBC-MAC approach. The
major problem with this is Davies-Meyer requires n AES key schedule
initializations, one for each block Mi. However, since the derivation
for AK and KDK occurs "once," this overhead should be insignificant.

Other approaches to computing IV may also be worth considering. Which
one to 
choose will probably depend on the outcome of the discussion we have
below for the TEK/MSK/EMSK derivation. And if the CBC-MAC construction
is used, then we will need some methodology to select the well-known key
K.

In any event, to summarize, using a hashed value of the derived bit
length and identities instead of the zero IV would improve the design in
three ways:

a. It directly binds the identities of the server and peer to AK and to
KDK, and indirectly binds these to any TEK, MSK, or EMSK derived from
these.

b. It improves the usability of the entire design by forcing AK and KDK
to be unique and cryptographically separated for each pair of distinct
identities, even when the same PSK is configured on all devices within
an administrative domain.

c. It defeats prefix attacks.

Finally, in a totally different direction, perhaps it would be
worthwhile to give some thought to key roll-over for the long-lived
keys--no key can ever be eternal when security is an issue. It might be
better to bind the key pair <AK, KDK> to a triplet that included some
sort of PSK generation number, e.g., <EAP-PSK, NAI, psk-instance>. Here
psk-instance could be a date-timestamp or a sequence number or any other
generation marker. If you do this, the text should give some
consideration to how the key instance is conveyed by the protocol and
perhaps in the key derivation as well.

2. TEK, MSK, and EMSK issues

The derivation of the TEK, MSK, and EMSK depend on only RAND_S and KDK.
This means the peer assumes (i.e., "trusts") that the server generates a
statistically unique RAND_S for each session. If the server fails to
generate a statistically unique RAND_S, then the TEK, MSK, and EMSK are
compromised on each repeated session.

To understand the implications of this, again it is useful to spell out
pseudo-code for the key derivation:

        T1 := AES-128-Encrypt(KDK, RB)
        for ci = 1 to 9 do
                T2 := T1 XOR ci
                SK[ci] := AES-128-Encrypt(KDK, T2)
        Securely delete T1 and T2
        TEK := SK[1]
        MSK := SK[2..5]
        EMSK := SK[6..9]
        Securely delete SK

Here, the pseudo-code treats assumes ci is represented as a 128 bit
integer in network byte order.

Since the length is not included in the key derivation, prefix attacks
are again possible against the key derivation algorithm itself, even if
this is not a concern within the overall design.

Returning to the trust assumption, the peer has to assume that the
server will generate a different RAND_S on every instance of the
protocol. We will see in the protocol analysis this is not a good
assumption--replay attacks are feasible against the peer--and indeed, it
is unnecessary. It is almost always a good idea to remove unnecessary
assumptions when we can. We could perhaps remove the trust assumption
about RAND_S by again hashing together RAND_S and RAND_P to obtain the
RB value to use, e.g.:

        RB := AES-128-CBC-MAC(0^128, RAND_S || RAND_P || 0^117 || 0x480)

using the CBC-MAC hashing method with a 0 key, or

        H := 00000000000000000000000000000000
        H := AES-Encrypt-128(RAND_P, H) XOR H
        H := AES-Encrypt-128(RAND_S, H) XOR H
        RB := AES-Encrypt-128(0^117 || 0x480, H) XOR H

using Davies-Meyer hashing. Here 0x480 = 1152 is the number of bits
derived, which is encoded in 11 bits, leaving 0^117 = 117 bits of zeros
needed to complete the padding block. Note we do not need any padding
between RAND_S and RAND_P to protect against sliding window attacks,
because both are fixed length. If this RB value is used as the input for
the TEK/MSK/EMSK derivation, then both parties can assure themselves
that the session key is fresh by contributing their own statistically
unique input, and the inclusion of the length defeats prefix attacks.
This construction could also be used to address one of the security
flaws in the present definition of the protocol message flows, discussed
below.

This is a case where the choice between CBC-MAC and Davies-Meyer hashing
probably matters. The CBC-MAC approach requires only a single key
schedule initialization (perhaps per device reboot), while the
Davies-Meyer approach requires three (for each protocol instance). Since
the session key derivation occurs once at the start each instance of the
protocol, the CBC-MAC construction might therefore be preferable, even
though it is a hack.

3. Protocol issues

The message flow tries to "optimize" away "unnecessary" parts of the
AKEP2 protocol. This does not work, because the Bellare-Rogaway
construction is optimal and cannot be further optimized in any
fundamental way without degrading its security. There are at least three
problems in the present design: (a) message 2 fails to include ID_S, (b)
message 3 fails to include ID_S and RAND_P, and (c) it is not evident
that message 4 is protected from forgery. 

Point (a). Since message 2 does not repeat ID_S, the peer never attests
that it agrees ID_S is the server's identity. This problem cannot be
fixed by replacing ID_P with ID_S in message 2, because then the peer
would have no vehicle to attest to its own identity and hence identify
the correct AK to use.

The omission of ID_S is a symptom of a deeper problem. Since this
construction does not include both ID_S and ID_P, man-in-the-middle
attack becomes possible. In this particular case, the server has no way
of knowing whether the identity ID_S was delivered to the peer. In the
present design a malicious node M could replace ID_S with ID_M, and the
peer will authenticate with the wrong party M instead of the server. At
least one authenticated message must MAC both identities, or the key
used for the MAC can be replaced by the man-in-the-middle. This must be
fixed.

I expect the message 2 format was drawn the way it is to prevent
fragmentation. However, since there is no way to defend against
man-in-the-middle attacks without MACing both identities, the spec will
have to do so, or it will have to further limit the maximum combined
lengths of ID_S and ID_P, or it will have to find one way to compress
some of the fields, or we will have to accept man-in-the-middle attacks.

ID_S could be replaced in message 2 by some hashed representation of
ID_S, such as AES-128-CBC-MAC(0^128, ID_S || 0^(length(ID_S) +
length(length(ID_S)) mod 128 || length (ID_S)). This "extra" crypto is
unattractive on low power devices. The question becomes would you rather
spend the extra MIPS or increase the bandwidth consumed by inserting
ID_S into message 2 or be subject to man-in-the-middle attacks?
Resolving this issue is the only hard choice I can see that is needed to
completing the document.

Point (b). The peer P never learns whether messages 1 and 3 are live,
because the protocol does not force the server to MAC the peer's
challenge RAND_P. This problem allows a malicious entity M to replay an
old message 1 and 3 to convince the peer to think it has authenticated
with the server. And the message needs to include ID_S instead of ID_P,
because the server has never had the opportunity to attest to its own
identity, i.e., to the correct AK to use; remember message 1 and its
ID_S value could have been a forgery. The missing ID problem can be
fixed by including ID_S instead of ID_P in message 3. The missing RAND_P
problem again can be fixed either by including it directly in message 3
or by including it in the derivation of AK. Since the latter is not
possible, message 3 has to somehow include RAND_P.

One way to accomplish this without changing the message 3 format is to
replace RAND_S in message 3 with hashed RB value suggested above; recall
that we proposed "hashing" RAND_S and RAND_P together to form RB. Since
such an RB includes RAND_P, the peer will receive assurance that the
message is indeed fresh when RB is MACed. And RB makes for a perfectly
good instance (i.e., session) identifier. This would be especially
beneficial to protect exchanges protected by the TEK in message 4 and
beyond. If this direction is taken, then we would NOT want to use the
KDK for RB derivation, because it is then explicitly a public value, not
a key; we would want to use either Davies-Meyer hashing or CBC-MAC
hashing based on a well-known key.

The alternative, of course, is to explicitly include RAND_P in message
3, as done by the Bellare-Rogaway construction.

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). In the
latter case, we need to know which bits are encrypted and which merely
forgery protected. To accomplish this end, the text could, for instance,
in Figure 8 use notation like {...}* to indicate EAX encryption under
the TEK; the rest of the message would be EAX authenticated. The session
identifier--whether RAND_S or the derived RB above--should remain in the
clear but be integrity protected. 

Since we would want to leave part of the P_CHANNEL_P_1 data structure in
the clear (e.g., the sequence number) and a notation for accomplishing
this is awkward, this suggests that we have not yet found the right
boundary between the P_CHANNEL data structure and its underlying
transport.

There is another problem with message 3: P_CHANNEL_P_1 is not protected
by the MAC. Depending on what happens otherwise with the protocol
definition, this could enable cut-and-paste attacks against the message.

3. Retries, Replays, and Errors

It will be necessary somewhere to specify how to handle retransmissions,
i.e., we need a standardized treatment of "retries" as distinct from
"replays". This holds for both the messages in the base protocol, and
extended messages protected by the nonce N. Retries should cause the
receiver to retransmit, while replays should be discarded. The
difference between the two will always be an arbitrary distinction, but
is needed for interoperability's sake.

The document uses sequence numbers for the extended portion of the
protocol, but fails to indicate the sequence spaces associated with
each, how they are initialized, and how they are used to detect replays.
I believe that there needs to be different sequence spaces for each of
the two logical half-duplex channels, but perhaps the request/response
nature of EAP will save us from this fate.

The protocol seems to protect itself from reflection attacks by
including the EAP header in the MAC. This is a detail the text glosses
over and needs to be made explicit, especially in extended
authentication protection provided by EAX, as it will likely be missed
by many implementers.

One notable omission from the spec is failure processing. As an example,
what does the server do if it receives a message 2 for a protocol
instance that it has not initiated? Experience shows that different
implementers will handle such messages in different ways, almost always
to the detriment of interoperability.

4. Security Bounds

Page 39, Section 6.5 asserts that EAP-PSK is not subject to dictionary
attack. This is not true when the PSK is computed from a feasibly
searched key space, e.g., when it is, or is derived from, a password.
Suppose, for instance, that the 802.11i password-to-key mapping is used
to establish a PSK. The attacker can invoke this mapping on each
dictionary entry, derive the AK, and use each value to simulate an
authentication exchange. The attacker has only to compare the results of
a recorded EAP-PSK instance with each simulated exchange computed using
a key from the dictionary. The attacker can do the same with any other
exposed key. Thus, none of the derived keys has any more strength than
the original password. The specification should make this clear.
Conversely, however, all of the derived keys are immune to dictionary
attacks if PSK is. For the remainder of this section we will assume the
PSK is taken from an infeasibly searched key space, so that dictionary
attack is not possible.

When AES is used in any CBC-MAC-like mode, the key should be replaced
after 2^48 blocks have been processed. Since EAP-PSK protects at most 4
OMAC1-protected messages for each protocol instance, and since each
message is at most about 1024 octets = 2^6 blocks, this means that AK
should be replaced after about 2^40 instances. This bound could be
improved, but why bother? There are about 2^35 milliseconds per year, so
this permits about 2^5 years worth of protocols instances if new
instances are initiated once per millisecond.

Estimating the security of the KDK is tricky. The modified counter mode
scheme is similar enough to the parallel key generation scheme in [1]
that we should be able to derive bounds using an argument modeled on
theirs, but I have not tried to push this through. The alternative taken
here is to make a back-of-the-envelope estimate of the distribution of
the derived keys directly. If the RB passed as input into the
TEK/MSK/EMSK derivation is uniformly distributed, and if we were
deriving only one block, then we expect a significant chance of RB's
repetition after 2^64 invocations. Each protocol instance, however,
derives a swath of 9 consecutive blocks from the KDK, so the probability
of hitting any particular block again with a new randomly selected RB
and its children is 9/2^128 < 1/2^124. We should therefore expect a
significant probability collisions of RB to result in collisions of
counter mode blocks after about 2^62 invocations. If we limit the total
number of protocol instances to 2^40 or so, then it appears the design
has a safety margin for all of the derived session keys to be unique.

The text exhibits some confusion about how to measure the EAX key
strength. It is not the number of messages but rather the total number
of encrypted and integrity protected blocks that has to be limited. The
probability that an attacker can successfully attack the EAX encryption
scheme after q blocks have been encrypted is bounded by 9*q^2/2^128. The
probability that an attacker can produce a successful forgery after q
blocks have been integrity protected is bounded by (10*q^2 + 1)/2^128.
The EAX proof of security says that these bounds are tight, i.e., that
no attacker can do any better than this if AES is secure. If the
protocol spec were to bound q at, say, 2^46, then we would have
confidence that an adversary would never have more than about a
9*(2^46)^2/2^128 = 9*2^92/2^128 = 9/2^36 < 1/2^32 chance of somehow
breaking the encryption, and no more than a 10*(2^46)^2 + 1)/2^128 <
10*2^93/2^128 < 1/2^31 to successfully create a forgery, assuming AES is
a secure block cipher. That is, if we were to limit the total amount of
data protected under the TEK to 2^46 blocks, then we would have great
confidence that the protocol will not expose protected data. While the
number of encrypted blocks will be smaller than the number of integrity
protected blocks, this limit should never become a problem in practice.

Estimating the number of the MSKs and EMSKs that can be safely derived
depends on how they are used; the techniques in [1] are appropriate for
doing this. It is sufficient to say that EAP-PSK appears as robust in
this dimension as any other EAP method.

5. Odds and Ends

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.

Page 5, Section 1.1.1, and Page 43, Section 6.9: While the protocol does
not offer PFS, it does offer forward secrecy if the PSK is securely
deleted after the AK and KDK are derived and if the PSK is not taken
from a feasibly searched key space. This would be worth noting.

Page 17: What specific security claim is being made by the phrase "proof
of security"? Please detail the security model and assumptions used, and
also the specific claims being made based on these. The proof may or may
not be relevant in the present context.

Page 21: The design requires the EAP server to expose its identity and
to use the same identity with each peer, unless there is something in
the EAP-Response/Identity triggering the method that tells it otherwise.
This is a subtle configuration constraint that may not be evident to
administrators deploying the protocol.

Page 23, Figure 9: The hashed RB value constructed above that
incorporates both RAND_S and RAND_P seems like a better session
identifier than the RAND_S in messages 3 through 2i+1, because it is
computationally infeasible for either party to force it to a value used
by a prior protocol instance. Beginning in message 4, the P_CHANNEL_P_k
needs to be protected by EAX using the TEK.

Page 25, Flags field: The figure of the Flags field needs to be cleaned
up. It should be relabled to have only 8 bits, not 9. And the unreserved
field should be widened from 1 to 2 bits.

Page 35: What happens if the tunneled method fragments? 

Page 38, Section 6.1: Until message 2 is fixed to include both ID_S and
ID_P, EAP-PSK does not provide mutual authentication.

Page 38, Section 6.2: The assertion that the R field is protected does
not yet appear warranted, given that the sequence spaces have not yet
been completely specified, so replay and perhaps reflection attacks
appear to be possible, and further given that the message 1 and 3
constructions allow an attacker to replay old EAP-PSK messages. The
existing text would become correct when these issues are addressed.

Page 42, Section 6.7: Since message 1 is unprotected, it can be forged
by an adversary. Once it chooses to initiate an EAP_PSK instance, the
server must commit to a value RAND_S to enable the peer to recover from
a denial-of-service attack based on flooding forged message 1s. This is
a reasonable constraint to put on server implementations. It will
require you to fill out the missing discussion on the difference between
retries and replays. RAND_S remains constant across retries, but is
changed on all protocols instances the server classifies as "new". The
receiver should retransmit the last message if it receives a duplicate
within some retry message, and declare a duplicate a replay otherwise.

Page 43, Section 6.8: Actually session independence comes about by
choosing non-repeating instance identifiers <ID_S, ID_P, RAND_S,
RAND_P>. The current protocol lacks this property due to its inability
to protect against replayed messages 1 and 3. When this is fixed, the
protocol will have session independence.

Page 43, Section 6.9. The protocol design explicitly assumes that
neither AK nor KDK are shared beyond the two parties utilizing them. AK
loses its efficacy to mutual authenticate the peer and server with each
other when it is shared. Similarly, the derived TEK, MSK, and EMSK lose
their value for authentication when KDK is shared with a third party.

Page 43, Section 6.12: It should be easy to add a "fast reconnect" if
the server and peer maintain the TEK and their replay counters. Whether
this is valuable is dubious, however.

Page 46, Section 6.16. I think it is a mistake to not define a
cryptographic binding mechanism of a key producing inner method and
EAP-PSK. It is easy to do, and it makes EAP-PSK safe to use key deriving
inner methods. Subsidiary methods are becoming more important, as IT
departments are moving to evaluation of the patch level of devices
before they allow data to pass.


References:

[1] M. Abdalla and M. Bellare, "Increasing the lifetime of a Key: A
Comparative Analysis of the Security of Re-Keying Techniques", ASIACRYPT
2000

[2] M. Dworkin (NIST), SP800-38C, "Recommendation for Block Cipher Modes
of Operation: The CMAC Mode for Authentication", May 2005