Kerberos SPAKE Pre-Authentication
draft-ietf-kitten-krb-spake-preauth-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-08-27
|
(System) | Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-kitten-krb-spake-preauth and RFC 9588, changed IESG state to RFC … Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-kitten-krb-spake-preauth and RFC 9588, changed IESG state to RFC Published) |
|
2024-08-22
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2024-06-10
|
13 | (System) | RFC Editor state changed to AUTH48 |
2024-04-02
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2024-02-20
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2024-02-20
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2024-02-20
|
13 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2024-02-16
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2024-02-15
|
13 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'Overtaken by Events' |
2024-02-15
|
13 | Tero Kivinen | Assignment of request for Telechat review by SECDIR to Melinda Shore was marked no-response |
2024-02-09
|
13 | (System) | IANA Action state changed to In Progress |
2024-02-09
|
13 | (System) | RFC Editor state changed to EDIT |
2024-02-09
|
13 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-02-09
|
13 | (System) | Announcement was received by RFC Editor |
2024-02-09
|
13 | (System) | Removed all action holders (IESG state changed) |
2024-02-09
|
13 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-02-09
|
13 | Cindy Morgan | IESG has approved the document |
2024-02-09
|
13 | Cindy Morgan | Closed "Approve" ballot |
2024-02-09
|
13 | Cindy Morgan | Ballot approval text was generated |
2024-02-08
|
13 | Paul Wouters | Last issue on whether a draft is a stable specification text removed, as per IESG ballot request. |
2024-02-08
|
13 | Paul Wouters | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2024-02-08
|
13 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-13.txt |
2024-02-08
|
13 | (System) | New version approved |
2024-02-08
|
13 | (System) | Request for posting confirmation emailed to previous authors: Greg Hudson , Nathaniel McCallum , Robbie Harwood , Simo Sorce |
2024-02-08
|
13 | Greg Hudson | Uploaded new revision |
2024-01-26
|
12 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Melinda Shore |
2024-01-26
|
12 | Gunter Van de Velde | Request closed, assignment withdrawn: Victor Kuarsingh Last Call OPSDIR review |
2024-01-26
|
12 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2024-01-23
|
12 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2024-01-23
|
12 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-01-23
|
12 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-12.txt |
2024-01-23
|
12 | (System) | New version approved |
2024-01-23
|
12 | (System) | Request for posting confirmation emailed to previous authors: Greg Hudson , Nathaniel McCallum , Robbie Harwood , Simo Sorce |
2024-01-23
|
12 | Greg Hudson | Uploaded new revision |
2024-01-18
|
11 | (System) | Changed action holders to Nathaniel McCallum, Simo Sorce, Robbie Harwood, Greg Hudson (IESG state changed) |
2024-01-18
|
11 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2024-01-18
|
11 | Murray Kucherawy | [Ballot comment] In Section 12, we're telling the Designated Experts that an I-D counts as a specification, even if it is never published as an … [Ballot comment] In Section 12, we're telling the Designated Experts that an I-D counts as a specification, even if it is never published as an RFC. But an I-D can expire. Are we OK with having an IANA registry with an entry that claims as its authoritative specification an expired I-D? Section 12.2.2 appears to have four registrations all run together. Could we separate them somehow, either with line breaks or with subsections? Section 4.1: Why is this only a SHOULD? Is it OK if I do something different? Section 4.3: Same question. === Additional comments from incoming ART AD, Orie Steele: 9. Hint for Authentication Sets Why MAY and not SHOULD? Phrasing around MUST NOT and must only could be clearer, and is possibly the reason for the MAYs? 10.2 Unauthenticated Plaintext > Second factor types MUST account for this when specifying the semantics of the data field. It's not clear (to me) how to comply with this MUST, an example of citation might help. In 10.4 Several SHOULD's that maybe ought to be MUSTs? It would be nice to see clearer recommendations on achieving forward secrecy, and on rotating the cookie. |
2024-01-18
|
11 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2024-01-18
|
11 | Warren Kumari | [Ballot comment] I'm going to steal John's opening comment, as it sums um my views nicely: "Thanks for this document. To the extent I was … [Ballot comment] I'm going to steal John's opening comment, as it sums um my views nicely: "Thanks for this document. To the extent I was able to follow it as a decided non-expert, I found it clear and readable." :-) [ Paul has reassured me that process is fine, converting from Abstain to NoObj ] |
2024-01-18
|
11 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Abstain |
2024-01-17
|
11 | Roman Danyliw | [Ballot comment] ** On a process note, I observe that: -- the IETF LC on this document occurred 3.5 years ago (May 2020). Is there … [Ballot comment] ** On a process note, I observe that: -- the IETF LC on this document occurred 3.5 years ago (May 2020). Is there confidence on the consensus? -- the Shepherd Report from January 2019 is wrong about IPR: there was an IPR claim filed in Jun 2020. -- the Shepherd Report comments about referencing draft-irtf-cfrg-spake2-06. That was published as RFC9382 in September 2023. ** Section 2 This mechanism uses a derivation similar to the second algorithm (SPAKE2) with differences in detail. What does “differences in detail” mean? ** Section 2. [SPAKE] needs to be a normative reference. Likewise, as John Scudder mentioned, please improve the current reference text with a DOI pointer. ** Section 4.1. Per the SECDIR review discussion: ==[ snip ]== > Upon receipt of this AS-REQ, a KDC which > requires pre-authentication and supports SPAKE SHOULD reply with a > KDC_ERR_PREAUTH_REQUIRED error, with METHOD-DATA containing an empty > PA-SPAKE PA-DATA element > > SHOULD? Why might it not? What happens if it doesn’t? (So, why isn’t it > MUST, and how can an implementor decide whether it’s OK not to?) A principal might be configured to require specific pre-authentication mechanisms. Or a principal might have no associated long-term keys, in which case only preauth mechanisms like PKINIT or FAST OTP (which do not use long-term keys) can be offered. ==[ snip ]== Consider adding some version of this explanation to the text. I also initially have the same question. ** Section 12.1.1 Reference: URI or otherwise unique identifier for where the details of this algorithm can be found. It should be as specific as reasonably possible. Why is the Reference for "Kerberos Second Factor Types" defined as above but the “Kerberos SPAKE Groups” registry defines references (e.g., Specification, Serialization, etc) to as a “Reference to the definition ...). Aren’t all of these entries some version of “Specification Required”? ** Appendix B. Python needs a normative reference. |
2024-01-17
|
11 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2024-01-17
|
11 | Murray Kucherawy | [Ballot comment] Section 12.2.2 appears to have four registrations all run together. Could we separate them somehow, either with line breaks or with subsections? Section … [Ballot comment] Section 12.2.2 appears to have four registrations all run together. Could we separate them somehow, either with line breaks or with subsections? Section 4.1: Why is this only a SHOULD? Is it OK if I do something different? Section 4.3: Same question. === Additional comments from incoming ART AD, Orie Steele: 9. Hint for Authentication Sets Why MAY and not SHOULD? Phrasing around MUST NOT and must only could be clearer, and is possibly the reason for the MAYs? 10.2 Unauthenticated Plaintext > Second factor types MUST account for this when specifying the semantics of the data field. It's not clear (to me) how to comply with this MUST, an example of citation might help. In 10.4 Several SHOULD's that maybe ought to be MUSTs? It would be nice to see clearer recommendations on achieving forward secrecy, and on rotating the cookie. |
2024-01-17
|
11 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2024-01-17
|
11 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2024-01-17
|
11 | Murray Kucherawy | [Ballot discuss] [For the IESG to discuss] I'd like to discuss some of the procedural stuff that's been raised by others before going to either … [Ballot discuss] [For the IESG to discuss] I'd like to discuss some of the procedural stuff that's been raised by others before going to either ABSTAIN or NO OBJECTION. Basically I have the same concerns as Eric: The shepherd writeup is 4+ years old and doesn't use an approved template; the directorate reviews are stale; IETF Last Call was 3+ years ago. Maybe this is all fine, but I'd like to be sure we talk about it first. In Section 12, we're telling the Designated Experts that an I-D counts as a specification, even if it is never published as an RFC. But an I-D can expire. Are we OK with having an IANA registry with an entry that claims as its authoritative specification an expired I-D? |
2024-01-17
|
11 | Murray Kucherawy | [Ballot comment] Section 12.2.2 appears to have four registrations all run together. Could we separate them somehow, either with line breaks or with subsections? Section … [Ballot comment] Section 12.2.2 appears to have four registrations all run together. Could we separate them somehow, either with line breaks or with subsections? Section 4.1: Why is this only a SHOULD? Is it OK if I do something different? Section 4.3: Same question. |
2024-01-17
|
11 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2024-01-17
|
11 | Warren Kumari | [Ballot comment] Like Eric I am abstaining, simply because I don't really understand the process and somewhat odd timing. I'm assuming that the responsible AD … [Ballot comment] Like Eric I am abstaining, simply because I don't really understand the process and somewhat odd timing. I'm assuming that the responsible AD will be able to reassure me, at which point I'll happily convert this into a NoObjection. I'm going to steal John's opening comment, as it sums um my views nicely: "Thanks for this document. To the extent I was able to follow it as a decided non-expert, I found it clear and readable." :-) |
2024-01-17
|
11 | Warren Kumari | [Ballot Position Update] New position, Abstain, has been recorded for Warren Kumari |
2024-01-17
|
11 | John Scudder | [Ballot comment] Thanks for this document. To the extent I was able to follow it as a decided non-expert, I found it clear and readable. … [Ballot comment] Thanks for this document. To the extent I was able to follow it as a decided non-expert, I found it clear and readable. I have just a few small notes that I hope may be helpful. - Section 4.3 ends with the line, KEY_USAGE_SPAKE 65 I understand this to be, that you're providing the reader with the IANA-assigned value. But without descriptive words around it, it's just puzzling and lacking in context. I think you could safely delete the line, since its information is included in Section 11 and in general it's desirable, in my experience, to have only a single source of truth for this kind of thing. Or otherwise, maybe you can work the information into the prose more smoothly. - Although RFC 7322 section 4.8.6 provides shockingly little guidance about how to format your references, I still think you should try to do better than [SPAKE] Abdalla, M. and D. Pointcheval, "Simple Password-Based Encrypted Key Exchange Protocols", February 2005. which omits some of the usual things like what publication it appeared in. A few seconds of searching took me to https://dl.acm.org/doi/10.1007/978-3-540-30574-3_14, so assuming that authoritative perhaps something like the information provided there would be suitable? ("CT-RSA'05: Proceedings of the 2005 international conference on Topics in Cryptology February 2005 Pages 191–208") - You might want to consider your usage of "man-in-the-middle" in light of https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/. |
2024-01-17
|
11 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2024-01-17
|
11 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2024-01-17
|
11 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-kitten-krb-spake-preauth-11 Thank you for the work put into this document. Due to the very specialised content … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-kitten-krb-spake-preauth-11 Thank you for the work put into this document. Due to the very specialised content of this I-D, I only quickly browsed through it. Please find below some non-blocking COMMENT points. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Global history of the document I find the trajectory of this document really weird, hence my ABSTAIN: * The outdated shepherd write-up is dated 2019-01-23 (i.e., it deserves a refresh about IPR & AD at least) * The IETF Last call is dated 2020-05-12 https://mailarchive.ietf.org/arch/msg/ietf-announce/_PtiER1BI4UJGuSnX2LQn5R1xJU/ ending 2020-05-26 * There is an IPR declaration dated 2020-06-02 * 3.5 years later, it is at IESG evaluation I am trusting the responsible AD for checking the last call comments/reviews and that the IPR declaration should not influence the intended status. ## Section 1.2 `this pre-authentication mechanism`, which one is this ? I guess the Kerberos one but it may be worth being clear on "this". ## Section 1.3 Suggest to expand "OTP" at first use. |
2024-01-17
|
11 | Éric Vyncke | [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke |
2024-01-17
|
11 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2024-01-16
|
11 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2024-01-16
|
11 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2024-01-14
|
11 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2024-01-14
|
11 | Barry Leiba | Assignment of request for Telechat review by SECDIR to Barry Leiba was rejected |
2024-01-12
|
11 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Barry Leiba |
2024-01-12
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2024-01-11
|
11 | Cindy Morgan | Placed on agenda for telechat - 2024-01-18 |
2024-01-11
|
11 | Paul Wouters | Ballot has been issued |
2024-01-11
|
11 | Paul Wouters | [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters |
2024-01-11
|
11 | Paul Wouters | Created "Approve" ballot |
2024-01-11
|
11 | (System) | Changed action holders to Paul Wouters (IESG state changed) |
2024-01-11
|
11 | Paul Wouters | IESG state changed to IESG Evaluation from Waiting for Writeup |
2024-01-11
|
11 | Paul Wouters | Ballot writeup was changed |
2024-01-10
|
11 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-11.txt |
2024-01-10
|
11 | (System) | New version approved |
2024-01-10
|
11 | (System) | Request for posting confirmation emailed to previous authors: Greg Hudson , Nathaniel McCallum , Robbie Harwood , Simo Sorce , kitten-chairs@ietf.org |
2024-01-10
|
11 | Greg Hudson | Uploaded new revision |
2022-06-08
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-06-08
|
10 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-10.txt |
2022-06-08
|
10 | (System) | New version approved |
2022-06-08
|
10 | (System) | Request for posting confirmation emailed to previous authors: Greg Hudson , Nathaniel McCallum , Robbie Harwood , Simo Sorce |
2022-06-08
|
10 | Greg Hudson | Uploaded new revision |
2022-05-25
|
09 | Barry Leiba | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Barry Leiba. Sent review to list. |
2022-05-19
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2022-05-19
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Barry Leiba |
2022-05-19
|
09 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Klaas Wierenga was rejected |
2022-03-23
|
09 | Amy Vezza | Shepherding AD changed to Paul Wouters |
2020-06-12
|
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-10
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-06-10
|
09 | Robbie Harwood | New version available: draft-ietf-kitten-krb-spake-preauth-09.txt |
2020-06-10
|
09 | (System) | New version accepted (logged-in submitter: Robbie Harwood) |
2020-06-10
|
09 | Robbie Harwood | Uploaded new revision |
2020-06-03
|
Jenny Bui | Posted related IPR disclosure Nokia of America Corp's Statement about IPR related to draft-ietf-kitten-krb-spake-preauth and draft-mccallum-kitten-krb-spake-preauth | |
2020-05-26
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-05-22
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-05-22
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-kitten-krb-spake-preauth-07. 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-kitten-krb-spake-preauth-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the Pre-authentication and Typed Data registry on the Kerberos Parameters registry page located at: https://www.iana.org/assignments/kerberos-parameters/ the existing registration for: Type: 151 Name: PA-SPAKE Reference: [draft-ietf-kitten-krb-spake-preauth] will have its reference changed to [ RFC-to-be ]. Second, a new registry is to be created called the Kerberos Second Factor Types registry. IANA Question --> This document says that 'All specifications must be published prior to entry inclusion in the registry.' Does an I-D count as a published specification, or is the intention that an I-D must be published as an RFC before an assignment can be made? For documents produced by other organizations, does making the document available online in any form count as publication? IANA Question --> Where should this new registry be located? Does it belong on the Kerberos Parameters registry page located at: https://www.iana.org/assignments/kerberos-parameters/ or, should it be added to another existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry will be managed via Specification Required as defined in RFC8126. There is a single, initial registration in the new registry as follows: ID Number Name Reference ------------------------------+-----------------+------------ -2147483648 to -1 Reserved for Private and/or Experimental Use 0 Reserved 1 SF-NONE [ RFC-to-be ] 2 to 2147483647 Unassigned Third, a new registry is to be created called the Kerveros SPAKE Groups registry. IANA Question --> Where should this new registry be located? Does it belong on the Kerberos Parameters registry page located at: https://www.iana.org/assignments/kerberos-parameters/ or, should it be added to another existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry will be managed via Specification Required as defined in RFC8126. The registry has values between -2147483648 to 2147483647, inclusive. Value 0 is reserved. There are four initial registrations in the new registry as follows: ID Number: 1 Name: edwards25519 Specification: Section 4.1 of [RFC7748] (edwards25519) Serialization: Section 3.1 of [RFC8032] Multiplier Length: 32 Multiplier Conversion: Section 3.1 of [RFC8032] SPAKE M Constant: d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf SPAKE N Constant: d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab Hash function: SHA-256 ([RFC6234]) ID Number: 2 Name: P-256 Specification: Section 2.4.2 of [SEC2] Serialization: Section 2.3.3 of [SEC1] (compressed format) Multiplier Length: 32 Multiplier Conversion: Section 2.3.8 of [SEC1] SPAKE M Constant: 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f SPAKE N Constant: 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49 Hash function: SHA-256 ([RFC6234]) ID Number: 3 Name: P-384 Specification: Section 2.5.1 of [SEC2] Serialization: Section 2.3.3 of [SEC1] (compressed format) Multiplier Length: 48 Multiplier Conversion: Section 2.3.8 of [SEC1] SPAKE M Constant: 030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba3664 34b363d3dc36f15314739074d2eb8613fceec2853 SPAKE N Constant: 02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca215 18f9c543bb252c5490214cf9aa3f0baab4b665c10 Hash function: SHA-384 ([RFC6234]) ID Number: 4 Name: P-521 Specification: Section 2.6.1 of [SEC2] Serialization: Section 2.3.3 of [SEC1] (compressed format) Multiplier Length: 66 Multiplier Conversion: Section 2.3.8 of [SEC1] SPAKE M Constant: 02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db1 8d37d85608cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b5 6979962d7aa SPAKE N Constant: 0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542b c669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34 9d95575cd25 Hash function: SHA-512 ([RFC6234]) IANA Question --> How should the references to the Standards for Efficient Cryptography Group references appear in the registry? The IANA Functions Operator 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. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-05-20
|
08 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-08.txt |
2020-05-20
|
08 | (System) | New version approved |
2020-05-20
|
08 | (System) | Request for posting confirmation emailed to previous authors: Greg Hudson , Robbie Harwood , Nathaniel McCallum , Simo Sorce |
2020-05-20
|
08 | Greg Hudson | Uploaded new revision |
2020-05-19
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2020-05-19
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2020-05-15
|
07 | Russ Housley | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Russ Housley. Sent review to list. |
2020-05-14
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2020-05-14
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Russ Housley |
2020-05-14
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2020-05-14
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2020-05-12
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-05-12
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-05-26): From: The IESG To: IETF-Announce CC: kaduk@mit.edu, kitten-chairs@ietf.org, draft-ietf-kitten-krb-spake-preauth@ietf.org, kitten@ietf.org, Nicolas … The following Last Call announcement was sent out (ends 2020-05-26): From: The IESG To: IETF-Announce CC: kaduk@mit.edu, kitten-chairs@ietf.org, draft-ietf-kitten-krb-spake-preauth@ietf.org, kitten@ietf.org, Nicolas Williams , nico@cryptonector.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (SPAKE Pre-Authentication) to Proposed Standard The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'SPAKE Pre-Authentication' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-05-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 defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without relying on FAST. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ No IPR declarations have been submitted directly on this I-D. |
2020-05-12
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-05-12
|
07 | Benjamin Kaduk | Last call was requested |
2020-05-12
|
07 | Benjamin Kaduk | Last call announcement was generated |
2020-05-12
|
07 | Benjamin Kaduk | Ballot approval text was generated |
2020-05-12
|
07 | Benjamin Kaduk | Ballot writeup was generated |
2020-05-12
|
07 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-04-30
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-04-30
|
07 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-07.txt |
2020-04-30
|
07 | (System) | New version approved |
2020-04-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: Simo Sorce , Greg Hudson , Robbie Harwood , Nathaniel McCallum |
2020-04-30
|
07 | Greg Hudson | Uploaded new revision |
2020-04-28
|
06 | Benjamin Kaduk | Putting in "revised I-D needed" so it changes to "AD Followup" when the next revision arrives. Sorry for the spam |
2020-04-28
|
06 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-04-04
|
06 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
2019-01-23
|
06 | Robbie Harwood | Summary: Nico Williams is the shepherd, Ben Kaduk is the responsible AD. This document describes a new "pre-authentication" protocol for Kerberos V5 [RFC4120], … Summary: Nico Williams is the shepherd, Ben Kaduk is the responsible AD. This document describes a new "pre-authentication" protocol for Kerberos V5 [RFC4120], one that uses a zero-knowledge password proof for authenticating a client principal to a Kerberos Authentication Server (AS), part of the Kerberos key distribution center (KDC). Besides supporting the use of simple passwords, this method also supports second factors. Review and Consensus: The KITTEN WG mailing list has had a number of threads on the topic of Simple Password Authenticate Key Exchange (SPAKE) for Kerberos, and four on this particular Internet-Draft. Recent threads make it clear that this document is ready for advancement. Some participants have suggested additional features, but there is consensus that these can be added as extensions to this protocol in future updates (the protocol is extensible), or if need be as a new protocol. Intellectual Property: There are no intellectual property disclosures against this document, and all authors have confirmed compliance with BCPs 78 and 79. Note: This draft is targeting Proposed Standard status, and has a normative down-reference to draft-irtf-cfrg-spake2-06, which draft is targeting Informational status, and is not yet out of CFRG. |
2019-01-23
|
06 | Robbie Harwood | Responsible AD changed to Benjamin Kaduk |
2019-01-23
|
06 | Robbie Harwood | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-01-23
|
06 | Robbie Harwood | IESG state changed to Publication Requested from I-D Exists |
2019-01-23
|
06 | Robbie Harwood | IESG process started in state Publication Requested |
2019-01-23
|
06 | Robbie Harwood | Changed consensus to Yes from Unknown |
2019-01-23
|
06 | Robbie Harwood | Intended Status changed to Proposed Standard from None |
2019-01-23
|
06 | Nicolás Williams | Summary: Nico Williams is the shepherd, Ben Kaduk is the responsible AD. This document describes a new "pre-authentication" protocol for Kerberos V5 [RFC4120], … Summary: Nico Williams is the shepherd, Ben Kaduk is the responsible AD. This document describes a new "pre-authentication" protocol for Kerberos V5 [RFC4120], one that uses a zero-knowledge password proof for authenticating a client principal to a Kerberos Authentication Server (AS), part of the Kerberos key distribution center (KDC). Besides supporting the use of simple passwords, this method also supports second factors. Review and Consensus: The KITTEN WG mailing list has had a number of threads on the topic of Simple Password Authenticate Key Exchange (SPAKE) for Kerberos, and four on this particular Internet-Draft. Recent threads make it clear that this document is ready for advancement. Some participants have suggested additional features, but there is consensus that these can be added as extensions to this protocol in future updates (the protocol is extensible), or if need be as a new protocol. Intellectual Property: There are no intellectual property disclosures against this document, and all authors have confirmed compliance with BCPs 78 and 79. Note: This draft is targeting Proposed Standard status, and has a normative down-reference to draft-irtf-cfrg-spake2-06, which draft is targeting Informational status, and is not yet out of CFRG. |
2019-01-23
|
06 | Robbie Harwood | Notification list changed to Nicolas Williams <nico@cryptonector.com> |
2019-01-23
|
06 | Robbie Harwood | Document shepherd changed to Nicolas Williams |
2018-11-15
|
06 | Robbie Harwood | IETF WG state changed to In WG Last Call from WG Document |
2018-08-21
|
06 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-06.txt |
2018-08-21
|
06 | (System) | New version approved |
2018-08-21
|
06 | (System) | Request for posting confirmation emailed to previous authors: Nathaniel McCallum , Robbie Harwood , Simo Sorce , Greg Hudson |
2018-08-21
|
06 | Greg Hudson | Uploaded new revision |
2018-08-14
|
05 | (System) | Document has expired |
2018-02-10
|
05 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-05.txt |
2018-02-10
|
05 | (System) | New version approved |
2018-02-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: Nathaniel McCallum , Robbie Harwood , Simo Sorce , Greg Hudson |
2018-02-10
|
05 | Greg Hudson | Uploaded new revision |
2018-01-24
|
04 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-04.txt |
2018-01-24
|
04 | (System) | New version approved |
2018-01-24
|
04 | (System) | Request for posting confirmation emailed to previous authors: Nathaniel McCallum , Robbie Harwood , Simo Sorce , Greg Hudson |
2018-01-24
|
04 | Greg Hudson | Uploaded new revision |
2017-11-30
|
03 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-03.txt |
2017-11-30
|
03 | (System) | New version approved |
2017-11-30
|
03 | (System) | Request for posting confirmation emailed to previous authors: Nathaniel McCallum , Robbie Harwood , Simo Sorce , Greg Hudson |
2017-11-30
|
03 | Greg Hudson | Uploaded new revision |
2017-10-20
|
02 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-02.txt |
2017-10-20
|
02 | (System) | New version approved |
2017-10-20
|
02 | (System) | Request for posting confirmation emailed to previous authors: Nathaniel McCallum , Robbie Harwood , Simo Sorce , Greg Hudson |
2017-10-20
|
02 | Greg Hudson | Uploaded new revision |
2017-09-15
|
01 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-01.txt |
2017-09-15
|
01 | (System) | New version approved |
2017-09-15
|
01 | (System) | Request for posting confirmation emailed to previous authors: Nathaniel McCallum , Robbie Harwood , Simo Sorce , Greg Hudson |
2017-09-15
|
01 | Greg Hudson | Uploaded new revision |
2017-06-06
|
00 | Benjamin Kaduk | This document now replaces draft-mccallum-kitten-krb-spake-preauth instead of None |
2017-06-06
|
00 | Greg Hudson | New version available: draft-ietf-kitten-krb-spake-preauth-00.txt |
2017-06-06
|
00 | (System) | WG -00 approved |
2017-06-06
|
00 | Greg Hudson | Set submitter to "Greg Hudson ", replaces to draft-mccallum-kitten-krb-spake-preauth and sent approval email to group chairs: kitten-chairs@ietf.org |
2017-06-06
|
00 | Greg Hudson | Uploaded new revision |