Subject: [eap] Proposed resolution to Issue 127: Security Terms

From: [email-masked] (Bernard Aboba)
Date: Mon, 12 May 2003 10:42:11 -0700 (PDT)

I'd like to recommend that the proposed changes be accepted. Any
objections?

-----------------------------------------------------------------
Issue 127: Security Terms
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: May 12, 2003
Reference:
Document: EAP-02
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:
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.
[BA] "For a discussion of security issues in peer-to-peer
operation, see Section 7.7."