Re: [Emu] EMU Meetings

[Dan Harkins <[e-mail]>]

   Hello,

On 1/24/22 8:20 PM, Joseph Salowey wrote:
> We are requesting a session at IETF 113.  There has not been a whole 
> lot of discussion on the list of any topic. Before scheduling an 
> interim we would like to understand what the topics would be.
>
> Do we need an interim for EAP-Types or is it ready for last call?
>
> What is the working group interested in meeting on?

   I'd like to present tls-pok (or tls-eap-dpp, or whatever we want to 
call it).
Owen and I did some rejiggering of the exchange based on feedback from
the TLS WG and it's much simpler and more congruent with the TLS exchange
than before. It can slide pretty easily into TEAP (as described in the 
draft).

   We will be updating the repository very soon but I'd like to get on the
agenda for Vienna.

   regards,

   Dan.

>
> Thanks,
>
> Joe
>
>
> On Wed, Jan 19, 2022 at 4:58 AM Alan DeKok <[e-mail]> 
> wrote:
>
>     On Jan 19, 2022, at 6:38 AM, John Mattsson
>     <[e-mail]> wrote:
>     > >    draft-arkko-emu-rfc3748bis
>     >
>     >   I heard significant opposition to that at the last EMU
>     meeting.  I don't see a compelling reason to rev 3748.
>     >
>     > John: I think we should get back to this topic for more
>     discussion on if and how. Bernard expressed opposition to obsolete
>     as he said that would require recertification of products. But
>     there was also a suggestion that we should instead do Internet
>     Standard instead. EAP does definitly deserve to be an Internet
>     Standard. Another suggestion was to make an update instead of
>     obsolete which would not trigger recertification.
>
>       Are there any implementors of EAP who are asking for it to be
>     updated?  From what I can see, the answer is "no".  Which means
>     that the IETF is free to work on a document, but it will be either
>     opposed, or at best, ignored.
>
>     > The following has been brought up as reasons for doing some kind
>     of update:
>     > - EAP is essential for network acces authentication and should
>     be an Internet Standard
>
>       Like RADIUS accounting.  But we've lived for 25+ years without
>     that.  I think it's fine.
>
>     > - "Master" should be changed to "Main" tofollow inclusive
>     language recommendations (TLS is already doing this).
>
>       This reminds me of a comment about "codes of conduct" for
>     software projects.  The observation was that in many cases, the
>     proponents of such codes engaged in such extreme behavior that
>     they should have been banned under the codes which they were
>     proposing.  Yet that never happened.  The only conclusion then is
>     that something else is going on.
>
>       In linguistics these re-naming of "bad" things is called the
>     "euphemism treadmill".  History has other names for such morality
>     plays.
>
>     > - Several of the methods defines in RFC 3748 like MD5-Challenge
>     would benefit from security consideration and references to more
>     recommended methods such as EAP-TLS.
>
>       While that's true, I would like to see how that benefit is worth
>     the effort involved in updating the standard.
>
>     > - There are errata.
>     > - The consideration and recommendations for identity protection
>     is not up to data with current best practice.
>
>       For me, that's been adequately patched in updates to EAP
>     methods.  i.e. methods where identity protection matter. For
>     insecure methods, they're used in situations where identity
>     protection doesn't really matter.
>
>     > - RFC 3748 does not even mention forward secrecy is more and
>     more becoming a requirement to acceptable security.
>     > - Mention new access technologies such as 5G where EAP is an
>     essential part.
>
>       I don't understand how this is useful.
>
>     > - Mention of recommend use of documents such as [RFC4137]
>     [RFC5113] [RFC5247] [RFC6677] [RFC7029].
>     >
>     > IETF is at least nowadays very often making updates such as this
>     (RFC7296, RFC8446bis, RFC7616, RFC8489, RFC8656, RFC8445, etc.)
>     >
>     > My personal view would be that the security considerations
>     considering MD5, identity protection, and forward secrecy would be
>     worthwhile doing in some way. It would also be good to mention
>     essential updates such as RFC 4137.
>
>       Given the significant opposition, I don't see how WG consensus
>     can be achieved here.  The only way forward would be to ignore all
>     of the EAP implementors, and declare consensus despite their
>     objections.
>
>     > >    draft-ingles-eap-edhoc
>     >
>     >   That seems useful for limited situations (i.e. IoT). It also
>     has issues with publicizing identities.
>     >
>     > John: I think the only thing that is missing is to mandate use
>     of ananymous NAIs.
>
>       I don't see any provision in the draft for providing a "real"
>     identity.  So the only NAI used is the outer one, which therefore
>     cannot be fully anonymized.
>
>       Alan DeKok.
>
>     _______________________________________________
>     Emu mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/emu
>
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius