Notes: Janfred
No addition to the agenda.
Alan DeKok presenting.
TEAP has a lot of issues. A lot of effort went into getting the document
into shape.
Now there are interoperable implementations, and errata have been
addressed.
Open Issues:
Nobody has implemented the PKCS portions; should we keep or remove this?
Maybe we have to go through another bis iteration if we discover issues
with this once it gets implemented
Request-Action raised by Elliot still needs discussion.
Signalling: The server has no mechanism to select an auth based on the
client identity. This lack may result in either increased roundtrips or
failure.
Eliot: The decision can be made based on the initialization. E.g., if
the device does not present a cert, it is probably not a machine but a
user.
Alan: TEAP just sets up a TLS tunnel, there are some cases where the
server knows something about the client, but in general this can not be
said. If the client and server disagree about the inner methods, bad
things can happen.
Problem there is: How do you know what the other end wants to do? E.g.,
server only wants to do machine authentication and the client wants to
do user authentication.
Client should be able to propagate its capabilities to the server.
Implementation Issues:
Windows send an empty EAP identity if the server wants to do
machine+user authentication and the credentials for the user do not
exist. (The machine auth runs fine). The client should send an error TLV
indicating that it does not have the credentials. There is no error like
"I don't have it" only "Unavailable" which probably is more like "I
can't access it right now".
Joe: Is it a difference between "Unavailable" as in "Can't access it"
and "Unavailable" as in "I don't have it"?
Alan: Probably no difference, but sending an error is better than
sending an empty identity; now servers need to check for this empty
identity.
We may want to ship the document as a documentation of what is currently
out there, so we have something to point to and then focus on TEAPv2.
Maybe even leave PKCS out if no one has implemented it.
Elliot: We have implemented PKCS. Some issues need fixing. PKCS needs to
stay in TEAP.
Dan: PKCS needs to stay in. Bootstrapped TLS needs this, Michael
Richardson also has a draft that depends on the CSR TLVs.
Joe: Do we have these changes queued up, can we get a PR?
Elliot: Didn't put in the PR; Alan did that, but I can do this soon. One
issue raised on when the message should be sent.
Joe: With regard to PKCS: Is there anyone who wants to remove this from
the TEAP spec? (no one opposed)
Anyone who wants to comment on the Identity issues?
Alan: The question is, do we want to add a new TLV? I don't think it is
complicated. The client just sends to the server an "Identity-Hint" TLV.
Elliot: Implementation should be simple. We should add some discussion
to the trust/distrust the server should put into this.
Alan: That's why it's called "Hint"
Massimiliano: Should there be some trust in the identity?
Alan: No, the server just needs some sort of hint to select EAP or
Password authentication.
Joe: Get a PR for this in.
John: Coming back to TLS: Should we update the TLS specs to require
up-to-date cipher suites, maybe refer to the TLS BCP?
Joe: If anyone could help to go through the errata to ensure that
everything has been addressed, that would be appreciated.
John: In reference to the chat, do we really specify something with
_RSA_ in 2023?
Yoav: If we would specify new today, we would probably use ECDSA, but
there is nothing really wrong with RSA.
Elliot: For IoT use case we need small keys like with ECDSA. Let's put
this discussion on the list. I will come back to this in a few days.
Elliot: Regarding the Request-Action I had a brief discussion on the
list. I'll put it in a PR to help the discussion.
Dan Harkins presenting.
The Internet-Draft solves the Catch-22 that you need a cert to get on a
network, but you need to be on the network to get a cert.
Suggestion in the draft: Reuse Wi-Fi DPP EC bootstrap to provision the
cert.
Just puts existing RFCs together in an interesting way.
For TEAP, the client sends a generic identity, then does the TLS
exchange. Afterwards over the TEAP tunnel the client uses the PKCS#10
and PKCS#7 TLVs to get a certificate.
Not much changes from -01
Question on the list by Hannes regarding RFC9258: Why the additional key
derivation? Some parts of the spec can be removed, but the EPSKID
extension needs to stay there because this is also used to derive the
PSK.
There have been no substantive protocol change since adoption and review
by TLS WG is done.
This document should be ready for WGLC.
Joe: Definitely publish document with the proposed changes. Also have
the CSR items linked with the TEAP document.
May wait with WGLC for this, chairs will look at this.
Elliot: Don't think this needs to wait for WGLC just because of CSR
attributes.
Regarding Hannes' comments, this probably is only needed for wireless
auth, but not wired?
Dan: Since we use the Identity as PSK and we send this to a probably
unauthenticated peer, we need a way to identify the target without
exposing the PSK.
John Preuß Mattsson presenting.
Interest in EAP in IoT/5G. EAP is missing a lightweight method. EDHOC is
specified in LAKE WG.
The target is small message size and small code size.
EDHOC supports X.509 certs or CBOR-encoded certificates.
Message sizes for EDHOC is approximately 100 bytes per message.
The specification is mostly stable and should be ready for adoption.
Dan: What is in the 5th packet in the exchange?
John: Nothing in there, just to give the server the ability to send a
Success
Joe: Question for the room: Is this an appropriate item for the emu WG?
(4 raised hands)
Not a whole lot of support, take it to the list.
Meiling Chen presenting.
Goal is to improve authentication efficiency for IoT.
Not much interest in the last adoption call, still looking for more
people interested in this.
A prototype is implemented.
Some changes from -04 to -05: Algorithm rename, RPK exchange and mutual
auth with TLSv1.3 removed, updated references, added security
considerations.
Poll: Who has read the draft? (2 read, 8 did not read)
Alan presenting on behalf of Michael Richardson.
Alan: This is another method for bootstrapping, with some overlap with
TEAP. Working on implementation.
Dan: Draft talks about 802.11u, this is intended for wireless only? Why
not use RFC 8110 (Opportunistic Wireless Encryption) instead of doing
another round of EAP?
Alan: Will take a look.
Some discussion about EAP-AKA on the list, if we want to discuss this
now, we would have time.
John: Discussion mostly about wording on future PQC. Some updates, but
no major technical updates, actually adding PQC will come later. Some
reviews, will update based on the comments and make a new revision.
John: Received a few questions about old draft for TLS with PSK. Maybe
there is interest for IoT, but for these use cases EDHOC or cTLS would
be better.
Alan: EAP-TLS supports PSK allegedly already. We have to understand why
this is useful to support.
Massimiliano: Some work for EAP-CREDS for managing credentials over EAP.