On Feb 12, 2021, at 2:53 AM, John Mattsson
<john.mattsson=40ericsson....@dmarc.ietf.org> wrote:
> But how do these work with other EAP methods now that we are taking about a
> protected success. I assume this will be needed in TTLS, PEAP, FAST, TEAP?
The other methods use the TLS tunnel to send application data. That
application data is authentication credentials.
Once the inner tunnel authentication method has finished, the user is
authenticated. That inner authentication method serves (mostly) as a
protected success indicator.
If the inner method fails, then that method serves (mostly) as a protected
failure indicator.
> The -13 commitment message could be sent as the first application data, the
> protected success would to my understanding be the last application data.
>
> This was discussed in the last months but with unclear definitions of what
> the commitment message was.
>
> Is it only (1a) or (1b) that work?
>
> My understanding is that:
>
> "After sending application data in an EAP-Request the EAP-TLS server MUST
> send only EAP-Success."
>
> would not work for TTLS, PEAP, FAST, TEAP. To make it work the application
> data would have to be something specific like "EAP-SUCCESS".
That MUST for EAP-TLS shouldn't apply to other TLS-based EAP methods.
Because the application data is an inner authentication method, with it's own
meaning.
The resumption behavior for these methods will be identical to EAP-TLS, since
there is no application data being exchanged. So we don't need to worry about
that.
However...
I say "mostly" above because not all inner methods include success / failure
signalling. For example with TTLS and PAP inside the tunnel, the server
receives the clear-text password from the peer in one EAP message (encapsulated
in TLS). If the password is OK, the reply from the server is EAP-Success. If
the password is wrong, the reply from the server is EAP-Failure.
In contrast, when MS-CHAP is used, or other EAP methods are used inside of
the TLS tunnel, there is inner-tunnel signalling for success / failure.
We cannot use application data as a protected success indicator, as it's
already being used for inner-tunnel authentication credentials. We don't want
to modify the inner-tunnel authentication methods, as that involved rev'ing
things like PEAP, which is not an IETF standard.
If we want the same protection for other methods as for TLS (and I suspect we
do), then we need something else.
After looking through the options, it appears one solution may be:
* require all TLS-based EAP methods to send close_notify after successful
inner-tunnel authentication. This will add another round trip, but I don't
think there are many other options.
* require all TLS-based EAP methods to send a TLS alert after failed
inner-tunnel authentication. The TLS alert could be "access_denied":
A valid certificate or PSK was received, but when
access control was applied, the sender decided not to proceed with
negotiation.
I don't think there is a better choice.
There are a few big caveats here. There appears to be no OpenSSL API which
allows the application to send a TLS alert. After rooting through OpenSSL a
bit, it seems that it has no code which can *ever* send an "access_denied"
alert. Also, it's not clear that the TLS state machine allows for this alert
after exchanging application data.
So in short, it's relatively easy to add protected success indicators for
other TLS-based EAP methods. Adding protected failure indicators may be more
difficult.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
