Diameter Support for the EAP Re-authentication Protocol (ERP)
draft-ietf-dime-erp-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-05-10
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-04-25
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-04-16
|
17 | Jouni Korhonen | Changed shepherd to Jouni Korhonen |
2013-04-15
|
17 | Jouni Korhonen | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2013-04-15
|
17 | Jouni Korhonen | Annotation tag Other - see Comment Log set. |
2013-03-29
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-03-13
|
17 | Jouni Korhonen | Very late update just to keep Datatracker updated. |
2013-03-13
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-03-13
|
17 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-03-13
|
17 | (System) | RFC Editor state changed to EDIT |
2013-03-13
|
17 | (System) | Announcement was received by RFC Editor |
2013-03-13
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-03-12
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-03-12
|
17 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-03-12
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-03-12
|
17 | (System) | IANA Action state changed to In Progress |
2013-03-12
|
17 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-03-12
|
17 | Amy Vezza | IESG has approved the document |
2013-03-12
|
17 | Amy Vezza | Closed "Approve" ballot |
2013-03-12
|
17 | Amy Vezza | Ballot approval text was generated |
2013-03-12
|
17 | Amy Vezza | Ballot writeup was changed |
2013-03-12
|
17 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-03-11
|
17 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss point. One quick check, the diff seems to include a value change for the key type. -16: … [Ballot comment] Thanks for addressing my discuss point. One quick check, the diff seems to include a value change for the key type. -16: The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. -17: The value of the Key-Type AVP MUST be set to 1 for rRK or 2 for rMSK. |
2013-03-11
|
17 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-03-11
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-03-11
|
17 | Glen Zorn | New version available: draft-ietf-dime-erp-17.txt |
2013-02-27
|
16 | Elwyn Davies | Request for Telechat review by GENART Completed: Not Ready. Reviewer: Elwyn Davies. |
2013-01-25
|
16 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Vincent Roca. |
2013-01-24
|
16 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2013-01-24
|
16 | Pete Resnick | [Ballot comment] Thanks to the AD and shepherd for following up on my questions. I will leave it in their hands. |
2013-01-24
|
16 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2013-01-24
|
16 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2013-01-24
|
16 | Sean Turner | [Ballot comment] 1) s8.3.1: Should the values for rRK and rMSK be 1 and 2 and not 2 and 3 based on the registry: Key-Type … [Ballot comment] 1) s8.3.1: Should the values for rRK and rMSK be 1 and 2 and not 2 and 3 based on the registry: Key-Type AVP Values (code 582) Registration Procedures Specification Required Reference [RFC6734] AVP Values Attribute Name Reference 0 DSRK [RFC6734] 1 rRK [RFC6734] 2 rMSK [RFC6734] 3 IKEv2 SK [RFC6738] |
2013-01-24
|
16 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-01-24
|
16 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-01-23
|
16 | Pete Resnick | [Ballot discuss] Two procedural questions for the shepherd and AD. The first one is worthy of a DISCUSS, but I am fine letting the document … [Ballot discuss] Two procedural questions for the shepherd and AD. The first one is worthy of a DISCUSS, but I am fine letting the document go forward once it is answered: The shepherd writeup says: (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. No IPRs have been declared. That doesn't answer the question. Have all of the authors confirmed that they have made all of the appropriate IPR disclosures they are required to make? Has each author been asked, "Have you made all of your required disclosures?" and they've all answered, "Yes, I have no required disclosures to make."? |
2013-01-23
|
16 | Pete Resnick | [Ballot comment] Second question, though I'm certainly not going to hold up the document even if the answer is "no": The shepherd writeup says: … [Ballot comment] Second question, though I'm certainly not going to hold up the document even if the answer is "no": The shepherd writeup says: Document Quality There are no publicly announced implementations of the protocol. Do we know if any are planned? Is there some indication that this protocol is going to get some use? |
2013-01-23
|
16 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2013-01-23
|
16 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2013-01-23
|
16 | Russ Housley | [Ballot comment] The term 'domain' was being very loosely used. Please do not assume that readers knew all the various RFCs which this … [Ballot comment] The term 'domain' was being very loosely used. Please do not assume that readers knew all the various RFCs which this document builds. |
2013-01-23
|
16 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2013-01-23
|
16 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2013-01-23
|
16 | Martin Stiemerling | [Ballot comment] I was surprised by the list of references in the security considerations without any further discussion of any potential new threads that could … [Ballot comment] I was surprised by the list of references in the security considerations without any further discussion of any potential new threads that could arise of DIME ERP. However, I am not a DIAMETER and EAP experts to judge whether the current security considerations are sufficient and a just short cut. |
2013-01-23
|
16 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-01-22
|
16 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-01-22
|
16 | Benoît Claise | State changed to IESG Evaluation from IESG Evaluation::AD Followup |
2013-01-22
|
16 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-01-21
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-01-21
|
16 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2013-01-21
|
16 | Stephen Farrell | [Ballot discuss] This might be a no-brainer, but I wanted to check. RFC 6734 says that messages containing keys MUST be protected either via some … [Ballot discuss] This might be a no-brainer, but I wanted to check. RFC 6734 says that messages containing keys MUST be protected either via some Diameter-specific scheme (an e2e scheme is being developed, but is not yet done, right?) or else via mutually-authenticated TLS or IPsec. This draft says that the security considerations of 6734 apply, which means that the response messages MUST be protected like that if they contain keys. So far so good. However, that leaves open the possibility that the request or error messages defined here could be sent unprotected, or am I mis-reading things? If not, then any attack that could be mounted based on a cleartext request would arguably be new here. Are there such attacks? I'm not sure. Would it help in any case to re-state the MUST from 6734 here but to also include the request messages that (all going well) cause keys to be sent in responses (and error messages) and say that all that has to use the same e.g. TLS session or involve the same entities? (If e.g. TLS was only turned on for responses, then I'd start to be worried about the kind of problem that caused us to do the TLS re-negotiation fix, RFC 5746, but I've not tried to figure out if there's a real new attack yet, maybe the authors thought that through already?) |
2013-01-21
|
16 | Stephen Farrell | [Ballot comment] - I think it'd be clearer to say TBD1 everywhere you mean that rather than sometimes say . Also, are those angle brackets … [Ballot comment] - I think it'd be clearer to say TBD1 everywhere you mean that rather than sometimes say . Also, are those angle brackets missing in the 1st para of section 7? - Ought there be a space in the name of the TBD4 value in 9.1? (I guess not since its not in 10.3) |
2013-01-21
|
16 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-01-17
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-01-17
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-01-10
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Vincent Roca |
2013-01-10
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Vincent Roca |
2013-01-09
|
16 | Benoît Claise | Ballot has been issued |
2013-01-09
|
16 | Benoît Claise | [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise |
2013-01-09
|
16 | Benoît Claise | Created "Approve" ballot |
2013-01-04
|
16 | Benoît Claise | Placed on agenda for telechat - 2013-01-24 |
2012-12-20
|
16 | Elwyn Davies | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Elwyn Davies. |
2012-12-10
|
16 | Glen Zorn | New version available: draft-ietf-dime-erp-16.txt |
2012-12-10
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-12-10
|
15 | Glen Zorn | New version available: draft-ietf-dime-erp-15.txt |
2012-12-04
|
14 | Benoît Claise | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-11-08
|
14 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Vincent Roca. |
2012-10-30
|
14 | Benoît Claise | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-10-22
|
14 | Glen Zorn | New version available: draft-ietf-dime-erp-14.txt |
2012-10-22
|
13 | Glen Zorn | New version available: draft-ietf-dime-erp-13.txt |
2012-09-24
|
12 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-09-19
|
12 | Pearl Liang | IANA has reviewed draft-ietf-dime-erp-12 and has the following comments: IANA has questions about the IANA actions requested in this document. IANA understands that, upon approval … IANA has reviewed draft-ietf-dime-erp-12 and has the following comments: IANA has questions about the IANA actions requested in this document. IANA understands that, upon approval of this document there are three actions which IANA must complete. First, in the Application IDs subregistry of the Authentication, Authorization, and Accounting (AAA) Parameters registry located at: www.iana.org/assignments/aaa-parameters/aaa-parameters.xml a new application ID will be added as follows: ID Value: [ tbd ] Name: Diameter ERP Reference: [ RFC-to-be ] Second, in the AVP Codes subregistry of the Authentication, Authorization, and Accounting (AAA) Parameters registry located at: www.iana.org/assignments/aaa-parameters/aaa-parameters.xml two new AVP Codes will be added as follows: AVP Code: [ TBD ] Attribute Name: ERP-RK-Request Reference: [ RFC-to-be ] AVP Code: [ TBD ] Attribute Name: ERP-Realm Reference: [ RFC-to-be ] Currently the AVP Codes registry for AAA is maintained through expert review as defined in RFC 5226. IANA Question -> has the document been reviewed by the AVP Codes registry expert? Third, in the Result-Code AVP Values (code 268) - Permanent Failure subregistry of the Authentication, Authorization, and Accounting (AAA) Parameters registry located at: www.iana.org/assignments/aaa-parameters/aaa-parameters.xml a new Permanent Failures Result-Code AVP Value will be added as follows: AVP Value: [ TBD ] Attribute Name: DIAMETER_ERROR_EAP_CODE_UNKNOWN Reference: [ RFC-to-be ] IANA understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2012-09-14
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-09-14
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-09-14
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2012-09-14
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2012-09-10
|
12 | Amy Vezza | Ballot writeup was changed |
2012-09-10
|
12 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Diameter Support for the EAP Re-authentication … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Diameter Support for the EAP Re-authentication Protocol (ERP)) to Proposed Standard The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Support for the EAP Re-authentication Protocol (ERP)' 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 ietf@ietf.org mailing lists by 2012-09-24. 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 EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-09-10
|
12 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-09-10
|
12 | Benoît Claise | Last call was requested |
2012-09-10
|
12 | Benoît Claise | Last call announcement was generated |
2012-09-10
|
12 | Benoît Claise | Ballot approval text was generated |
2012-09-10
|
12 | Benoît Claise | Ballot writeup was generated |
2012-09-10
|
12 | Benoît Claise | State changed to Last Call Requested from AD Evaluation |
2012-09-10
|
12 | Benoît Claise | State changed to AD Evaluation from Publication Requested |
2012-07-31
|
12 | Cindy Morgan | (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? … (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? Diameter Support for the EAP Re-authentication Protocol (ERP) is to be published as a Standards Track RFC, which is indicated in the I-D's cover page Intended Status field. Diameter Support for the EAP Re-authentication Protocol complements the Hokey WG's EAP Re-authentication work and provides the needed AAA backend support for both ER servers and EAP servers. (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 The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. Working Group Summary The I-D has been discussed extensively in the DIME WG and has reached the overall working group consensus. The work has been done in a cooperation with the Hokey WG that defined the EAP Re-authentication Protocol solution. Document Quality There are no publicly announced implementations of the protocol. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. (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 reviewed the document after it has concluded the WGLC. The document shepherd thinks the document 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. The document has yet to be reviewed by the AAA and security directorate. (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. The document shepherd has no specific concerns regarding the I-D itself. The document shepherd expects that the long lasting topic on sensitive information transport, such as key material, over Diameter gets discussed again. However, this is a known feature of Diameter and its hop-by-hop security properties. The existing security considerations should cover this when it references to e.g. I-D.ietf-dime-local-keytran. (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. No IPRs have been declared. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPRs have been declared. (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 WG consensus is solid and does not represent only the opinion of few individuals. (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. (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 document passes IDnits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not define MIBs, media types, URIs etc. (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. No. (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. No. (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 only requests for code points and values from an existing IANA registry. (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. None. (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. Checked with IDnits and against ietf-dime-rfc3588bis CCF (a modified ABNF). |
2012-07-31
|
12 | Cindy Morgan | Note added 'Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd.' |
2012-07-31
|
12 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-07-31
|
12 | Cindy Morgan | IESG process started in state Publication Requested |
2012-07-31
|
12 | Glen Zorn | New version available: draft-ietf-dime-erp-12.txt |
2012-07-30
|
11 | Glen Zorn | New version available: draft-ietf-dime-erp-11.txt |
2012-06-03
|
10 | Qin Wu | New version available: draft-ietf-dime-erp-10.txt |
2012-04-01
|
09 | Jouni Korhonen | Annotation tag Other - see Comment Log set. |
2012-04-01
|
09 | Jouni Korhonen | IETF state changed to In WG Last Call from WG Document |
2012-02-09
|
09 | (System) | New version available: draft-ietf-dime-erp-09.txt |
2012-02-09
|
09 | Jouni Korhonen | The WGLC ends 15th April. |
2012-02-09
|
09 | Jouni Korhonen | Two weeks WGLC will end 15th April |
2012-01-13
|
08 | (System) | New version available: draft-ietf-dime-erp-08.txt |
2011-09-06
|
07 | (System) | New version available: draft-ietf-dime-erp-07.txt |
2011-05-04
|
06 | (System) | New version available: draft-ietf-dime-erp-06.txt |
2011-04-28
|
09 | (System) | Document has expired |
2010-10-25
|
05 | (System) | New version available: draft-ietf-dime-erp-05.txt |
2010-09-06
|
04 | (System) | New version available: draft-ietf-dime-erp-04.txt |
2010-03-07
|
03 | (System) | New version available: draft-ietf-dime-erp-03.txt |
2009-10-08
|
02 | (System) | New version available: draft-ietf-dime-erp-02.txt |
2009-08-28
|
01 | (System) | New version available: draft-ietf-dime-erp-01.txt |
2009-01-14
|
00 | (System) | New version available: draft-ietf-dime-erp-00.txt |