[por...@eap.arpa]
EAP-Success
Sounds sensible.
I don't think it's that straight forward.
For Enterprise-WiFi we still need cryptographic keys for the WiFi 4-way
handshake, so establishing a TLS-Tunnel is needed to derive the WPA keys.
Cheers,
Janfred
--
Herr Jan-Frederik Rieckers
Security, T
but after the EMU time slot, so hopefully you will have
formed an opinion by then, if not sooner. We hope to hear
from lots of you!
Joe and Peter
1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@df
On 05.03.24 13:40, Alan DeKok wrote:
On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers wrote:
Well, the beauty of CBOR is that it is very easily extendable.
I completely agree that, with the limited list of map keys, using CBOR instead
of TLVs seems like shooting cannons at mosquitos
uthdata, signature) in a
CBOR map, and have the possibility to put multiple of these maps in the
message.
I'll try to get some Face2Face time with some CBOR experts and talk to
them about the way they would suggest using CBOR in this protocol.
Cheers,
Janfred
--
Herr Jan-Frederik Riecke
If the server side thinks the peer has picked
incorrectly, that is when it responses with the list of PKIDs as it now also
knows the peer's identity.
Cheers,
Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Ma
one? The last
one? Do we abort completely?
I find it better to be explicit, this way we avoid such errors in
implementation from the get-go.
Cheers,
Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-
Thanks so much for the comments.
I'll respond to some from the top of my head, the others I'll address
some time next week.
On 03.03.24 13:39, Alexander Clouter wrote:
Section 4.1.2
-
It just popped up as an idea in my reply to the the SEC review of TEAP but...
EAP-TLS
tf.org wrote:
A new version of Internet-Draft draft-janfred-eap-fido-02.txt has been
successfully submitted by Jan-Frederik Rieckers and posted to the
IETF repository.
Name: draft-janfred-eap-fido
Revision: 02
Title:EAP-FIDO
Date: 2024-03-01
Group:Individual Submission
Pages:
new draft version that includes that too
towards the end of the year.
Cheers,
Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pr
it sounds more like "EAP is not the right thing for IoT"
rather than "EAP-FIDO is not the right thing for IoT"
I will definitely look into the FIDO Device Onboarding specification to
see if this can help make EAP-FIDO more IoT compatible.
Cheers,
Janfred
--
Herr Jan-Fred
onsiderations section.
The idea is to have a similar strong bind to the server certificate in
EAP-FIDO as we have in WebAuthn. How exactly this is achieved is still
TODO, as outlined in the "Open Questions" section in the I-D.
But this strong binding is essential.
Cheers,
Janfred
--
the FIDO public keys from the database.
With the current movement the FIDO alliance is pushing this is actually
a great step, because the FIDO Passkey that is already provisioned for
logging into the account in the web can now simply be used for network
access as well.
Cheers,
Janfred
--
He
ready registered with the
institution. Then it's really just "Hey Phone, I want to use this WiFi
with EAP-FIDO, and my realm is example.com".
Cheers,
Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +
idea, because the latency of end-user action is
immense (esp. if they are not technically versed)
--Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
-
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__
DFN - Deutsches Forschungsnetz | G
ked
FIDO implementations)
Cheers,
Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns:
the WebPKI for the FIDO registration process.
Janfred
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pr
requested a time slot at the emu session on Tuesday, to
shortly present the work.
Any feedback is welcome.
Cheers
Janfred
[1]: https://datatracker.ietf.org/doc/draft-janfred-eap-fido/
--
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services
E-Mail: rieck...@dfn.de | Fon: +4
Hi all,
I have read section 1-3 of the current version of the RFC7170bis draft
and found a few nits:
Section 2.1:
and handles the iapplication data
Section 3.2:
TLS-PSK may work (or not) with TEAP, depending on the status of a
particular implementation, and it
Hi to all,
In the introduction (Section 1 and and 1.3) the phrase "catch-22" is
used twice.
I needed to look up the phrase to know what it meant. I'm sure that I am
not the only one who does not know the meaning of this phrase, so I
suggest the authors reword this so it is clear to everyone
Hi,
I have just published a new version for my EAP-UTE draft I briefly
presented at IETF 113 in Vienna.
https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-ute/
EAP-UTE is an EAP method like EAP-NOOB, which relies on an Out-Of-Band
message to establish a mutual trust between peer and
Hi,
I'd be happy to take notes for all agenda items except the
EAP-NOOB/EAP-UTE discussion.
Greetings
Janfred
--
E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
Hi to all,
For a Masters project at the University of Bremen and in my capacity as
one of the national roaming operators for eduroam in Germany at the
German National Research and Education Network I am currently looking
into EAP-NOOB.
While reading the then draft, now RFC, for EAP-NOOB I
Hi to all,
I have found some small typos.
Section 2.4:
> There no "context_value" ([RFC8446] Section 7.5) passed to the TLS-
> Exporter function.
I suppose an "is" is missing.
Section 3:
At the end of the 6th paragraph
> completely bypass the "inner tunnel" authentication
a dot is missing
Hi to all,
as an operator of a EAP-TLS server for eduroam at the University Bremen
I just want to give some of my thoughts here, feel free to read or
ignore them ;)
The eduroam environment is heavily used for BYOD, so we don't have any
opportunity to change certificates via a Device Management.
On 18.11.19 16:22, Cappalli, Tim (Aruba) wrote:
> So again, if NAIRealm is not bound to an organization’s public domain
> name, how does a public CA prove ownership of an NAIRealm? How is this
> different than ESSID?
It must not be a public domain name, but it can be.
Speaking of eduroam this is
from remote)
Is there room for that?
Jan-Frederik Rieckers
signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On 12.11.19 10:28, Michael Richardson wrote:
> You were trying to do a CSR with some extra attributes with a CA (using
> ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't
> verify?
No, it was a direct request to the CA of our research network. The
problem here was, that the
WPA2-Enterprise can be secure if all devices are part of a
centralized Device Management, but especially in eduroam this isn't
possible. We have a lot of people who don't really care about security.
Jan-Frederik Rieckers
signature.asc
Description: OpenPGP di
in local deployment, the federation
connections are done at higher levels (country research networks), I
don't have an insight there.
Greetings,
Jan-Frederik Rieckers
signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
working group, but I think this is the right group of people for a first
feedback.
Kind regards
Jan-Frederik Rieckers
signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
31 matches
Mail list logo
