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

[Joseph Salowey <[e-mail]>]

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk <[e-mail]> wrote:

> 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.
>
>
[Joe] I would interpret the commitment message to mean that there are no
more handshake messages coming after completing the processing of this
entire EAP message.  An implementation should not stop processing the
packet in the middle of an EAP-TLS message, even if it is fragmented.  The
whole message should be consumed.


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



[Joe] Based on RFC 5216 the server could fail the finished message or as
section 2.1.3 shows it could send the finish and then it can send an Alert
and result in EAP-Failure.  In this case it would be possible for an
attacker to remove the Alert and send a success.  Whether your
implementation ends up in this scenario or not probably depends upon why
the auth failed and the behavior of your TLS library.

I do not believe that RFC 5216 provides protected result indications.   It
would be a fine thing to add, but it is new to the specification and I'm
not sure that is why the commitment message was added to begin with.


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