Re: [Emu] Adoption call for eap.arpa

[Mohit Sethi <[e-mail]>]

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 [e-mail] or 
[e-mail] 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 
[e-mail]) from later certificate renewal during 
re-provisioning (NAI [e-mail]). 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: 
[e-mail] for provisioning the certificate and 
[e-mail] 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
> [e-mail]
> 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