# EMU @ IETF 110


# Agenda

    Administrivia
    Notetaker: Watson Ladd
    Japper Scribe
    CodiMD
    Note Well
# Document status
See the slide for all
EAP-AKA: discussion ongoing. Meeting with 3GPP on 17th March. Details to be sent on the list
TLS 1.3 related drafts active today
Hope to make progress on working group adopted draft EAP-AKA-PFS
# Update from Hackathon (Alan Dekok) - 15 min
Apple, Cisco, Micorsoft Radius
Based on draft -13
Clients (Microsoft, wpa_supplicant)
Servers (Freeradius, one other)
EAP-TLS, PEAP, TTLSv0
Easy to add assuming TLS abstracted
Main issue is PEAP and TTLS. EAP-TLS is easy
Imposssible to control the state machine of OpenSSL. Throw it in stuff happens hope for best
Very difficult to say this happens now.
Some APIs only in OpenSSL v3 not released yet.
In application data ready doesn't come out, handshake goes back and forth after session initialized. Confused state machines.

In TLS 1.2 assumption was TLS Finished finishes the TLS. Either update to control more or be more flexible.

Configuration not state change.
SSL_new_session_ticket vs. SSL_CTX_num_tickets
TLS 1.3 cannot be deployed with OpenSSL v1 because of needed tweeks.
Corner cases.

Session tickets all alone in a packet ahead of application data. Not merged.
Confuses clients.

One session ticket.
Silence from Apple.
Cisco looking more into it.

Tested both close_notify and 1 octet application data
Application data prefered.
Easier to implemented seems to fit state machine model.
Overloading TLS signals to signal EAP seems imperfect
Feedback from TLS working group was application data should signal EAP not TLS state.

Exporters still in -13
Still spelunking to do for PEAP and TTLS.

Conclusion: Mostly sort of works, only EAP-TLS production ready.

Mohit: As WG: How much do we want to tie up to OpenSSL?
Provides features others don't.
wps_supplicant provides way to use WolfSSL, doesn't have all features. E.g. issuing variable tickets. Issue 48 link, BoringSSL hardcoded two tickets. Could change to one and recompile.

Alan: Hard question. OpenSSL v3 will not be released for a while. Requires lots of application work. if it works with v1, if not need to add note some libraries are broken just put up with it.

John: Session tickets. Multiple to remove round trips in resumption.

Alan: What about resumption across Media? Wifi and wired both EAP, should resumption work across. Everything in EAP silent on topic. Related to session tickets issue.

Mohit: One enough, send more in some cases. Ignore or save several

Alan: Related issue is application is not in control, early session tickets not useable, no explicit marker. Have to throw away. Not even clear client is notified of it.

John Mattason: Session tickets before are valid. No reason they would be invalid.

Alan: RFC 8446 less than clear on session ticket timing. Are there earlier ones? Need definitive answer.

Jorge Vergara: Issue is with client auth. Resumption can then result in failure.

Alan: Source of issues in the past. OpenSSL would cache by default, send whenever, possibly using EAP-TLS or PEAP. Possible for client to get ticket, not send password, resume. Jump through hoops.

Alan: We haven't seen it, does seem to be allowed. OpenSSL code is not at all clear. What it does I run away from.

Jorge: Did see in PEAP. Did have difficulty. Long before PEAP finished wanted to send session tickets. Not with EAP-TLS.

Alan: Impossible to send session ticket now. No control over when. Would hope that send no, now it's established, now send them. Doesn't seem to work. Were patches from Ben for OpenSSL v3. Not in OpenSSL v1.
Not sure if requirements we like are possible. 

Watson: If you are building around openssl, don't try to modify your protocol. bad for the whole ecosystem. 

Alan: We are stuck with opnessl. Huge swathes of deployment which will not be updated to opnessl v3. May be as simple as recommending as you write more code for these other states. Wave hands due to library issues. TLS 1.3 substantial change. May be if you get it keep the TLS going. Same thing with number of sesson tickets: pick one after verification. If you get more than one pick one.
Not breaking the standards. Recommending implementors can work around OpenSSL.

Joe: Any other implementors. More participation in interop will be great. 

# EAP-TLS with TLS 1.3 (John) - 30 Min

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

Goes through Alan's comments, Github issues. Hopefully get rought consensus, close issues, submit -15, agree what needs work.

