Re: [Emu] Early allocation request for an EAP Method Type number for draft-ietf-emu-eap-noob

[Joseph Salowey <[e-mail]>]

There have been some recent reviews  for EAP-NOOB.  I think it would be
prudent to wait until this round of comments are resolved before moving
forward with the request for early allocation.

On Tue, May 26, 2020 at 1:53 AM Mohit Sethi M <[e-mail]>
wrote:

> I would add that there is also an early implementation of EAP-TLS-PSK:
> https://github.com/rohitshubham/EAP-TLS-PSK
>
> We had agreed that external PSK authentication for EAP-TLS will use a new
> method type number. The draft for EAP-TLS-PSK (
> https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00) is still
> in the early stages and will undergo many changes before it can be
> considered for adoption by the working group. However, allocating a method
> type number for EAP-NOOB now would ensure that EAP-TLS-PSK doesn't use the
> same code point.
>
> --Mohit
> On 5/26/20 6:56 AM, Joseph Salowey wrote:
>
> The authors of EAP-NOOB (draft-ietf-emu-eap-noob) have requested early
> allocation of the EAP type code value 56.  If you object to the early code
> point assignment please let the list know why by June 14, 2020.
>
> The criteria for early assignment includes the following:
>
> A.    The code points must be from a space designated as "RFC Required",
> "IETF Review", or "Standards Action".  Additionally, requests for early
> assignment of code points from a "Specification Required" registry are
> allowed if the specification will be published as an RFC.
>
> EAP Methods have an allocation policy of Designated Expert, with
> Specification Required.  The specification in this case the
> draft-ietf-emu-eap-noob.
>
> B.  The format, semantics, processing, and other rules related to handling
> the protocol entities defined by the code points henceforth called
> "specifications") must be adequately described in an Internet-Draft.
>
> The specification draft-ietf-emu-eap-noob-00 contains the protocol
> specifics.  There are implementations based on this specification listed
> below
>
> C. The specifications of these code points must be stable; i.e., if there
> is a change, implementations based on the earlier and later specifications
> must be seamlessly interoperable.
>
> Although the document is a 00 document, the predecessor document
> draft-aura-eap-noob
> <https://datatracker.ietf.org/doc/draft-aura-eap-noob/> has been
> discussed for over a year.  This call is a request for working group
> members to review the document and object if the specification is not
> stable.
>
> D. There is sufficient interest in the community for early (pre-RFC)
> implementation and deployment, or that failure to make an early allocation
> might lead to contention for the code point in the field.
>
> Several implementations exist, but it would be good to see if there is
> additional interest in implementing this protocol
>
> The authors note that currently, the following implementations of EAP-NOOB
> exist:
>
> 1. Implementation with wpa_supplicant (client) and hostapd (server):
> https://github.com/tuomaura/eap-noob
>
> 2. Lightweight implementation on Contiki (client only):
> https://github.com/eduingles/coap-eap-noob (Tested with server
> implementation from #1)
>
> 3. Minimal EAP-NOOB (based on #1 with cleaner code and updates to match
> current draft version): https://github.com/Vogeltak/eap-noob
>
> Thanks,
>
> Joe
>
> _______________________________________________
> Emu mailing [e-mail]://www.ietf.org/mailman/listinfo/emu
>
>