Received changes through RFC Editor sync (created alias RFC 8940, changed title to 'Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP)', changed abstract to 'RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods.  The derivation of Session-Id was not given for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication.  The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA.  The derivation of Session-Id for Protected EAP (PEAP) is also given.  The definition for PEAP follows the definition for other TLS-based EAP methods.', changed pages to 7, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-10-23, changed IESG state to RFC Published, created updates relation between draft-ietf-emu-eap-session-id and RFC 5247)

[Ballot comment]
Thanks for all the updates!
It looks like there's one "fast re-authentication" that is split across       
a line (in Section 2.3) and thus escaped the cleanup pass.

[Ballot discuss]
Should be a couple easy ones:

Section 2.2 discusses the "AT_MAC attribute from the
EAP-Request/AKA-Reauthentication" in the context of computing the
EAP-SIM Session-Id, but there is no such EAP-Request message for
EAP-SIM.  Presumably it should be "EAP-Request/SIM/Re-authentication",
and a similar change in Session 2.3 (which would need to cover both the
AKA and SIM cases)?

We need some kind of a reference for PEAP.  (Is
draft-josefsson-pppext-eap-tls-eap tolerable?)

[Ballot comment]
I'm pretty underwhelmed by the level of security analysis that this
document suggests has been done for these new Session-Id constructions.
That said, it's probably still worth publishing the document so that
everyone agrees on the same construction, and they seem to already be in
sufficiently wide use that we'll have a fire drill if there's a problem
with the construction, whether or not we hold up the document to get
more analysis.

RFC 5247 (and 3748) refer to a "fast reconnect" mechanism, not a "fast
re-authentication" mechanism as we discuss it here (though it does
discuss "fast EAP re-authentication").  Is there a consistent
terminology to settle on?

Also, some of the attributes we use for the fast re-authentication
Session-Id generation are encrypted for transit.  Should we say
something about the decrypted version being needed for producing the
right input?

I also want to mention an observation that I made (which may itself be
erroneous), and ask how that relates to the Session-Id usage: in
EAP-AKA, the full authentication's Session-Id construction uses just the
RAND and AUTN, which are server-generated and are related in a way that
can be validated using just(?) the peer's identity as additional input.
When we start pulling in AT_MAC for the fast re-authentication
Session-Id, the MAC can no longer be validated without the context of the
full EAP packet it was obtained from.  I don't know of any case where
there would be a need to do internal consistency checking on a
Session-Id in a way that's made difficult by using AT_MAC divorced from
the containing EAP packet, but it seemed worth checking.

I agree with the genart reviewer that the abstract+introduction should
mention that the definition of Session-Id for EAP-SIM full
authentication gets some additional clarification.

Section 1

  The IEEE is defining FILS authentication [FILS], which needs the EAP

nit: can we expand Fast Initial Link Setup here?

  Further, [RFC5247] did not define Session-Id for PEAP. We correct
  these deficiencies here by updating [RFC5247] with the Session-Id
  derivation during fast-authentication exchange for EAP-SIM and EAP-
  AKA; and defining Session-Id derivation for PEAP.

Perhaps note that this definition for PEAP is for both the
fast-authentication and full-authentication cases?

Section 2.2

It's not entirely clear that we need to expend the text to introduce the
"RAND1", "RAND2", "RAND3" terminology, that AFAICT is not defined in RFC
4186 itself (though it is used in one example).

Also, I'm not entirely sure why we copy the Peer-Id/Server-Id paragraph
unchanged and put the fast re-auth case after it for EAP-SIM, when we
ignored that paragraph for EAP-AKA.

Section 2.3

  re-authentication case. Based on [RFC4187] Section 5.2, and similar
  text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP-

The RFC 4186 text is its section 5.2 (as well), which might be worth
mentioning more clearly.

  Request/AKA-Reauthentication corresponds to AUTN. That would seem to
  imply that the Session-Id could be defined using NONCE_S and MAC
  instead of RAND and AUTN/NONCE_MT.

