On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
> That's a scenario that I was starting to puzzle over this weekend as well
> -- with EAP-Success "completely unauthenticated", it would be fairly easy
> for an on-path attacker to send the EAP-Success the EAP peer was expecting
> and make the EAP peer think things succeeded even if the server had
> rejected the client cert.
Yes.
> Now, a server that has rejected the client cert
> is hopefully not going to be exporting the keys and continuing to run the
> next steps of protocol operation, but to some extent it seems that the
> security of the system as a whole relies on the server operating correctly
> in this regard.
The TLS exporter keys are used for 802.1X / MacSec. But they're not always
used.
> ... it
> seems like a lot of what is being described as desired here ends up relying
> on ordering between application data and handshake messages.
I think there's no implementation issue here. The draft should be clearer
that there's no guaranteed ordering.
> (A lot of my hedging in messages on this thread is because I also don't
> really understand why the message is there.)
> I believe I read somewhere that it stemmed from the change in who speaks
> last in the TLS handshake, but am a bit hazy on how that implies it is
> needed.
I would like clarification on just what that message *means*. If we want an
explicit EAP layer signal that the server saw the client cert and authenticated
it, then we MUST NOT send any such signal until after the server has seen the
client cert. And because the EAP-Success is sent all alone, we MUST then have
another full round of TLS exchange, before the final EAP-Success. i.e.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Commitment Message)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Ack) -------->
<-------- EAP-Success
In that scenario, the commitment message *does* have a purpose:
* It was not needed in TLS 1.2, because the "TLS Finished" message from the
server came after the server saw the client cert.
* In TLS 1.3, that behaviour has changed
* so the *implicit* meaning of "server sends TLS finished" is no longer "server
has seen client cert"
* Since EAP-TLS wishes to authenticate the client cert, it MUST have an EAP
state after the "TLS Finished" message
* Since EAP-TLS does not provide for any data exchanged in the EAP layer, any
data MUST be mangled into TLS
* and the only possibility is TLS application data.
I'd like to know if any of these assumptions are false.
If all this is true, then the 3.5 round EAP-TLS goal is impossible.
> I don't disagree with what you say, but I will note that if we are seeing a
> conflict between a desire to ship something ASAP and uncertainty that the
> current specification is fully correct, it's easy process-wise to allocate
> a new type code for people to ship "now" without locking in behavior for
> 0x0d. Whether we call it an early allocation, an experimental usage, or a
> normal allocation via specification required doesn't seem terribly
> important (and given that Joe is the expert and he basically suggested it,
> I suspect that allocation would occur quite quickly after a request).
> How easy it would be to get things back onto 0x0d in the future is less
> clear, though.
As an implementor, I fervently hope to *not* support an "ad hoc" EAP type for
the next 10 years.
My preference is to get this right, even it means more delays.
Alan DeKok.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
