[Emu] [IANA #1359904] expert review for draft-ietf-emu-rfc7170bis (teap-parameters)
Dear Margaret Cullen and Nancy Cam-Winget (cc: emu WG), As the designated experts for the TEAP Error TLV (value 5) Error Codes registry, can you review the proposed registration in draft-ietf-emu-rfc7170bis-15 for us? Please see https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/ The due date is March 19. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/teap-parameters/ Please let us know if you would like for us to wait for both reviewers to respond, or if one response is enough. With thanks, David Dong IANA Services Sr. Specialist On Tue Mar 05 20:19:55 2024, david.dong wrote: > Dear Margaret Cullen and Nancy Cam-Winget (cc: emu WG), > > As the designated experts for the TEAP Error TLV (value 5) Error Codes > registry, can you review the proposed registration in draft-ietf-emu- > rfc7170bis-15 for us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/ > > The due date is March 19. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/teap-parameters/ > > Please let us know if you would like for us to wait for both reviewers > to respond, or if one response is enough. > > With thanks, > > David Dong > IANA Services Sr. Specialist ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Tue, 12 Mar 2024, at 14:45, Jan-Frederik Rieckers wrote: > On 12.03.24 13:45, Alexander Clouter wrote: >> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: >>> My understanding here is that the EAP server and client will not >>> authenticate each other in EAP-TLS, and all the authentication will be >>> done in the " captive portal ". So why recommend EAP-TLS as a >>> provisioning method? Just send the identifier "por...@eap.arpa" and >>> then jump to a " captive portal ". Is that OK? >> >> So for OOB provisioning (ie. get an IP to access a captive portal) the >> conversation would be: >> >> >>> EAP-Identity Request >> <<< EAP-Identity Response[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. Nice catch. Cheers ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On 12.03.24 13:45, Alexander Clouter wrote: On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "por...@eap.arpa" and then jump to a " captive portal ". Is that OK? So for OOB provisioning (ie. get an IP to access a captive portal) the conversation would be: EAP-Identity Request <<< EAP-Identity Response[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, 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 | German National Research and Education Network Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1 | 10178 Berlin https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: > My understanding here is that the EAP server and client will not > authenticate each other in EAP-TLS, and all the authentication will be > done in the " captive portal ". So why recommend EAP-TLS as a > provisioning method? Just send the identifier "por...@eap.arpa" and > then jump to a " captive portal ". Is that OK? So for OOB provisioning (ie. get an IP to access a captive portal) the conversation would be: >>> EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa] >>> EAP-Success Sounds sensible. Cheers ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I think this work is useful for bootstrapping IoT devices. I am in favour of adoption. There is also a comment. In Section 5.1 EAP-TLS, " This identifier signals the EAP server that the peer wishes to obtain "peer unauthenticated access" as per [RFC5216] Section 2.1.1 and [RFC9190]. " and " The device SHOULD ignore the EAP server certificate entirely, as the servers identity does not matter. Any verification of servers can be done at the HTTPS layer when the device access the captive portal. " My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "por...@eap.arpa" and then jump to a " captive portal ". Is that OK? Regards, Lei YAN -Original Message- From: Emu On Behalf Of Peter Yee Sent: Friday, March 8, 2024 6:38 AM To: emu@ietf.org Subject: [Emu] Adoption call for eap.arpa This is an adoption call for the eap.arpa Internet-Draft (draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed during the Prague (IETF 118) meeting. Seeing as it primarily exists as a forward-looking extraction of certain descriptive material and IAB .arpa domanrequests from other EMU documents, we consider it within the scope of the WG charter. Alan did a recent minor update to the document and will speak briefly about it during IETF 119. With that said, your WG chairs would appreciate hearing your feedback on whether this document is adopted or not. While it's not critical to adopt, it really simplifies the domain registration for things like TLS-POK and would have been great back when we did EAP-NOOB. We are particularly interested in hearing from parties who are willing to review the specification. So, if you've got interest in seeing the work adopted, please formalize that by responding to the EMU mailing list with your position. The deadline for feedback is March 21st. Yes, that's during IETF 119 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/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Thu, 7 Mar 2024, at 22:38, Peter Yee wrote: > The deadline for feedback is March 21st. Yes, that's during IETF > 119 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! > > 1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/ I am in favour of adoption. Regards ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Opsdir last call review of draft-ietf-emu-rfc7170bis-15
Reviewer: Bo Wu Review result: Has Nits Hi Authors, I am the assigned opsdir reviewer for this document. Overall, the document makes a significant improvement over RFC 7170. This document obsoletes RFC 7170 (Tunnel Extensible Authentication Protocol (TEAP) version 1), and improves the protocols with modifications to several sections of RFC 7170, such as the Introduction, Terminology, TEAP protocol, Message Formats, IANA Considerations, Message Formats, Security considerations, and Examples. This document obsoletes Protected Access Credentials (PAC) from implementation experience and improves the definition of the inner method. Here are some nits I found: 1.2. Terminology Inner method-> Inner Method PKCS: Good to expand on first use. 3.2. TEAP Authentication Phase 1: Tunnel Establishment TLS-PSK: Good to expand on the first use and add reference. 3.3. Server Certificate Requirements Redundant word: Systems SHOULD use a a private Certification Authority (CA) -> Systems SHOULD use a private Certification Authority (CA) 3.4. Server Certificate Validation Redundant period: Further guidance on server identity validation can be found in [RFC9525] Section 6.. -> Further guidance on server identity validation can be found in [RFC9525] Section 6.. In Section 3.6.2: TOTP expand on the first use Redundant word: The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED -> The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED 3.6.4. Limitations on inner methods -> 3.6.4. Limitations on Inner Methods EAP-TLS, EAP-MSCHAPv2, and perhaps EAP-pwd I think it is good to add some reference. 3.6.5. Protected Termination and Acknowledged Result Indication Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange It is not clear to me "except as noted below" is useful here. 3.11.2. Certificate Content and Uses The format of a CSR is complex, and contain a substantial amount of information. -> The format of a CSR is complex, and contains a substantial amount of information. 3.11.3. Server Unauthenticated Provisioning Mode Instead, they should use that mode to set up a secure / authenticated tunnel -> Instead, they should use that mode to set up a secure authenticated tunnel Note that server unauthenticated provisioning -> Server Unauthenticated Provisioning 4.2.13. Crypto-Binding TLV OLD: < 1 Binding Response New: 1 Binding Response 4.2.19. CSR-Attributes TLV The base64 encoding in used -> The base64 encoding is used 4.2.20. Identity-Hint TLV The Identity-Hint TLV is an optional TLV which can sent -> The Identity-Hint TLV is an optional TLV which can be sent When the Identity-Hint is use -> When the Identity-Hint is in use The Identity-Hint TLV is used only as a guide to selecting -> The Identity-Hint TLV is used only as a guide to select 5.3. Computing the Compound MAC is run then no EMSK or MSK will be generated. The sentence is incomplete. 5.4. EAP Master Session Key Generation The label is is the ASCII value for the string without quotes. -> The label is the ASCII value for the string without quotes. I think the Appendix sections better to be placed after the References section. Thanks, Bo Wu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
