On 2019-11-07 12:43 p.m., Alan DeKok wrote: >> E.g. we have documented in >> https://tools.ietf.org/html/draft-lear-eap-teap-brski-05#section-5 that: >> >> " A device that has not been bootstrapped at all SHOULD send an >> identity of teap-bootstrap@TBD1. " >> >> If we register that "teap-bootstrap@TBD1" with IANA, then it could be the >> mechanism by which the peer tells the server that it wants to use TEAP. If >> the server does not support TEAP, it will return an error response. > The discussion prior to IETF 105 was that we should use the ".arpa" domain: > https://www.iana.org/domains/arpa That domain is explicitly intended for > this kind of negotiation.
BTW, related to BRSKI is that the 6tisch CoJP protocol uses 6tisch.arpa in the CoAP header. (Not that we'd use the same one, but registering it wasn't hard) i.e. an EAP Failure message. >> EAP provides no mechanism to return an error code to the peer. How could we >> signal in EAP the error difference between routing vs EAP method unsupported >> failures? Or can we at all? > EAP provides for a NAK for negotiation, and a Notification packet for > signalling errors or messages. Unfortunately, most supplicants don't support > Notification. And the ones that do won't show Notification messages to the > end user. Owen, do we have a need to recognize that a device needs to perform onboarding again after a movement? i.e. device A enrolls on network 1, gets an LDevID usable on network 1, uses that with EAP-FOOBAR. device A then is moved to network 2, it tries to use same LDevID, receives an error and then recognizes that it needs to perform another enrollment. What is that error, and is it recognizeable? Do we need a new error code to distinguish from "I reject you" from "I reject you but, you could try enrolling with BRSKI-TEAP" (hoping re-installed laptop works)
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