Lots of changes -12 to -14 changes, normative changes mostly TLS arranging. Clairification on errors and message flows. Clarification ticket lifetime, OCSP status.

Change to close alert, some flows more flight.

Type code appended, not in context. Separating MSK and EMSK labels.

Issue 32, type code in context, or appended to labels. Recent comment by Alan should be coordinated. Think change was coordinated.

Alan: Wouldn't register variable label. Whoever wants to pick it up would put their labels with different code in.

John: Specific labels in draft seems doable.

Alan: Push on context: there is no session information. Can go over many transports. So for shear laziness put the type code, less work for implementors. IANA registry doesn't have 60 minor variations. 

John: Should we go for context again? Or different labels

Roman: will get informal nod ahead of people changing code.

Alan: Not huge amount of code, just a little easier.

PR 42 and 44: Close out IESG comments missed in -14. Several question about relation to TLS EAP Types. Have been added as reference. Comment about message flows specific to TLS 1.3

No issue related, just PR.

Joe: Merge 'em. No objection, will go to list for some, but this is editorial.

PR 45: New session tickets. Conclusion was resumption useful for packetization reasons.

Issue 48, PR 51. Ticket request mentioned. Comment from Alan should have more guidance. Should take into account fewer tickets. Most cases single sufficient. More guidance needed. Recent comment on list RFC 8446 should be included.

Require server just send one? Require too restrictive, expect probably good.

Joe: problem with new session tickets early. Thought resumption key derived from both finished.

Need to sort out security guideance.

Mohit: Say one is enough, say you might send more. What remains is to schedule when. Want to send only after client Hello.

Alan: Needs to be documented as Here Be Dragons. Otherwise we've been beating our head against this for months. Best to write it all down and say by the way TLS 1.3 anything can happen. Sorry.

Joe: Clarifying helpful.

Joe: Think tickets and handling still open, rest not.
John: Activity on github appreciated.

Issue 36, PR 41:  What can attacker modify in what. Pull request tries to sumarize. Protection of failure, availabity.

Conclusion: Any number of other problems. Any bad packets cause failure, nothing that can be done. Can always connect again.

Similiar for success indications. Unclear exactly what and when protected success protects against.

Bernard: Don't understand where it says protected failure may be unauthenticated. What does it mean to have unauthenticated integrity protection?

Mohit: Opportunistic DH to indicate. In TLS 1.3 early failures may be unauthenticated

Alan: protected_failure from generally good. Only thing is to make sure that errors get back to user and administrator. Ubiquituous "Failed" with no way to fix.

Rabbit hole?

Alan: Yes, requiring all errors go back too strong.

Eliot: Yup, hard problem in IOT

Issue 49, PR 50: Replace master with main, where not needed removed
Suggestion to do ths ahead since it will be the future.

Issue 38, PR 46: must send error alert
user_cancelled unclear behavior, issue for 8446 bis

Issue 33, PR 40: Eap state machine
Thinks to finalize would need conclusion on protected indication. Includes RFC 4137, tries to make it nonnormative.

Mohit: Most important issue.

Bernard: Has to be application data

Alan: Have to tell OpenSSL not to be quiet, send close_notify. Shut down, ask for data to send, it says no. Are we using API incorrectly or is OpenSSL v1 just broken? One byte well tested for TLS. Think we're running into OpenSSL.

John: Makes sense if not a commitment to avoid more handshake. Would this avoid Discuss

Alan: Signal is that EAP later promises not to poke, not TLS signal. For other EAP things they send their own application data. For resumption case of EAP-TLS of resumption.

John: Should we go with application data after his discuss?
Mohit: put in with application data, see new IESG. Ben's discuss mostly as commitment to no more post-handshake, but now as success fine.

John: All alerts failure as well.

Joe: Sounds like close_notify even if working control issues, application data works. Think IESG comment was more control about TLS than EAP.

Hannes: Sounds like an OpenSSL bug. Want to make in mBedTLS. Suit stuff took longer. Everything takes longer than I think.

Issue 47: Key derivation and bidding down. Seems to be consensus no more needed in key derivation. Text in RFC 5216 lacking, more guidance need. Currently only issue, no PR.

Latest suggestion by Joe: number of tightenings. Maybe what we need high level guidance on how to do this securely.