This "would seem to imply" language is not terribly confidence
inspiring.  Perhaps we want to talk about providing a random value
contributed by the server and a value derived from that random value
with inclusion of secret key material and the peer's identity, which
seem to be the relevant "corresponding properties" to this reader.  My
question above about independent validation still stands, though.

Section 3

  Protected EAP (PEAP).  For consistency with EAP-TLS the definition
  given in [RFC5216] Section 2.3, we define it as:

nit: the grammar here is a bit wonky, perhaps "consistency with the
definition given in [RFC5216] Section 2.3 for EAP-TLS"?

  This definition is already in wide-spread use in multiple PEAP
  implementations.

More details about these implementations (and, for that matter, the
EAP-AKA and EAP-SIM ones) in the shepherd writeup would have been
helpful.

  Note that this definition for Session-Id only applies when TLS 1.2 is
  used.  A different derivation is defined for TLS 1.3 in [TLS-EAP-

Is PEAP defined for use with TLS 1.1 or prior?  (I know that we're in
the process of deprecating TLS prior to 1.2, but that's not quite done
yet.)

Section 4

We probably want to say something about how these constructions are
unique per session and unforgeable+unguessable by an outside party.
(Section 5.10 of RFC 5247 implies a need for the unguessable property.)

"No known security issues" is a pretty low bar.  Who has looked (how
hard?) and what are their qualifications?

Section 6.1

I don't think RFC 6696 needs to be a normative reference.

Acknowledgments

I guess we should mark eid 5011 as "Hold For Document Update" before
this document gets published (it's currently just "Reported")?

[Ballot comment]
Alan,

Thank you for the work put into this document. The short document is easy to read and I am trusting the security AD for the security aspects.

Just wondering why there is no -03 ;-) and suggest to update errata 5011 (that is still open)

Regards

-éric

[Ballot comment]
Like Warren, this document a long way outside of my area of expertise.

However, having said that, I found the document easy to read and follow, and believe that this represents useful work, so thank you.

Regards,
Rob

[Ballot comment]
— Section 2 —

  This section updates [RFC5247] ...
  It further
  defines Session-ID derivation for PEAP.

This section does not address PEAP; that’s done in Section 3.  I suggest removing that last sentence.

— Section 3 —

  [RFC5247] did not define Session-Id definition for Microsoft's
  Protected EAP (PEAP).  For consistency with EAP-TLS the definition
  given in [RFC5216] Section 2.3, we define it as:

Both sentences here need some fixing:

NEW
  [RFC5247] did not define Session-Id for Microsoft's
  Protected EAP (PEAP).  For consistency with the EAP-TLS definition
  given in [RFC5216] Section 2.3, we define it as:
END

[Ballot comment]
Thank you for this document — this is far outside my expertise, so I’m balloting NoObjection, because, well,  I have no objection :-)

Do please see the OpsDir comments at https://datatracker.ietf.org/doc/review-ietf-emu-eap-session-id-03-opsdir-lc-dodge-2020-05-24/ , for some useful nits...

[Ballot comment]
I suspect it would be helpful to expand EAP, EAP-SIM, EAP-AKA, PEAP, and FILS on first use.

Section 2 feels like it's phrased as an erratum.  I suggest removing the explicit citation of the existing document and just include the new text.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-emu-eap-session-id-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-27):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: draft-ietf-emu-eap-session-id@ietf.org, emu@ietf.org, Mohit Sethi <mohit.m.sethi@ericsson.com>, mohit.m.sethi@ericsson.com, rdd@cert.org, emu-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-emu-eap-session-id-02.txt> (EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP) to Proposed Standard


The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'EAP Session-Id Derivation for EAP-SIM,
EAP-AKA, and PEAP'
  <draft-ietf-emu-eap-session-id-02.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA
  when using the fast re-authentication exchange instead of full
  authentication.  This document updates RFC 5247 to define those
  derivations for EAP-SIM and EAP-AKA.  RFC 5247 also does not define
  Session-Id derivation for PEAP.  A definition is given here which
  follows the definition for other TLS-based EAP methods.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/



No IPR declarations have been submitted directly on this I-D.

