On Oct 6, 2024, at 11:25 AM, Heikki Vatiainen <h...@radiatorsoftware.com> wrote: > 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.
I would say that the current authentication fails, and the peer may try to use any existing credentials. TBH, this discussion really requires a new section on renewing credentials. > 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. I could see an EAP server having multiple provisioning methods, e.g. f...@tls.eap.arp and b...@teap.eap.arpa. If the client sends a request for th...@ttls.eap.arpa, do we want to allow the server to reply with a NAK, suggesting TLS or TEAP? I can see that being useful, but also dangerous. If we forbid it, then we have to require that all EAP NAKs for provisioning NAIs contain type zero (0) only. > 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. My biggest priority is not breaking existing implementations which are in the field. Any provisioning methods sent to a system which doesn't support them MUST be safe. The second priority is to ensure that the provisioning workflows will always work, and do something useful. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
