| Miscellaneous (unaddressable?) comments on RFC 3748 | <– Date –> <– Thread –> |
From: Florent Bersani (florent.bersani rd.francetelecom.fr)
|
|
| Date: Thu, 10 Jun 2004 08:30:28 -0400 (EDT) | |
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
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
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.