Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
draft-ietf-emu-rfc5448bis-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-10-05
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-29
|
10 | (System) | RFC Editor state changed to AUTH48 |
2021-07-08
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-06-09
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-06-09
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-06-09
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-06-01
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-05-26
|
10 | (System) | RFC Editor state changed to EDIT |
2021-05-26
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-05-26
|
10 | (System) | Announcement was received by RFC Editor |
2021-05-26
|
10 | (System) | IANA Action state changed to In Progress |
2021-05-26
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-05-26
|
10 | Amy Vezza | IESG has approved the document |
2021-05-26
|
10 | Amy Vezza | Closed "Approve" ballot |
2021-05-26
|
10 | Amy Vezza | Ballot approval text was generated |
2021-05-26
|
10 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::External Party |
2021-05-10
|
10 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-10.txt |
2021-05-10
|
10 | (System) | New version accepted (logged-in submitter: Jari Arkko) |
2021-05-10
|
10 | Jari Arkko | Uploaded new revision |
2021-04-27
|
09 | Roman Danyliw | 3GPP-IETF coordination meeting occurred on March 17, 2021 |
2021-01-11
|
09 | Roman Danyliw | Authors engaged with 3GPP |
2021-01-11
|
09 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::External Party from Approved-announcement to be sent::AD Followup |
2021-01-11
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-01-11
|
09 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-09.txt |
2021-01-11
|
09 | (System) | New version accepted (logged-in submitter: Jari Arkko) |
2021-01-11
|
09 | Jari Arkko | Uploaded new revision |
2020-10-30
|
08 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2020-10-30
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-10-30
|
08 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-08.txt |
2020-10-30
|
08 | (System) | New version accepted (logged-in submitter: Jari Arkko) |
2020-10-30
|
08 | Jari Arkko | Uploaded new revision |
2020-09-28
|
07 | (System) | Removed duplicate secdir lc review |
2020-07-26
|
07 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2020-04-24
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from Approved-announcement to be sent::Point Raised - writeup needed |
2020-04-09
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2020-04-09
|
07 | Cindy Morgan | Changed consensus to Yes from Unknown |
2020-04-09
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-04-09
|
07 | Robert Wilton | [Ballot comment] One minor comment: I wasn't convinced that this paragraph was needed in the abstract, and thought that it might be better if this … [Ballot comment] One minor comment: I wasn't convinced that this paragraph was needed in the abstract, and thought that it might be better if this was contained in the introduction instead: EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC- SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA. |
2020-04-09
|
07 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-04-09
|
07 | Éric Vyncke | [Ballot comment] Thank you for this document. Please respond to Russ' IOTDIR review: https://mailarchive.ietf.org/arch/msg/iot-directorate/vpbPLLBpdDnbL0A-bBLSEDyRA_M |
2020-04-09
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-04-08
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-04-08
|
07 | Alissa Cooper | [Ballot comment] Why isn't this document on the standards track? I understand that it updates and obsoletes informational documents and I'm assuming there are historical … [Ballot comment] Why isn't this document on the standards track? I understand that it updates and obsoletes informational documents and I'm assuming there are historical 3GPP-related reasons why those documents were informational, but couldn't that be fixed in this update? This certainly seems like it is specifying normative behavior. == Section 5.3.2 == "Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is configured to use." It may be that I'm missing context, but 5.3.1.1 says "A SUPI is either an IMSI or a Network Access Identifier," which makes me wonder what it means to employ a SUPI that is neither an IMSI nor an NAI. == Section 7.1 == "The use of the null scheme is NOT RECOMMENDED where identity privacy is important." I think it might be better to say "The use of the null scheme is NOT RECOMMENDED where the SUCI can be linked to a human user." "The pseudonym usernames and fast re-authentication identities MUST also not be used for other purposes (e.g. in other protocols)." The normative language is not right. I think what you want is: The pseudonym usernames and fast re-authentication identities MUST NOT be used for other purposes (e.g. in other protocols). s/will available/will be available/ It would be good to provide citation(s) for "tunneled EAP methods" since their security properties are not discussed here. |
2020-04-08
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-04-08
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-04-07
|
07 | Benjamin Kaduk | [Ballot comment] I mostly only read the diff and skimmed the rest. Section 1 The rest of this specification is structured as follows. Section … [Ballot comment] I mostly only read the diff and skimmed the rest. Section 1 The rest of this specification is structured as follows. Section 3 defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to prevent bidding down attacks from EAP-AKA'. Section 5 specifies requirements regarding the use of peer identities, including how EAP- AKA' identifiers are used in 5G context. Section 6 specifies what I'm not sure if it's "EAP-AKA' identifiers being used in 5G context" or "5G identifiers being used in an EAP-AKA' context" -- which way does the causality go? Section 4 Note that we assume (Section 7) that EAP-AKA' is always stronger than EAP-AKA. As a result, there is no need to prevent bidding "down" attacks in the other direction, i.e., attackers forcing the endpoints to use EAP-AKA'. I'd prefer to say something like "we do not provide" rather than "there is no need". Section 5.2 I agree with the IoTdir reviewer's concerns about over-stating the need for a secure PRNG in pseudonym generation. Section 5.3.1 In all other cases, the following applies: The identity used in the key derivation formula MUST be exactly the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent, regardless of the kind of identity that it may have been. If no AT_IDENTITY was sent, the identity MUST be the exactly the one sent in the generic EAP Identity exchange, if one was made. Again, the identity MUST be used exactly as sent. If no identity was communicated inside EAP, then the identity is the one communicated outside EAP in link layer messaging. In this case, the used identity MUST be the identity most recently communicated by the peer to the network, again regardless of what type of identity it may have been. Just to check: there's a strong message sequencing, so that there cannot be ambiguity between peers about the "most recently communicated" identity? Section 5.3.1.1 234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org Should this be using an example domain name instead of 3gppnetwork.org? (I think "no", but have to check.) Section 5.3.2.1 For the null-scheme: type0.rid678.schid0.userid0999999999@nai.5gc.mnc015. mcc234.3gppnetwork.org For the Profile protection scheme: type0.rid678.schid1.hnkey27.ecckey. cip.mac@nai.5gc. mnc015.mcc234.3gppnetwork.org [ditto] Section 6 The EAP-AKA' Session-Id is the concatenation of the EAP Type Code (0x32, one byte) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x32 || RAND || AUTN When using fast re-authentication, the EAP-AKA' Session-Id is the concatenation of the EAP Type Code (0x32) with the contents of the [...] nit: the second paragraph contradicts the first, since the first one does not disclaim that it's only for "regular authentication" (non-fast-reauthentication). Section 7 In general, it is expected that the current negotiation capabilities in EAP-AKA' are sufficient for some types of extensions and cryptographic agility, including adding Perfect Forward Secrecy ([I-D.ietf-emu-aka-pfs]) and perhaps others. But as with how EAP-AKA' itself came about, some larger changes may require a new EAP method type. Could we mention that we are not agile with respect to the use of SHA256/HMAC-SHA256? Section 7.2 Basin et al [Basin2018] have performed formal analysis and concluded that the AKA protocol would have benefited from additional security requirements, such as key confirmation. This feels a bit like a teaser -- what would be gained/prevented by using key confirmation? Is there a path towards performing key confirmation in the future? Section 7.3 As described Section 7.2, after the publication of RFC 5448, new nit: "As described in" In particular, it is crucial that manufacturers limit access to the secret information and the cards only to necessary systems and personnel. It is also crucial that secure mechanisms be used to communicate the secrets between the manufacturer and the operator that adopts those cards for their customers. No recommendation for encryption at rest? Beyond these operational considerations, there are also technical means to improve resistance to these attacks. One approach is to provide Perfect Forwards Secrecy (PFS). This would prevent any passive attacks merely based on the long-term secrets and observation of traffic. Such a mechanism can be defined as a backwards- compatible extension of EAP-AKA', and is pursued separately from this specification [I-D.ietf-emu-aka-pfs]. Alternatively, EAP-AKA' authentication can be run inside a PFS-capable tunneled authentication method. In any case, the use of some PFS-capable mechanism is recommended. My preference would be to drop the "Perfect" and also discuss forward secrecy with respect to specific event(s). See also the discussion at https://mailarchive.ietf.org/arch/msg/saag/81XWrBZiLNoPg7kfnAdaxIB8da8/ Section 7.4 The server receives the EAP transaction from a given access network, and verifies that the claim from the access network corresponds to the name that this access network should be using. It becomes impossible for an access network to claim over AAA that it is another access network. In addition, if the peer checks that the information it has received locally over the network-access link layer matches with the information the server has given it via EAP-AKA', it becomes impossible for the access network to tell one story to the AAA network and another one to the peer. These checks prevent some Why is this an "if" the peer checks -- shouldn't it be mandatory? Appendix 9.2 It looks like the only place we reference [FIPS.180-1] and [FIPS.180-2] is in the note saying that we updated the references to them :) |
2020-04-07
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2020-04-07
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-04-07
|
07 | Warren Kumari | [Ballot comment] Oooof. I really dislike the apostrophe in EAP-AKA', but that's a grump at RFC 5448, not this document... |
2020-04-07
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-04-06
|
07 | Erik Kline | [Ballot comment] doc{draft-ietf-emu-rfc5448bis-07} ballot{No Objection} [nits] S1 * "in 5G context" -> "in a 5G context", "in 5G contexts", "in the 5G context" … [Ballot comment] doc{draft-ietf-emu-rfc5448bis-07} ballot{No Objection} [nits] S1 * "in 5G context" -> "in a 5G context", "in 5G contexts", "in the 5G context" S3.1 * "for both non-3GPP access networks for 5G access networks" -> "for both non-3GPP access networks and 5G access networks"? S5.3.2.1 * I assume 23.003 specifies which ECC to use and the encoding of both the ephemeral key and the encrypted version of the MSISN? * Does this NAI risk tripping any length concerns? S6 * Does the Session-Id for fast re-authentication also need to take into consideration the counter? Please forgive my naivety. |
2020-04-06
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-04-04
|
07 | Murray Kucherawy | [Ballot comment] The apostrophe in "EAP-AKA'" makes me think there’s a typo present every time I see it. I primarily reviewed the diff between this … [Ballot comment] The apostrophe in "EAP-AKA'" makes me think there’s a typo present every time I see it. I primarily reviewed the diff between this document and RFC 5448. Nothing stood out to me as needing particular discussion. The thorough treatment on security, privacy, and vulnerability is appreciated. Abstract: * "memo" should really be "document". (This was beaten into me by a previous AD, but I kind of agree with it.) Section 5.1: Nit: * List item (1)(b) is missing a closing parenthesis. Section 7.2: Nit: * "There has also been attacks …" -- s/has/have/ Section 7.3: Nit: * "Perfect Forwards Secrecy …" -- s/Forwards/Forward/ |
2020-04-04
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-04-03
|
07 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2020-03-27
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-03-27
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2020-03-27
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2020-03-24
|
07 | Russ Housley | Request for Telechat review by IOTDIR Completed: Ready with Issues. Reviewer: Russ Housley. Sent review to list. |
2020-03-23
|
07 | Ari Keränen | Request for Telechat review by IOTDIR is assigned to Russ Housley |
2020-03-23
|
07 | Ari Keränen | Request for Telechat review by IOTDIR is assigned to Russ Housley |
2020-03-23
|
07 | Éric Vyncke | Requested Telechat review by IOTDIR |
2020-03-23
|
07 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-03-22
|
07 | Cindy Morgan | Placed on agenda for telechat - 2020-04-09 |
2020-03-22
|
07 | Roman Danyliw | Ballot has been issued |
2020-03-22
|
07 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2020-03-22
|
07 | Roman Danyliw | Created "Approve" ballot |
2020-03-22
|
07 | Roman Danyliw | Ballot writeup was changed |
2020-03-09
|
07 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-07.txt |
2020-03-09
|
07 | (System) | New version accepted (logged-in submitter: Jari Arkko) |
2020-03-09
|
07 | Jari Arkko | Uploaded new revision |
2020-03-09
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-02-24
|
06 | Roman Danyliw | Please respond to GENART and SECDIR Last Call Reviews |
2020-02-24
|
06 | Roman Danyliw | IESG state changed to Waiting for Writeup::Point Raised - writeup needed from Waiting for Writeup |
2020-02-06
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kyle Rose. Submission of review completed at an earlier date. |
2020-02-03
|
06 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2020-01-29
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-01-28
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-01-28
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-emu-rfc5448bis-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-emu-rfc5448bis-06. If any part of this review is inaccurate, please let us know. We understand that upon approval of this document, there is a single action which we must complete. The six references to RFC 5448 at https://www.iana.org/assignments/eapsimaka-numbers and the single reference to that document at https://www.iana.org/assignments/eap-numbers, all of which are named in Sections 8.1-8.3, will be replaced with references to this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-01-27
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kyle Rose. |
2020-01-27
|
06 | Kyle Rose | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Kyle Rose. Sent review to list. |
2020-01-25
|
06 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. Sent review to list. |
2020-01-20
|
06 | Scott Bradner | Assignment of request for Last Call review by OPSDIR to Scott Bradner was rejected |
2020-01-19
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2020-01-19
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2020-01-19
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Kyle Rose |
2020-01-19
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Kyle Rose |
2020-01-16
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-01-16
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2020-01-15
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-01-15
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-01-29): From: The IESG To: IETF-Announce CC: rdd@cert.org, emu@ietf.org, Joseph Salowey , joe@salowey.net, … The following Last Call announcement was sent out (ends 2020-01-29): From: The IESG To: IETF-Announce CC: rdd@cert.org, emu@ietf.org, Joseph Salowey , joe@salowey.net, draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')) to Informational RFC The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')' as Informational RFC 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-01-29. 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 The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the primary authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' is also an algorithm update, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC- SHA-1 as in EAP-AKA. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2020-01-15
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-01-15
|
06 | Roman Danyliw | Last call was requested |
2020-01-15
|
06 | Roman Danyliw | Last call announcement was generated |
2020-01-15
|
06 | Roman Danyliw | Ballot approval text was generated |
2020-01-15
|
06 | Roman Danyliw | Ballot writeup was generated |
2020-01-15
|
06 | Roman Danyliw | IESG state changed to Last Call Requested from Publication Requested |
2020-01-15
|
06 | Roman Danyliw | AD review: https://mailarchive.ietf.org/arch/msg/emu/L06wb8jiwA5ahuSxU-_3bYbWcd8 |
2019-11-18
|
06 | Joseph Salowey | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a revision of an existing informational document (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. Working Group Summary There was consensus for the document in the working group. Document Quality This document is used by 3GPP standards including 5G standards and has had review from members of that community. Personnel Joe Salowey is the document shepherd and Roman Danyliw is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been reviewed by the document shepherd and is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. NA (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No Specific concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Confirmation received from authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The documents predecessor (RFC-5448) has an IPR disclosure https://datatracker.ietf.org/ipr/search/?rfc=5448&submit=rfc which applies to this document as well. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has working group consensus behind it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threat of appeal (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. NA (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. NA (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document will update RFC 4187 and obsolete RFC 5448. These documents are listed in the header, abstract and introduction (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The document does not make changes to the IANA considerations section (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document does not define any new registries and there are designated experts for the existing registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. NA |
2019-11-18
|
06 | Joseph Salowey | Responsible AD changed to Roman Danyliw |
2019-11-18
|
06 | Joseph Salowey | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2019-11-18
|
06 | Joseph Salowey | IESG state changed to Publication Requested from I-D Exists |
2019-11-18
|
06 | Joseph Salowey | IESG process started in state Publication Requested |
2019-11-17
|
06 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-06.txt |
2019-11-17
|
06 | (System) | New version accepted (logged-in submitter: Jari Arkko) |
2019-11-17
|
06 | Jari Arkko | Uploaded new revision |
2019-11-17
|
05 | Joseph Salowey | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a revision of an existing informational document (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. Working Group Summary There was consensus for the document in the working group. Document Quality This document is used by 3GPP standards including 5G standards and has had review from members of that community. Personnel Joe Salowey is the document shepherd and Roman Danyliw is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been reviewed by the document shepherd and is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. NA (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No Specific concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Confirmation received from authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The documents predecessor (RFC-5448) has an IPR disclosure https://datatracker.ietf.org/ipr/search/?rfc=5448&submit=rfc which applies to this document as well. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has working group consensus behind it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threat of appeal (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. NA (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. NA (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document will update RFC 4187 and obsolete RFC 5448. These documents are listed in the header, abstract and introduction (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The document does not make changes to the IANA considerations section (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document does not define any new registries and there are designated experts for the existing registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. NA |
2019-10-30
|
05 | Joseph Salowey | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a revision of an existing informational document (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. Working Group Summary There was consensus for the document in the working group. Document Quality This document is used by 3GPP standards including 5G standards and has had review from members of that community. Personnel Joe Salowey is the document shepherd and Roman Danyliw is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been reviewed by the document shepherd and is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. NA (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No Specific concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Message sent to authors, most have confirmed (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The documents predecessor (RFC-5448) has an IPR disclosure https://datatracker.ietf.org/ipr/search/?rfc=5448&submit=rfc which applies to this document as well. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has working group consensus behind it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threat of appeal (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few references that need to be updated. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. NA (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. NA (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document will update RFC 4187 and obsolete RFC 5448. These documents are listed in the header, abstract and introduction (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). The document does not make changes to the IANA considerations section (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document does not define any new registries and there are designated experts for the existing registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. NA |
2019-10-10
|
05 | Joseph Salowey | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a revision of an existing informational document (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. Working Group Summary There was consensus for the document in the working group. Document Quality This document is used by 3GPP standards including 5G standards and has had review from members of that community. Personnel Joe Salowey is the document shepherd and Roman Danyliw is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document has been reviewed by the document shepherd and is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. NA (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No Specific concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The documents predecessor (RFC-5448) has an IPR disclosure https://datatracker.ietf.org/ipr/search/?rfc=5448&submit=rfc which applies to this document as well. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has working group consensus behind it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threat of appeal (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document will update RFC 4187 and obsolete RFC 5448. These documents are listed in the header, abstract and introduction (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. NA |
2019-10-10
|
05 | Joseph Salowey | Notification list changed to Joseph Salowey <joe@salowey.net> |
2019-10-10
|
05 | Joseph Salowey | Document shepherd changed to Joseph A. Salowey |
2019-10-10
|
05 | Joseph Salowey | Intended Status changed to Informational from None |
2019-07-31
|
05 | Joseph Salowey | Tag Doc Shepherd Follow-up Underway set. |
2019-07-31
|
05 | Joseph Salowey | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2019-07-23
|
05 | Mohit Sethi | Added to session: IETF-105: emu Wed-1330 |
2019-07-08
|
05 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-05.txt |
2019-07-08
|
05 | (System) | New version approved |
2019-07-08
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jari Arkko , Pasi Eronen , Vesa Lehtovirta , Vesa Torvinen |
2019-07-08
|
05 | Jari Arkko | Uploaded new revision |
2019-03-14
|
04 | Mohit Sethi | Added to session: IETF-104: emu Mon-0900 |
2019-01-17
|
04 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-04.txt |
2019-01-17
|
04 | (System) | New version approved |
2019-01-17
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jari Arkko , Vesa Lehtovirta , Vesa Torvinen , Pasi Eronen , emu-chairs@ietf.org |
2019-01-17
|
04 | Jari Arkko | Uploaded new revision |
2018-11-07
|
03 | Joseph Salowey | IETF WG state changed to In WG Last Call from WG Document |
2018-11-04
|
03 | Joseph Salowey | Added to session: IETF-103: emu Mon-1610 |
2018-10-19
|
03 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-03.txt |
2018-10-19
|
03 | (System) | New version approved |
2018-10-19
|
03 | (System) | Request for posting confirmation emailed to previous authors: Jari Arkko , Vesa Lehtovirta , Vesa Torvinen , Pasi Eronen |
2018-10-19
|
03 | Jari Arkko | Uploaded new revision |
2018-09-17
|
02 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-02.txt |
2018-09-17
|
02 | (System) | New version approved |
2018-09-17
|
02 | (System) | Request for posting confirmation emailed to previous authors: Jari Arkko , Vesa Lehtovirta , Vesa Torvinen , Pasi Eronen |
2018-09-17
|
02 | Jari Arkko | Uploaded new revision |
2018-07-02
|
01 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-01.txt |
2018-07-02
|
01 | (System) | New version approved |
2018-07-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jari Arkko , Vesa Lehtovirta , Vesa Torvinen , Pasi Eronen |
2018-07-02
|
01 | Jari Arkko | Uploaded new revision |
2018-06-25
|
00 | Joseph Salowey | This document now replaces draft-arkko-eap-rfc5448bis instead of None |
2018-06-25
|
00 | Jari Arkko | New version available: draft-ietf-emu-rfc5448bis-00.txt |
2018-06-25
|
00 | (System) | WG -00 approved |
2018-06-24
|
00 | Jari Arkko | Set submitter to "Jari Arkko ", replaces to (none) and sent approval email to group chairs: emu-chairs@ietf.org |
2018-06-24
|
00 | Jari Arkko | Uploaded new revision |