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

[Alan DeKok <[e-mail]>]

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

  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.

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

  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.

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

> 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

  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.

  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.

  Alan DeKok.