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

[Benjamin Kaduk <[e-mail]>]

Hi Alan,

I'll try to stick to the stuff that hasn't already progressed more in the
downthread discussions.

On Wed, Dec 16, 2020 at 07:23:45PM -0500, Alan DeKok wrote:
> On Dec 16, 2020, at 5:36 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > To start with the easy one: currently the way in which the structure of
> > the Commitment Message is described makes reference to many fields of
> > TLS Record Layer structures in order to specify what is fundamentally a
> > message on the TLS Application Data stream.  This is a layering
> > violation; I don't see any reason to say more than what was suggested in
> > https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ :
> 
>   I will wave a magic wand of "implementation issues".  :(

You can only get away with that if you are clear about what properties you
actually need, though.  I think we've been making good progress at drilling
down into that, so far, so let's keep it up.

>   There appears to be few ways to *explicitly* signal that negotiation has completed.  i.e. ways which are both implemented in SSL libraries, and available to EAP-TLS implementations.
> 
>   We implemented multiple ways in FreeRADIUS (0 octet of application data and other methods).  I'll have to double-check the list archive.  But my recollection is that the "0x00" of application data was the least ugly alternative.
> 
> > Next, the whole reason for the existence of a Commitment Message seems
> > under-justified -- the only mention I could find in the document is that
> > it serves "to decrease the uncertainty for the EAP-TLS peer".  What harm
> > would be caused by a lack of certainty in this area?  Why does waiting
> > for an EAP-Success or EAP-Failure not provide a similar level of
> > certainty?
> 
>   The EAP-Success and EAP-Failure messages are *not* protected.  i.e. they are 4-bytes of data which can be spoofed rather trivially.
> 
>   In contrast, the 0 byte is an application-layer signal that EAP-TLS has succeeded.
> 
> > The commitment message as specified seems to itself be a layering
> > violation.  The TLS protocol itself consists of a few sub-protocols,
> > e.g., the handshake protocol, record protocol, and alert protocol.  The
> > operation of the handshake protocol is supposed to be completely
> > independent of the application-data record protocol (except to the
> > extent that the handshake protocol supplies the keys used for
> > cryptographic protection of application data records).  In particular,
> > there should not be any interaction between the handshake state machine
> > and the application data.  If there is to be a commitment made about the
> > operation of the TLS handshake protocol, that more properly belongs in
> > the handshake layer itself, or perhaps the alert layer if it relates to
> > the overall operation of the TLS connection.  It seems inappropriate and
> > unsustainable to expect that an application-data message would affect
> > the operation of the handshake layer.
> 
>   IMHO, it doesn't affect the TLS-layer handshakes.  It's a signal specific to EAP-TLS, which is an application using TLS.

EAP-TLS is an application using TLS, yes.  That means it can't peek into
TLS's abstraction barriers -- the example Martin gave where the TLS stack
returns a bunch of records that say "application_data" on the outside is a
case in point.

> > The use of application data for the commitment message also may have
> > unfortunate interactions with other TLS-using EAP methods, which is very
> > briefly mentioned as a possibility but not explored at all:
> 
>   I have a draft on precisely this issue.  We have implemented TLS 1.3 for TTLS and PEAP (hostap && FreeRADIUS).  Where they send application data, there is no need for a commitment message.  The EAP method sends it's own application data.

Those messages seem to play the role that Martin has identified, as
confirming that the handshake has successfully completed, but that is
distinct from what the commitment message is currently described in the
draft as doing (indicating no more handshake messages; the NewSessionTicket
interaction is most prominent but not unique).

>   Where the methods don't send application data (i.e. session resumption), they have the same problem as EAP-TLS, and require a similar solution.
> 
>   In general, a number of your comments here conflate EAP-TLS with other TLS-based EAP methods.  This document specifies a standard for EAP-TLS.  It doesn't apply to other methods.  There are similar issues for other methods, but those methods require method-specific solutions.

Well, this document does say "many other EAP methods ... depend on TLS and
EAP-TLS", as well as allowing for the negotiated ciphersuite to be used to
secure application data "as done in other TLS-based EAP methods".  That
alone would be enough to justify me thinking about the interaction with
other methods, not to mention the general obligation of the IESG to be
responsible stewards of the IETF protocol suites and consider where/whether
reusability would be desired.

> > Section 2.3
> > 
> > The use of a constant 0x0D (the "Type-Code") as the TLS-Exporter context
> > is rather unusual; per RFC 8446 this value is intended to be a
> > "per-association context value provided by the application using the
> > exporter" per RFC 5705 -- this value is not a per-association value but
> > rather a global one.
> 
>   The existing TLS-based EAP methods have consistently used exporters which are global.
> 
>   I'm not even sure what would be used for per-association value.  This is EAP, there is generally no underlying transport method (or data) which is consistently available to the EAP layer.
> 
>   i.e. Can you suggest a per-association value which would *work* for EAP?  Across RADIUS, Diameter, PANA, ...

I don't have such a thing handy, which is not surprising given that I'm not
much of an expert in all of those.

> > Section 5.5
> > 
> > It seems like there may be some scope for improvements on the RFC 5216
> > behavior here.  For example, what if we used the EAP Type field as the
> > TLS Exporter 'context' argument, instead of the literal 0x0D?
> 
>   The EAP-Type field is 0x0D for EAP-TLS.  This value is hard-coded for EAP-TLS.  For other EAP types, the use of the field is clarified here;
> 
> https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00

Ah.  I strongly suggest referencing this document for explaining how that
value was picked (and ideally mentioning the reusability of the machinery
we are specifying, though it sounds like you are perhaps reluctant to do
that part).

>   i.e. this document specifies EAP-TLS, and does *not* affect other TLS-based EAP methods.  Those are defined elsewhere.
> 
> >  That
> > seems like it would prevent the modification from successfully causing a
> > different TLS-based EAP method to be used, by using a different
> > key-derivation formula, exactly as postulated by RFC 5126.
> 
>   I think there's a misunderstanding here.  This document specifies EAP-TLS.  It doesn't specify how other TLS-based EAP methods use TLS 1.3.

(I think I covered this above; other EAP methods are not intrinsically out
of scope for discussion in this document.)

>   The discussion in the WG, and implementations guided this approach.  This document species EAP-TLS.  The above referenced document "patches" this one in order to specify the use of TLS 1.3 with other TLS-based EAP methods.
> 
> >   If any authorization, accounting, or policy decisions were made with
> >   information that have changed between the initial full handshake and
> >   resumption, and if change may lead to a different decision, such
> >   decisions MUST be reevaluated.  It is RECOMMENDED that authorization,
> >   accounting, and policy decisions are reevaluated based on the
> >   information given in the resumption.  [...]
> > 
> > I'm not sure I understand how these two sentences fit together.  Is it
> > trying to say that "if there could be a different decision, you
> > definitly have to re-check, and we recommend just always re-checking
> > since that's timpler"?
> 
>   Pretty much, yes.

Thanks,

Ben