Subject: [eap] Miscellaneous (unaddressable?) comments on RFC 3748

From: Florent Bersani <[email-masked]>
Date: Thu, 10 Jun 2004 14:46:53 +0200

Hi all,

Below are some comments that came to my mind while reading the latest 
version of EAPbis I am aware of (namely RFC 3748b).

I know that these comments,much like the ones I made on the EAP state 
machines very recently, may:
* Come much too late (since IIRC RFC 3748 is now in AUTH48 so it 
shouldn't be the time IINM to propose any "real" changes to this document)
* Be completely naive or off the rocket
* Echo some comments that have already been made (although I tried my 
best to reread - and understand ;-) - the EAP issues tracked by Bernard)

I just felt like making them:
* Because the probability that they be of some help somehow is - I hope 
- non-zero
* Because the probability that someone kindly replies to educate me, is 
- I hope - non-zero
* For the record

So here they go:

Comment #1 - editorial/technical

Section 1.2

At the entry "successful authentication" we can read:
"Successful Authentication In the context of this document, "successful 
authentication" is an exchange of EAP messages, as a result of which the 
authenticator decides to allow access by the peer, and the peer decides 
to use this access. The authenticator's decision typically involves both 
authentication and authorization aspects; the peer may successfully 
authenticate to the authenticator, but access may be denied by the 
authenticator due to policy reasons."

and at the end of section 1.2 :
"Result indications A method provides result indications if after the 
method's last message is sent and received: 1) The peer is aware of 
whether it has authenticated the server, as well as whether the server 
has authenticated it. 2) The server is aware of whether it has 
authenticated the peer, as well as whether the peer has authenticated 
it. In the case where successful authentication is sufficient to 
authorize access, then the peer and authenticator will also know if the 
other party is willing to provide or accept access. This may not always 
be the case. An authenticated peer may be denied access due to lack of 
authorization (e.g., session limit) or other reasons. Since the EAP 
exchange is run between the peer and the server, other nodes (such as 
AAA proxies) may also affect the authorization decision. This is 
discussed in more detail in Section 7.16 <#section-7.16>. "

