I would like to support the adoption of the document with two caveats based on my deployment experience thus far. Obviously, Alan and Heikki have much more expertise and experience than me but just providing a data point:

1. Instead of servers deciding the EAP method based on the username part of the NAI, the EAP method could be decided based on the sub domain under eap.arpa in the realm portion of the NAI. Thus a peer wanting to be provisioned would use provision...@noob.eap.arpa or provision...@tls.eap.arpa depending on whether it supports: EAP-NOOB or EAP-TLS for provisioning. Leaving the username semantics to individual provisioning drafts (example: draft-ietf-emu-bootstrapped-tls) might be beneficial in the long run as explained below.

The username part will likely be needed to distinguish, for example, initial certificate enrollment during provisioning (NAI provision...@teap.eap.arpa) from later certificate renewal during re-provisioning (NAI re-provision...@teap.eap.arpa). I assume the certificates issued will have a limited lifetime and need to be renewed. There are other good reasons where the username part is used to indicate the provisioning state. For example, if provisioning a certificate and a password, the peer may use different username in the NAI: pha...@teap.eap.arpa for provisioning the certificate and pha...@teap.eap.arpa for provisioning the password. There have been proposals in the past about provisioning different types of credentials: https://datatracker.ietf.org/doc/draft-pala-tian-eap-creds-spp/

I have already created a pull request for such a change should this be amenable to Alan and others in the working group: https://github.com/FreeRADIUS/eap-arpa/pull/1

2. It may beneficial to not limit the provisioning to a local network only. First, while developing EAP-NOOB, there was a specific request from Rhys Smith and Josh Howlett from JISC. Their use case wanted to support provisioning of student IoT devices when they were on an exchange semester in a visiting university. See slide 8 onward: https://datatracker.ietf.org/meeting/106/materials/slides-106-emu-slides-106-draft-aura-eap-noob-00.

There are other legitimate reasons for avoiding such limitation. For example, a network owner wants to outsource the provisioning of a new device to the device vendor. Such scenarios were briefly discussed a while back: https://datatracker.ietf.org/doc/html/draft-st-t2trg-nw-access-01 and there was support from Hannes Tschofenig and others. It was later covered in the media as well so I presume there was some interest: https://www.theregister.com/2018/07/25/internet_draft_iot_security/.

Finally, there are situations where the device vendor installs the device at the customer site and uses the the customer network for Internet-connectivity but is still responsible for the device provisioning, lifecycle management, services, maintenance, etc. For example, a bunch of elevators installed at customer premises using customer network for sending back maintenance requests. Here again, the customer intentionally wants the device to be provisioned and managed by a remote vendor server.

I don't think all these scenarios need to be described in this draft. Just removing the limitation is sufficient. My pull request already includes such a change, should this amenable to Alan and others in the working group: https://github.com/FreeRADIUS/eap-arpa/pull/1

If the working group finds these requests amenable and my pull requests are useful, I'd also volunteer to co-author and help drive
this document to the RFC editor queue.

Also, at some later point, if volunteers are needed for the IANA expert registry or something else, I'd be available.

--Mohit

PS: There was also an issue that the current draft recommends Expert Review for assignment of new values but then also expects RFCs: "The intention is that any non-prefix allocation will be accompanied by a published RFC.". I think it will be beneficial to have "Specification Required". Note "Expert Review" and "RFC Required" are separate things in RFC 8126.

On 3/8/24 04:08, Peter Yee wrote:
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dekok-emu-eap-arpa%2F&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C58eafed9abd249bdf0c208dc3ef75f7c%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638454479714860779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=xOYgXpp9COroHW62xnagFFC3Z%2FYzFJM3zGnzaWF4oH0%3D&reserved=0


_______________________________________________
Emu mailing list
Emu@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=05%7C02%7Cmohit.sethi%40aalto.fi%7C58eafed9abd249bdf0c208dc3ef75f7c%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638454479714868956%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=NTbWAghCVLWjPxv6zRImDYLq0qDWgz65V21jF88I%2FAA%3D&reserved=0

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to