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

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Jan 2021 14:44:01 +1100

Hi All,

Ben asked me to take a look at this draft and I think that the general gist of Ben's comments need some careful consideration.

# Commitment Message

I think that Ben's concerns about the Commitment Message are justified, but aren't as bad a layering violation as observed (almost).  It would be annoying and difficult to implement this correctly, but not impossible.  We've done much worse in QUIC.

However, it would be much better not to include the Commitment Message at all.

In addition to the reasons Ben describes, I have a much simpler one: the EAP layer has a signal that the protocol is complete: EAP-Success.  The only thing that the Commitment Message adds to that is a very narrow form of authentication.  The cost of that authentication is fairly significant, as Ben identifies, but what it gets you is a strong assurance that the messages preceding it were not truncated.

As both entities have to verify that the TLS handshake was successfully completed independent of any EAP signals, the only thing the Commitment Message provides is the assurance that an attacker didn't insert or remove any post-handshake messages.  Any inserted messages would still need to be authentic, so given that a server won't send stuff it isn't permitted to (unless it likes failures), the exposure is minimal.  The only real "attack" I can see based on the current design is the removal of NewSessionTicket.  The effect of that attack is limited to denying the client access to resumption.  This is something we live with in other TLS usage contexts; EAP can probably manage too.

The draft does not attempt to apply similar protection to client messages, despite having the same theoretical problem.

I also think that the idea that you might get a TLS Alert after declaring success is odd.  I don't see any cause to keep the TLS session active after declaring success.  I would also remove EAP-Failure (for TLS reasons at least) after EAP-Success from the state machine.  TLS state can be discarded once EAP-{Success|Failure} is sent and received.

I would instead either prohibit the use of application data outright or say that it carries no semantics unless otherwise negotiated.  The current design has the effect of rendering application data unusable, so perhaps the former is best.

# Key Schedule

The other thing I observe is the way that this slices up the exporter output.  This was something that old versions of TLS did, but TLS 1.3 did away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - and should - do the same.  All it means is having more exporter labels.

I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS exporter for each of the six values that the protocol requires.  I also note that the 0x0D value is used multiple times, unnecessarily, both as a context strong to the exporter and as a prefix to the session ID.

# Editorial Nits

I found the way that this updates RFC 5216 to be extremely difficult to process.  Section 2.1.4 (which updates Section 2.1.3...) is particularly nasty to read.

RFC 5216 is a short document; obsoleting it completely would have been my preferred approach.  There is enough new material in this document that applies to TLS 1.2 as well as TLS 1.3 to justify a revision rather than a patch.  

Section 5.4 "EAP--TLS" has two hyphens.

