Subject: [eap] security properties issues in 2284bis-03.f

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 23:43:15 +0300

I have a few question marks related to specific
security issues:

>    Replay protection
>              This refers to protection against replay of EAP messages,
>              including EAP Requests and Responses, and method-specific
>              success and failure indications.

Question: Is it always so that replay protection of messages
implies replay protection of the full method? I could imagine a
broken method which initializes the replay protection (e.g.
client gives a counter) in a way which makes it possible for
someone to replay the whole method? Suggest s/EAP messages
including EAP requests and responses, and/ an EAP method or its
messages, including/

>   Man-in-the-Middle resistance
>              The ability for the peer to demonstrate to the
>              authenticator that it has acted as the peer for each
>              authentication method within the conversation. Similarly,
>              the authenticator demonstrates to the peer that it has
>              acted as the authenticator for each authentication method
>              within the conversation. If this is not possible, then the
>              authentication sequence or tunnel may be vulnerable to a
>              man-in-the-middle attack.

This applies only for tunnels and sequences, but the text
could be clearer about it. Replace last sentence with "If
this is not possible, then there may be a vulnerability to
a man-in-the-middle attack." Add a new sentence at the
beginning: "This property applies only for the use of
multiple methods in a combination, such as in authentication
sequences or tunnels.".

>       MiTM resistance:        No

(In many places.) I believe this should really be a "N/A"
instead, because an individual method can do little to
protect against MitM even if its perfect. Unless the
method is a tunnel method, of course, in which case it can do or
not do much for MitM...

>    Since EAP is a peer-to-peer protocol, an independent and simultaneous
>    authentication may take place in the reverse direction. Both peers
>    may act as authenticators and authenticatees at the same time.

Perhaps add a reference to Section 7.7 which talks about the
limitations of two simultaneous authentications.

>    Where a single EAP authentication method is utilized, but other
>    methods are run within it (a "tunneled" method) the prohibition
>    against multiple authentication methods does not apply.  Such
>    "tunneled" methods appear as a single authentication method to EAP.
>    Backward compatibility can be provided, since a peer not supporting a
>    "tunneled" method can reply to the initial EAP-Request with a Nak
>    (legacy or expanded).  To address security vulnerabilities,
>    "tunneled" methods MUST support protection against man-in-the-middle
>    attacks.

"support protection" sounds like an optional to use thing. Maybe
we should say "protect". Note that this would require
at least a policy-based mechanism to prevent problems
with non-key-generating methods.

--Jari