An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
draft-nir-ipsecme-erx-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-01-03
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-01-03
|
11 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-01-02
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-01-02
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-01-02
|
11 | (System) | IANA Action state changed to In Progress |
2013-01-02
|
11 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-01-02
|
11 | Amy Vezza | IESG has approved the document |
2013-01-02
|
11 | Amy Vezza | Closed "Approve" ballot |
2013-01-02
|
11 | Amy Vezza | Ballot approval text was generated |
2013-01-02
|
11 | Amy Vezza | Ballot writeup was changed |
2013-01-02
|
11 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-12-20
|
11 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2012-12-20
|
11 | Ralph Droms | [Ballot comment] I see that the document no longer updates RFC 5996, so I've cleared... |
2012-12-20
|
11 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2012-12-20
|
11 | Yoav Nir | New version available: draft-nir-ipsecme-erx-11.txt |
2012-12-20
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-12-20
|
10 | Yoav Nir | New version available: draft-nir-ipsecme-erx-10.txt |
2012-12-13
|
09 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-12-13
|
09 | Brian Haberman | [Ballot comment] I support Ralph's DISCUSS point. |
2012-12-13
|
09 | Brian Haberman | Ballot comment text updated for Brian Haberman |
2012-12-13
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-12-12
|
09 | Ralph Droms | [Ballot discuss] Consistent with my Discuss position on draft-ietf-tcpm-initcwnd, I object to an Experimental document listing itself as updating a PS document. I realize … [Ballot discuss] Consistent with my Discuss position on draft-ietf-tcpm-initcwnd, I object to an Experimental document listing itself as updating a PS document. I realize there are precedents for Experimental docs updating PS docs. However, in this case, I would be happier with "is an experiment based on" metadata. Lacking that option, I would like to see the "Updates" metadata dropped from this document. And, of course, if the experiment is successful and a PS spec based on this doc is published, it would update RFC 5996. |
2012-12-12
|
09 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms |
2012-12-12
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-12-12
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-12-12
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-12-12
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-12-11
|
09 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-12-10
|
09 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-12-10
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-12-10
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-12-10
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-12-10
|
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-12-09
|
09 | Pete Resnick | [Ballot comment] Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the … [Ballot comment] Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the below and fix. There are 6 occurrences of MUST per 2119. 5 of them seem obviously wrong: Section 3: The IDi payload MUST have ID Type ID_RFC822_ADDR and the data field MUST contain the same value as the KeyName-NAI TLV in the EAP_Initiate/Re-auth message. Section 4: o Protocol ID (1 octet) MUST be zero, as this message is related to an IKE SA. o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 of RFC 5996. o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value assigned for ERX. TBA by IANA. Ask yourself in each case: What would happen if an implementation chose not to do what you say is something that they MUST do? If the answer is, "They wouldn't be implementing the protocol", then the MUST is not being used correctly; you should instead use "will". If the answer is, "They would be implementing the protocol if they did something different, but they fail to interoperate", then the MUST would be correct. In each of the 5 cases above, I cannot figure out how the MUST is justified. The only other MUST is in section 3.1: Section 3.16 of RFC 5996 enumerates the EAP codes in EAP messages which are carried in EAP payloads. The enumeration goes only to 4. It is not clear whether that list is supposed to be exhaustive or not. To clarify, an implementation conforming to this specification MUST accept and transmit EAP messages with at least the codes for Initiate and Finish (5 and 6) from RFC 6696, in addition to the four codes enumerated in RFC 5996. Here, the MUST would be appropriate if you are changing 5996, but if so, you have worded this poorly: Change "an implementation conforming to this specification" to "an implementation of IKEv2". You are saying that *any* IKEv2 EAP implementation MUST handle all 6. If you are not saying that, then the MUST is wrong and should be changed to "will". |
2012-12-09
|
09 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2012-12-09
|
09 | Pete Resnick | [Ballot comment] Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the … [Ballot comment] Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the below and fix. There are 6 occurrences of MUST per 2119. 5 of them seem obviously wrong: Section 3: The IDi payload MUST have ID Type ID_RFC822_ADDR and the data field MUST contain the same value as the KeyName-NAI TLV in the EAP_Initiate/Re-auth message. Section 4: o Protocol ID (1 octet) MUST be zero, as this message is related to an IKE SA. o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 of RFC 5996. o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value assigned for ERX. TBA by IANA. Ask yourself in each case: What would happen if an implementation chose not to do what you say is something that the MUST do? If the answer is, "They wouldn't be implementing the protocol", then the MUST is not being used correctly; you should instead use "will". If the answer is, "They would be implementing the protocol if they did something different, but they fail to interoperate", then the MUST would be correct. In each of the 5 cases above, I cannot figure out how the MUST is justified. The only other MUST is in section 3.1: Section 3.16 of RFC 5996 enumerates the EAP codes in EAP messages which are carried in EAP payloads. The enumeration goes only to 4. It is not clear whether that list is supposed to be exhaustive or not. To clarify, an implementation conforming to this specification MUST accept and transmit EAP messages with at least the codes for Initiate and Finish (5 and 6) from RFC 6696, in addition to the four codes enumerated in RFC 5996. Here, the MUST would be appropriate if you are changing 5996, but if so, you have worded this poorly: Change "an implementation conforming to this specification" to "an implementation of IKEv2". You are saying that *any* IKEv2 EAP implementation MUST handle all 6. If you are not saying that, then the MUST is wrong and should be changed to "will". |
2012-12-09
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-12-06
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2012-12-06
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Joel Halpern |
2012-12-06
|
09 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-12-05
|
09 | Sean Turner | For the record, I screwed up. I forgot that this draft had already been through IETF LC once and there was no need to redo … For the record, I screwed up. I forgot that this draft had already been through IETF LC once and there was no need to redo IETF LC. I asked the IESG Secretary to retract the 2nd IETF LC and they did so. Sorry for any confusion. |
2012-12-04
|
09 | Sean Turner | Removed telechat returning item indication |
2012-12-04
|
09 | Sean Turner | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-12-04
|
09 | Sean Turner | Ballot has been issued |
2012-12-04
|
09 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
2012-12-04
|
09 | Sean Turner | Created "Approve" ballot |
2012-12-04
|
09 | Sean Turner | Ballot writeup was changed |
2012-12-04
|
09 | Cindy Morgan | Second Last Call message was sent in error, and was retracted (see https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11438&tid=1354658477). |
2012-12-04
|
09 | Sean Turner | Telechat date has been changed to 2012-12-13 from 2013-01-10 |
2012-12-04
|
09 | Cindy Morgan | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-12-04
|
09 | Sean Turner | Placed on agenda for telechat - 2013-01-10 |
2012-12-04
|
09 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (An IKEv2 Extension for Supporting ERP) to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'An IKEv2 Extension for Supporting ERP' as Experimental 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 ietf@ietf.org mailing lists by 2013-01-01. 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 This document updates the IKEv2 protocol, described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 6696. The file can be obtained via http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-12-04
|
09 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2012-12-04
|
09 | Sean Turner | Last call was requested |
2012-12-04
|
09 | Sean Turner | State changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup |
2012-12-04
|
09 | Sean Turner | Last call announcement was generated |
2012-12-04
|
09 | Yoav Nir | New version available: draft-nir-ipsecme-erx-09.txt |
2012-12-04
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-12-04
|
08 | Yoav Nir | New version available: draft-nir-ipsecme-erx-08.txt |
2012-11-27
|
07 | Sean Turner | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-11-26
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-11-21
|
07 | Pearl Liang | IANA has reviewed draft-nir-ipsecme-erx-07 and has the following comments: IANA understands that, upon approval of this document, there is a single action which IANA must … IANA has reviewed draft-nir-ipsecme-erx-07 and has the following comments: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the IKEv2 Notify Message Types - Status Types subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml IANA will assign a new IKEv2 notify message type as follows: Value: [ tbd ] NOTIFY MESSAGES - STATUS TYPES: ERX_SUPPORTED Reference: [ RFC-to-be ] IANA understands that, upon approval of this document, this is the only IANA action required to be completed. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-11-03
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2012-11-03
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2012-11-03
|
07 | Jean Mahoney | Assignment of request for Last Call review by GENART to Christer Holmberg was rejected |
2012-11-01
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2012-11-01
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2012-11-01
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2012-11-01
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sandra Murphy |
2012-10-29
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (An IKEv2 Extension for Supporting ERP) to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC The IESG has received a request from an individual submitter to consider the following document: - 'An IKEv2 Extension for Supporting ERP' as Experimental 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 ietf@ietf.org mailing lists by 2012-11-26. 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 This document updates the IKEv2 protocol, described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 6696. The file can be obtained via http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-10-29
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-10-29
|
07 | Sean Turner | Last call was requested |
2012-10-29
|
07 | Sean Turner | Ballot approval text was generated |
2012-10-29
|
07 | Sean Turner | Ballot writeup was generated |
2012-10-29
|
07 | Sean Turner | State changed to Last Call Requested from Publication Requested |
2012-10-29
|
07 | Sean Turner | Last call announcement was generated |
2012-10-29
|
07 | Cindy Morgan | Document Shepherd Writeup Document: draft-nir-ipsecme-erx-07 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this … Document Shepherd Writeup Document: draft-nir-ipsecme-erx-07 (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? Experimental RFC. This is appropriate since the proposed protocol has not been implemented yet. (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 document describes an extension to the IKEv2 protocol that allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension (ERP, RFC 6696). Working Group Summary: This is not the product of any working group. Document Quality: There are no known implementations of the protocol, nor are we aware of vendor plans in this regard. The document has been lightly reviewed by both the HOKEY and the IPsecME working groups. Personnel: Yaron Sheffer is the document shepherd. Sean Turner 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 shepherd has read the document thoroughly, as well as several previous versions. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have previously indicated to the authors that the level of review this document has seen does not warrant publication in the Standards Track. Indeed they have now chosen to publish it as Experimental. (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. As noted, the documented has seen some limited review in the HOKEY group (AAA) and in the IPsecME group (security). (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 such issues. (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. Yes, both authors confirmed so. No such disclosures are required. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No such disclosures have been filed. (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? This is not a WG document. (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 such issues. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The automated tool produces 2 comments. Both of them are bogus - the "IP address" is in fact a section number. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No relevant formal criteria. (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 such issues. (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. None such. (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. This document will update RFC 5996 (IKEv2) in a small way (see Sec. 3.1). Arguably, since use of this protocol is indicated by a notification, even this "updates 5996" is unnecessary. (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 5226). The document defines a single code point, and reasonably so. The IANA expert for the registry (Tero Kivinen) has reviewed the request and has no objections to the request. (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. No 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. No such sections. |
2012-10-29
|
07 | Cindy Morgan | Assigned to Security Area |
2012-10-29
|
07 | Cindy Morgan | Note added 'Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd' |
2012-10-29
|
07 | Cindy Morgan | State Change Notice email list changed to ynir@checkpoint.com, sunseawq@huawei.com, draft-nir-ipsecme-erx@tools.ietf.org, yaronf.ietf@gmail.com |
2012-10-29
|
07 | Cindy Morgan | Intended Status changed to Experimental |
2012-10-29
|
07 | Cindy Morgan | IESG process started in state Publication Requested |
2012-10-29
|
07 | Cindy Morgan | Stream changed to IETF from None |
2012-10-29
|
07 | Sean Turner | Shepherding AD changed to Sean Turner |
2012-08-01
|
07 | Yoav Nir | New version available: draft-nir-ipsecme-erx-07.txt |
2012-08-01
|
06 | Yoav Nir | New version available: draft-nir-ipsecme-erx-06.txt |
2012-07-30
|
05 | Yoav Nir | New version available: draft-nir-ipsecme-erx-05.txt |
2012-05-20
|
04 | Yoav Nir | New version available: draft-nir-ipsecme-erx-04.txt |
2012-04-12
|
03 | Yoav Nir | New version available: draft-nir-ipsecme-erx-03.txt |
2011-11-19
|
02 | (System) | New version available: draft-nir-ipsecme-erx-02.txt |
2011-07-11
|
01 | (System) | New version available: draft-nir-ipsecme-erx-01.txt |
2011-05-01
|
00 | (System) | New version available: draft-nir-ipsecme-erx-00.txt |