The editorial part is that IMHO some wording in the latter text ("In the 
case where successful authentication is sufficient to authorize access") 
seem to contradict some of the former one (""successful authentication 
is an exchange of EAP messages, as a result of which the authenticator 
decides to allow access by the peer, and the peer decides to use this 
access. The authenticator's decision typically involves both 
authentication and authorization aspects"). Indeed the former text 
appears also to be self-contradictory ("the peer may successfully 
authenticate to the authenticator, but access may be denied by the 
authenticator due to policy reasons.").
Perhaps, this comes from my poor mastery of the beautiful English 
language, perhaps it does not. I guess it could be worth fixing this 
wording (provided I am not the only one who finds it slippery ;-))

The technical part is another shot at some old stuff on EAP that has 
been noticed and discussed for instance in issues #2, 10, 26, 62, 80, 
121, 212, 217, 222

First, partly mixing authentication and authorization is bad IMHO (by 
partly I typically mean what EAP is doing, i.e. a protected result 
within EAP of successful authentication may mean that the peer and the 
server have also performed authorization but also may not or this 
authorization may be modified by some other device -e.g. a proxy AAA 
server). But I think it is way too late to clean up things (and some 
people might also disagree with my POV)

Second, I find the sentence "after the method's last message is sent and 
received" quite hypocrite. Since we are working with lower layers that 
may not guarantee delivery, we have to implement our own retransmission 
mechanism.
To start with, let me allude to the well-known coordinated attack 
problem (see e.g. "Knowledge and common knowledge in a distributed 
environment" by Joseph Y. Halpern and Yoram Moses available at 
http://www.cs.cornell.edu/home/halpern/papers/common_knowledge.pdf) that 
may clarify what may be understood and achievable under the wording 
"result indication" and "synchronization of state".
Let us now imagine for a second that an EAP dialog did not use EAP 
Success/Failure but only EAP requests/response pairs. In that case, 
there is still a possibility that the peer and a server fall out of 
sync, e.g. the server doesn't receive the peer's (last) answer and the 
peer doesn't receive any of the retransmitted requests. In this 
scenario, after a while, the peer will assume that its last message has 
been received and transition to success while the server will transition 
to failure. I am afraid there's not much we can do about his (i.e. since 
the ultimate common knowledge goal is unattainable, we have to place a 
threshold on how much we are willing to risk and to spend to mitigate 
this risk). A small point worth noting here, is the nature of EAP 
clients: do they continue to listen for a while or do they kill 
themselves immediately after their transition to success. The former 
case would be IINM similar to what IKE clients do and has many 
advantages IMHO while the latter would be problematic: how long has a 
peer has to wait before it transitions to success? because if it doesn't 
wait, it will probably miss any retransmission request and if it waits 
too long, this burdens the authentication with a fix delay (which some 
situations may really want to avoid).
Let us now introduce the EAP Success/Failure and consider the following 
scenario: the peer receives a (cryptographically protected) request from 
the server saying that the server has successfully authenticated it 
(whatever that means ;-)). The peer decides to send a (cryptographically 
protected) response to the server saying that it (i.e. the peer) has 
also successfully authenticated the server. Thus, we can consider that 
both the peer and the server have protected result indications. But what 
happens then if an attacker intercepts (e.g. jams) the peer's response 
and sends an EAP-Success to the peer before the server has a chance to 
retransmit its request. Well, the peer will transition to success and if 
the EAP peer "kills itself" immediately after its transition to success, 
it won't get the server's retransmissions. Thus, the server will go to 
failure while the peer will believe they are both in the success state 
despite the protected result indications:-( Again here, the fixes I am 
aware of do not completely solve this problem, imply a trade off between 
efficiency and resilience to this problem or probably require 
modifications to EAP peer's implementations (if they "kill themselves 
after success" which is what most do IMHO though I have absolutely no 
justification for this opinion - I intend to test this in the near future).
My main point in this discussion is that I think that EAP could 
(should?) have had:
1) A (more thorough) discussion of these Dos-like issues (e.g. in its 
Security considerations section). Indeed, my feeling as I have already 
expressed about DoS is that it is important to distinguish between 
attacks that are a "real" DoS and attacks that aren't (e.g.if an 
attacker jams the 802.11 frequency with a microwave oven, there's not 
much to do to prevent it - the best one can hope is to detect this and 
possibly catch the attacker). Discussion on this in RFC 3748 would have 
shown what had been considered (and mitigated or not) by the group
2) A clearer goal that it advertises against its applications/higher 
layers. For instance, do the higher layers/applications need to do key 
confirmation after a successful authentication - and are they able to do 
any better than EAP on that regard?
Last, let me remind the courageous reader that has managed to read all 
this that I am quite a newbie to protocol design, cryptography, DoS,... 
so the discussion here above may be completely stupid, have ignored EAP 
discussions/new articles/techniques on the matter...

Comment #2 - editorial/technical

Section 2.2 says: "Within EAP, the Type field functions much like a port 
number in UDP or TCP"
Although I find the analogy somehow enlightening in some way, I am 
concerned by a potential misunderstanding it could lead to (though the 
sentence that follows my quotation does provide some clarification): is 
an EAP peer capable of having multiple EAP conversations (possibly of 
the same method type) in parallel? Here's my tentative answer: if the 
EAP peer is talking to different EAP servers or different authenticators 
that it can distinguish (for instance if an EAP peer talks over 802.11 
to two different APs, it could demultiplex its conversations according 
to the AP MAC address) then there's no problem. However, if the peer 
tries to talk in parallel to the same authentication 
server/authenticator using the same method type, I bet that we will get 
into trouble due to the very small EAP identifier space... Does my 
tentative answer makes sense? [Here again a comparison with IKEv2 seems 
enlightening to me since IKEv2 would be able IINM to handle the latter 
scenario]
Perhaps it would have been worth mentioning this triviality?

Comment #3 - technical

