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
