eap Mailing List: Re: methods and expert reviews

[Thomas Otto (t.otto]

Hi Jesse, 

some comments regarding Section 3 of your review. 
Please see my comments inline. 

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

The paper "Entity Authentication and key distribution",
http://www-cse.ucsd.edu/users/mihir/papers/eakd.pdf , 
illustrates in figure 5 the AKEP2 protocol, namely

A->B: RA
A<-B: [B.A.RA.RB]a
A->B: [A.RB]a

If both sides can verify the MAC, this protocol results in a common
session key, \alpha, by applying some key derivation function f.
In terms of EAP-PSK, \alpha is the TEK. 


EAP-PSK now swap both sides to comply with the EAP message flow

 Bob                                                       Alice
    |                         A||RA                            |
    |<---------------------------------------------------------|
    |                                                          |
    |                     [B||A||RA||RB]                       |
    |--------------------------------------------------------->|
    |                                                          |
    |                        [A||RB]                           |
    |<---------------------------------------------------------|

                      Figure 4: Overview of AKEP2


and assign the peer to Bob, and the EAP server to Alice, which leads
to the following message flow of EAP-PSK: 

 peer                                                      server
    |                                    Flags||RAND_S||ID_S   |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||RAND_P||MAC_P||ID_P                     |
    |--------------------------------------------------------->|
    |                                                          |
    |                     Flags||RAND_S||MAC_S||PCHANNEL_S_0   |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_1                            |
    |--------------------------------------------------------->|
    |                                                          |

So, how far has EAP-PSK modified AKEP2? 




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

Although ID_S is not sent *explicitely* in message 2, it is gone in the 
computation of MAC_P,

MAC_P = OMAC1-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)

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

Having received message 2, the server does the same computation of MAC_P
and verifies the result with the received MAC_P. So, if both MACs are 
the same, the server knows that his 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.

The peer computes MAC_P = OMAC1-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P),
which is verified by the server, and the server computes 
MAC_S = OMAC1-AES-128(AK, ID_S||RAND_P), which is in turn verified by the
client. That is, the peer MAC both identities.



[snip]
> 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. 

Message 3 contains MAC_S (see above), so the client does recognize
whether messages 1 and 3 are live (and not a replay). 



TBC