On Thu, Dec 17, 2020, at 09:38, Benjamin Kaduk wrote:
> Hi TLS WG,
> 
> I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3
> draft here, since they relate to some rather core TLS protocol concepts,
> and I'd like to get some broader feedback with the extra time given by
> deferring the ballot.
> 
> Please ensure that comments reach the EMU WG list (cc'd).
> 
> Thanks,
> 
> Ben
> 
> On Wed, Dec 16, 2020 at 02:36:50PM -0800, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-emu-eap-tls13-13: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > I'm going to defer this document's evaluation because I think there are
> > several interrelated subtle issues that merit closer consideration than
> > has been given so far.  I will also invite the TLS WG to provide input
> > on these issues, since they relate to rather fundamental issues of the
> > operation of the TLS sub-protocols.
> > 
> > Most of them concern the Commitment Message, in terms of what goals it
> > aims to achieve, how it is specified, and what mechanism is used to
> > effectuate it.
> > 
> > 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/ :
> > "the commit[ment] message is a single byte of [value] 0 in the application data
> > stream".  All the bits about cryptographic protection and expansion of the
> > plaintext in prepararation for record protection are just adding noise,
> > and the interface between the TLS stack and the application is supposed
> > to be a data-stream abstraction, not a record abstraction.
> > 
> > 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 document also suggests in several places that the Commitment Message
> > can or should be sent at 0.5-RTT data in the same flight as the server
> > Finished.  The intent, as determined from the mailing list archive,
> > seems to be to save a round-trip compared to a typical full message flow
> > where the server does not send application data until after the client's
> > Finished (and any application data alongside it) is received.  In
> > particular, this came out during discussion of how a TLS "close_notify"
> > alert would be unsuitable for the role of the Commitment Message, since
> > sending the "close_notify" in 0.5-RTT would prevent sending an alert if
> > the client authentication failed, and the diagnostic value of such
> > alerts is significant.  This is where the issues start to become
> > interrelated -- the Commitment Message as a new application-data
> > construct is for the objective of reducing the number of round trips.
> > However, TLS session resumption is also designed to reduce the number of
> > round-trips (including by no longer needing to send potentially large
> > TLS Certificate messages that get fragmented at the EAP layer, with the
> > cost of a round trip per fragment), and there is a nasty interaction
> > between the two mechanisms.  Specifically, TLS 1.3 session resumption
> > requires the use of a NewSessionTicket message, which is associated with
> > a resumption secret; the resumption secret, in turn, is not available in
> > the key schedule until the client Finished (and client authentication
> > messages, if any) is available.  While it is possible in many Web
> > scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this
> > is because the server can precompute what the valid client Finished
> > would be and use that in the key schedule to precompute the resumption
> > secret.  If the client is to be authenticated, as is the case for the
> > vast majority of EAP exchanges, then such precomputation is impossible,
> > and the session ticket cannot be issued until the extra round trip is
> > completed.  The document contains no discussion of the inherent tradeoff
> > between sending the commitment message in 0.5-RTT and using resumption,
> > and this tradeoff seems to call into question the merits of choosing
> > this mechanism to implement the commitment message, since...
> > 
> > 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.
> > 
> > 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:
> > 
> >    While EAP-TLS does not protect any application data except for the
> >    Commitment Message, the negotiated cipher suites and algorithms MAY
> >    be used to secure data as done in other TLS-based EAP methods.
> > 
> > If we are to expect this construction of commitment message to become
> > the de facto standard for using TLS 1.3 with EAP, I think we need to
> > consider whether other EAP methods that do need to actually protect
> > application data with the TLS connection will be affected by this
> > proposal to insert the EAP commitment message into the application data
> > stream.  This is worth particular consideration given that we require
> > that "EAP-TLS peer implementations MUST accept any application data as a
> > Commitment Message from the EAP-TLS server to not send any more
> > handshake messages" -- these seem like new semantics that might be quite
> > unexpected if applied to other EAP methods.
> > 
> > There's also a few internal inconsistencies that raise to a
> > discuss-level and will need to be resolved before publication:
> > 
> > The body text around Figure 3 indicates that mutual authentication
> > should be depicted, but the figure shows only normal server-only
> > authentication.
> > 
> > The example in Figure 8 needs a TLS CertificateRequest in there in order
> > for the rest of the flow to make sense.
> > 
> > Section 2.1.4 says that "TLS warning alerts generally mean that the
> > connection can continue normally and does not change the message flow."
> > but this is no longer true with TLS 1.3 -- the only alerts sent at
> > warning level are "close_notify" and "user_cancelled", both of which
> > indicate that the connection is not going to continue normally.
> > 
> > Section 2.1.9 claims that the largest size of a TLS record is 16387
> > octets, but by my count a TLSCiphertext can get up to 16643, since the
> > length field "MUST NOT exceed 2^14 + 256 bytes" (and there's the other 3
> > bytes of header).
> > 
> > Please also check the statements made about RFC 8446 that I note in my
> > comments on Section 5.1.
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Some of these comments are a bit rough, as I did not do my full editing pass
> > since I plan to defer the ballot.  I'm including them anyway as they still
> > seem likely to be useful even in this form.
> > 
> > I strongly suggest that the option for the server to send an alert
> > instead of HelloRetryRequest in the case of missing "key_share" be
> > removed; see my comments on Section 2.1.3.  As far as I can tell this
> > option is flat-out bad practice and should not be allowed.
> > 
> > I also strongly suggest that the WG make the simple modification to the
> > key schedule that I suggest in my comments on Sections 2.3 and 5.5, that
> > would have the effect of achieving the property anticipated by Section
> > 5.5 of RFC 5216, whereby incorporating the EAP-TLS Type information into
> > the key derivation formula prevents a type of packet modification
> > attack.
> > 
> > Abstract
> > 
> >    reduced latency when compared to earlier versions of TLS.  EAP-TLS
> >    with TLS 1.3 further improves security and privacy by mandating use
> >    of privacy and revocation checking.  This document also provides
> > 
> > I agree with the secdir reviewer that some indication of what is meant
> > by (EAP) "privacy" here is likely in order.
> > 
> > Section 1
> > 
> >    In addition to the improved security and privacy offered by TLS 1.3,
> >    there are other significant benefits of using EAP-TLS with TLS 1.3.
> >    Privacy is mandatory and achieved without any additional round-trips,
> > 
> > (ditto)
> > 
> > Section 2.1.1
> > 
> >    for resumption.  SessionID is deprecated in TLS 1.3 and the EAP-TLS
> >    server SHALL ignore the legacy_session_id field if TLS 1.3 is
> >    negotiated.  TLS 1.3 introduced early application data which is not
> > 
> > (nit) we could perhaps quibble about whether "SHALL ignore" is
> > consistent with the RFC 8446 requirement to echo the legacy_session_id
> > value from the ClientHello in the ServerHello, though I'm not going to
> > make a big deal about it.
> > 
> >    used in EAP-TLS.  A EAP-TLS server which receives an "early_data"
> >    extension MUST ignore the extension or respond with a
> >    HelloRetryRequest as described in Section 4.2.10 of [RFC8446].
> > 
> > It's probably better to place restrictions on the indication that early
> > data might be possible, than to (just) place restrictions on accepting
> > it.  That is, if the server is forbidden from generating a
> > NewSessionTicket message that includes the "early_data" extension, then
> > the client is also forbidden from sending "early_data" in a ClientHello.
> > [ed. we do do this in §2.1.2]
> > 
> > Section 2.1.3
> > 
> >    full handshake.  It is left up to the EAP-TLS peer whether to use
> >    resumption, but it is RECOMMENDED that the EAP-TLS server accept
> >    resumption as long as the ticket is valid.  However, the EAP-TLS
> > 
> > But the EAP-TLS server sets how long the ticket is valid :)
> > Should we give some guidance on how long that should be (noting that it
> > must say within the RFC 8446-mandated 7 day maximum).
> > 
> >    was used in the original full authentication.  E.g. the NAI @realm
> >    can safely be reused, while the NAI ZmxleG8=@realm cannot.  The TLS
> > 
> > (Does base64("flexo") have enough randomness to be reflective of a good
> > privacy NAI?)
> > 
> >    A subsequent authentication using resumption, where both sides
> >    authenticate successfully (without the issuance of more resumption
> >    tickets) is shown in Figure 3.
> > 
> > (It's slightly surprising to show an example of resumption without
> > issuing additional resumption tickets, since such issuance is basically
> > necessary in order to comply with the recommendation from earlier in the
> > section to follow the client tracking prevention mechanisms in Appendix
> > C.4 of RFC 8446.  Though I guess draft-ietf-tls-ticketrequests is
> > potentially relevant for just how necessary it is going to be in
> > practice.)
> > 
> >    back to a full handshake.  If the EAP-TLS peer did not supply a
> >    "key_share" extension when attempting resumption, the EAP-TLS server
> >    needs to reject the ClientHello and the EAP-TLS peer needs to restart
> >    a full handshake.  The message flow in this case is given by Figure 4
> >    followed by Figure 1.
> > 
> >    Also during resumption, the EAP-TLS server can respond with a Hello
> >    Retry Request (see Section 2.1.6) or issue a new ticket (see
> >    Section 2.1.2)
> > 
> > I don't understand why the "alert plus fresh handshake" flow is even
> > listed as an option -- AFAICT the HelloRetryRequest (note: no spaces)
> > flow is uniformly superior.  There is no benefit in round-trip count to
> > starting a fresh handshake, and HelloRetryRequest allows the initial
> > interaction to be authenticated by the continued handshake transcript.
> > Aborting and starting over is analogous to the dreaded "downgrade dance"
> > that has periodically plagued the TLS ecosystem, and I'm confused that
> > we would consider encouraging it to return.  I would instead say that
> > the server "needs to send HelloRetryRequest to signal that additional
> > information is needed to complete the handshake, and the EAP-TLS peer
> > needs to send a second ClientHello containing that information" (or
> > similar), and drop the "Figure 4 followed by Figure 1" sentence.  (The
> > final paragraph would then become a bit redundant, but perhaps there is
> > still some information that should be persisted.)
> > 
> > Section 2.1.4
> > 
> >    The two paragraphs below replaces the corresponding paragraphs in
> >    Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
> >    higher.  The other paragraphs in Section 2.1.3 of [RFC5216] still
> >    apply with the exception that SessionID is deprecated.
> > 
> >       If the EAP-TLS peer authenticates successfully, the EAP-TLS server
> >       MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
> >       TLS records conforming to the version of TLS used.  The message
> >       flow ends with the EAP-TLS server sending an EAP-Success message.
> > 
> >       If the EAP-TLS server authenticates successfully, the EAP-TLS peer
> >       MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
> >       TLS records conforming to the version of TLS used.
> > 
> > Just to walk through the various scenarios here; if the last message of
> > the TLS handshake for a given TLS version is sent by the TLS client, that
> > will go in an EAP-Response, so the server is then able to send
> > EAP-Success directly.  On the other hand, if the last TLS handshake
> > message is sent by the server, that will have to go in an EAP-TLS
> > EAP-Request, and so the peer will have to send an empty EAP-TLS response
> > in order for the server to be able to wend EAP-Success?  Do we need to
> > have any text here to handle that empty EAP-TLS Eap-Request case?
> > 
> >    In the case where the EAP-TLS server rejects the ClientHello with a
> >    fatal error, the conversation will appear as shown in Figure 4.  The
> > 
> > Should we perhaps say that these examples are with TLS 1.3, even if the
> > actual normative protocol is no longer tied to a specific TLS version?
> > 
> > Section 2.1.5
> > 
> > In some sense, this figure depicting the no-peer-authentication case is
> > just an example specific to TLS 1.3 and is not necessarily
> > representative of the generic EAP-TLS case for potential future versions
> > of TLS.  Should we make that more clear from the prose?
> > 
> > Section 2.1.6
> > 
> >    the handshake.  One use case is if the EAP-TLS server does not
> >    support the groups in the "key_share" extension, but supports one of
> > 
> > I'd consider adding a parenthetical "(or there is no "key_share"
> > extension)".
> > 
> > Section 2.1.8
> > 
> >    username in cleartext in the Identity Response.  Following [RFC7542],
> >    it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but
> >    other constructions such as a fixed username (e.g. anonymous@realm)
> >    or an encrypted username (e.g.  YmVuZGVy@realm) are allowed.  Note
> > 
> > (I note that YmVuZGVy is just base64("bender"); does that really count
> > as "encrypted"?)
> > 
> > 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.
> > 
> > Section 2.4
> > 
> >    While EAP-TLS does not protect any application data except for the
> >    Commitment Message, the negotiated cipher suites and algorithms MAY
> >    be used to secure data as done in other TLS-based EAP methods.
> > 
> > This makes me uncomfortable -- is this other data being secured going to
> > live in the same "namespace" as the Commitment Message?
> > 
> > Section 2.5
> > 
> >    and TLSPlaintext.fragment = 0x00).  Note that the length of the
> >    plaintext is greater than the corresponding TLSPlaintext.length due
> > 
> > (This sentence reads oddly; perhaps "length of the TLSInnerPlaintext" is
> > more clear?  But we shouldn't be saying this at all, per the Discuss.)
> > 
> > Section 5.1
> > 
> >    [2] Confidentiality: The TLS 1.3 handshake offers much better
> >    confidentiality than earlier versions of TLS by mandating cipher
> >    suites with confidentiality and encrypting certificates and some of
> >    the extensions, see [RFC8446].  When using EAP-TLS with TLS 1.3, the
> > 
> > I note that there exist codepoints for TLS 1.3 ciphersuites that do not
> > provide confidentiality protection.  Please point to the part of RFC
> > 8446 that mandates this behavior.
> > 
> >    [3] Key strength: TLS 1.3 forbids all algorithms with known
> >    weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3
> > 
> > Where does RFC 8446 forbid 3DES?  CBC is forbidden by the requirement to
> > be AEAD, and RC4 and MD5 are explicitly forbidden, but the situation for
> > SHA-1 is more subtle.  Please reword this sentence to be accurate.
> > 
> > Section 5.4
> > 
> >    When EAP-TLS is used with TLS 1.3, the revocation status of all the
> >    certificates in the certificate chains MUST be checked.
> > 
> > What does this mandatory checking entail when a certificate contains
> > neither a CRL Distribution Point nor an OCSP responder URL?  (See also
> > the recent thread on the LAMPS WG list with Subject: "The
> > id-ce-noRevAvail extension".)
> > 
> >    TLS, see Section 4.4.2.1 of [RFC8446].  In TLS 1.3 the OCSP
> >    information is carried in the CertificateEntry containing the
> >    associated certificate instead of a separate CertificateStatus
> >    message as in [RFC4366].  This enables sending OCSP information for
> > 
> > RFC 4366 seems like a stale (obsolete) reference, and RFC 6066 should be
> > preferred.  (RFC 4366 would then become an unused reference, I believe.)
> > 
> >    To enable revocation checking in situations where EAP-TLS peers do
> >    not implement or use OCSP stapling, and where network connectivity is
> >    not available prior to authentication completion, EAP--TLS peer
> >    implementations MUST also support checking for certificate revocation
> >    after authentication completes and network connectivity is available,
> >    and they SHOULD utilize this capability by default.
> > 
> > If it's RECOMMENDED to use OCSP stapling, what does it mean that they
> > "SHOULD utilize this capability by default" (as well)?
> > 
> > (Also, nit: only one '-' in EAP-TLS.)
> > 
> > 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?  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.
> > 
> > Section 5.7
> > 
> >    and the authorizations of the other party may have been reduced.  If
> >    the cached revocation is not sufficiently current, the EAP-TLS peer
> >    or EAP-TLS server MAY force a full TLS handshake.
> > 
> > nit: s/cached revocation/cached revocation data/
> > 
> >    in the certificate chain has been revoked or has expired.  In all
> >    such cases, resumption results in a full TLS handshake instead.
> > 
> > nit: s/resumption results/an attempt at resumption results/ (or similar)
> > 
> >    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"?
> > 
> >    Where a good decision is unclear, EAP-TLS servers SHOULD reject the
> >    resumption.
> > 
> > I suggest "reject the assumption and continue with a full handshake".
> > 
> >    Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
> >    considerations for resumption.
> > 
> > I'm curious why specifically § 8.1 and 8.2 were selected, given that §8
> > as a whole is about "0-RTT and Anti-Replay", which is a more specific
> > topic than just resumption.
> > 
> > Section 5.8
> > 
> >    Tracking of users by eavesdropping on identity responses or
> >    certificates is a well-known problem in many EAP methods.  When EAP-
> >    TLS is used with TLS 1.3, all certificates are encrypted, and the
> >    username part of the identity response is always confidentiality
> >    protected (e.g. using anonymous NAIs).  [...]
> > 
> > As written this applies to server certificates as well as TLS client
> > certificates.  For which the statement is technically true, but with the
> > caveat that it is typically easy to persuade the server to (re-)send
> > those same certificates encrypted to a key known to the attacker, so the
> > protection provided by the encryption is limited.  (The server has been
> > fairly strongly authenticated by the time the EAP peer makes the
> > decision to send its certificate, so there the reverse situation is
> > different.)
> > 
> >    and only using the pseudo-random usernames a single time.  Note that
> >    the privacy-friendly usernames also MUST NOT include substrings that
> >    can be used to relate the identity to a specific user.  Similarly,
> >    privacy-friendly username SHOULD NOT be formed by a fixed mapping
> >    that stays the same across multiple different authentications.
> > 
> > I think that violating the SHOULD NOT would intrinsically violate the
> > preceding MUST NOT ... so should they both be MUST NOTs?
> > 
> >    static RSA based cipher suites without privacy.  This implies that an
> >    EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
> >    server responds to an empty certificate message with a TLS alert
> >    message.
> > 
> > Just to check my understanding, this "response" would be an EAP-TLS
> > response containing a new ClientHello (that would proceed to do a
> > handshake including the client certificate in the unprotected initial
> > handshake)?  That is, it would be a response at the EAP layer but not at
> > the TLS layer.
> > 
> > Section 5.9
> > 
> >    Pervasive monitoring refers to widespread surveillance of users.  In
> >    the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS
> > 
> > nit: "context of"
> > 
> > Section 5.10
> > 
> >    summarizes the attacks that were known at the time of publishing and
> >    [RFC7525] provides recommendations for improving the security of
> >    deployed services that use TLS.  However, many of the attacks are
> > 
> > Using BCP195 as the slug is probably preferred, since any RFCs
> > associated with the BCP are going to be relevant and topical.
> > 
> > 
> > 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 3 Jan 2021 22:18:22 -0800

Hi Martin,

Thanks for taking a look at this, some comments below:

On Sun, Jan 3, 2021 at 7:45 PM Martin Thomson <[email-masked]> wrote:

> Hi All,
>
> Ben asked me to take a look at this draft and I think that the general
> gist of Ben's comments need some careful consideration.
>
> # Commitment Message
>
> I think that Ben's concerns about the Commitment Message are justified,
> but aren't as bad a layering violation as observed (almost).  It would be
> annoying and difficult to implement this correctly, but not impossible.
> We've done much worse in QUIC.
>
> In addition to the reasons Ben describes, I have a much simpler one: the
> EAP layer has a signal that the protocol is complete: EAP-Success.  The
> only thing that the Commitment Message adds to that is a very narrow form
> of authentication.  The cost of that authentication is fairly significant,
> as Ben identifies, but what it gets you is a strong assurance that the
> messages preceding it were not truncated.
>
> As both entities have to verify that the TLS handshake was successfully
> completed independent of any EAP signals, the only thing the Commitment
> Message provides is the assurance that an attacker didn't insert or remove
> any post-handshake messages.  Any inserted messages would still need to be
> authentic, so given that a server won't send stuff it isn't permitted to
> (unless it likes failures), the exposure is minimal.  The only real
> "attack" I can see based on the current design is the removal of
> NewSessionTicket.  The effect of that attack is limited to denying the
> client access to resumption.  This is something we live with in other TLS
> usage contexts; EAP can probably manage too.
>
> The draft does not attempt to apply similar protection to client messages,
> despite having the same theoretical problem.
>
> I also think that the idea that you might get a TLS Alert after declaring
> success is odd.  I don't see any cause to keep the TLS session active after
> declaring success.  I would also remove EAP-Failure (for TLS reasons at
> least) after EAP-Success from the state machine.  TLS state can be
> discarded once EAP-{Success|Failure} is sent and received.
>
> I would instead either prohibit the use of application data outright or
> say that it carries no semantics unless otherwise negotiated.  The current
> design has the effect of rendering application data unusable, so perhaps
> the former is best.
>
>
[Joe] I'm not sure I remember correctly, but I think the commitment message
was to make the integration with EAP statement machine cleaner and perhaps
to future proof against additional messages sent after the handshake.  I
tend to agree that the value is low in the current situation (It is a
deviation from RFC 5216).   Given all the discussion this message has
caused I'm tempted to agree that we should just remove it (or make it
"optional" in case implementations already do this).  There may need to be
some text in the draft that says the NewSessionTicketMessage must be sent
in the same flight as the finished message. I'd like to understand if there
is an implementation consideration that requires the commitment message.

> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
> I appreciate that this uses exporters now rather than abusing the internal
> PRF.  That's good.  The next step is to dispense with the intermediate
> values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and
> use the TLS exporter for each of the six values that the protocol
> requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
> [Joe]  I can see your point, but I don't think the way the keys are
derived is wrong and don't really see the need to change it at this point.

> # Editorial Nits
>
> I found the way that this updates RFC 5216 to be extremely difficult to
> process.  Section 2.1.4 (which updates Section 2.1.3...) is particularly
> nasty to read.
>
> RFC 5216 is a short document; obsoleting it completely would have been my
> preferred approach.  There is enough new material in this document that
> applies to TLS 1.2 as well as TLS 1.3 to justify a revision rather than a
> patch.
>
> [Joe] yes, however I think the agreement during the chartering was that it
would just update and not obsolete RFC 5216.

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Jan 2021 17:38:15 +1100

On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote:
> [Joe] I'm not sure I remember correctly, but I think the commitment 
> message was to make the integration with EAP statement machine cleaner 
> and perhaps to future proof against additional messages sent after the 
> handshake.  I tend to agree that the value is low in the current 
> situation (It is a deviation from RFC 5216).   Given all the discussion 
> this message has caused I'm tempted to agree that we should just remove 
> it (or make it "optional" in case implementations already do this).  
> There may need to be some text in the draft that says the 
> NewSessionTicketMessage must be sent in the same flight as the finished 
> message. I'd like to understand if there is an implementation 
> consideration that requires the commitment message.   

That might be possible, but many implementations won't be happy with that requirement.  Some implementations, particularly those that use tickets rather than server state, can't send NewSessionTicket until they have the client Certificate.

> derived is wrong and don't really see the need to change it at this 

Depends on what you consider "wrong".  In TLS, we did this so that you could exercise good key hygiene.  If you are backing this with PKCS#11, then you might prefer not to be exporting the value of keys just so that you can do some slicing and then re-import the same value.  I see no reason that EAP would be above this.

> [Joe] yes, however I think the agreement during the chartering was that it would 
> just update and not obsolete RFC 5216. 

Given the magnitude of the change, I don't see what this gains you other than a document that is really hard to use.

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 4 Jan 2021 10:01:56 +0000

Top posting to explain the need for a reliable notification of protocol completion:

On 1/4/21 5:44 AM, Martin Thomson wrote:

 I have a much simpler one: the EAP layer has a signal that the protocol is complete: EAP-Success

Alan Dekok explained in a separate email thread why this is not the case (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  i.e. they are 4-bytes of data which can be spoofed rather trivially.".

There are two more quirks as to why EAP-Success cannot be used as an indication of protocol completion:

a) Section 2.2 of RFC 3748 says https://tools.ietf.org/html/rfc3748#section-2.2:

   EAP packets with Codes of Success or Failure do not include a Type
   field, and are not delivered to an EAP method.

What this means is that the EAP-Success is delivered to EAP (the framework) and not to EAP-TLS (the authentication method/protocol). Thus, EAP methods cannot rely on EAP-Success or EAP-Failure as an indication of anything since they never receive that message.

b) Section 3.1 (https://tools.ietf.org/html/rfc3748#section-3.1)  and 4.2 (https://tools.ietf.org/html/rfc3748#section-4.2) of RFC 3748 says:

   Note that EAP Success and Failure packets are not retransmitted.
   Without a reliable lower layer, and with a non-negligible error rate,
   these packets can be lost

   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.

The knee-jerk reaction would be that EAP is bad and it should be fixed/updated. I have myself wondered if we can add some payload to the EAP-Success message. But EAP has been around for over a decade now and is used in many networks so the threshold for change is naturally high.

I also think that this should not be treated as an issue for EAP-TLS only. I can imagine other deployments which use TLS for making authorization decisions but do not use the TLS for sending message. So I am glad that Ben has brought this to the TLS working group for further discussion. Whether we use this 1-byte of application data (as done in this draft) or some other mechanism (such as close_notify), we need a reliable way of telling that no further post handshake messages will be sent.

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Mon, 4 Jan 2021 09:08:07 -0500

> The other thing I observe is the way that this slices up the exporter output.  This was something that old versions of TLS did, but TLS 1.3 did away with.  Though RFC 5216 did this, EAP-TLS for TLS…

  That's easy enough to change at this state.  The question is what are those labels?

  And, we're getting very close to needing an implementation soon.  RFC 8446 is over two years old.  Web services have started serious migration to TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that this is an issue.

  At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the major EAP peer / server implementations.  This code is alpha, and not in any major release.  But we need to decide fairly soon what we're doing, as testing and releases take time.

  The alternative is to dither around for another year or two, all the while relying on legacy TLS versions for 802.1X / WiFi authentication.  i.e. packets which are trivially monitored by anyone with a WiFi card.

> I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the sl…

  If EAP-TLS was the only TLS-based EAP method, I would agree with you.  But it's not.  Historically, each TLS-based EAP method uses it's own key derivations, using method-specific strings.  This practice made implementations more difficult and error-prone.

  The use of 0x0D is to allow standard key derivations across TLS-based EAP methods.  The other methods replaced the 0x0D byte with their own EAP type value.  This practice greatly simplifies implementations.

  See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more information.

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jan 2021 06:40:46 -0800

>   That's easy enough to change at this state.  The question is what are

They're just strings, so as long as they don't conflict, it's largely up to
the EAP WG.

-Ekr

  The alternative is to dither around for another year or two, all the
> while relying on legacy TLS versions for 802.1X / WiFi authentication.
> i.e. packets which are trivially monitored by anyone with a WiFi card.
>
> > I appreciate that this uses exporters now rather than abusing the
> internal PRF.  That's good.  The next step is to dispense with the
> intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that
> occurs and use the TLS exporter for each of the six values that the
> protocol requires.  I also note that the 0x0D value is used multiple times,
>   If EAP-TLS was the only TLS-based EAP method, I would agree with you.
> But it's not.  Historically, each TLS-based EAP method uses it's own key
> derivations, using method-specific strings.  This practice made
> implementations more difficult and error-prone.
>
>   The use of 0x0D is to allow standard key derivations across TLS-based
> EAP methods.  The other methods replaced the 0x0D byte with their own EAP
> type value.  This practice greatly simplifies implementations.
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 4 Jan 2021 11:12:35 -0500

On Jan 4, 2021, at 9:40 AM, Eric Rescorla <[email-masked]> wrote:
> They're just strings, so as long as they don't conflict, it's largely up to the EAP WG.

  My point was more that we cannot afford to wait another year or two to pick these labels.  This work is becoming timely, and there is no reason to delay it any more.

  Alan DeKok.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Jan 2021 10:26:40 +1100

On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote:
> Alan Dekok explained in a separate email thread why this is not the 
> case 
> (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). He wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  i.e. they are 4-bytes of data which can be spoofed rather trivially.". 

I specifically addressed that point in my original email.  My assertion was that this is not an significant concern.

Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 and while it says "A peer MUST allow for this circumstance as described in this note.", I see no explanation of how to concretely make that allowance.  Are you saying that EAP methods don't really use EAP-Success and condition their behaviour on other signals?  For TLS 1.3, where the server indicates success before the client, I can see how you might want a reliable confirmation that the server has accepted the client Finished.

As an aside, this makes is clear that the signal does not exist for the reason implied by the draft.  It does not exist to signal that the TLS messages are done; it exists to signal that the server has received and accepted the client Finished.  To that end, it's not really a layering violation in the sense that Ben describes.  The layering violation exists only because of the language constraining what TLS does thereafter; in that case, a language cleanup might be enough to address the concerns.

Note however, that the proposed design does not guarantee that a Confirmation Message acknowledges the client Finished.  The server can send the proposed Confirmation Message before the client completes the handshake.  

Echoing the client Finished might help, but that's a layering violation too.  Ideally you would be able use something like exporters to help, but those have problems (see below).  I know it's a knee-jerk, but the idea of making EAP-Success reliable is far more appealing to me than anything you suggest.
 
> I also think that this should not be treated as an issue for EAP-TLS 
> only. I can imagine other deployments which use TLS for making 
> authorization decisions but do not use the TLS for sending message. So 
> I am glad that Ben has brought this to the TLS working group for 
> further discussion. Whether we use this 1-byte of application data (as 
> done in this draft) or some other mechanism (such as close_notify), we 
> need a reliable way of telling that no further post handshake messages 
> will be sent. 

EAP has the privilege of being the first to grapple with this.

I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not the ideal design.  They should have included the full handshake transcript, just like the resumption secret.  There were good reasons at the time for designing them as they are, and there are likely reasons to retain the current design as an option (it's stronger than the early exporter and there might be use cases), but those original reasons are less relevant.  The current design gives short shrift to client authentication, to the detriment of use cases like EAP.

Having exporters depend on the entire transcript would serve EAP better.  In this case, you could provide an application-level signal using an exported value.

Without that sort of in-TLS affordance, confirming receipt of the client Finished might do.  You still have the possibility that the server doesn't depend on client authentication and so predicts the value, but that would be true of a full-transcript exporter too, so arguably that doesn't matter.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 4 Jan 2021 22:05:44 -0500

On Jan 4, 2021, at 6:26 PM, Martin Thomson <[email-masked]> wrote:
> Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 and while it says "A peer MUST allow for this circumstance as described in this note.", I see no explanation of how to concretely make that allowance.  Are you saying that EAP methods don't really use EAP-Success and condition their behaviour on other signals?

  EAP-Success by itself is *not* a reliable indication of Success.  See RFC 3748 Section 4.2:

   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.

  With TLS 1.3, we don't know if the authentication has completed until the TLS layer sees either (a) CloseNotify, or (b) application data.  So the EAP-TLS implementations cannot distinguish a "finished authentication" EAP-Success from a "spoofed" EAP-Success.  Because the EAP-TLS implementation has no idea of TLS is done, and therefore no way to tell that the EAP-Success is permitted at this point in the negotiation.

  Therefore, we need an explicit signal to the EAP-TLS layer that the EAP-TLS method has finished.  Discussion on the list went back and forth between CloseNotify and sending one octet of application data.  Implementations have done both.  The conclusion was that the one octet of application data was slightly easier to implement.

  Plus, sending CloseNotify precluded the TLS layer from sending a TLS Fatal Alert:  https://www.mail-archive.com/[email-masked]/msg03092.html, which says in part:

...
If the Commitment Message is changed to close_notify, the TLS Fatal Alert would 
have to be changed to an EAP-Failure instead. The difference is that The TLS 
Fatal Alert can contain information such as 

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc. while EAP-Failure must not contain any additional data.
...

  As someone who supports end users, I am very opposed to removing this information.  802.1X authentication is hard enough to deploy correctly as it is.  If we require the use of CloseNotify for EAP-TLS and TLS 1.3, then a whole host of useful error messages just go away.  Errors which are used to debug real-world certificate compatibility issues.

  I can't think of many things worse for EAP-TLS than to replace a set of descriptive messages with a simple "Failed".  Was your certificate revoked?  Failed.  Was it expired?  Failed.  Was the CA known?  Failed.  What went wrong?  Too bad for you, the only message you get is "Failed".

  End users and sysadmins will be cursing the standard for years.  And, trying to stick with something *useful*, such as TLS 1.2.

  My $0.02 is that the one byte of application data is less "pure" than a solution which relies on TLS negotiation.  But if using CloseNotify makes deployments substantially more difficult, then that is a very strong reason to avoid it.

  Alan DeKok.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Jan 2021 14:50:15 +1100

Hi Alan,

>    the method to finish at that point.

This is fine.  What you might be concerned about is the nature of the signals that the EAP authenticator is receiving from TLS.  What you had in the case of TLS 1.2 was the stack providing bytes to send (which were to go in EAP-Request) and then, after everything is done, a positive signal saying that the handshake was complete and satisfactory.  That latter signal is the important one.

TLS 1.3 muddies things by allowing bytes to be sent *after* the complete+satisfactory signal from TLS.  That's what you are grappling with here.  What I'm suggesting is that you don't rely on looking at what bytes hit the wire, but wait until two conditions are complete:

1. The TLS stack says that it is content: the handshake is complete and it is OK with whatever the other side has provided.
2. The TLS stack has no more bytes to send.

The latter is likely where the confusion comes from, but if the stack doesn't produce bytes when you give it bytes, then you don't need to keep waiting.  For what you depend on, that's enough.

The mistake with sending application data is that there is no obligation on the part of the TLS stack to order its sending of NewSessionTicket relative to the application data.  Nor is is possible for you to correctly distinguish TLS data that contains your Confirmation Message from a record that just contains a little bit of a session ticket.  But you don't need to worry about that.

An example might help illustrate:

1. ... many steps occur
2. Client sends EAP-Response ending in a TLS Finished.
3. Server reads that message, processes it and determines that the handshake is complete and acceptable (e.g., checks the client certificate against its policy).
4. As the server is happy, it writes the Confirmation Message to TLS.
5. Server asks TLS stack for outstanding data to write; TLS stack provides a bunch of application_data records.
6. Server writes TLS records into an EAP-Request and sends it.
7. Client receives this and sends an empty EAP-Response.
8. Server sends EAP-Success.

This is, I assume what you intend here, with a little more detail around steps 3-5.  But what happens if the TLS stack prioritizes application data above its own maintenance such that at step 5 the Confirmation Message is written to the wire before the TLS NewSessionTicket?  Is that a problem?  What validation is the client expected to perform at step 7?

>   With TLS 1.3, we don't know if the authentication has completed until 
> the TLS layer sees either (a) CloseNotify, or (b) application data.  So 
> the EAP-TLS implementations cannot distinguish a "finished 
> authentication" EAP-Success from a "spoofed" EAP-Success.  Because the 
> EAP-TLS implementation has no idea of TLS is done, and therefore no way 
> to tell that the EAP-Success is permitted at this point in the 
> negotiation.

As I indicated in my response to Mohit, if the intent is to provide the client with a signal, then using TLS application data to do that is imperfect, but probably OK.  What would have been ideal is some EAP-layer message that is authenticated somehow.

>   Therefore, we need an explicit signal to the EAP-TLS layer that the 
> EAP-TLS method has finished.  Discussion on the list went back and 
> forth between CloseNotify and sending one octet of application data.  
> Implementations have done both.  The conclusion was that the one octet 
> of application data was slightly easier to implement.
> 
>   Plus, sending CloseNotify precluded the TLS layer from sending a TLS 
> Fatal Alert:  https://www.mail-archive.com/[email-masked]/msg03092.html, 
> which says in part:

I agree that sending a close_notify alert isn't ideal - during this process.  I also agree that making sure that genuine handshake failures are reported reliably using EAP-Request, that's just plain good sense.

I don't understand why you would want to send a fatal alert after successfully completing and accepting the handshake, but if that is something you care about, then that clearly rules out its use for signaling success.  I didn't suggest that.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jan 2021 21:26:40 -0800

Hi Martin,

Thanks for chiming in here; your insight has been quite helpful already.
(I am going to reply to the thread in reverse order so as to not duplicate
what you've already said.)

> This is fine.  What you might be concerned about is the nature of the signals that the EAP authenticator is receiving from TLS.  What you had in the case of TLS 1.2 was the stack providing bytes to…

Yes.  Part of what had me so unhappy about this document is that the
Commitment Message is discussed only as a "promise to not send more
handshake messages", not "an indication that the handshake is complete and
the TLS layer is happy".  (Furthermore, what Alan writes below about
"cannot distinguish a "finished authentication" EAP-Success from a
"spoofed" EAP-Success" really needs to make its way into the document.)

> The latter is likely where the confusion comes from, but if the stack doesn't produce bytes when you give it bytes, then you don't need to keep waiting.  For what you depend on, that's enough.

I agree that this is probably good enough.  There may be some complications
depending on how badly the availability of session resumption is desired (I
know OpenSSL provides an API to let the application requst a new session
ticket regardless of whether any were sent with the initial handshake -- I
wrote it -- though I need to tweak it so that it will not always wait for
application data to send before sending the ticket), but I believe this
provides the key functionality.

> 5. Server asks TLS stack for outstanding data to write; TLS stack provides a bunch of application_data records.

(In particular, this is the TLSCiphext content type that is
"application_data", and the inner content type could be handshake or
application data.  The application doesn't have visibility into it.)

> This is, I assume what you intend here, with a little more detail around steps 3-5.  But what happens if the TLS stack prioritizes application data above its own maintenance such that at step 5 the…

I would like to see a more precise description of what properties are
actually needed by peer and responder here, yes.  I agree that TLS 1.3 has
changed things compared to 1.2, but the text currently in the draft doesn't
do very well to motivate why this information is important, and (at least
to me) doesn't give a strong enough justification to merit the awkwardness
of the proposed design.

> I don't understand why you would want to send a fatal alert after successfully completing and accepting the handshake, but if that is something you care about, then that clearly rules out its use f…

This somewhat gets into another point that I was hoping would be discussed
more.  (The proposal for "close_notify" came up as the in-TLS way to
signify "no more records coming", which includes "no more handshake records
coming".)  The perceived issue with "close_notify" as the commitment
message, clearly discussed in the linked message, is that "close_notify" is
unsuitable as a commitment message when being sent in the same flight as
server Finished.  What is very unclear to me is how often that state could
actually be achievable.  For one, if we do move (per the previous
discussion) to the state where the "TLS is done" signal is something like
"TLS says it's done and has no more bytes to send", this situation *by
definition* cannot occur, since TLS will not report the handshake as
complete until client Finished is processed.  Even if we ignore that,
though, we have to consider the interaction between resumption and client
authentication.

My understanding is that EAP is primarily used as a mutual authentication
protocol, i.e., the client has a certificate it's going to use to
authenticate, and the EAP Peer's identity is the identity from that
certificate.  The desire to send the commitment message in the same flight
as the server Finished stems from the desire to avoid another round-trip.
But using TLS resumption will *also* save round trips, and in these
pessimal cases where the certificate chains are huge, resumption will save
a lot more than one round-trip.  But, if you send the commitment message
with the server Finished, you can't send a NewSessionTicket that includes
the client certification information at all.  So by gaining the 1 RTT from
moving up the commitment message, you sacrifice a lot more RTTs by losing
resumption.  Given my priors about how this is going to be used, that seems
like a lousy tradeoff.  I'm happy to hear that I'm making invalid
assumptions here, but it seems like you would only be able to take
advantage of that 1 RTT gain from the commitment message for the case of
unauthenticated clients, in expected deployments, and unauthenticated
clients seem to be rare.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jan 2021 21:32:27 -0800

> I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not the ideal design.  They should have included the full handshake transcript, just like the resumption secret.  There wer…

I was just grappling with this topic recently in a different context.  I
agree that it would be good to have at least some version of an exporter
available that includes the full transcript's hash in the context.  It
seems to have made some implicit assumptions about how TLS is used (to
carry application data, not as a key-exchange or authentication mechanism)
and how TLS records are carried (over TCP, which serializes handshake
messages and application data; not the case for QUIC) that are causing
problems for us now.

That said, it doesn't seem like it would be *terribly* complicated to
specify a new type of exporter interface that does use the full transcript.
It might have to be TLS 1.3+ only, and getting the IANA considerations
right might be gnarly, but the core of it seems pretty simple.

> Without that sort of in-TLS affordance, confirming receipt of the client Finished might do.  You still have the possibility that the server doesn't depend on client authentication and so predicts t…

If there truly is a need for a signal from TLS to not generate more
handshake messages (including to tear down the connection if KeyUpdate
would be needed), that seems like it is arguing for a new TLS handshake
message.  I am not 100% sure whether those semantics are needed for the
EAP-TLS case, but they might be needed elsewhere, as Mohit notes.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jan 2021 21:43:51 -0800

> I would instead either prohibit the use of application data outright or say that it carries no semantics unless otherwise negotiated.  The current design has the effect of rendering application dat…

The "rendering application data unusable" bit is something that bothered me
a lot as well.  While banning application data is okay for EAP-TLS itself
(AIUI), the document implies that other TLS-based EAP mechanisms do need to
convey application data, and I think that the responsible thing to do is
ensure that the machinery we use here would be compatible with those other
EAP mechanisms with no, or only minimal, changes.

> I appreciate that this uses exporters now rather than abusing the internal PRF.  That's good.  The next step is to dispense with the intermediate values (Key_Material, MSK, EMSK, IV) and all the sl…

I think Alan explained the dual purpose of the Type-Code here.  (I myself
had missed the connection of where the 0x0d value came from, and a
reference for that seems like it would be helpful, as setting up this
machinery for reuse by other mechanisms in a way that provides key
separation.)

-Ben

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 4 Jan 2021 22:44:42 -0800

>   That's easy enough to change at this state.  The question is what are

  And, we're getting very close to needing an implementation soon.  RFC
> 8446 is over two years old.  Web services have started serious migration to
> TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that
> this is an issue.
>
>   At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with
> the major EAP peer / server implementations.  This code is alpha, and not
> in any major release.  But we need to decide fairly soon what we're doing,
> as testing and releases take time.
>

[Joe] It may be worth having separate exporter tags for EMSK and MSK.
(EXPORTER_EAP_TLS_MSK
and EXPORTER_EAP_TLS_EMSK).   I believe current applications define the use
EAP key material based on the MSK or EMSK.   The mechanism for splitting
the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in
specific legacy cases (WEP, MPPE?) and may still be the radius attributes
used in some deployments, so I don't think we should alter that
derivation.   I'm not sure where the IV is used, but I don't think
splitting it up more will be helpful.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Jan 2021 09:47:24 +0000

Hi again,

The following issues are related but not exactly the same:
1. indication from the server that the handshake is complete and it is 
okay to tear down the tunnel
2. indication from the server that no more post-handshake messages 
(containing NewSessionTicket or something else) will be sent.

We can't rely on EAP-Success as an indication of either since that 
message is never delivered to EAP-TLS and it maybe lost or spoofed. 
Ben's discuss arises from 2 and not 1. More at the end of the email.

> unauthenticated clients, in expected deployments, and unauthenticated
In figure 1 of the current EAP-TLS draft: 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13#section-2.1.1, 
the server already announces its intent of not issuing NewSessionTicket 
before receiving the client certificate (potentially saving one round 
trip). In figure 2: 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13#section-2.1.2, 
this is done after receiving the client certificate (causing one extra 
round trip but at the same time helping with resumption).

What I am gathering is that this commitment message should instead be 
made into a confirmation message, i.e. it should only be sent after 
receiving TLS Finished from the client? This would result in one extra 
round trip to both figure 1 and 3 in the current draft. So we would end 
up with the same number of messages as RFC 5216 for full authentication 
(https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do 
worse than RFC 5216 (one extra round trip) in case resumption 
(https://tools.ietf.org/html/rfc5216#section-2.1.2).

Maybe this is acceptable? The draft anyway notes that "Sending the 
Commitment Message in a separate EAP-Request adds an additional 
round-trip, but may be necessary in TLS implementations that only 
implement a subset of TLS 1.3.". In which case, I am not sure if the 
reasons against using close_notify apply anymore.

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Jan 2021 15:05:23 +0000

Hi Joe,

On 1/5/21 8:44 AM, Joseph Salowey wrote:

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:

[Joe] It may be worth having separate exporter tags for EMSK and MSK.  (EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK).   I believe current applications define the use EAP key material based on the MSK or EMSK.   The mechanism for splitting the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy cases (WEP, MPPE?) and may still be the radius attributes used in some deployments, so I don't think we should alter that derivation.   I'm not sure where the IV is used, but I don't think splitting it up more will be helpful.

This sounds reasonable. I was initially hesitant to change because we have working implementations. But after a brief glance at the current hostap implementation: https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am convinced that using separate labels for MSK and EMSK is better. The current implementation seems incorrect.

About the IV: RFC 5247 (published after RFC 5216) says the following (https://tools.ietf.org/html/rfc5247#section-1.2):

As a result, its use has been deprecated and it is
      OPTIONAL for EAP methods to generate it.  However, when it is
      generated, it MUST be unpredictable.

Should we still export it in EAP-TLS with TLS 1.3?

And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in hostap/freeradius implementations. It could be that they are still used by Microsoft but I am unsure?

--Mohit

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Jan 2021 10:32:38 -0500

On Jan 5, 2021, at 10:05 AM, Mohit Sethi M <[email-masked]> wrote:
> This sounds reasonable. I was initially hesitant to change because we have working implementations.

  Nothing has been published in an official release.  So we have some time.

  But I'm at the point now where I'd like to release the next version of FreeRADIUS.  We've implemented the current draft.  If there's still uncertainty, then I will disable TLS 1.3 support before the release.  It's better to forbid something than to do it wrong.

> But after a brief glance at the current hostap implementation: https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am convinced that using separate labels for MSK and EMSK is better. The current implementation seems incorrect. 

  IIRC hostap has EAP-TLS working for TLS 1.3.  The PEAP and TTLS patches have not yet been merged.

> Should we still export it in EAP-TLS with TLS 1.3?

  I don't recall any uses of it.  

> And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in hostap/freeradius implementations. It could b…

   I'm not sure what is meant by Enc-SEND-Key.    RFC 2548 Section 2.4.2 defines MS-MPPE-Send-Key.  That and MS-MPPE-Recv-Key are used everywhere in WiFi.  FreeRADIUS and hostap both export and use these fields.

  Removing MS-MPPE-Send-Key and/or MS-MPPE-Recv-Key will destroy global WiFi.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Jan 2021 10:41:50 -0500

> (https://tools.ietf.org/html/rfc5216#section-2.1.2).

  That sounds right.

> reasons against using close_notify apply anymore.

  I won't offer opinions on TLS internals, as I'm out of my depth there.

  As an implementor, the priority is getting TLS alerts (expired cert, etc.) back from the EAP server to the EAP peer.  Those messages can then be used to debug deployment issues.

  The exact method of doing this is less important.  The "0x00" octet works now, so I'm happy with it.  But if TLS review decides that should change, that's fine, too.

  Alan DeKok.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 15:42:40 +0000

Since there was a question upthread about what the exporter tags should be; the draft picks them and sends email to [email-masked]<mailto:[email-masked]> requesting them.  See https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels  Pretty easy.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Jan 2021 11:05:46 -0500

> Therefore, we need an explicit signal to the EAP-TLS layer that the

Do you mean, "to the EAP layer"?
s/EAP-TLS layer/EAP/ ??

    > EAP-TLS method has finished.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Jan 2021 11:12:21 -0500

> Do you mean, "to the EAP layer"?

  If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS layer needs to have a way to say "we're done, EAP-Success is now OK".

  It's really nested:  EAP ( EAP-TLS ( TLS ) ) 

  We can't finish EAP until we know that EAP-TLS is finished.  We can't finish EAP-TLS until we know that TLS is finished.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Jan 2021 16:13:56 +0000

Hi Alan,

Cleaning up the email. The current draft says the exporter should be called once as:

   Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
                               Type-Code, 128)

and then split the 128 into MSK (64) and EMSK (64). As said, from initial glance, it seems the exporter is called twice (once in eap_tls_get_emsk and once in eap_tls_getKey). Both the calls are with exactly the same context, context length, and labels. In getKey, the EMSK parts are cleared with

os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);

while in get_emsk, they are read with

                os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
                                  EAP_EMSK_LEN);

Maybe we can live with this. But if exporter is called twice, we should use different labels as suggested by Martin?

Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I was thrown off by Joe's comment "The mechanism for splitting the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy cases (WEP, MPPE?)" and the fact that other EAP methods only export MSK. Other EAP methods leave it to the AAA architecture for splitting up the MSK. Why should EAP-TLS be different?

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Jan 2021 11:29:18 -0500

> Maybe we can live with this. But if exporter is called twice, we should use different labels as suggested by Martin?

  Yes.

  Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK, which seem simple enough.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 5 Jan 2021 08:46:49 -0800

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> and then split the 128 into MSK (64) and EMSK (64). As said, from initial
> glance, it seems the exporter is called twice (once in eap_tls_get_emsk and
> once in eap_tls_getKey). Both the calls are with exactly the same context,
> context length, and labels. In getKey, the EMSK parts are cleared with
>
> Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
> Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I
> was thrown off by Joe's comment "The mechanism for splitting the MSK into
> Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy
> cases (WEP, MPPE?)" and the fact that other EAP methods only export MSK.
> Other EAP methods leave it to the AAA architecture for splitting up the
> MSK. Why should EAP-TLS be different?
>
[Joe] EAP TLS was defined before the keying framework so it
explicitly called out those keys.  Originally, there were RADIUS attributes
for carrying send key and receive key material defined for MPPE.  These
were reused to carry key material when WEP was integrated with 802.1x/EAP.
 With 802.11i and the EAP revision things were made more formal and the MSK
was defined, but the same RADIUS attributes were used for key transport.
Essentially, 802.11i takes the First half of the MSK and uses it as the PMK
for the 4-way handshake, this is transported to the authenticator in the
ms-mppe-recv-key attribute.   The second half of the key is sent in the
ms-mppe-send-key attribute and may be used by some other IEEE
specifications.   Newer attributes have been developed for key transport in
RADIUS over the years.  I don't know their adoption rate at this
point.  THe EMSK was developed as a key that was shared between the AAA
(EAP Server) and supplicant (EAP-Peer) that is not known to the
EAP-Authenticator.   We could leave the definition of how to derive the
receive and send keys from the MSK in the EAP-TLS spec and reference it
from this one.  Or we could just include it.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Jan 2021 09:53:32 -0800

>   We can't finish EAP until we know that EAP-TLS is finished.  We can't finish EAP-TLS until we know that TLS is finished.

Okay.  What step suffices to determine that "TLS is finished" for your use
case.  The natural definition is "the handshake is complete", which would
be incompatible with the text currently in the draft (and with 0.5-RTT
entirely).

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Jan 2021 19:52:28 -0500

pedantically, because I think that there is much confusion here.
Let me go back to the whole sentence:

Alan>  Therefore, we need an explicit signal to the EAP-TLS layer that the
Alan>  EAP-TLS method has finished.  Discussion on the list went back and
Alan>  forth between CloseNotify and sending one octet of application data.
Alan>  Implementations have done both.  The conclusion was that the one octet
Alan>  of application data was slightly easier to implement.

    > If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's
    > possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS
    > layer needs to have a way to say "we're done, EAP-Success is now OK".

    > It's really nested:  EAP ( EAP-TLS ( TLS ) )

Okay, so I think that we need:
      1) signal from the TLS layer to EAP-TLS layer
      2) signal from the EAP-TLS layer to the EAP layer

But, you said, above:

     "to the EAP-TLS layer that the EAP-TLS method has finished"

so I still think that there might be a typo :-)

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 5 Jan 2021 22:24:02 -0800

On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok <[email-masked]> wrote:

> > and then split the 128 into MSK (64) and EMSK (64). As said, from
> initial glance, it seems the exporter is called twice (once in
> eap_tls_get_emsk and once in eap_tls_getKey). Both the calls are with
> exactly the same context, context length, and labels. In getKey, the EMSK
> parts are cleared with
>   Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and
> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>
> [Joe] I created a pull request (
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
proposed labels.  Is this change going to cause significant problems for
implementation?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 6 Jan 2021 09:47:14 -0500

On Jan 6, 2021, at 1:24 AM, Joseph Salowey <[email-masked]> wrote:
> [Joe] I created a pull request (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the proposed labels.  Is this change going to cause significant problems for implementation? 

  After making this change:

$ git diff src/modules/rlm_eap/ | wc -l
      89

  It's fine.

   Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Jan 2021 23:21:20 -0800

> > receiving TLS Finished from the client? This would result in one extra 

I forget if it has been explicitly mentioned in the thread so far, but
https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
"Servers MAY send data after sending their first flight, but because the
handshake is not yet complete, they have no assurance of either the peer's
identity or its liveness (i.e., the ClientHello might have been replayed)."
In particular, "no assurance of the peer's identity" means that the server
is at this point sending to an unauthenticated client.  If the goal of
EAP-TLS is to ascertain that there is in fact an authenticated client, it
may be ill-advised to send indications of overall success to an
unauthenticated client.  Part of what Martin alluded to with the situation
being lousy overall is that there are basically two things that can
cryptographically confirm that the client has authenticated: successful
processing of the client Finished, and values derived from the resumption
master secret.  In "normal" TLS usage the server will bail out if the
client Finished doesn't validate, so continued receipt of application data,
including application data bearing application-protocol responses to data
the client sent in 1-RTT after client Finished, effectively implies that
the server validated the client Finished, but the EAP-TLS usage is quite
different from that.  There's not a cryptographic way to tell whether 0x00
application data was generated before or after the client Finished was
processed.

> > (https://tools.ietf.org/html/rfc5216#section-2.1.2).

While counting arrows in the diagram like this is definitely useful, part
of my concerns related to the need (in non-resumption flows) to convey the
entire (enlarged) server Certificate chain in individual 1020-byte
EAP-Requests.  My understanding was that the server had to send a single
1020-byte EAP-Request and wait for the corresponding EAP-Response before
sending the next chunk of the certificate chain.  It was in that scenario
that I expected a substantial difference between resumption and
non-resumption.

>   The exact method of doing this is less important.  The "0x00" octet works now, so I'm happy with it.  But if TLS review decides that should change, that's fine, too.

It's pretty much guaranteed that we can get the TLS alerts if we always
wait for client Finished to be processed (whatever signal we end up
choosing to send after that occurs).  Have we reached agreement on whether
we should always wait for client Finished?

-Ben

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 08 Jan 2021 09:41:25 +1100

Hi Joe,

Thanks for doing this, I think that this is a distinct improvement (and I will take your word for the difficulties involved with further splits).

One point that I made poorly perhaps, and was dismissed, might be worth restating:

MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64) 

The inclusion of a type code as context is, I believe, a misuse of the field.  As this is a fixed value, the value is being used for domain separation.  However, that is the function of the exporter label input.  The label exists to establish that this is EAP-TLS and the key is (in this case) MSK.  If you need different derivations for different type codes, I strongly suggest that this be included in the label.

The Context input exists to pull in variables from the context that endpoints might need to agree on.  It is not for domain separation.  For example, if you thought it necessary to authenticate the Identity values that client and server exchange, you might add those to this field.  (As an aside, you might want to consider that as their value could be used to determine what parameters to feed into the TLS handshake.)

If, however, you have an adjacent usage of EAP that wants its own MSK, then that is domain separation.  The right thing to do would be to create new labels for that usage.

This might be a fine point in light of the fact that these all just get fed into HKDF, but I think that it is important to respect the purpose for which these inputs were designed.

Cheers,
Martin

On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
> [Joe] I created a pull request 
> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the 
> proposed labels.  Is this change going to cause significant problems 
> for implementation? 
>  
> >   Alan DeKok.
> >

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 8 Jan 2021 07:54:24 +0000

Hi Martin,

Thanks for pointing this out. I think Ben also mentioned this in his 
review. I am not sure if it is necessary to add the type-code to the 
label when it is already part of the label string as 'EAP_TLS'. Other 
TLS based EAP methods should ideally register labels of the form 
EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the 
EAP-TLS label) as is currently done in 
https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.

I do agree with your point about the incorrect usage of the context. 
Perhaps the ideal choice here would be Server-Id and Peer-Id (if client 
certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. 
However, I checked the wpa_supplicant implementation and currently these 
values are not available. As far as I can tell, the Server-Id and 
Peer-Id are not exported for any EAP method. So we'll need to think 
what's the right thing to do: update implementation/use some other 
sensible value/or leave the context empty (which is allowed in RFC 5705).

--Mohit

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 8 Jan 2021 08:16:21 +0000

Hi Ben,

> application data was generated before or after the client Finished was
Yes, this was discussed. See email from Hannes 
(https://mailarchive.ietf.org/arch/msg/emu/Vf4Zor-xIDVZLQB-BE9mPvlDZMM/) 
where we did look at the text from RFC 8446 about the peer being 
unauthenticated. It was (at that time) accepted since the server was 
only committing to not sending more post-handshake messages (rather than 
indicating successful completion of handshake).
> we should always wait for client Finished?

I hope so. I'll try to submit an update next week.

--Mohit

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 08 Jan 2021 19:25:00 +1100

> https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.

Sounds good to me.

> certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. 

Maybe, as I said, it depends.

> sensible value/or leave the context empty (which is allowed in RFC 5705).

This suggests that the values aren't critical to any decision making process made by either peer and maybe you don't need to include them.  I would check a little more thoroughly though.  One implementation not using them isn't strong enough evidence that they aren't used at all.  If those identifiers determine what certificate is selected, or anything like that, then it would be good to ensure that peers agree on what they were.  That might mean making them available in implementations that did not previously use them.  On the other hand, if they are always going to be anonymous identifiers that have no bearing on the TLS operation, don't worry about it and use the empty string.

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 8 Jan 2021 08:44:15 +0000

Hi Martin,

Thanks for the quick response.

> This suggests that the values aren't critical to any decision making process made by either peer and maybe you don't need to include them.  I would check a little more thoroughly though.  One imple…

These values are critical for making authorization decisions about 
network access. It is more a question of where these values are 
available, exported, and used for decision making in implementations. 
Thank you for nudging us in the right direction. :)

--Mohit

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 10 Jan 2021 22:07:27 -0800

On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson <[email-masked]> wrote:

> Hi Joe,
>
> Thanks for doing this, I think that this is a distinct improvement (and I
> will take your word for the difficulties involved with further splits).
>
[Joe] I think you propose something like this instead (eliminating context):

MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64)

Where + is concatenation and ASCII-Type-Code is "13"

the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13

> The inclusion of a type code as context is, I believe, a misuse of the
> field.  As this is a fixed value, the value is being used for domain
> separation.  However, that is the function of the exporter label input.
> The label exists to establish that this is EAP-TLS and the key is (in this
> case) MSK.  If you need different derivations for different type codes, I
> strongly suggest that this be included in the label.
>
> The Context input exists to pull in variables from the context that
> endpoints might need to agree on.  It is not for domain separation.  For
> example, if you thought it necessary to authenticate the Identity values
> that client and server exchange, you might add those to this field.  (As an
> aside, you might want to consider that as their value could be used to
> determine what parameters to feed into the TLS handshake.)
>
> If, however, you have an adjacent usage of EAP that wants its own MSK,
> then that is domain separation.  The right thing to do would be to create
> new labels for that usage.
>
> This might be a fine point in light of the fact that these all just get
> fed into HKDF, but I think that it is important to respect the purpose for
> which these inputs were designed.
>
>
[Joe] I see your point that we should eliminate the context and include the
type code in the label as it will always be the same for EAP-TLS (which
also goes to the point that has been made by several people that this value
may be redundant since we would expect another EAP type to use a different
label).  In the past, people have used TLS in all sorts of innovative and
unique ways in different EAP methods all loosely based on EAP-TLS.  I don't
see this usage as too far outside the intended use of the context field
(the value should match on both sides) and I think including the type value
in the context value would help avoid some potential implementation
problems if the key derivation is reused for another method.

Cheers,
> > > > Maybe we can live with this. But if exporter is called twice, we
> should use different labels as suggested by Martin?
> > >
> > >   Yes.
> > >

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Jan 2021 08:28:11 -0500

> the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13

  That's fine, but I have a minor forward-looking comment based on other EAP types.  They'll have to do similar things.  This is OK for 8-bit EAP types.  This is more complex for the "extended" EAP types.

  For simplicity, I would suggest that the ASCII type code is represented as hex, instead of decimal.  This makes implementations simpler.  They can just hex-ify whatever EAP thing they have (8 bits, or more for extended types), and then append that to the "EXPORTER_EAP_TLS_MSK" string.

  Decimal is just ugly for computers to deal with. :)

> [Joe] I see your point that we should eliminate the context and include the type code in the label as it will always be the same for EAP-TLS (which also goes to the point that has been made by several people that this value may be redundant since we would expect another EAP type to use a different label).  In the past, people have used TLS in all sorts of innovative and unique ways in different EAP methods all loosely based on EAP-TLS.  I don't see this usage as too far outside the intended use of the context field (the value should match on both sides) and I think including the type value in the context value would help avoid some potential implementation problems if the key derivation is reused for another method.  

  I agree here.  I think it's simpler conceptually, for implementations, and there's less for IANA to deal with.

 But maybe the TLS people have a strong opposition to using the context in this way.  In that case, it's ugly, more work for everyone, but still possible to just append the hexified EAP type code to the label.

  Alan DeKok.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 12 Jan 2021 11:08:45 +1100

> Where + is concatenation and ASCII-Type-Code is "13"

I was not exactly.  I was thinking that EAP-TLS uses the unadorned string and other usages (that need a different MSK) define their own string as needed.  Though what you describe would scale more, if the ordinality of that scale is bounded by RFC numbers, defining the extra strings would not be that hard.  You could provide some sort of infrastructure in the form of a recommended label prefix if you are concerned about misuse.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Jan 2021 10:22:04 -0500

On Jan 11, 2021, at 7:08 PM, Martin Thomson <[email-masked]> wrote:
> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string and other usages (that need a different MSK) define their own string as needed.

  Which is largely what was done for <= TLS 1.2.

  That choice made implementations more difficult.  Not impossible, but annoying.  The other TLS-based EAP types are generally implemented as variants of EAP-TLS.  They re-use much of the EAP-TLS code.  So every difference is more code, and more things to test.

>  Though what you describe would scale more, if the ordinality of that scale is bounded by RFC numbers, defining the extra strings would not be that hard.  You could provide some sort of infrastructure in the form of a recommended label prefix if you are concerned about misuse.

  I'm not sure EAP-TLS is the place to make recommendations for other EAP types.  There is a draft to deal with other EAP types:

https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00

  It's pretty trivial.  Adding more complexity is annoying, but not much worse than that.

  My preference is to remain with the EAP type as the context.  The code is simple, and it's easy to understand.  But if it causes issues with TLS review, we can change it.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 23 Jan 2021 17:28:10 -0500

We're approaching 2 weeks since the last discussion of this topic.  This document has been in development for 3 years.  We desperately need to finish it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

  We have multiple inter-operable implementations which have implemented draft-13.  That work over the last few months have resulted in implementors making plans to do beta testing in the next few weeks.  Those plans have been put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer to have consensus on a *solution*. Right now, we just have a series of proposed changes, with little to no discussion.

  We're getting to the point where we have to ship code as promised to customers soon (weeks, not months).  We therefore need consensus, as soon as possible.

  My preference is to implement draft-13.  We know the code works.  People are ready to ship it.  Any changes will add not just more months of standard discussion, but more months of interoperability testing.

  If there is no progress in EMU, we're looking at September for first betas.  With no guarantee that there won't be further changes made after that.

  So the question is:

* are the draft-13 0x00 byte and exporter *terrible* enough to delay the standard another 6 months?

* if the answer is "no", then we can ship now.

* if the answer is 'yes", then the next question is "when can we get this finalized?"  "March" would be late.  "July" is a major problem.

> On Jan 12, 2021, at 10:22 AM, Alan DeKok <[email-masked]> wrote:
>

---

From: Jorge Vergara <[email-masked]>
Date: Thu, 28 Jan 2021 23:57:19 +0000

I am in favor of sticking to draft-13. There was some discussion about whether draft-13 contained a TLS layering violation, but I believe that discussion concluded that it does not. As noted, discussion has mostly stalled since then with a few additional ideas surfacing that have added round trips. Other threads are now popping up expressing dissatisfaction with the extra round trip.

Alan mentions that betas may be months out for his product line - for Microsoft and Windows, the situation is much tighter. If we cannot reach consensus quickly we will need to push this out of our 2021 release cycle. Seeing as we're sitting on draft-13 with multiple implementations available, I would really prefer to reach consensus to finalize draft-13 and get this into the hands of customers this calendar year.

Jorge Vergara

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Saturday, January 23, 2021 2:28 PM
To: Martin Thomson <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  So the question is:

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-00&amp;data=04%7C01%7Cjovergar%40microsoft.com%7Cb558b067ea62444150d008d8bfee5b6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637470377753309597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eTBptf92iMhYupJv9kRLl%2FzAV75fZXSbDjTI9sKu%2Bvs%3D&amp;reserved=0
> 

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Cjovergar%40microsoft.com%7Cb558b067ea62444150d008d8bfee5b6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637470377753319592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=JQCtoTOMTzouZnJ0ILj%2B8%2BtIpJW8t04HbSlDDGYf8VQ%3D&amp;reserved=0

---

From: John Mattsson <[email-masked]>
Date: Fri, 29 Jan 2021 10:31:19 +0000

Hi,

I can live with any version, the important thing is that interoperable implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

We (the authors) have addressed all the comments from IESG/TLS WG in GitHub.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/tree/master

Text format:

https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

The diff can be found here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This would be ready for submission but I think the Implementors, WGs, Chairs, Shepard, ADs need to agree on the direction before we do that. The two important technical changes from -13 are

(1) Changing key derivation
(2) Changing Commitment message to close_notify

The key derivation changes are good and more modern. I personally like the change but the change but I don't think it is essential and was not done for security reasons.

The close_notity changes are not only positive as it sometimes introduce an additional roundtrip. The Commitment message can according to specification be sent with the server Finish even if some/most/all implementation does not seem to allow this. If the commitment message cannot be send with Finished in practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 and EAP interacts. I am not sure I fully agree with the layer violation argument, my interpretation was that this was information for the EAP state machine which is the application using TLS. Maybe the text regarding the commitment message was badly written and should have talked about the EAP state machine more instead of TLS....

We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward:

A. Add (1) and (2)
B. Only add (1)
C. Only add (2)
D. Do not add (1) or (2)

I assume implementors (Alan, Jorge) are fine with all other changes since -13.

Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as we agree on a way forward we can update and submit a new version within 24 h.

Cheers,
John

-----Original Message-----
From: TLS <[email-masked]> on behalf of Jorge Vergara <jovergar=[email-masked]>
Date: Friday, 29 January 2021 at 00:57
To: Alan DeKok <[email-masked]>, Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Jorge Vergara

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Saturday, January 23, 2021 2:28 PM
To: Martin Thomson <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  So the question is:

> https://protect2.fireeye.com/v1/url?k=fe7995f2-a1e2acf7-fe79d569-86d2114eab2f-8b83bd94fff2883d&q=1&e=5d168f81-6781-466c-bb9e-ff8cc7ea124e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-dekok-emu-tls-eap-types-00%26amp%3Bdata%3D04%257C01%257Cjovergar%2540microsoft.com%257Cb558b067ea62444150d008d8bfee5b6a%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637470377753309597%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3DeTBptf92iMhYupJv9kRLl%252FzAV75fZXSbDjTI9sKu%252Bvs%253D%26amp%3Breserved%3D0
> 

_______________________________________________
Emu mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=80417b72-dfda4277-80413be9-86d2114eab2f-701eaa3e4f1d35c4&q=1&e=5d168f81-6781-466c-bb9e-ff8cc7ea124e&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Femu%26amp%3Bdata%3D04%257C01%257Cjovergar%2540microsoft.com%257Cb558b067ea62444150d008d8bfee5b6a%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637470377753319592%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C1000%26amp%3Bsdata%3DJQCtoTOMTzouZnJ0ILj%252B8%252BtIpJW8t04HbSlDDGYf8VQ%253D%26amp%3Breserved%3D0

---

From: Alan DeKok <[email-masked]>
Date: Fri, 29 Jan 2021 08:10:13 -0500

> I can live with any version, the important thing is that interoperable implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 1.3 is mandatory to support in 3GPP Rel-16 if EAP…

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> The close_notity changes are not only positive as it sometimes introduce an additional roundtrip. The Commitment message can according to specification be sent with the server Finish even if some/most/all implementation does not seem to allow this. If the commitment message cannot be send with Finished in practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 and EAP interacts.

  The TLS implementations largely assume that TLS is being used (a) over TCP, and (b) to exchange application data.  These assumptions *severely* limit the choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS implementations include native support for TLS over TCP.  While there have been assertions that TLS libraries also implement EAP, those assertions seem to be firmly outside of the bounds of reality.

> We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward:

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as…

  TBH, implementors have already had multiple informal discussions and calls.  One more wouldn't make much difference.

  Alan DeKok

---

From: Alan DeKok <[email-masked]>
Date: Fri, 29 Jan 2021 08:11:13 -0500

> a) draft-13 in February.  There are multiple interoperable implementations, including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

  Typo:   2022.  :(

---

From: Jorge Vergara <[email-masked]>
Date: Fri, 29 Jan 2021 16:59:44 +0000

> We need to get agreement on how to proceed here asap. I would like implementors and security AD to agree on the way forward before submitting -14. Four ways forward:

My preference is D.

> Do we need to have a telephone meeting to discuss these things? We cannot have a formal interim meeting as that formally takes weeks to setup. This can also not wait until the next IETF. As soon as…

Totally open to this.

Jorge Vergara

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Friday, January 29, 2021 5:10 AM
To: John Mattsson <[email-masked]>
Cc: Jorge Vergara <[email-masked]>; Martin Thomson <[email-masked]>; Benjamin Kaduk <[email-masked]>; Roman Danyliw <[email-masked]>; <[email-masked]> <[email-masked]>; EMU WG <[email-masked]>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  Then our choices are:

b) ??? in 2021.

  Yes,

  Alan DeKok

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 29 Jan 2021 10:32:20 -0800

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

>   We're approaching 2 weeks since the last discussion of this topic.  This document has been in development for 3 years.  We desperately need to finish it.  IMHO waiting another 6 months is not an…

My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.

>   I understand getting feedback from the TLS WG is useful.  But I would prefer to have consensus on a *solution*. Right now, we just have a series of proposed changes, with little to no discussion.

I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

> * are the draft-13 0x00 byte and exporter *terrible* enough to delay the standard another 6 months?

Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben

> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwNRryTgg$ 
> > 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$

---

From: Alan DeKok <[email-masked]>
Date: Fri, 29 Jan 2021 14:09:09 -0500

On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk <[email-masked]> wrote:
> other TLS-using EAP mechanisms.

  OK. 

>  (I do note that the current editor's copy

  The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type codes begin with 0xfe.  So there is no prefix issue, even if the type codes form part of the label.

  That being said, using them as the context is preferred, I think.

> actually the right thing that the protocol needed.

  I'm less sure.  There was a lot of discussion around a lot of things.  Part of the issue seems to be that bits of the TLS state machine are underspecified so far as the EAP needs go.

  i.e. when Z happens, is A guaranteed to have happened before that?  RFC 8446 is not clear.

> universal agreement of that as the sole relevant property.

  The issue is in part due to API limitations in OpenSSL.  I will send a separate message summarizing the issues.

> mentioned above of what properties EAP-TLS actually requires from TLS.

  I've had some further discussions and will send a separate message summarizing the issues.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 29 Jan 2021 19:34:42 +0000

Hi Ben,

On 1/29/21 8:32 PM, Benjamin Kaduk wrote:

Hi Alan,

RFC 5705 says:

   If no context is provided, it then computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random
               )[length]

   If context is provided, it computes:

           PRF(SecurityParameters.master_secret, label,
               SecurityParameters.client_random +
               SecurityParameters.server_random +
               context_value_length + context_value
               )[length]

We use only two arguments and say "No context data is used in the TLS exporter interface.". We could show the context argument as empty in the calls to make things clearer. By the way, this is what is done by TEAP also. RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to derive the session_key_seed.  The label used in the derivation is "EXPORTER: teap session key seed".  The length of the session key seed material is 40 octets.  No context data is used in the export process."

The change of moving the type-code from the context to the label was made based on your review (comments from Martin) and the fact that some libraries such as wolfssl don't support passing a context (so far). See: https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996

I think there was a misunderstanding that an authenticated signal of authentication completed was needed. Only a signal of no more post handshake messages was needed. I think Alan's summary might also explain the situation better.

--Mohit

  So the question is:

-Ben

On Jan 12, 2021, at 10:22 AM, Alan DeKok <[email-masked]><mailto:[email-masked]> wrote:

On Jan 11, 2021, at 7:08 PM, Martin Thomson <[email-masked]><mailto:[email-masked]> wrote:

 Alan DeKok.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$

---

From: Alan DeKok <[email-masked]>
Date: Fri, 29 Jan 2021 15:00:51 -0500

This is a new message to summarize history, requirements, etc. for EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and how the 0x00 commitment message versus CloseNotify meets those.  I'll ignore the exporter changes here, as those are less controversial.

  The original proposal in the EAP-TLS draft was to send a zero-length application data message in order to signal that no more post-handshake messages were needed.  From the -05 version:

   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

  However, the OpenSSL APIs (among others) do not allow for sending zero octets of application data.  The proposal was then changed to send a 0x00 octet.

 There was discussion that CloseNotify could achieve the same goals.  But CloseNotify requires an additional round trip.  There are strong opinions that additional round trips are bad.

  In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal Alert:  https://www.mail-archive.com/[email-masked]/msg03092.html

  i.e. there would be no TLS layer signalling for the following situations:

access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages are required by people deploying EAP-TLS.  Without those messages, it will be near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS handshakes.  So it's still possible for the EAP state machine to send a 0x00 octet, and then the TLS state machines sends that *before* a Session Ticket.

  In addition, RFC 8446 Figure 1 shows that application data can be sent by the server to the client, *before* the client certificate is sent to the server.  So sending this octet in EAP-TLS does not prove that the client certificate has been validated.

DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a positive signal of either "finished TLS", or "successful authentication".

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?

DISCUSS: We have interoperable implementations of -13.  Does this mean that the EAP state machines *implicitly* work with the TLS state machines?  There is no *explicit* requirement in the draft about ordering, and no discussion thereof.  I suspect that this means the implementations work in part by accident, instead of by design.  So updates to TLS libraries *may* break EAP-TLS.  It would be best to make any assumptions explicit.  And / or to recommend to implementors that they be flexible with respect to changing order of the 0x00 octet vs session tickets.

  In situations where resumption is not needed, figure 1 of https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.  There are 3.5 rounds, which is about as low as possible.  Adding resumption here would *increase* there number of rounds to 4.5, which is worse!

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.

  In situations where the certificate chain is longer, the initial authentication will be >=4.5 round trips, and session tickets are perhaps more useful.

DISCUSS: the EAP-TLS draft should be updated to better explain the costs / benefits of using resumption

  I hope that this summary clarifies the issues and requirements.  The 0x00 octet is intended as a promise that no more handshake messages are sent.  I leave it to others to discuss whether or not that promise is useful.

  As for what to do, my $0.02 is that the behaviour described in -13 is fine.  The 0x00 octet is useful.  The key exporters are perhaps odd, but not problematic.  We have multiple inter-operable implementations.

  The remaining question is this:

DISCUSS: other than word-smithing the above points, are there serious objections to the behaviour documented in -13?  i.e. does the IETF want to recommend that EAP-TLS alpha testing begins *now*, or should it wait until 2022?

  The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no "version" flag in the EAP-TLS header.  See https://tools.ietf.org/html/rfc5216#section-3.1

  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.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 29 Jan 2021 13:28:32 -0800

On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> We use only two arguments and say "No context data is used in the TLS
> exporter interface.". We could show the context argument as empty in the
> calls to make things clearer. By the way, this is what is done by TEAP
> also. RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters
> defined in [RFC5705] to derive the session_key_seed.  The label used in the
> derivation is "EXPORTER: teap session key seed".  The length of the session
> key seed material is 40 octets.  *No context data is used in the export
> process.*"
>
> The change of moving the type-code from the context to the label was made
> based on your review (comments from Martin) and the fact that some
> libraries such as wolfssl don't support passing a context (so far). See:
> https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996
>
[Joe] If this implements the derivation RFC 5216.  It's not clear that
function will give you the right output with TLS 1.3 since we are now using
exporters.  Perhaps they provide an exporter interface which should be used
instead.

Personally, I think including the method byte in the context is a bit less
error prone and straight forward then including it in the label.

> I think there was a misunderstanding that an authenticated signal of
> authentication completed was needed. Only a signal of no more post
> handshake messages was needed. I think Alan's summary might also explain
> the situation better.
>
> --Mohit
>
> On Jan 12, 2021, at 10:22 AM, Alan DeKok <[email-masked]> <[email-masked]> wrote:
>
> On Jan 11, 2021, at 7:08 PM, Martin Thomson <[email-masked]> <[email-masked]> wrote:
>
> TLS mailing [email-masked]://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!BN9rm7SoWGOKFjfY7fFgpHjeV58wJeRS31O8qeE3B4tZbNy-zWi1yMwitxxMCA$
>
> Emu mailing [email-masked]://www.ietf.org/mailman/listinfo/emu
>

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 29 Jan 2021 14:00:13 -0800

HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[email-masked]>
wrote:

>   This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus CloseNotify meets those.  I'll
> ignore the exporter changes here, as those are less controversial.
>
>   The original proposal in the EAP-TLS draft was to send a zero-length
> application data message in order to signal that no more post-handshake
> messages were needed.  From the -05 version:
>
>   However, the OpenSSL APIs (among others) do not allow for sending zero
> octets of application data.  The proposal was then changed to send a 0x00
> octet.
>
>  There was discussion that CloseNotify could achieve the same goals.  But
> CloseNotify requires an additional round trip.  There are strong opinions
> that additional round trips are bad.
>
>   In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal
> Alert:  https://www.mail-archive.com/[email-masked]/msg03092.html
>
>   This limitation would be an unmitigated disaster for EAP-TLS.  Those
> messages are required by people deploying EAP-TLS.  Without those messages,
> it will be near impossible to debug configuration issues.
>
>   There is a related issue, in that TLS 1.3 separates Session Tickets from
> TLS handshakes.  So it's still possible for the EAP state machine to send a
> 0x00 octet, and then the TLS state machines sends that *before* a Session
> Ticket.
>
>   In addition, RFC 8446 Figure 1 shows that application data can be sent
> by the server to the client, *before* the client certificate is sent to the
> server.  So sending this octet in EAP-TLS does not prove that the client
> certificate has been validated.
>
> DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a
> positive signal of either "finished TLS", or "successful authentication".
>
> [Joe] It would be good to be clear about the purpose of the message.

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

> DISCUSS: We have interoperable implementations of -13.  Does this mean
> that the EAP state machines *implicitly* work with the TLS state machines?
> There is no *explicit* requirement in the draft about ordering, and no
> discussion thereof.  I suspect that this means the implementations work in
> part by accident, instead of by design.  So updates to TLS libraries *may*
> break EAP-TLS.  It would be best to make any assumptions explicit.  And /
> or to recommend to implementors that they be flexible with respect to
> changing order of the 0x00 octet vs session tickets.
>
> [Joe] Yes we should be clear about this.

>
>   In situations where resumption is not needed, figure 1 of
> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.
> There are 3.5 rounds, which is about as low as possible.  Adding resumption
> here would *increase* there number of rounds to 4.5, which is worse!
>
> 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.

>
>   In situations where the certificate chain is longer, the initial
> authentication will be >=4.5 round trips, and session tickets are perhaps
> more useful.
>
>   I hope that this summary clarifies the issues and requirements.  The
> 0x00 octet is intended as a promise that no more handshake messages are
> sent.  I leave it to others to discuss whether or not that promise is
> useful.
>
>   As for what to do, my $0.02 is that the behaviour described in -13 is
> fine.  The 0x00 octet is useful.  The key exporters are perhaps odd, but
> not problematic.  We have multiple inter-operable implementations.
>
> DISCUSS: other than word-smithing the above points, are there serious
> objections to the behaviour documented in -13?  i.e. does the IETF want to
> recommend that EAP-TLS alpha testing begins *now*, or should it wait until
> 2022?
>
> [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 would like to start "alpha" testing ASAP, if we find problems in the
alpha test, it could result in implementation changes

>   The only advice I offer here is that we *cannot* rev EAP-TLS, as there
> is no "version" flag in the EAP-TLS header.  See
> https://tools.ietf.org/html/rfc5216#section-3.1
>
>   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).

---

From: Jorge Vergara <[email-masked]>
Date: Fri, 29 Jan 2021 22:35:54 +0000

[Jorge] My only recommendation would be to wordsmith this part of draft-13 found in section 2.5. I am not a good wordsmith but I see potential confusion here:
>After sending the Commitment Message, the EAP-TLS
>   server may only send an EAP-Success, an EAP-Failure, or an EAP-
>   Request with a TLS Alert Message.

[Jorge] The diagrams in the draft mostly imply that the commitment message being the last thing sent, after any NewSessionTicket. As stated, this is problematic since the TLS stack may re-order these, and the NewSessionTicket may have to come in another EAP-TLS fragment entirely if the combined message ends up crossing a fragment boundary.

In my mind, it is obvious that the rest of the EAP-TLS packet should be processed so that the EAP-TLS client can correctly receive the NewSessionTicket and any other handshake data that may have been in this final message. However, once that complete EAP-TLS packet is processed, the next message from the server should indeed be an EAP-Success, EAP-Failure, or EAP-Request with a TLS Alert Message as draft-13 indicates.

This is currently how the Windows client implementation operates, but it is mostly by chance. If we made the full processing of the EAP-TLS packet explicit, then I think this would resolve the concerns around ordering here.

Jorge Vergara

From: Emu <[email-masked]> On Behalf Of Joseph Salowey
Sent: Friday, January 29, 2021 2:00 PM
To: Alan DeKok <[email-masked]>
Cc: EMU WG <[email-masked]>; Benjamin Kaduk <[email-masked]>; Martin Thomson <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan,

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:
  This is a new message to summarize history, requirements, etc. for EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and how the 0x00 commitment message versus CloseNotify meets those.  I'll ignore the exporter changes here, as those are less controversial.

  In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal Alert:  https://www.mail-archive.com/[email-masked]/msg03092.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Femu%40ietf.org%2Fmsg03092.html&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836111592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mvsTA5W4KMdnLyFin4tzW185JUB%2FuxP%2FyNjI2Mh2Mkg%3D&reserved=0>

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.

  In situations where resumption is not needed, figure 1 of https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-emu-eap-tls13-13&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836121589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1UC%2BP%2B1opA0%2Bq18bznKj3jgrfAqxUTZPLarrTCVCN0E%3D&reserved=0> is correct.  There are 3.5 rounds, which is about as low as possible.  Adding resumption here would *increase* there number of rounds to 4.5, which is worse!

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

DISCUSS: other than word-smithing the above points, are there serious objections to the behaviour documented in -13?  i.e. does the IETF want to recommend that EAP-TLS alpha testing begins *now*, or should it wait until 2022?
[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 would like to start "alpha" testing ASAP, if we find problems in the alpha test, it could result in implementation changes

  The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no "version" flag in the EAP-TLS header.  See https://tools.ietf.org/html/rfc5216#section-3.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5216%23section-3.1&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836121589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tGmJaIg4RiU6bw3Y670yYp2LHw8TwsR7uDV934NH%2Fmw%3D&reserved=0>

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

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836131579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FngrGmmyOMYXSItAC8ciJymsmG1liBdTcFryyw4822A%3D&reserved=0>

---

From: Alan DeKok <[email-masked]>
Date: Sun, 31 Jan 2021 09:20:57 -0500

> [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 appl…

  I think so, too.

> [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"?

  RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine for EAP peer and server.  Does this work follow that?

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

  I agree.

  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.

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

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 31 Jan 2021 09:30:36 -0500

On Jan 29, 2021, at 5:35 PM, Jorge Vergara <[email-masked]> wrote:
> In my mind, it is obvious that the rest of the EAP-TLS packet should be processed so that the EAP-TLS client can correctly receive the NewSessionTicket and any other handshake data that may have been in this final message.

  OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages *after* the Finished message.  i.e. the Session Ticket, etc.  When an application calls SSL_Read(), all of the TLS data is processed, instead of just the "TLS finished" message.  They've made this the default, because most applications get it wrong.

  It would be good for the draft to note that TLS libraries should process all of the TLS messages before handing application data over to the application.

> However, once that complete EAP-TLS packet is processed, the next message from the server should indeed be an EAP-Success, EAP-Failure, or EAP-Request with a TLS Alert Message as draft-13 indicates.

  Section 2.1.1. says:

   After the EAP-TLS server has recieved a EAP-
   Response to the EAP-Request containing the Commitment Message, the
   EAP-TLS server sends EAP-Success.

  Which *could* be seen as mandating EAP-Success, no matter what certificate is sent by the client.  I suggest making this behaviour clearer.  i.e. the document should include something like your sentence above.

  I agree.

  I would also like clarification on just what the commitment message does, and why it's needed here, and not for TLS 1.2.

  Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 18:16:44 -0800

> > [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 ap…

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?

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

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]

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.

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

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

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.

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

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

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 18:51:10 -0800

Hi Mohit,

The quoting in your note is not coming across usefully in my MUA, so I'm
trimming to (what I think are) just your remarks without other history.

> We use only two arguments and say "No context data is used in the TLS exporter interface.". We could show the context argument as empty in the calls to make things clearer. By the way, this is what…

We're using the TLS 1.3 exporter, though, so the RFC 8446
(https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument
form seems most relevant.  Note that there is no difference in TLS 1.3
between an absent context and a zero-length context.

> The change of moving the type-code from the context to the label was made based on your review (comments from Martin) and the fact that some libraries such as wolfssl don't support passing a contex…

I'm not going to get super hung-up on label vs context (but it's clearly a bug
if WolfSSL doesn't support contexts).  I guess Martin even wanted the type code
to be in the label part in the first place, so having it in the label is
"better"; we just need to actually show that there's an empty context
argument.

> I think there was a misunderstanding that an authenticated signal of authentication completed was needed. Only a signal of no more post handshake messages was needed. I think Alan's summary might a…

I note that Alan seems to also be a bit unclear about exactly what purpose
the commitment message serves; I look forward to seeing how the questions
he has listed get answered.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 18:53:11 -0800

Hi Alan,

With my apologies to everyone on the thread for so many mails in
succession...

>   The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type codes begin with 0xfe.  So there is no prefix issue, even if the type codes form part of the label.

Ah, of course I should have realized that the 0xfe octet separates them.
You are correct; there is no issue with prefixes, and sorry for the
confusion.

Thanks,

Ben

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 31 Jan 2021 22:00:37 -0800

On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk <[email-masked]> 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.
>
[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.
> >
> >   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"?
>
> [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.

> could achieve this by not exporting keys until you've sent all those bytes
[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
[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.
>
[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".
>

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 1 Feb 2021 06:21:16 +0000

Alan DeKok <[email-masked]> writes:

>OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages
>*after* the Finished message. i.e. the Session Ticket, etc. When an
>application calls SSL_Read(), all of the TLS data is processed, instead of
>just the "TLS finished" message. They've made this the default, because most
>applications get it wrong.

Asking as the author of a TLS library that has always done this, why would you
stop immediately after the Finished and leave metadata messages sitting unread
in the input stream?  Was it just some arbitrary implementation decision, or
is there a technical reason for it?

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 Jan 2021 22:28:16 -0800

> is there a technical reason for it?

I expect (but did not attempt to validate) that this was SSLeay-vintage logic
involving only reading a single record from the wire per call to
SSL_read().  If that record was a handshake record and not application
data, well, then the SSL_read() didn't do something useful and so the
special "try again" code was returned and the application was supposed to
call SSL_read() again.

There's no technical reason that I'm aware of.

-Ben