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

[Joseph Salowey <[e-mail]>]

On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk <[e-mail]> wrote:

> On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote:
> > On Jan 29, 2021, at 5:00 PM, Joseph Salowey <[e-mail]> wrote:
> > > DISCUSS: the EAP-TLS draft should also explain that session tickets
> may be sent either before or after the 0x00 octet.  Does the packet flow
> look any different for the two cases?  If so, what does that mean?
> > >
> > > [Joe] I believe the flow of the message flights would be the same, but
> the on-the-wire format of those flights could be reversed.  I don't think
> this will necessarily cause a problem since the application data is
> consumed by the EAP TLS and the NewSessionTicket is consumed by TLS,
> However I think the draft should be clear that this can happen.
> >
> >   I think so, too.
>
> I think we should talk about that, yes.
> But I haven't managed to convince myself yet that it is 100% safe in the
> face of fragmentation -- can we rule out a case where we end up delivering
> an EAP-TLS message that ends exactly at the end of the application data
> record (say, if bundled along with the tail end of the server handshake
> flight) and there is a NewSessionTicket queued that would get fragmented
> into the next EAP-TLS message?
>
>
[Joe] As Alan points out, the peer should parse all fragments to get the
complete message and pass them all to the TLS layer.  It would be good to
call this out, but I don't think it should be a problem for
implementations.  For example, if the peer is notified that application
data is available before it has finished passing all the data to the TLS
layer it should pass the rest of the data to the TLS layer before
responding.


> > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note
> that this examples does not include Session Tickets.  Section 2.1.2 should
> be updated to note that there are more rounds than for the previous section.
> > >
> > > [Joe] Yes.  It might be helpful to say that the commitment message may
> be sent before or after the client authentication is verified, but in the
> case that resumption is used it will always be after.
> >
> >   I think that's a good idea.  The current draft doesn't make this
> explicit.
> >
> >   But... if the commitment message is sent before the client
> certificates have been authenticated, what does that commitment message
> *mean*?
> >
> >   i.e. can the server send the commitment message, ignore the client
> cert information, and send an EAP-Success?  Even if the client certs have
> expired, been revoked, etc.?  Can the client detect a rogue server which
> always answers "yes"?
>
> 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.  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.  Strictlys speaking, it need not do so -- we could have
> defined a mechanism where the exported keys depend, cryptographically, on
> the client authentication flight such that the TLS layer will not produce
> the needed keys on failed authentication. [0]
>
> [Joe] This could be also a difference between EAP-TLS 1.2 and EAP-TLS
1.3.  In 1.2, the server's finished came second so, if the server rejected
the peer certificate it could abort before sending the finished and the
client's state machine would not be able to continue.  However, 5216
section 2.1.3, suggests that errors should be sent after the finished which
means they could be removed from the conversation and the peer would be
none the wiser.   It seems the behavior between 1.2 and 1.3 would be
similar in this regard.

I'm assuming that people will not be terribly keen on switching to such a
> scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter
> variant that includes the full transcript hash, [1] not just up to Server
> Finished, which would incur at a minimum several months' delay.  It might
> be worth asking the teams that did formal analysis work on TLS 1.3 how they
> modelled client authentication and what assumptions on server behavior they
> made.
>
> So, if we do not wait for a cryptographic method to assure successful
> client authentication, and thus are going to be stuck requiring some amount
> of trust that the server is doing the right thing with the keys, how is it
> different to say that the server is going to not export the keys if the
> client authentication fails vs saying that the server is going to not
> export the keys if it is not done sending handshake messages?  There is
> perhaps some detail in terms of how EAP-TLS interacts with the TLS layer
> and what information is available when, but it seems that if you have an
> interface with TLS of "provide input bytes; get output bytes out" [2] you
> could achieve this by not exporting keys until you've sent all those bytes
> into EAP-TLS messages.
>
>
[Joe] I think this is worth saying since the key material is available at
an earlier point in TLS 1.3.


>
> >   RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state
> machine for EAP peer and server.  Does this work follow that?
>
> A good question!
>
> > > [Joe]  If we are going to make a change in the key derivation we
> should do it now.  Personally, I think we should update the key derivation
> to separate the MSK and EMSK, but it is workable as is.
> > > I think there are potential issues around the ordering of the 0x00
> octet and other messages, but I don't think this will require changes to
> implementations in the short term, but the spec needs to clarify this.
> >
> >   I agree.
>
> I wonder if (assuming that 0x00 goes forward instead of "close_notify") we
> should also go further and say that this mechanism does not use stock TLS
> 1.3, but rather a variant of the protocol that imposes an additional
> ordering
> requirement across the "higher-level protocols" that are multiplexed over
> the record layer (i.e., the TLS handshake protocol and the application data
> protocol).  In stock TLS there is only an ordering requirement for the TLS
> alert protocol with other messages carried by the record layer (because
> activity on the alert protocol tears down the record-layer connection),
> but it
> seems like a lot of what is being described as desired here ends up relying
> on ordering between application data and handshake messages.
>
>
[Joe] I don't think there is an ordering requirement.   The EAP-TLS
implementation must pass all the fragments of an EAP-TLS packet to the TLS
library before acting on the commitment message that comes with the
application data.


> >   There's also the question of *why* the commitment message is there.
> It's not in EAP-TLS for TLS 1.2.  The draft doesn't explain why it's not
> needed in TLS 1.2, but is needed for TLS 1.3.  Such an explanation would go
> a long way to clarifying many issues around the commitment message.
>
> (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.
>
>
[Joe]  I'm not sure why it's needed. It's not clear to me why the peer
can't hold the TLS session open until it receives more TLS messages
(handshake or alert) or an EAP failure or EAP Success.


> > >   So if we later discover that EAP-TLS is flawed, we can only
> deprecated EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type
> code.
> > >
> > > [Joe] Perhaps we could use an expanded EAP-Type for the alpha? Or
> perhaps experimental or a temporary experimental allocation could be made
> (not sure if that would be possible).
> >
> >   I think the issue for MS is less "alpha" code than "shipping" code.
> If we use an experimental type, it doesn't matter if it's interoperable,
> because people won't deploy it in production.  Implementors are already
> verifying code behind the scenes in builds which aren't shipped to
> customers.  So the type code is less of an issue, because that
> interoperability is "inter-engineer", and not "inter-customer".
>
> 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.
>
> -Ben
>
> [0] This sounds related to what 5247 calls a "compound key by which the EAP
> peer and server can prove that they have participated in the entire EAP
> exchange", but I am just reading that part of 5247 for the first time now
> and don't want to make too much of it.
>
> [1] Thinking about this further, it almost seems that for EAP-TLS purposes
> we would actually want to digest into the transcript *all* messages sent
> with TLS ContentType 'handshake', including NewSessionTicket, though even
> just adding the client authentication flight would go a long way.
>
> [2] This is essentially the interface that QUIC has with TLS, and for
> QUIC's purposes it's guaranteed that output bytes will only be generated
> immediately after processing input bytes and not at other times.  It is
> also possible to process input bytes and not produce output bytes, of
> course.
>