On Mar 21, 2024, at 11:30 PM, Mohit Sethi <mo...@iki.fi> 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 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.
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 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 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. "provision...@vendor.teap.eap.arpa". 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
