Subject: Re: [Emu] EMU Meetings

From: John Mattsson <[email-masked]>
Date: Sat, 15 Jan 2022 11:12:21 +0000

Any updates on this?

I think there is a quite a lot to discuss. I think an interim make a lot of sense.

- The adopted draft-ietf-emu-tls-eap-types and draft-ietf-emu-aka-pfs seems to be more or less done, very important, and need to progess.

- ACE WG seems to be done with draft-ietf-ace-wg-coap-eap. Would be good if more people from EMU WG reviewed this before it goes to IESG.

- There is a large amount of suggested work that might or not fit in the current charter. At some point we should discuss if and how to recharter.

   draft-arkko-emu-rfc3748bis
   draft-dekok-emu-eap-usability
   draft-lear-eap-teap-brski
   draft-mattsson-emu-eap-tls-psk
   draft-ingles-eap-edhoc
   draft-chen-emu-eap-tls-ibs

Cheers,
John

From: Emu <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Date: Wednesday, 29 September 2021 at 17:06
To: EMU WG <[email-masked]>
Subject: [Emu] EMU Meetings
Mohit and I discussed some options for meetings this year.  We think it would be better not to meet at IETF 112 and instead schedule some focused virtual interim meetings where we can address specific issues.  These interims will most likely take place after IETF 112. If you have a topic you would like to cover at an interim please let us know.

Thanks,

The chairs

---

From: Dan Harkins <[email-masked]>
Date: Mon, 17 Jan 2022 14:58:12 -0800

And also draft-friel-tls-eap-dpp.

   Dan.

On 1/15/22 3:12 AM, John Mattsson wrote:
> - The adopted draft-ietf-emu-tls-eap-types and draft-ietf-emu-aka-pfs 
> seems to be more or less done, very important, and need to progess.
>
> - ACE WG seems to be done with draft-ietf-ace-wg-coap-eap. Would be 
> good if more people from EMU WG reviewed this before it goes to IESG.
>
> - There is a large amount of suggested work that might or not fit in 
> the current charter. At some point we should discuss if and how to 
> recharter.
>
> *From: *Emu <[email-masked]> on behalf of Joseph Salowey 
> <[email-masked]>
> *Date: *Wednesday, 29 September 2021 at 17:06
> *To: *EMU WG <[email-masked]>
> *Subject: *[Emu] EMU Meetings
>
> Mohit and I discussed some options for meetings this year.  We think 
> it would be better not to meet at IETF 112 and instead schedule some 
> focused virtual interim meetings where we can address specific 
> issues.  These interims will most likely take place after IETF 112. If 
> you have a topic you would like to cover at an interim please let us 
> know.
>
> Thanks,
>
> The chairs
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> 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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Jan 2022 08:00:59 -0500

> - The adopted draft-ietf-emu-tls-eap-types and draft-ietf-emu-aka-pfs seems to be more or less done, very important, and need to progess.

  Agreed.

> - ACE WG seems to be done with draft-ietf-ace-wg-coap-eap. Would be good if more people from EMU WG reviewed this before it goes to IESG.

  I don't understand that one.  Reading the document doesn't clear up a lot for me.

>    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.

>    draft-dekok-emu-eap-usability

  That's had little discussion.  Recent updates to Passpoint (XML config file, pretty much as proposed by Stefan Winter) make it less relevant.  But it could still be useful.

>    draft-lear-eap-teap-brski

  I have no comments here.

>    draft-mattsson-emu-eap-tls-psk

  This needs a bit of fleshing out.  If we do PSK / password checking in the TLS layer, then the users identity must be public, which compromises privacy.

  I'm not sure how this is preferable to TTLS + PAP.

>    draft-ingles-eap-edhoc

  That seems useful for limited situations (i.e. IoT).  It also has issues with publicizing identities.

>    draft-chen-emu-eap-tls-ibs

  I have the same comments as above.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Wed, 19 Jan 2022 11:38:15 +0000

See inline for additional comments on some of the drafts.

From: Alan DeKok <[email-masked]>
Date: Tuesday, 18 January 2022 at 14:01
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] EMU Meetings

  Agreed.

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.

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
- "Master" should be changed to "Main" tofollow inclusive language recommendations (TLS is already doing this).
- 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.
- There are errata.
- The consideration and recommendations for identity protection is not up to data with current best practice.
- 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.
- 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.

  I have no comments here.

John: I am also very sceptical to the security properties and scope of this draft, which is a reason that is has not been updated. As you say, most use of PSKs compromise privacy. The only exception would be when the PSK identity is only used once.

In some deployments it does not make sense that the background authentication server (which might be owned by a different entity than the authenitcator) has access to the key used to encrypt communication betweed the peer and the authenticator. After the first EAP session, the peer and the authenticator should in such deployments do ECDHE authenticated with the MSK. Not sure if this MSK+ECDHE would be EAP or if it is already solved by any existing methods.

There is also a stange and mostly wrong conception that PSKs are needed for IoT, that is not correct unless you go to ridicolously constrained devices. PSK is never needed for constrained radio as PSK and public key authentication and key exchange can be done in the same message sizes (using implicit authentication or NIKE). The added processing latency is negligible for bootstrapping use cases. Public key authentication require slightly more code, but that is required for forward secrecy anyway and well worth it. Public keys makes key distribution much easier. I think mandatory forward secrecy and identity protection should be requirents in new EAP methods (but if PFS is done between the peer and the authenticator, it might be skipped between the peer and the backend authentication server).

- I think it could maybe make sense to have a good PSK+ECDHE EAP method for use cases where the PSK identity is used once, but that should not focus on IoT. Might be that TTLS + PAP is preferable.

- I also think Russ' use cases of using Certificates and PSK made sense, but that use case will likely be replaced by PQC algorithms quite soon.

- For constrained IoT radio, TLS 1.3 handshake messages are huge. If IoT is the focus I think EAP-EDHOC and/or EAP-cTLS would make a lot more sense.

John: I think the only thing that is missing is to mandate use of ananymous NAIs.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Jan 2022 07:57:44 -0500

> 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 a…

  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.

> - 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.

> - 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.

> - Mention new access technologies such as 5G where EAP is an essential part.

  I don't understand how this is useful.

> 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 essentia…

  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.

> 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.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 24 Jan 2022 20:20:45 -0800

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?

Thanks,

Joe

On Wed, Jan 19, 2022 at 4:58 AM Alan DeKok <[email-masked]>
wrote:

> >   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.
>
> > - "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.
>   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.
> > 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
> >
>   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.
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 25 Jan 2022 09:15:45 -0500

On Jan 24, 2022, at 11:20 PM, Joseph Salowey <[email-masked]> 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.  
> 

  I think it's as ready as it's going to be.  PEAP / TTLS is tested by multiple clients and servers.  There's been less feedback on FAST / TEAP.  So either it's correct, or it's not relevant.

> What is the working group interested in meeting on? 

  There's not a lot left which is critical, I think.

  Alan DeKok.

---

From: Dan Harkins <[email-masked]>
Date: Thu, 27 Jan 2022 13:16:16 -0800

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.
>

   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.

>     >   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.
>
>     > - "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.
>     > 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
>     >
>       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.
>