Skip to main content

Minutes IETF105: emu

Meeting Minutes EAP Method Update (emu) WG
Date and time 2019-07-24 17:30
Title Minutes IETF105: emu
State Active
Other versions plain text
Last updated 2019-07-31

IETF 105 EMU Agenda
Wednesday Jul-24-2019 1330-15:30
1. Administrivia  (5 Min)

2. WG Documents   (20 Min)
- draft-ietf-emu-rfc5448bis-05.txt
- draft-ietf-emu-eap-tls13-05
- draft-dekok-emu-eap-session-id
- draft-arkko-eap-aka-pfs
- draft-ms-emu-eaptlscert

3. RFC 7170 (TEAP) Erata (25 min)

4. TLS-based EAP types and TLS 1.3 (5 min)

5. Recharter Discussion (30 min)

6. EAP-Noob (15 min)

7. TEAP-BRSKI (10 min)

8. ACME Integrations (10 min)


Recharting discussion? changes to agenda?  None.

John Mattsson presented remotely
Changes and next steps
removed text on other TLS-based EAP methods

comments after WG last call by Jouni Malinen
use of empty TLS record is not supported by OpenSSL, whereas TLS 1.3 allows it.
OpenSSL also does not support early application data without early_data
extension need decisions on these comments

Mohit at the mic: implementation is more complex if there are multiple options
it seems better to just send one byte of zeroes and that's it

John: Question, should we document OpenSSL's requirement to send
NewSessionTicket, otherwise OpenSSL won't send early data to an unauthenticated

mic: Jim Schaad.  Doesn't seem like a good idea, because the server may not
want a newSessionTicket.  The server can still send a message saying we're done
after it's authenticated, and it should work.

John: the spec says otherwise right now

Jim: the server can send that message after client authentication.  It's just
the first encrypted data message from the server to the client.

John: To allow that we will need to rewrite the spec.  It's not clear how that
interacts with the EAP state machine.

Jim: it should match it fine.  Just send that message instead of the

John: Sounds good

Joe: Will clarify it on the list

John: It will introduce an additional round trip, but it seems OK.  Will send
summary to the list.

Joe: If there's no contention, we can move forward with this

Large certificates draft

changed text to address discussion on the list.

need WG adoption and reviews.  All WG comments have been addressed

Joe: Will call for adoption immediately after the meeting

EAP Session ID -

Mohit: We should adopt and WGLC as soon as possible.
  Need to change the title because it implies it is for all EAP methods

Joe; Will start adoption call after meeting

Joe: another draft waiting for adption, EAP-AKA PFS, but concerns about IPR
issues.  Consensus that the document is needed, and should move forward. 
Target is informational.  Proposal is to adopt it as WG item.

AD (Roman): not objecting, but didn't want to object.  Did we call out IPR
issues?  A: yes

RFC 5448bis -

Jari - Gone through WG LC.  Some feedback.  New version was published, with
some minor changes.

- added table of attributes, can / may appear in packet.  Didn't exist in 5448,
did exist in 4187.  Added to be clear on what's needed and what's not

next steps IESG

no comments, no objections to marking it as ready for IESG

Daniel: document seems ready

Eliot : who has reviewed the document?  5 people. + 1 jabber

Jari: many other people from 3GPP and Ericsson reviewing it

TEAP Errata -

Jouni Malinen filed errata against TEAP RFC.

Will walk through errata asking for opinions

Joe: proposed to accept the function signature for TLS-PFS errata.  Asking for
more responses.  Will tell Roman who can do the next steps

errata for Authority-ID is optional, proposal is to accept it.  No comments
from the room.

Eliot: why was it a MUST in the first place?

Joe: Good question, we don't know.  Perhaps because EAP-FAST has a similar
construct and may have bee marked mandatory there.  We will continue the
discussion on the list.

Mohit: is there text on what implementations should do when the TLVs aren't

Eliot: in the middle of doing the implementation for TEAP.  Let's take time for
implementations to see before we move ahead.

Errata (5767) for authentication method text.  Proposal is to adopt it.  But
may hold off until the implementors come back

Roman: if we're going to be waiting, we can just batch the, and set a date for
when we go forward if we don't hear back from the implementors

Joe: yes, Jouni's implementation is waiting

Errata 5768 - compound MAC is fixed to 20 bytes

SHA1 is no longer used, we need to decide what to do.  Simple fix is to
truncate.  It may be better to have variable length.  Will work with
implementors to work through the issue.

Roman: timing Q again.  Maybe wait until next IETF in Singapore

Elliot: Should have implementation by end of summer as a default timeout point
on answers.

Errata 5770 -
Joe: Needs to get clarification as it is incomplete.

Errata 5775 -
Joe - Value missing if not a key generating meethod.  Need to decide on whata
to use in that case.

Follow on question is do we need to do a bis version of TEAP.  But this can
wait until after all of these errata issues are decided.

Elliot:  The Brski work was modifying this and if the document is opened then
could do it in this document rather than as some extenions.

Alan: Next document fixes TEAP for 1.3 does not deal with 1.2 right now, but
could roll that into this as well or push to a different location.

TLS 1.3 - Alan

FAST and TEAP have more difficult key deriviation - punting on TEAP would make
things easier for this document.

Elliot: No personal opinon - will go back to team

Recharter Discussion

