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 <al...@deployingradius.com>
wrote:
On Jan 19, 2022, at 6:38 AM, John Mattsson
<john.matts...@ericsson.com> 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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
