EAP Method Update
charter-ietf-emu-08

[Ballot comment]
"EDHOC", paragraph 8
> In summary, the working group shall produce the following documents:
>
> * Documents for the maintenance and update of existing EAP protocols
>
> * Define mechanisms by which EAP methods can support creation of long-term
> credentials for the peer based on initial limited-use credentials.
>
> * Develop an EAP method for use in constrained environments that wish to
> leverage the EDHOC key exchange mechanism.
>
> * Devise a passwordless EAP method that can incorporate use of CTAP2 or other
> similar authentication mechanism.
>
> * An EAP method that provides privacy by preventing a visited network or
> service from knowing the identity of a user, and for keeping the identity
> provider for that user from tracking what networks or services a specific user
> is accessing.

I support Eric's BLOCK on indicating the intended status of the above list of documents.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3GPP, paragraph 0
> At the same time, some new use cases for EAP have been identified. EAP is now
> more broadly in mobile network authentication. The group will update existing
> EAP methods such as EAP-AKA' to stay in sync with updates to the referenced
> 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack.
> Perfect Forward Secrecy (PFS) is an important security property for modern
> protocols to thwart pervasive monitoring. The group will therefore work on an
> extension to EAP-AKA' for providing PFS.

Seem to be missing a word in the sentence "more broadly in mobile network ...". Also, is there a reference for EAP-AKA'?

[Ballot block]
Thanks for the rechartering effort, as usual in a charter, I am expecting to see the intended status of all work items (probably PS in all the work items).

The charter also mention OoB work but nothing appears to be listed so in the work items list.

The two above blocking points should be trivial to be addressed.

[Ballot comment]
And, here are some non-blocking comments:

Should there be a "used" in `AP is now more broadly in mobile network authentication` (also noted by Erik Kline) else I cannot parse it.

While adding PFS as a requirement, what about post-quantum or randomised and changing MAC addresses (with my MADINAS bias here). Should there be some links with IEEE 802 work ?

I also cannot parse the rather complex (and possibly incomplete) ` for keeping the identity provider for that user from tracking what networks or services a specific user is accessing`

[Ballot comment]
# Internet AD comments for charter-ietf-emu-07-00
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* I'm unclear on the technical specifics, but in the "privacy pass" paragraph
  it could be noted that the working group will reuse various things already
  developed and not go off and (re)invent crypto/privacy things?

## Nits

* "is now more broadly in mobile network authentication" ->
  "is now used more broadly in mobile network authentication"?

[Ballot comment]
Please find some minor comments:

# (nit) The charter uses different styles to cite RFCs: "The Extensible Authentication Protocol (EAP) [RFC 3748]" vs "TLS in RFC 8446" "RFC 7258 notes" vs "the EDHOC mechanism (RFC 9528)", etc. Likewise, the charter uses different styles for expanding: "Out-of-band (OOB)" vs. "EDHOC (Ephemeral Diffie-Hellman Over COSE)". Please use a consistent style.

# Some RFC citations will be stale soon (e.g., RFC 8446). Maybe better to soften the use of the RFC labels.

# Maybe get rid of some examples inherited from the OLD charter

CURRENT:
As an example, IETF has standardized a new and improved version..

# Other than 3GPP and VPN that are already from the OLD charter ("authentication framework used, for instance, in VPN and mobile network"), what are the new cases referred to in this part:

CURRENT:
  some new use cases for EAP have been identified

# Keep sync with 3GPP updates and PFS

Just out of curiosity, is "extension to EAP-AKA' for providing PFS" work coming (requested) from the 3GPP?

BTW, the main text promises working on an "extension to EAP-AKA' for providing PFS", but this is not listed in the summary & milestones.

# Stale References

draft-ietf-oauth-device-flow-13 is already published as RFC8628

[Ballot comment]
# Internet AD comments for charter-ietf-emu-06-00
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Nits

* "a recently discovered bug" ->
  "a recently discovered shortcoming" perhaps?

* "recently gained new knowledge" ->
  "recently gained knowledge" perhaps

[Ballot comment]
> The group will accordingly produce a specification for an EAP method incorporating the EDHOC mechanism (draft-ietf-lake-edhoc).

draft-ietf-lake-edhoc has been published as RFC 9528, please update the sentence above.

[Ballot comment]
I agree with comments about having 9 bullets for documents but only three milestones for adopting work. 

Recognizing that milestones can be updated w/out IESG review.... the milestones are for this month (which is half over).  Surely there is work that can be listed that is a little farther out?  This is just weird looking.

[Ballot comment]
# Internet AD comments for charter-ietf-emu-06-00
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Nits

* "a recently discovered bug" ->
  "a recently discovered shortcoming" perhaps?

* "recently gained new knowledge" ->
  "recently gained knowledge" perhaps