Mohit: Proposed text is a superset of current text in terms of current work

Roman: How many poeple have read it? - 2 (+1 in jabber)

Alan: What do we do about people who are violating current EAP standards and
put things out which are not reviewed?  This is not part of the charter but may
want a discussion.

Roman: What is the public act being proposed

Alan: If IETF is in change control for EAP, what can we do for external issues.

Roman: Not chartering of a new issue

Bernard: No EAP Police to call and have them arrested.  If security thing then
would not get blessing from NIST

Alan: Some 3GPP work has migrated out of there and is continuing.  Do we have a
charter item to work with people to get review on these things.

Mohit: Expert review to get an EAP method #.  Perhaps provide

Alan: Not new stuff - changes to existing EAP methods.
   Current expection of IETF review is not happening, but not sure what can be

Mohit: Can do some contact with known changes.

Roman: Don't need to change charter to talk to people, only for new formal work
(i.e. document).

Mohit: Comments on the new text is welcome.  Does it cover everthing that needs
to be done?

Roman: Suggest changing the text to be more in line with what the old charter
was laid out in.

Mohit: Old items were fixing things, but this is for new work.

Roman: Wants to know who is interested in doing the work (author and implement):

Joe:  OOB work - ~ 6 people raises hand.
Write code? Alan for sure

Eliot: where is the TEAP work covered?  A: entire second paragraph

Eliot: seems some inconsistency between first and second paragraphs.

Mohit: trying to capture current ideas, but updates are welcome

Eliot: it's clear that TEAP work is needed.  Recent conversation is that
they're not even sure if they want an outer TLS connection.  We need to have
that dialogue here.

Mohit: text doesn't require TEAP

Eliot: We may want to separate out third line text into deliverables text

? (CableLabs): seems to already be covered

Eliot: general text is good enough to go forward

Roman: still confirm on list

Joe: limited use EAP authentiction methods which can be used to create long
term credentials

- 6 reviewers
- 4 implementors


Tuomas: presenting slides

working for 3 years on this, implementations in hostap and wpa_supplicant,
modeling and verification, peer implementation in Contiki

Roman: Q: slide on SAAG presentation has wrong date; should be March 2019

Joe: questions?  None, moving on


Eliot - quick update.  Added Security Considerations

had to combine join registrar and EAP server to satisfy BRSKI requirements that
signatures match and are bound all the way thru

need implementation and development testing.  Finding ambiguities in TEAP.

doing wpa_supplicant and server implementation

may need 802.11 or WiFi alliance integration to deal with the 2K SSID (BSS)
problem.  Hunting through them is time-consuming and expensive

Joe: No comments?

Dan: Could this voucher that TEAP-BRSKI uses be considered an OOB mechanism?

Eliot: Partly.  this ties into the Anima architecture.  Could go to
manufacturer for voucher, largely in-band.  Or, been given a voucher (somehow)
and placed it into a join registrar.  From that point, it can authenticate
without a cloud transaction.  Or sales integration that happens, may hand you 
voucher at the time of the sale, which then goes into the AAA infrastucture. 
But these use-cases shouldn't change the bits on the wire

ACME TEAP integration -

Given same presentation in Acme and Anima.  Using cloud as back-end for certs
when doing enrollment over TEAP

strong interest in doing EST over BRSKI work

Eliot: Thanks for this.  A lot of small enterprises don't want to run a CA. 
Ability to link to public CA will be useful.
  I think what you're asking for the TEAP work is that do we need an error 202
  code for the draft we put together? A: yes.
Where is resource consumption?  What if the CA is unavailable? WHat if someone
is holding state?  How does state expire?

Dan: how do you envision that these certificates get named?  In the CSR?

A: It's an open issue.  How does the device know what FQDN to put in?

Joe: it's interesting to get a "come back later response.  But it largely means
no network.  The person gets a token to come back and call later.

A: could work with session resumption?  ACME supports "call me back later"

Joe: ACME would maintain the state.  But no network connectivity until that

Mohit: anything that happens beyond the TEAP server is not a concern for EMU. 
could use ACME?  Does ACME do client certs?  ACME seems mostly to be domain
validation and not client certs?

A: use-cases are for both client and cert getting certificates

Mohit: Is this the WG for it?  Or is ACME?

A: work may be required here in order to do this.  Is the mechanism by which
the station knows the FQDN?

Mohit: it's not the station.

Michael: It involves changes to the TEAP state machine in order to deal with
this.  ACME already deals with this.

Mohit: maybe we can look into it.  It should not be the device that says "issue
me the cert".  It's the server.  The server should enforce this.

A: client generates the CSR and the server interacts with the CA

Mohit: server would still enforce it when it sees the CSR

Joe: Server enforces policy, but client generates the request.

Joe: more questions?  None?  Agenda is done.  Other topics?

Bernard: working off-line to get Alan contacts for PEAP and TLS 1.3.  That's
the only comment.

Roman: pet topic sharing in all WGs. Can we put a list of implementations
relative to drafts, so that it's easily accessible?  Will help with interop
testing, and helps to advance the drafts.

Mohit: RFC 7942 says that drafts should include a section on implementation
status, but a Wiki is good too

Dan: Other business - EAP-PWD' new draft is available.  Please have a look

Bernard: Q on interop tests for TLS 1.3 and EAP