Here's my $0.02 on updates to the "Security Considerations" section.
---
5.9. Authorization
We note that EAP-TLS may be encapsulated in other protocols, such as
PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA
[RFC5191]. Systems implementing those protocols can make policy
decisions, and can enforce authorization based on information from
the EAP-TLS exchange. As such, we need to discuss interactions
between those protocols and EAP-TLS. For generality, we state
requirements on EAP servers, instead of updating those other
protocols.
As noted in Section 2.2, above, the EAP-Response / Identity is
unauthenticated. EAP servers therefore MUST NOT make policy decisions based
on
that identity. Instead, where they make policy decisions, EAP
servers MUST base those decisions on authenticated identities, such
as information from the client certificate, or from the PSK identity
provisioned for resumption, or from other cached information as
described in the next section.
We note that this requirement does not over-ride the requirements
given in [RFC7542] Section 4. EAP servers which use the NAI format
necessarily also MUST follow the requirements of the NAI
specification.
In order to implement the requirements of [RFC7542], EAP servers MAY
examine the EAP-Response / Identity field, and reject authentication
if they determine that the field is in any way unsuitable.
In short, EAP servers MUST NOT authorize sessions based the EAP-
Response / Identity field. The field is untrusted, and may be
trivially forged.
5.10. Resumption
There are a number of security issues related to resumption.
[RFC516] is unfortunately silent on this topic, so we discuss this
issue in detail here. We note that the problems outlined here are
also relevant to earlier versions of TLS. The solutions are also
similar.
When resumption occurs, it largely occurs based on the cached TLS
data, at the TLS layer. The only credentials supplied during this
resumption are the EAP-Response/Identity. However, as noted above in
Section 2.2, the identity presented in the EAP-Response/Identity is
unauthenticated information, and SHALL NOT be used for access control
or accounting purposes. Note that this also applies to resumption.
This requirement gives us a conundrum. We have a successful
resumption, but we have no idea what identity is being used in that
resumption. We are thus unable to apply any authorization to that
authentication request. Since we have no way to authorize the user,
the only secure step we can take is to reject the session. This
rejection removes any possibility of resumption.
The solution to this conundrum is to associate authentication
credentials and authorization information with the original
authentication. That information can then be obtained and applied
during resumption.
There are two ways to make this association. The first method is via
[RFC5077], where the TLS server encapsulates the session state into a
ticket and forwards it to the client. The client can subsequently
resume a session using the obtained ticket. The second method is
where the TLS server caches information about the TLS session, based
on a unique key. For TLS versions before 1.3, this key can be the
session ID. For TLS 1.3, this key is the unique PSK identity.
The following requirements apply to both methods of associating
additional data with the TLS session. For simplicity, we use the
term "cached data" to mean any authentication credentials or
authorization information that has been associated with the TLS
session via either session tickets, or via caching on the TLS server.
Where the EAP server applies no authorization policies to TLS
sessions, it MAY allow resumption where no cached data is available.
That is, if no policies are applied during the original
authentication, it is acceptable to not apply policies during any
resumption.
In all other cases, the EAP server MUST cache data during the
original authentication. This cached data MUST be sufficient to make
authorization decisions during session resumption. Where this cached
data is unavailable, the resumption MUST be rejected, as no policies
can be meaningfully applied.
Any authorization applied during resumption MUST be done using the
cached data, and MUST NOT be done by examining the EAP-Response /
Identity that was supplied during resumption. As noted earlier, that
identity is unauthenticated and therefore insecure.
The above requirements also apply if the EAP server expects some
system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached
data.
As discussed in the previous section, EAP-TLS may be carried inside
of another protocol. This encapsulation creates further security
issues with resumption.
These encapsulating protocols can provide additional, non-EAP
information to the EAP server. This information can include, but is
not limited to, the following data:
* MAC address of the EAP peer * IP address of the EAP peer *
Informtion about the ethernet switch to which the EAP peer is
connecting
* MAC address of the switch
* IP address of the switch
* switch port used by the EAP peer
* Wifi SSID
* Information about the ethernet layer used by the EAP peer
The EAP server also has access to the cached EAP-Response / Identity
from the original authentication.
None of these fields are authenticated or secured. As a result, any
or all of these fields can change between the original
authentication, and resumption. This change creates a "Time of
check, time of use" (TOCTOU) security vulnerability. A malicious
user could supply one set of data during authentication, and a
different set of data during resumption. The malicious user could
then obtain different authorization during resumption, potentially
leading to them obtaining access that they should not have.
When EAP servers make policy decisions based on unauthenticated
information, they MUST then add that information to the cached data
described above. This cached information MUST be used as part of any
policy decision or authorization made for resumption. That
requirement allows the EAP peer to potentially obtain the same
authorization as for the original session. The requirement also
ensures that where accounting is needed, the resumption is correctly
accounted for via the original authentication credentials.
The new information given during resumption SHOULD also be used as
part of any policy decision or authorization made for resumption.
EAP servers MAY reject resumption where the information supplied
during resumption does not match the information supplied during the
original authentication. Where a good decision is unclear, EAP
servers SHOULD err on the side of caution, and therefore reject the
resumption.
It is difficult for us to state the above requirement more precisely
than the above. We cannot require that the resumption be rejected in
all cases. For example, it may be permissible for a user to change
switch ports, and still use resumption. It may be permissible for
for the user to request additional authorization during resumption.
Where EAP servers determine that the user is acting maliciously, they
MUST reject the resumption.
We can unfortunately provide little additional guidelines here. It
is up to each implementation and / or deploymentment of EAP-TLS to
determine which information to examine, and which policies apply.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
