Re: [Emu] Adoption call for eap.arpa

[Alan DeKok <[e-mail]>]

On Mar 21, 2024, at 11:30 PM, Mohit Sethi <[e-mail]> wrote:
> 
> 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.

  That's a good idea.  My once concern is if IANA / IAB would allow for a separate sub-registry for the subdomains, and allow EMU to control that registry.

> 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 think this is a good idea.

> 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.

  It would be useful to allow some local self-allocation for this case.  So that a site can see requests in the eap.arpa domain, and associate them with a remote vendor that it has a relationship with.

  Perhaps subdomains?  e.g. "[e-mail]".  I'll have to think about that some more.

> 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

  I would lean towards explaining the common use-cases in this document.  Otherwise I'm worried that it either won't meet peoples needs, or people will get it wrong.

> 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.

  I'll take a look.

> 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.

  Agreed.

  Alan DeKok.