On Fri, 4 Oct 2024 at 23:53, Alan DeKok <al...@deployingradius.com> wrote:
> On Oct 4, 2024, at 3:18 PM, Heikki Vatiainen <h...@radiatorsoftware.com> > wrote: > > I was thinking something like this: > > - EAP client has credentials for EAP methodX that are about expire; > provisioning is required > > - The client attempts provisioning with EAP identity ending with > methodX.eap.arpa > > - The server for some reason responds with an EAP methodY, that is, not > methodX > > - The client proceeds with the methodY or NAKs and asks for methodX > > - The server does normal authentication with methodY or methodX > > How does the client do normal authentication when the EAP Identity is > "provision...@teap.eap.arpa" ? > I'm thinking of this from the implementation guidance point of view. When this document is implemented it's likely added to existing clients and servers. When the client or server knows that provisioning does not work at the moment, a fallback and negotiation to a non-provisioned full authentication, if available, must not happen. This fallback is what I wrote about the client or server being helpful. Whoever adds support for this document, must be careful to follow what the document says. Here's an example from draft-ietf-emu-eap-arpa-02 section 3.4.2 For example, an NAI of "@tls.eap.arpa" MUST NOT be used for any EAP method other than EAP-TLS. However, the use described in section 3 is about provisioning. There's nothing about allowing EAP method negotiation to non-provisioned full authentication. To remind implementers, I'd say it's enough to remind them that there must be no EAP method negotiation or selection with a provisioning NAI. The negotiation includes both trying to switch to a EAP method for provisioning or full authentication in case provisioning is deemed as non-operation at the moment. > - The logs show that provisioning realm used while the authentication was > non-provision and full authentication > > > > The client might try to be helpful by attempting to authenticate even if > the provisioning didn't work. Instead of continuing directly, it should > have just reset the link and try full authentication (no provision). > > The only way to do full authentication is with a non-provisioning > identity. > I agree on that. > > The server might have been helpful because it had lost connection to the > provisioning DB or otherwise had determined that it couldn't start > provisioning at this time. Instead of being helpful, the server should be > clear that this authentication can not continue and must fail. > > If the server can't authenticate, it just sends EAP Failure. > In case or provisioning NAI, I agree. To summarise: what I'm attempting is to think about what's useful to consider when adding support for this document into existing client and server implementations. -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