[Ballot comment]
I think it would be more use to set milestones for when some work is supposed be finished (send to IESG for publication) rather than when it's supposed to start (WG adoption).

[Ballot comment]
Can we consider just saying "forward secrecy" rather than "perfect forward         
secrecy"?  The "perfect" nature comes with many caveats in general...

[Ballot comment]
Can we consider just saying "forward secrecy" rather than "perfect forward
secrecy"?  The "perfect" nature comes with many caveats in general...

What's the relationship between "identifiers for fast re-authentication" and
"creation of long-term credentials for the peer based on initial limited-use credentials"?

There's a lot of stuff set to happen in Nov 2019; is that all staged and
ready to go?

[Ballot comment]
Just a couple of cosmetic nits...
- the introduction is really long
- in the intro, the specific TLS version should be mentioned
- the trailing prime/quote on EAP-AKA' looks weird but if 3GPP uses AKA', then let's keep it
- last sentence should be terminated by a dot.

[Ballot comment]
Just a couple of cosmetic nits...
- the introduction is really long
- in the intro, the specific TLS version should be mentionned
- the trailing prime/quote on EAP-AKA' looks weird but if 3GPP uses AKA', then let's keep it
- last sentence should be terminated by a dot.

[Ballot comment]
LGTM with some nits below:

 
    - Provide a guidance or update to enable the use of TLS 1.3 in the
      context of EAP TLS (RFC 5216). Update the security
      considerations relating to EAP TLS, to document the implications
      of using new vs. old TLS version, any recently gained new

Nit: versions

  In all of the above, it is a requirement that none of the updates
  break backwards compatibility with existing specifications or
  implementations. The current EAP-TLS RFCs shall not be obsoleted but

s/shall/will/?

  rather updated with either new information or instructions on
  what is needed, for instance, to employ a new TLS version.

Changed charter milestone "Adopt draft on operational recommendations for large certificate and chain sizes", set description to "WG adopts initial draft on operational recommendations for large certificate and chain sizes", set due date to December 2018 from July 2018

Changed charter milestone "Adopt draft to define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA", set description to "WG adopts initial draft on definition of session identifiers for fast re-authentication for EAP-SIM and EAP-AKA", set due date to October 2018 from July 2018

Changed charter milestone "Adopt draft for extension to EAP-AKA to support forward secrecy", set description to "WG adopts initial draft on extension to EAP-AKA to support forward secrecy", set due date to October 2018 from May 2018

Changed charter milestone "Begin work on EAP-AKA update, RFC5448-bis", set description to "WG adopts initial draft on EAP-AKA update, RFC5448-bis, including definition session identifiers for fast re-authentication for EAP-AKA'"

[Ballot comment]
Substantive:

First bullet point: "or other new concerns." makes this very open ended. Is this planned to be a standing working group? If not, can we put some constraints around "other new concerns"?

The prohibition against obsoleting RFCs seems harsh. It's possible to require backwards compatibility without this restriction. I think it should be up to the working group to decide whether work can be better organized using updates or bis-drafts.

The Feb 2019 milestone seems like two milestones.


Editorial:

-3rd paragraph: "And the
understanding of security threats in today's Internet evolves as
well,..."

I suggest dropping "And"

-- 2nd bullet: This is a bit hard to parse. I suggest:

OLD:
    Update the EAP-AKA' specification (RFC 5448) to ensure that its
    capability to provide a cryptographic binding to network context
    stays in sync with what updates may come to the referenced 3GPP
    specifications through the use of EAP in 5G.
NEW:
    Update the EAP-AKA' specification (RFC 5448) to ensure that its
    capability to provide a cryptographic binding to network context
    stays in sync with any 5G related updates to the referenced 3GPP
    specifications.

Same bullet point: The second paragraph seems out of place; was it intended to be its own bullet point?

4th bullet point: The second sentence seems like a non-sequiter. I suggest a top-level bullet point for "Analyzing opportunities to improve privacy..."

[Ballot comment]
Is

"This working group has been chartered to provide updates to some
commonly used EAP method."

really singular? Or should it be "commonly used EAP methods"?

[Ballot comment]
I would actually rather like to see milestones for when the work is supposed to be finished (send to IESG for publication) than when it is supposed to start (wg adoption) as the first is probably harder to achieve in time than the second.

[Ballot comment]
I would actually rather like to see milestones for when the work is supposed to be finished (send to IESG for publication) then when it is supposed to start (wg adoption) as the first is probably harder to achieve in time than the second.

The work items listed in the charter and the charter has been discussed on the EMU list.  The participants prefer to re-open EMU rather than move to a new name.  The work is being driven by several drafts that have surfaced with sufficient interest to start a working group.  This was reviewed at IETF 100 in the SecDispatch portion of the SAAG session and had very good support.