Overall, this document is in very good shape. Kudos to the authors.
A comment on EAP header protection (Section 4.2.3) and Type code modification (Section 6.3):
4.2.3. EAP Header Protection
A tunnel method SHOULD provide protection of the outer EAP header
information when possible to make sure the outer EAP header is not
modified by the intermediaries.
6.3. Outer EAP Method Header
There are several existing EAP methods which use a similar packet
format to EAP-TLS. Often for the initial portions of the exchange
the execution of the method is identical except for the method ID.
Protection of the outer EAP header helps to avoid vulnerabilities
that may arise when an attacker attempts to modify packets to make
one EAP message look like one from a different method.
[BA] The EAP header defined in RFC 3748 looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ...
+-+-+-+-+
Section 6.3 refers to modification of the Type field which can potentially
enable an attacker to make one TLS-based EAP method look like another one. It's worth
noting that such an attack can be addressed without necessarily requiring EAP
header protection, as described in Section 4.2.3.
For example, a Type field modification attack will only enable an EAP peer to subsequently
connect to an authenticator if the peer and server were able to derive the same MSK/EMSK.
To prevent such an attack, it is highly desirable for TLS-based EAP methods to utilize
key derivation formulas unique to the method. As an example, EAP-TLS and EAP-TTLSv0
utilize different key derivation formulas:
EAP-TLS:
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
client.random || server.random)
EAP-TTLSv0:
Keying Material = TLS-PRF-128(master_secret,
"ttls keying material", client_random || server_random)
Assuming that this approach is taken, the Type modification threat described in Section 6.3 can be
addressed without EAP header protection.
Given this, it seems to me that EAP header protection is really about protection of the Code, Identifier
and Length fields of the EAP header. However, the behavior of these fields is fairly rigidly specified
in RFC 3748, so that a well written implementation should only be vulnerable to DoS attack, which
would be the case even if EAP header protection were implemented.
For example, an attacker modifying the Code field might be able to cause an EAP peer or server to
drop the packet. However, the same thing would happen if EAP header protection were implemented,
and the packet failed the MIC check.
Via modification of the Identifier field, it might be possible to cause the peer or server to abort the EAP
session in progress. However, in TLS-based methods, failure of TLS integrity check is also a terminal
error, so that I'm not sure if anything is gained here either.
Modification of the Length field might have as its objective the inducement of a buffer overflow on
either the peer or the server, so it's aims are somewhat more nefarious than attacks on the Code or
Identifier fields. However, implementation of EAP header protection would not be likely to address
such an implementation bug since the MIC could not be computed until the EAP packet was fully received,
by which time the buffer overflow would have already occurred.
In summary, I am not clear that EAP header protection as described in Section 4.2.3 really brings much value
beyond addressing the EAP Type Code attack described in Section 6.3. I would therefore recommend that this
section be deleted, or at least justified in more depth.
|