Alan review: Came out of deployment issues with TLS 1.3. Document should suggest forbidding 1.4 until changes made.

Mohit: We don't know what 1.4 has. Maybe we can avoid changes. Also see Robs point to leave it open, but with big change.

John: Agree or higher should be remove 

Watson: QUIC did similar thing, what did they do. EAP is unfortunately tightly tied to TLS. 

John: Very different comments. Implementors need to bind. Similar to RFC 5216.

Hannes (in chat): Can always do another.

Eliot: Calling interface for nonweb use cases. Industrial cases. Short report when done, don't forget. Happy to help. Another doc that needs help.
WE should be active in TLS working group to highlight non-web use cases and their requirements.

Alan: Key exporters came out of EAP TLS. Original came out of reaching into internals. Realistically if +1 doesn't change APIs fine. But now can negotiate after finished, breaks all EAP.

Joe: Fundamental changes in the design that could have caused these problems. Especially since it was the same chair.

Alan: Section 5 doesn't discuss implication of not authenticating peer. Usecases, should be discussed.

Bernard: Have to manage carefully, especially around resumption.

Backwards combatibility: Doesn't say how this works.
Joe: Say we rely on TLS nothing in the EAP TLS headers to negotiate

HRR: No explanation of how it affects EAP-TLS. Maybe it doesn't. 
Any effect happy to add after a PR.

Alan: EAP identity, use same as from first authentication. Solves issues.
John: Not clear how it solves these.  Same identity encrypted so on wire different.

Alan: Think we can rely on sesson identification. No benefit to using PSK identiy in EAP identy

Watson: In resumption, your implementation has to keep track of credentials used if you have want to use the idea of the same user resumed. Not always be possible. Suspect part of the issues we see with resumption. 

John: Not sure PSK issue is there in the draft.

Alan: I'll double check. For previous comment: Yeah, this is what EAP server has been doing since forever. Caching, and reevaluating.

John: Think we only specify exporters for EAP-TLS 1.3

Alan: Should just be for EAP-TLS. Maybe change already done, point to others and say similar elsewhere.

# TLS-based EAP types and TLS 1.3 (Alan Dekok) - 15 Min

    https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/
Things mostly work, OpenSSL is horrible. What text do we put in to say we can't, so corner cases. Specific more to PEAP and TTLS.

Joe: Would like to more discussion as EAP-TLS may have implications?

# RFC3748bis (Jari) - 15 Min

    https://datatracker.ietf.org/doc/draft-arkko-emu-rfc3748bis/
    
Jari: Can see the difference

Motivation: Nothing wrong with existing RFC

Fold in errata or other issues, update security, core EAP documents update, point to those. Terminology improvements.

Discuss issues, point to newer ones, update security claims to discuss another one, IANA rules, 3GPP

Open Question: More on security, not complete.

Reduce with more core docs. Newer IEEE docs.

SASLprep is very old, updated two or three times. Not sure what to do. Replace, or is old one still working.

Next steps; what we missed? Too far? Discuss update.

Bernard: Bring to next step of standards. Surveys of implementors. Try to find interop issues, everythng two or more for advancement. Esp. for 17 years old, don't really change RFCs for it.

Jari: Wonderful things, but this is just 00

Mohit: At least in EAP TLS when we started updating for TLS 1.3 realized that two things are helpful: remove a round trip, make things protcted. If Session ticket in EAP_Success or other data. Much bigger change, but can consider as omething to do in this.

Roman: From what we standards, protocol maintance varies. Two things: document and elevate from PS to higher levels. Other element: what triggers a Bis. Is it in charter and triggers. Jam erata into BIS with no renumbering done before. Fo higher level would need revision to clean up anyway. Go through squint vs charter.

Eliot: If we go to bis, should there be things we do differently. Very lengthy conversation. Is connection model appropriate, appropriate for tunneling. Worth considering for BIS. Fine if we come down with a few tweeks to Full Standard. But before effort is it what we want. One example is applicability good across not just 802 and 3GPP. Not judging answer but we should ask.

Jari: Started with not changing. Could do EAP-NG. Whether sensible or not bigger discussion. Might also work on newer stuff. Weight in deployed systems. Mostly worried about as is than changes. Particularly chopping out bits we don't sue.

Joe: Milestones on list. Lots of this will have to be on the list, depend on where we want to go.
# Milestone review (if time) (there was not)