Minutes IETF105: emu
EAP Method Update
||Minutes IETF105: emu
IETF 105 EMU Agenda
Wednesday Jul-24-2019 1330-15:30
1. Administrivia (5 Min)
2. WG Documents (20 Min)
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
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
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
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
- 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