Notes: Ethan Thompson, Janfred Rieckers
Agenda remains unbashed.
Quick Off-Topic comment: 7170bis is waiting for an ACME draft
Since IETF 120:
WGLC ended.
Draft Status:
Implementation Status:
Alan - implementation challenges... takes time... should be straight
forward
Last comments are added to the draft.
Uploaded the next version, but there's one issue to be addressed:
even thought EDHOC carries connection identifier, we think that during
the EAP exchange there is a question on what happens, or is it even
possible to have an EAP conversation between the same peer and the same
server. Maybe we need to add come connection identifiers outside of the
EDHOC message
Questions to WG:
Alan: on the RADIUS side, the association between each individual EAP
packet and the next is controlled by the server which has a state
attribute that is globally unique to the RADIUS server. When a new
connection comes in, it doesn't look at the eap attribute to establisht
he detection. Basically, RADIUS servers are already required to
distinguish between eap sessions, so this shouldn't be a problem.
Joe: Same for lower levels like EAPOL
Rafael: They haven't seen any additional method to handle fragmentation.
There is nothing similar to EAP-TLS for fragmentation.
Alan: You do have to handle fragmentation. That is specific to each EAP
method.
Rafael: We did that that same way it was supported in 1.3.
Next Steps:
There will be a name change.
Updates since 120:
New Proof-of-Concept is running:
Discussion:
There are pros and cons for changing the FIDO challenge format.
Reasons for binding challenge to TLS channel:
Discussion:
Alan: In terms of binary vs. JSON, it only really matters if the JSON is
big since it would add more round trips. As for the rest, all the crypto
stuff is mainly about keeping the client from creating the challenge to
avoid attacks. If you make sure the FIDO credentials are all for the
same domain, it isn't an issue if they are forwarded.
Janfred: JSON never goes across the wire. It is hashed, then sent.
Joe: Regarding crypto binding: it is a concern for the middle person
attack as you would not know there is a middle person. Does the webauthn
derive any key material? Or is it just an authentication exchange?
Janfred: No, WebAuthn is completely web, just authentication, it doesn't
impact the HTTPS channel. Thought of including some of the FIDO material
into the exported material for the MSK, but not sure if that would solve
problems.
Joe: This is something we will still have to think about... it may not
be a problem.
Alan: Regarding middle-person attack - who could do that? What else do
you need to do to avoid it. If trying to reuse FIDO where the server
creates challenge, there isn't much more EAP can do to see if there is
no middle-person, since they could just change the challenge.
Joe: Yes. We would have to look into this further, but good server auth
should be enough. How is cert validation done?
Janfred: Current idea is to re-use the same PKI as web.
Joe: Name validation?
Janfred: Name validation would be the same. The current draft requires
specific domain names. We could change that to allow anything that would
be allowed in web PKI.
Alan: Not doing DNS validation, just cert name validation.
Joe: Are you concerned with what certificate you would accept to be a
valid server? Spoofing could be possible if this is opened up...
Alan: This is a policy thing inside of your domain.
Janfred: That is how WebAuthn works now. If you have a cert for a
domain, subdomains could request signatures from that...
Joe: We may need to take a closer look at how validation is done. That
could be a reason why we want more channel binding.
Janfred: Happy to remove channel binding to TLS, but we should make sure
we understand fully what this would impact.
Privacy Pass token is defined in RFC 9576. It is a token valid for
client identification.
EAP-PPT's main objective is providing anonymous network access.
Feedback from IETF 120:
Areas of privacy implications:
Absence of channel binding
draft-01:
key material generation has been introduced
Channel binding:
specifications to protect privacy in:
Deployment considerations
Would like feedback.
Mark: EAP-PPT has been presented to roaming and has been of great
interest. Checked if compatible with Passpoint, and it is. It would be
useful if extensions that would be desired could be included here.
Scott: One question is... is abuse a concern here? E.g., revocation? Do
we need this type of abuse prevention? It seems intuitive here.
Paresh: I agree, I think we need this mechanism to revoke a public key.
Bart: In response to Mark, we can include these details...
Alan: abuse is inevitable. If you can add something to solve this, it
would be positive, as it is a larger issue that is trying to be
resolved.
Mark: We need a mechanism or best-practice for revocation.
Scott: Think about it as blocking this access instead of [...]
Bart: Existing mechanisms do this mostly based on MAC addresses.
Mark: We aren't looking to undo the Privacy Pass work, just looking for
a mechanism to do this.
Alan: If this method has a way to revoke the EAP credentials, it is more
likely for vendors to apply this. There is no other way in RADIUS to
block bad behaviour.
Scott: Non-revocable credentials - let's work collaberatively on this
Joe: There is interest on this, it would be good to continue this
discussion on the list. A charter update may be needed. This may not
currently be in our charter. This could be covered by "out of band
authentication".
Eliot: "out of band authentication" may be in the charter and may
include this.
Joe: Look into this more. Also need to make sure we have coordination
with Privacy Pass. The idea of revocable credentials could be complex.
Should get other opinions.
Eliot: There is a good conversion on revocable credentials, it may
require additional signaling.
Joe: We need to talk this off to the list.
Aritra - working on post-quantum enchancements for EAP-AKA'. Will send
up to mailing list. Would like reviews. Keep an eye out on the mailing
list.