Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk <[e-mail]> 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.

Somehow I had convinced myself that the EMSK was only sometimes used, but
MSK was always used.  If MSK is always used, then key confirmation of the
MSK can play the role of handshake (and client authentication)
confirmation, but otherwise I seem to be coming around to your "4.5 round
trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
there is between cases that use the keys and those that don't, such that
the last round trip could be shaved off when the exported key is used for
key confirmation...

> > ... 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.

I was going to stick this in a reply to Joe (at
https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it in
here and save a message in everybody's inbox.

My understanding (based on
https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
fragments TLS records, or in some cases, groups of records, and the first
fragment includes a four-byte length field for the total message being
fragmented.  Recalling that a given TLS record can only have payload of a
single content type, in the scenario with a 0x00 confirmation message and a
NewSessionTicket, that means one record with inner type application data
and another record with inner type handshake.  If they are both grouped
together to the EAP-TLS fragmentation engine, then I agree that there is no
issue and a proper implementation should be waiting to reassemble the whole
fragmented bundle, including both records, before finalizing processing.
But is it also allowed to fragment the two records separately?  I didn't
see anything that required the entire TLS flight of messages to be
a single fragmentation input, and it's in the case that the 0x00 and
NewSessionTicket are fragmented separately that the ordering becomes
relevant -- if the 0x00 is fragmented first then the peer gets the complete
fragmented message, sees the commitment message, and prepares its
authentication flight in the EAP-Response, and based on the supposed
commitment semantics would then somehow be expected to reject an
EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
had a way to tell it was a handshake message at all, that is...)

I'd love to hear what I am missing that makes the above incorrect, and/or
that we have a way to require the NewSessionTicket and commitment message
to be part of the same fragmentation unit.

> > (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.

(I cannot contradict any of those assumptions, though I don't think I would
be one of the likely candidates to do so.)

>   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.

Understood!

Thanks,

Ben