On Feb 22, 2019, at 2:46 AM, John Mattsson wrote:
>
> I think Section 2.2 of RFC 5216 do discuss this issue, but it does not
> explicitly mention resumption. The text is also too soft.
I think that section discusses an entirely different issue, that has nothing
to do with resumption.
> Suggestion to add to Section 2.2 of EAP-TLS 1.3
>
> "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 text means that resumption is impossible in all practical networks.
Why? Because the user was originally authenticated via the credentials they
provide: the certificate. As per Section 2.2, any policies applied to that
user are applied based on those credentials.
When resumption happens, those credentials are not supplied. The only ID
provided is the EAP-Response/Identity, which systems are forbidden from
trusting.
So we now have resumption where we don't know the identity of who is
resuming. We don't know what policies were applied to them previously. We
don't know what policies to apply to them now.
Therefore, any *practical* resumption is impossible.
In my opinion, the document MUST give guidance for implementors and site
administrators:
* if resumption is used, the implementation MUST cache sufficient information
for the system to make appropriate policy decisions on resumption
* resumption MUST be rejected if no cached information is available, as we have
no idea what policies to apply
* the document MUST discuss the use of EAP-TLS in other protocols such as PPP,
PANA, RADIUS, and Diameter. Just a mention that they exist is fine.
* These protocols MAY carry additional information about the user and/or the
machine involved.e.g. MAC, switch IP, port, etc.
* When systems make policy decisions on that additional information, the
systems MUST be aware that the additional information can be different between
the original authentication and any resumption
* This difference creates a "Time of check, time of use" (TOCTOU) security
issue with the policies. i.e. The user can leverage the TOCTOU issue to get
one policy applied for the original authentication, and a different policy
applied for resumption.
* That difference allows users to exploit the system, and get access that they
should not have.
* Implementations SHOULD add such information to the above cache for the
session, so they can look for discrepancies between the original authentication
and resumption
* where there are discrepancies, the resumption SHOULD be rejected.
I don't understand why there's so little concern about people being able to
PWN your network. It's a disaster.
We can't just paper over this issue. It's a major security flaw that's
designed into the protocol. It needs to be addressed.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