The RFC type requested is Standards Track. The type of RFC is indicated on the page header. This document updates RFC 5247 and describes how session-Ids are derived during fast resumption for EAP-SIM, EAP-AKA, and PEAP. This information was missing in RFC 5247. Hence the requested RFC type is correct.

Technical Summary: RFC 5247 specifies the EAP key hierarchy and prescribes parameters/keys that EAP authentication methods must export. For EAP authentication methods such as EAP-SIM and EAP-AKA that were published prior to RFC 5247, it defines the exported parameters in Appendix A. Appendix A of RFC 5247 however did not specify the Session-Id parameter to be exported during fast resumption. This document defines the Session-Id to be exported during fast resumption for EAP-SIM, EAP-AKA, and PEAP.

Working Group Summary: The draft has been reviewed by John Mattsson,  Mohit Sethi, and Jouni Malinen. Session-Ids during fast resumption for EAP-SIM and EAP-AKA has been implemented in at least one open source tool by Mohit Sethi. 

Document Quality:  The document itself is very short and ready. There are minor nits. For example, lines are wrapped at random places. The shepherd recommends that the author or the RFC editor fixes them before final publication (by using xml2rfc etc.). All instances of Session-Id should have the 'd' without capitalization. Reference to draft-arkko-eap-rfc5448bis-06.txt needs to be updated.

The document shepherd is Mohit Sethi. The Area Director is Roman Danyliw.

The author has confirmed that he is not aware of any IPR on this draft.

The WG considers that the problem addressed in the document is relevant.  No one has threatened any appeal or indicated extreme discontent. No nits (other than those noted above) were found by the document shepherd.  No other automated checks were performed by the document shepherd.

All normative references are to published IETF and IEEE standards. No downward normative references exist. The publication of this document will update RFC 5247. The categorization of informative and normative references seems to be correct. Note that this draft does not reference or update EAP-SIM, EAP-AKA, and PEAP. This is keeping in line with how RFC 5247 handled the key management update for previously specified EAP authentication methods.

No new IANA registries are created and no changes to existing registries is requested.

The RFC type requested is Standards Track. The type of RFC is indicated on the page header. This document updates RFC 5247 and describes how session-Ids are derived during fast resumption for EAP-SIM, EAP-AKA, and PEAP. This information was missing in RFC 5247. Hence the requested RFC type is correct.

Technical Summary: RFC 5247 specifies the EAP key hierarchy and prescribes parameters/keys that EAP authentication methods must export. For EAP authentication methods such as EAP-SIM and EAP-AKA that were published prior to RFC 5247, it defines the exported parameters in Appendix A. Appendix A of RFC 5247 however did not specify the Session-Id parameter to be exported during fast resumption. This document defines the Session-Id to be exported during fast resumption for EAP-SIM, EAP-AKA, and PEAP.

Working Group Summary: The draft has been reviewed by John Mattsson,  Mohit Sethi, and Jouni Malinen. Session-Ids during fast resumption for EAP-SIM and EAP-AKA has been implemented in at least one open source tool by Mohit Sethi. 

Document Quality:  The document itself is very short and ready. There are minor nits. For example, lines are wrapped at random places. The shepherd recommends that the author or the RFC editor fixes them before final publication (by using xml2rfc etc.). All instances of Session-Id should have the 'd' without capitalization. Reference to draft-arkko-eap-rfc5448bis-06.txt needs to be updated.

The document shepherd is Mohit Sethi. The Area Director is Roman Danyliw.

The author has confirmed that he is not aware of any IPR on this draft.

The WG considers that the problem addressed in the document is relevant.  No one has threatened any appeal or indicated extreme discontent. No nits (other than those noted above) were found by the document shepherd.  No other automated checks were performed by the document shepherd.

All normative references are to published IETF and IEEE standards. No downward normative references exist. The publication of this document will update RFC 5247. The categorization of informative and normative references seems to be correct. Note that this draft does not reference or update EAP-SIM, EAP-AKA, and PEAP. This is keeping in line with how RFC 5247 handled the key management update for previously specified EAP authentication methods.

No new IANA registries are created and no changes to existing registries is requested.