Here again, this is about DoS resilience. While rereading EAP and the 
EAP state machines, I did not find mention of the possibility for a 
peer/server at some point to cache multiple requests/responses to 
improve its resilience against someone sending bogus packets (this 
concerns EAP as well as EAP authentication methods). The is loosely 
similar for instance to the point made in section "2.4 State 
Synchronization and Connection Timeouts" of 
draft-ietf-ipsec-ikev2-14.txt ("There is a Denial of Service attack on 
the Initiator of an IKE_SA that can be avoided if the Initiator takes 
the proper care. Since the first two messages of an SA setup are not 
cryptographically protected, an attacker could respond to the 
Initiator's message before the genuine Responder and poison the 
connection setup attempt. To prevent this, the Initiator MAY be willing 
to accept multiple responses to its first message, treat each as 
potentially legitimate, respond to it, and then discard all the invalid 
half open connections when she receives a valid cryptographically 
protected response to any one of her requests. Once a cryptographically 
valid response is received, all subsequent responses should be ignored 
whether or not they are cryptographically valid"). I reckon this kind of 
behavior is not forbidden by the current text in EAP (and is only very 
partially relevant since EAP is probably not capable of handling 
multiple simultaneous conversations with the same peer see comment #2 
above). It's just that I was wondering whether this had been thought of 
in case of EAP. In case it had, then it would have been a good idea to 
capture these thoughts...

Comment #4 - technical

Section 7.5 "Packet Modification Attacks"

"Since EAP messages of Types Identity, Notification, and Nak do not 
include their own MIC, it may be desirable for the EAP method MIC to 
cover information contained within these messages, as well as the header 
of each EAP message."

I was wondering how an EAP method could access to such messages (which 
is a preliminary to MIC them ;-)).
Although the situation seems OK for identity as section 2.2 says "Since 
EAP authentication methods may wish to access the Identity, 
implementations SHOULD make the Identity Request and Response accessible 
to authentication methods (Types 4 or greater), in addition to the 
Identity method.", it does not seem to be very straightforward for 
notifications & NAK as section 2.2 says "It cannot be assumed that the 
contents of the Notification Request or Response are available to 
another method" & "It cannot be assumed that the contents of the Nak 
Response(s) are available to another method"...

Any idea?

Comment #5 - technical

This is about a (probably) small lack of discussion IMHO in the security 
considerations section of RFC 3748 on the implications of allowing an 
EAP method to process notifications (and I believe there are at least 
from a DoS point of view) as section 5.2 only says "The peer MUST 
respond to a Notification Request with a Notification Response unless 
the EAP authentication method specification prohibits the use of 
Notification messages". My point is just about saying why a method would 
possibly forbid the processing of notifications (and I believe that this 
should be the standard behavior of EAP methods) - RFC 3748 IIRC only 
says that a notification packet is vulnerable to a packet modification 
attack.

Comment #6 - technical

Last, this is also about a (probably) small lack of discussion IMHO in 
the security considerations section of RFC 3748 on the implications of 
fragmentation. Indeed, IIRC RFC 3748 only says that:
- in the abstract and section 1 "Fragmentation is not supported within 
EAP itself; however, individual EAP methods may support this."
- in section 1.3 "Since EAP does not support fragmentation and 
reassembly, EAP authentication methods generating payloads larger than 
the minimum EAP MTU need to provide fragmentation support."
-  in section 3.1 "EAP methods can assume a minimum EAP MTU of 1020 
octets in the absence of other information.  EAP methods SHOULD include 
support for fragmentation and reassembly if their payloads can be larger 
than this minimum EAP MTU (...)  EAP is a lock-step protocol, which 
implies a certain inefficiency when handling fragmentation and reassembly"
- and fragmentation is again defined in section 7.2.1 without any new 
information

The DoS implications of fragmentation are I believe well-known and EAP 
is IHMO particlarly vulnerable to attacks on the fragmentation (whenever 
the fragments are not cryptographically protected).

Classic reference on the matter seems to be Kent's "fragmentation 
considered harmful" and Kaufman's et al. "DoS protection for UDP based 
protocol". I also believe that this point has been (is still being?) 
looked at by the IPsec WG.

There's a note in EAP-TLS (RFC 2716 - section 3.3 "However, note that in 
order to protect against reassembly lockup and denial of service 
attacks, it may be desirable for an implementation to set a maximum size 
for one such group of TLS messages. Since a typical certificate chain is 
rarely longer than a few thousand octets, and no other field is likely 
to be anwhere near as long, a reasonable choice of maximum acceptable 
message length might be 64 KB." However I believe that this note only 
very partially address the issue I am raising here; for instance if an 
attacker inject a bogus fragment in a lengthy EAP-TLS Certificate 
exchange (e.g. 60 KB) then the current behavior is IMHO a failure (since 
the behavior I expect is not the one I evoke in comment #3 - see above).

I guess I would have appreciated a discussion on that topic/hint to EAP 
method developers, since the issue is quite general, isn't it?

(issue #74 is vaguely related IMHO to this last comment)

Florent, hope this helps
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap