Login Security Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-login-security-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-08-03
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-07-28
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-25
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-12
|
10 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2020-03-12
|
10 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Shaun Cooley was marked no-response |
2020-03-09
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-03-09
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-03-09
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-02-28
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-02-28
|
10 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
2020-02-27
|
10 | (System) | RFC Editor state changed to EDIT |
2020-02-27
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-02-27
|
10 | (System) | Announcement was received by RFC Editor |
2020-02-27
|
10 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
2020-02-27
|
10 | (System) | IANA Action state changed to In Progress |
2020-02-27
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-02-27
|
10 | Cindy Morgan | IESG has approved the document |
2020-02-27
|
10 | Cindy Morgan | Closed "Approve" ballot |
2020-02-26
|
10 | Cindy Morgan | Ballot approval text was generated |
2020-02-26
|
10 | Barry Leiba | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-02-26
|
10 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss and Comment points! |
2020-02-26
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-02-26
|
10 | James Gould | New version available: draft-ietf-regext-login-security-10.txt |
2020-02-26
|
10 | (System) | New version approved |
2020-02-26
|
10 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2020-02-26
|
10 | James Gould | Uploaded new revision |
2020-02-24
|
09 | James Gould | New version available: draft-ietf-regext-login-security-09.txt |
2020-02-24
|
09 | (System) | New version approved |
2020-02-24
|
09 | (System) | Request for posting confirmation emailed to previous authors: James Gould , Matthew Pozun |
2020-02-24
|
09 | James Gould | Uploaded new revision |
2020-02-03
|
08 | Roman Danyliw | [Ballot comment] Thank you for talking through or revising the text to address my COMMENT and DISCUSS points. |
2020-02-03
|
08 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-01-31
|
08 | Joseph Yee | Document Shepherd Writeup Draft-ietf-login-security-08 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. … Document Shepherd Writeup Draft-ietf-login-security-08 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. Working Group Summary The WG discussed this topic in both mailing list and at meetings; there are no controversies or lack of coverage. The working group agreed to submit this draft for publication on the Standards Track. There were several in-depth discussions on password complexity and its indicator ‘[LOGIN-SECURITY]’. The WG reached consensus on the approach. Document Quality There is one registry implementation captured in the Implementation Status section. Personnel Shepherd: Joseph Yee AD: Barry Leiba Shepherd Comment The document shepherd reviewed the latest version (-08) of the document and this document’s discussion both on the mailing list and in meetings (both REGEXT). The shepherd has no concern on the depth or breadth of the reviews that have been performed. There are several XML samples and one formal syntax on the XML. The shepherd ran the syntax check against the XML in section 5.1 Formal Syntax and found no error. IPR There is no IPR disclosure regarding this draft. |
2020-01-30
|
08 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS points. |
2020-01-30
|
08 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2020-01-30
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-01-30
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-01-30
|
08 | James Gould | New version available: draft-ietf-regext-login-security-08.txt |
2020-01-30
|
08 | (System) | New version approved |
2020-01-30
|
08 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2020-01-30
|
08 | James Gould | Uploaded new revision |
2020-01-23
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-01-23
|
07 | Alexey Melnikov | [Ballot discuss] Thank you for this document. I have several small comments similar to what was raised by Roman and Ben: 1) In 4.1: … [Ballot discuss] Thank you for this document. I have several small comments similar to what was raised by Roman and Ben: 1) In 4.1: : OPTIONAL client user agent that identifies the client application software, technology, and operating system used by the server to identify functional or security constraints, current security issues, and potential future functional or security issues for the client. The element MUST contain at least one of the following child elements: : OPTIONAL name of the client application software with version if available, such as the name of the client SDK "EPP SDK 1.0.0". : OPTIONAL technology used for the client software with version if available, such as "Java 11.0.2". : OPTIONAL client operating system used with version if available, such as "x86_64 Mac OS X 10.11.6". Is there a registry of allowed values or at least some instructions how to construct these values? There are probably several existing IETF registries that can be reused. If these values are not supposed to be used by servers for anything other than logging (i.e. if they can't be used to work around bugs), then the document needs to say that. 2) In the same section: : OPTIONAL plain text password that is case sensitive, has a minimum length of 6 characters, and has a maximum length that is up to server policy. All leading and trailing whitespace is removed, and all internal contiguous whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 (space) is replaced with a single #x20 (space). This element MUST only be used if the [RFC5730] element is set to the "[LOGIN-SECURITY]" value. What is the definition of "whitespace"? Does this only include characters listed above or does it also include other Unicode characters (e.g. Unicode whitespace property)? If the former, then instead of using "whitespace that includes ..." use something like "whitespace is defined as one of ..." : OPTIONAL plain text new password that is case sensitive, has a minimum length of 6 characters, and has a maximum length that is up to server policy. All leading and trailing whitespace is removed, and all internal contiguous whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 (space) is replaced with a single #x20 (space). This element MUST only be used if the [RFC5730] element is set to the "[LOGIN-SECURITY]" value. As above. |
2020-01-23
|
07 | Alexey Melnikov | [Ballot comment] 8. Security Considerations The extension leaves the password ( element) and new password ( element) minimum length beyond 6 characters and … [Ballot comment] 8. Security Considerations The extension leaves the password ( element) and new password ( element) minimum length beyond 6 characters and the maximum length up to sever policy. Typo: sever -> server |
2020-01-23
|
07 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2020-01-23
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-01-22
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2020-01-22
|
07 | Alissa Cooper | [Ballot comment] Thanks for addressing my ballot comments. |
2020-01-22
|
07 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2020-01-22
|
07 | Benjamin Kaduk | [Ballot discuss] This document+extension claims to provide "Login Security" but has no substantive discussion of why the previous mechanism was insecure and how this extension … [Ballot discuss] This document+extension claims to provide "Login Security" but has no substantive discussion of why the previous mechanism was insecure and how this extension improves the security. I find it hard to believe that any such discussion could fail to acknowledge that sending the plaintext password (after only processing for whitespace) to the server (akin to SASL PLAIN) is severely lacking on several security-related fronts. While it may be possible that there is adequate justification for only pursuing the smallest incremental improvement in the current document, it would require some additional discussion to convince me that the "small incremental improvement" of removing a protocol-level maximum password length is the best choice at this time, as opposed to a broader approach that attempts to tackle more axes upon which "security" can be measured. Does this discussion already exist somewhere? (This document also includes functionality for relatively rich event notifications, that are likely worth doing in their own right, but do not seem to be "security improvements" per se, to me.) I also think that there many places in the description of the XML elements/attributes that are underspecified, given that XML is traditionally thought of as a machine-readable format. Several instances have already been noted by my fellow IESG members (e.g., custom events, statistical warnings, "value" attribute), but they seem prevalent enough that I would like to see the authors make a pass through all the protocol elements and assess which ones need to be machine-readable vs. only for human consumption, and accurately document that. I list some examples in the Comment section, and specifically call out the and encodings, which leaves many ambiguities with respect to what non-ASCII behavior is allowed other than OpaqueString, what constitutes "whitespace" in the two listed situations, and whether the password encoding is related to the XML document encoding of the request. As I note in the comment, my understanding was that the PRECIS profiles were intended to be used at a protocol-level (vs. a deployment level) and thus the nature of the profile usage would be fairly tightly specified by this document; perhaps the responsible AD (or someone else) will correct my understanding. I'd also like to have a bit of discussion regarding the prohibition of using the literal string "[LOGIN-SECURITY]" as an actual password. Section 3.2 notes '''[t]he server MUST NOT allow the client to set the password to the value "[LOGIN-SECURITY]"''', and though I did not do a full case-by-case analysis, this feels like something that a server implementing this extension wants to do always, regardless of whether a given client indicates support for this extension. That seems like it could meet the criteria to mark this document as Updating RFC 5730, to reserve this sentinel value. Is there more reasoning for or against having this document Update the password-handling behavior RFC 5730 to reserve this sentinel value? |
2020-01-22
|
07 | Benjamin Kaduk | [Ballot comment] (per the first Discuss point) I understand that per RFC 5734 we're always using TLS client certificates to identify the client machine (but … [Ballot comment] (per the first Discuss point) I understand that per RFC 5734 we're always using TLS client certificates to identify the client machine (but can have multiple user credentials using the same client certificate for their TLS connections), but that doesn't completely alleviate the problems inherent to passwords (see Discuss). For example, with passwords there's the risk of password theft, whether from the on-disk server password database or by leveraging a fraudulent TLS server certificate to capture live incoming traffic, but that's not a complete listing. Section 1 (Side note: I note that the phrase "security event" is used as a term of art by the SECEVENT WG, for the "security event token" work of RFC 8417 and its consumers. They seem to have a somewhat different set of expected "security events", not that this document necessarily needs to change in response.) (side note: IMHO, the long list of security-event attributes (and possibly the security events themselves) is not needed in a high-level Introduction like this. But that's not an actionable comment.) Section 2 Servers which implement this extension SHOULD provide a way for clients to progressively update their implementations when a new version of the extension is deployed. Servers SHOULD (for a temporary migration period up to server policy) provide support for older versions of the extension in parallel to the newest version, and allow clients to select their preferred version via the element of the command. I see the opsdir review (and response), but I can't help wondering if this second paragraph is a proposed way to meet the requirement^Wrecommendation of the first paragraph. If so, it would be tempting to make the first one into a "MUST", since we really think it's important that servers should do this in some way, though we don't have as strong an opinion on how. (I do not expect my reasoning to convince you more if the opsdir review did not, though, so feel free to treat this as a side note.) I also think that the response to the genart review was incomplete -- the genart reviewer's point about knowing, given two versions of this extension, which one is said to be "newer" is perhaps still open. (Suppose version 1.1 is published in 2021, 2.0 in 2022, and 1.2 in 2.23. Is version 2.0 "newer than" 1.2?) I didn't find much in 5730 that we could lean on, though it's kind of drowned out by the sea of ''' MAY include a free-form description. All of the nit: I'm not sure whether we want to consider "" as an adjective (" element") or a noun in its own right, but I am having a hard time with the definite article in the current text. Since the previous sentence talks about multiple events being allowed, maybe "Each" is best? (Also, is this description "as the body of the element"?) "type": A REQUIRED attribute that defines the type of security event. The enumerated list of "type" values includes: [...] (side note: the specific "type" values chosen by the authors is rather different from what I would have written. It feels a bit presumptuous to assume that expiration is the only password- or certificate-related event that could occur and privilege those events to have the bare "password" and "certificate" type values, for example. I don't know what the server would do to convey knowledge of a breach of the server's password database file, for example But what's there is clearly documented so I have no real grounds to object to it per se.) "exDate": Contains the date and time that a "warning" level has or will become an "error" level. At expiry there MAY be an error to connect or MAY be an error to login. An example is an expired The "MAY"s feel a little out of place here, and I would suggest "At this expiration time, the error might be realized as either a connection failure or a login failure" to also avoid the "error to" construction that flows strangely to my eye. "value": Identifies the value that resulted in the login security event. An example is the negotiated insecure cipher suite or the negotiated insecure TLS protocol. Right now the encoding used for this value feels highly under-specified. Consider the case of an insecure TLS cipher suite. IANA manages a table of TLS ciphersuites (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) so one might see a pair of hex values, a single four-hex-digit-string, a human-readable "Description", the decimal value corresponding to the four-hex-digit-string, etc. I mostly expect that this value will only ever be displayed to a human and is not expected to be machine-parseable, but we really need to say that if so (and perhaps also that the human-readable string form is preferred when there are multiple choices). Example login security event for password expiration, where the current date is 2018-03-25: I appreciate the use of a "current date" for purposes of the example; that's a nice touch! Section 3.2 The element MUST override the [RFC5730] element only if the contains the predefined value of "[LOGIN-SECURITY]", which is a constant value for the server to use the element for the password. Similarly, the element nits(?): the "MUST override [...] only if" construction seems prone to misreading (both here and for "). Is it a prohibition against overriding in other scenarios? A mandate to override? Both? Perhaps a declarative "When the element contains the predefined value "[LOGIN-SECURITY]", the element overrides the element" is more clear. Also, there seems to be a word or two missing for the current formulation to parse properly, in "is a constant value for the server to use the element for the password" -- perhaps saying that this "indicates to" the server. (I myself would use the phrase "sentinel value" to describe this password string, but maybe that's overused.) Section 3.3 Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters. nit(?): "the EPP XML Schema" or "this protocol's XML Schema", I think. Section 4.1 Sending detailed userAgent information seems to merit some discussion of privacy considerations w.r.t user profiling and/or tracking. : OPTIONAL client user agent that identifies the client application software, technology, and operating system nit: is this better as "client user agent information"? : OPTIONAL plain text password that is case sensitive, has a minimum length of 6 characters, and has a maximum length Why is it optional? Also, 6 characters feels a bit short for a password, these days. (Yes, I did pull up SP 800-63B.) that is up to server policy. All leading and trailing whitespace is removed, and all internal contiguous whitespace that includes We list explicitly the values considered "internal whitespace" but not "leading and trailing whitespace". I note that using Unicode attributes to determine whitespace nature (which would seem reasonable to many people) will recognize quite a few more codepoints as being whitespace, and it is important to have a clear and unambiguous procedure. #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 (space) is replaced with a single #x20 (space). This element MUST only be used if the [RFC5730] element is set to the "[LOGIN-SECURITY]" value. What does "only be used" mean? Is this restricting transmission from the client or processing by the server, or both? What should the error handling behavior be when it is present and it's not supposed to be? [ditto for ] (space) - #x7E (~), with high entropy, such as 128 bits. If non- ASCII characters are supported with the plain text password, then use a standard for passwords with international characters, such as the OpaqueString PRECIS profile in [RFC8265]. My understanding is that the PRECIS profiles are intended to be used at a per-protocol level, not a per-deployment level. So this needs to be stronger than just "such as". Also, if (as per the example) this is carried in a client's XML request that contains an "encoding" attribute, what's the interaction between that encoding and any per-password encoding for non-ASCII data? [I think I asked about repeating the "ABC-12345" clTRID for multiple examples in the same document for a previous EPP document, but forget why it was deemed to be okay. Assuming that I do remember the tenor of the prevous discussion correctly, no response is needed here.] C: x86_64 Mac OS X 10.11.6 (macOS 10.11 feels a bit dated for 2010) C: this is a long password (side note: Long, but fairly low-entropy. "Correct horse battery staple" might get a smile from some readers... Similarly for the other examples) Upon a completed login command (success or failed), the extension MUST be included in the response based on both of the following conditions: I suggest "MUST be included in the response when both of the following conditions hold". Example EPP response to a failed login command where the password has expired and the new password does not meet the server complexity requirements: nit: the exDate given here is 2018-03-26, but the most recent "time of request" we listed was 2018-03-25, which is before this nominal expiration date. It would be nice to either mention a new "time of request" or mak the examples more consistent across each other. I also wonder about the usefulness of sending detailed errors back to an unauthenticated user. It would, for example, probably not be a good idea to report various statistical events to an unauthenticated user that's potentially an attacker seeking information for further attacks. Section 8 I think it would be appropriate to have a brief note that while this extension increases the maximum length of password that may be used for EPP authentication, it still involves sending unmodified passwords to the server for verification, and as such retains the security considerations of doing so from RFC 5730. The maximum length that Section 4.1 has as "up to server policy" is in some sense an anti-DoS measure, to keep the server from having to dedicate potentially "unlimited" resources to handling a client request that is authenticated only by the TLS connection. As mentioned above, we should have a bit of discussion of the security/privacy considerations of the information sent with the security events, particularly when sent to an unauthenticated user. The extension leaves the password ( element) and new password ( element) minimum length beyond 6 characters and the maximum length up to sever policy. The server SHOULD enforce minimum and nit: I don't understand what "minimum length beyond 6 characters means". Section 10 Why is RFC 2119 Normative but RFC 8174 Informative? Together they are both BCP 14, and I don't see why they would be treated differently. [ed. I see Éric already asked and got a response.] |
2020-01-22
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-01-22
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-01-22
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-01-22
|
07 | Roman Danyliw | [Ballot discuss] ** Section 3.1. When @type=”stat” and the name of the stat is set in @name, how does a client know the semantics of … [Ballot discuss] ** Section 3.1. When @type=”stat” and the name of the stat is set in @name, how does a client know the semantics of this stat? Is that negotiated out of band? ** Section 4.1. Per , how are the clients supposed to generate the app, tech or os strings in a way that the server will understand? If this is out of scope, please just say so. |
2020-01-22
|
07 | Roman Danyliw | [Ballot comment] I support Alissa Cooper’s DISCUSS position. ** Section 3.1. Is a @value required when @type=”cipher” or @type=”tlsProtocol”? The examples in Section 4 show … [Ballot comment] I support Alissa Cooper’s DISCUSS position. ** Section 3.1. Is a @value required when @type=”cipher” or @type=”tlsProtocol”? The examples in Section 4 show the use of @value. Also, what format should be used to express the cipher or tlsProtocol? ** Section 3.1. Per the description of event@lang, please cite the language format as coming from Section 3.4.3[W3C.REC-xmlschema-2-20041028] ** Section 4.1. Per the children of , would supporting a more formal approach also be useful -- using SWID (ISO/IEC 19770-2:2015) or COSWID (draft-ietf-sacm-coswid)? ** Section 4.1. Per pw and newPW’s descriptions of “all internal continuous whitepaces … is replaced with a single #x20” – is this intentionally precluding a password with a double space? ** Section 4.1. Per “If non-ASCII characters are supported with the plain text password, then use a standard for passwords with international characters, such as the OpaqueString PRECIS profile in [RFC8265].”, if non-ASCII characters are supported, how does a client know which approach to take with a given server in an interoperable. RFC8265 is a helpful reference but the current text seems to provide no guidance. ** Section 5. Please note in the Section 5 introduction that the blob between the BEGIN and END tags in Section 5.1 are formally specified by XML Schema. ** Section 8. Please note that the Security Considerations of RFC5730 apply and that this document enhances these security services. ** Editorial Nits -- Section 1. Typo. s/pssword/password/ |
2020-01-22
|
07 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-01-22
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-01-22
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-01-21
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-01-21
|
07 | Alissa Cooper | [Ballot discuss] Perhaps some simple questions (apologies if I'm missing something obvious): since there is no registry of custom events, how do developers of independent … [Ballot discuss] Perhaps some simple questions (apologies if I'm missing something obvious): since there is no registry of custom events, how do developers of independent implementations know which custom events they should be aiming to support? And how do they understand the semantics associated with custom events beyond what the event names can convey? |
2020-01-21
|
07 | Alissa Cooper | [Ballot comment] = Section 5 = "One schema is presented here that is the EPP Login Security Extension schema." This phrasing seems a little … [Ballot comment] = Section 5 = "One schema is presented here that is the EPP Login Security Extension schema." This phrasing seems a little odd (is there more than one schema?). I would suggest "The EPP Login Security Extension schema is presented here." |
2020-01-21
|
07 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2020-01-20
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2020-01-18
|
07 | Éric Vyncke | [Ballot comment] Thank you for the easy to read and understand document. I have just one comment: RFC8174 should be in the normative references IMHO … [Ballot comment] Thank you for the easy to read and understand document. I have just one comment: RFC8174 should be in the normative references IMHO -éric |
2020-01-18
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-01-17
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-01-17
|
07 | Cindy Morgan | Placed on agenda for telechat - 2020-01-23 |
2020-01-17
|
07 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-01-17
|
07 | Barry Leiba | Ballot has been issued |
2020-01-17
|
07 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-01-17
|
07 | Barry Leiba | Created "Approve" ballot |
2020-01-17
|
07 | Barry Leiba | Ballot writeup was changed |
2019-12-06
|
07 | James Gould | New version available: draft-ietf-regext-login-security-07.txt |
2019-12-06
|
07 | (System) | New version approved |
2019-12-06
|
07 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-12-06
|
07 | James Gould | Uploaded new revision |
2019-12-04
|
06 | Carlos Pignataro | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Carlos Pignataro. Sent review to list. |
2019-11-18
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-11-18
|
06 | James Gould | New version available: draft-ietf-regext-login-security-06.txt |
2019-11-18
|
06 | (System) | New version approved |
2019-11-18
|
06 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-11-18
|
06 | James Gould | Uploaded new revision |
2019-11-14
|
05 | Amanda Baber | IANA Experts State changed to Expert Reviews OK |
2019-11-14
|
05 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-11-12
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-11-12
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-regext-login-security-05. 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-regext-login-security-05. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the ns section of the IETF XML Registry located at: https://www.iana.org/assignments/xml-registry/ a single, new namespace will be registered as follows: ID: epp:loginSec-1.0 URI: urn:ietf:params:xml:ns:epp:loginSec-1.0 Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the schema section of the IETF XML Registry located at: https://www.iana.org/assignments/xml-registry/ a single, new schema will be registered as follows: ID: epp:loginSec-1.0 URI: urn:ietf:params:xml:schema:epp:loginSec-1.0 Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at: https://www.iana.org/assignments/epp-extensions/ a single, new extension is to be registered as follows: Name of Extension: "Login Security Extension for the Extensible Provisioning Protocol (EPP)" Document status: Standards Track Reference: [ RFC-to-be ] Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active Notes: None As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. 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 |
2019-11-12
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-11-04
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2019-11-04
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2019-11-02
|
05 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list. |
2019-11-01
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2019-11-01
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2019-10-31
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shaun Cooley |
2019-10-31
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shaun Cooley |
2019-10-29
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-10-29
|
05 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-11-12): From: The IESG To: IETF-Announce CC: jyee@afilias.info, Joseph Yee , draft-ietf-regext-login-security@ietf.org, regext-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2019-11-12): From: The IESG To: IETF-Announce CC: jyee@afilias.info, Joseph Yee , draft-ietf-regext-login-security@ietf.org, regext-chairs@ietf.org, barryleiba@gmail.com, regext@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Login Security Extension for the Extensible Provisioning Protocol (EPP)) to Proposed Standard The IESG has received a request from the Registration Protocols Extensions WG (regext) to consider the following document: - 'Login Security Extension for the Extensible Provisioning Protocol (EPP)' 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 2019-11-12. 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 Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-10-29
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-10-29
|
05 | Barry Leiba | Last call was requested |
2019-10-29
|
05 | Barry Leiba | Last call announcement was generated |
2019-10-29
|
05 | Barry Leiba | Ballot approval text was generated |
2019-10-29
|
05 | Barry Leiba | Ballot writeup was generated |
2019-10-29
|
05 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation::Point Raised - writeup needed |
2019-10-29
|
05 | James Gould | New version available: draft-ietf-regext-login-security-05.txt |
2019-10-29
|
05 | (System) | New version approved |
2019-10-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-10-29
|
05 | James Gould | Uploaded new revision |
2019-10-28
|
04 | Barry Leiba | IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation |
2019-10-27
|
04 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2019-10-25
|
04 | James Galvin | Document Shepherd Writeup Draft-ietf-login-security-04 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. … Document Shepherd Writeup Draft-ietf-login-security-04 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. Working Group Summary The WG discussed this topic in both mailing list and at meetings; there are no controversies or lack of coverage. The working group agreed to submit this draft for publication on the Standards Track. There were several in-depth discussions on password complexity and its indicator ‘[LOGIN-SECURITY]’. The WG reached consensus on the approach. Document Quality There is one registry implementation captured in the Implementation Status section. Personnel Shepherd: Joseph Yee AD: Barry Leiba Shepherd Comment The document shepherd reviewed the latest version (-04) of the document and this document’s discussion both on the mailing list and in meetings (both REGEXT). The shepherd has no concern on the depth or breadth of the reviews that have been performed. There are several XML samples and one formal syntax on the XML. The shepherd ran the syntax check against the XML in section 5.1 Formal Syntax and found no error. IPR There is no IPR disclosure regarding this draft. |
2019-10-25
|
04 | James Galvin | Responsible AD changed to Barry Leiba |
2019-10-25
|
04 | James Galvin | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-10-25
|
04 | James Galvin | IESG state changed to Publication Requested from I-D Exists |
2019-10-25
|
04 | James Galvin | IESG process started in state Publication Requested |
2019-10-25
|
04 | James Galvin | Document Shepherd Writeup Draft-ietf-login-security-04 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. … Document Shepherd Writeup Draft-ietf-login-security-04 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. Working Group Summary The WG discussed this topic in both mailing list and at meetings; there are no controversies or lack of coverage. The working group agreed to submit this draft for publication on the Standards Track. There were several in-depth discussions on password complexity and its indicator ‘[LOGIN-SECURITY]’. The WG reached consensus on the approach. Document Quality There is one registry implementation captured in the Implementation Status section. Personnel Shepherd: Joseph Yee AD: Barry Leiba Shepherd Comment The document shepherd reviewed the latest version (-04) of the document and this document’s discussion both on the mailing list and in meetings (both REGEXT). The shepherd has no concern on the depth or breadth of the reviews that have been performed. There are several XML samples and one formal syntax on the XML. The shepherd ran the syntax check against the XML in section 5.1 Formal Syntax and found no error. IPR There is no IPR disclosure regarding this draft. |
2019-10-21
|
04 | Joseph Yee | Document Shepherd Writeup Draft-ietf-login-security-04 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. … Document Shepherd Writeup Draft-ietf-login-security-04 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. Working Group Summary The WG discussed this topic in both mailing list and at meetings, there are no controversies or lack of coverage. The working group agreed to publish this draft as Standard Track. There are several in-depth discussions on password complexity and its indicator ‘[LOGIN-SECURITY]’, and reached consensus on the approach. Document Quality There is one registry implementation captured in the Implementation Status section. Personnel Shepherd: Joseph Yee AD: Barry Leiba Shepherd Comment The document shepherd reviewed the latest version (-04) of the document and this document’s discussion both on the mailing lists and in meetings (both REGEXT). The shepherd has no concern on the depth or breadth of the reviews that have been performed. There are several XML samples and one formal syntax on the XML. The shepherd ran the syntax check against the XML in section 5.1 Formal Syntax and found no error. IPR There is no IPR disclosure regarding this draft. |
2019-09-30
|
04 | James Gould | New version available: draft-ietf-regext-login-security-04.txt |
2019-09-30
|
04 | (System) | New version approved |
2019-09-30
|
04 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-09-30
|
04 | James Gould | Uploaded new revision |
2019-09-24
|
03 | Joseph Yee | Document Shepherd Writeup Draft-ietf-login-security-03 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. … Document Shepherd Writeup Draft-ietf-login-security-03 Technical Summary The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. Working Group Summary The WG discussed this topic in both mailing list and at meetings, there are no controversies or lack of coverage. The working group agreed to publish this draft as Standard Track. There are several in-depth discussions on password complexity and its indicator ‘[LOGIN-SECURITY]’, and reached consensus on the approach. Document Quality There is one registry implementation captured in the Implementation Status section. Personnel Shepherd: Joseph Yee AD: Barry Leiba Shepherd Comment The document shepherd reviewed the latest version (-03) of the document and this document’s discussion both on the mailing lists and in meetings (both REGEXT). The shepherd has no concern on the depth or breadth of the reviews that have been performed. There are several XML samples and one formal syntax on the XML. The shepherd ran the syntax check against the XML in section 5.1 Formal Syntax and found no error. There are two areas the editors need to address: (1) Section 3.1 - the paragraph that specifies when “name” must be mandatory. The text needs more work to be precise. The current text only specifies “name” is required when “type”==“custom”, where “name” is mandatory too when “type”==“stat”. (2) In Section 4.1, specifies that one of the child element must be included if the request contained . In the Formal Syntax section, the XML does not enforce it. If the XML syntax uses what XML Schema offers, then editors should check on element. IPR There is no IPR disclosure regarding this draft. |
2019-09-13
|
03 | Antoin Verschuren | Notification list changed to Joseph Yee <jyee@afilias.info> |
2019-09-13
|
03 | Antoin Verschuren | Document shepherd changed to Joseph Yee |
2019-08-23
|
03 | James Galvin | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2019-08-05
|
03 | James Gould | New version available: draft-ietf-regext-login-security-03.txt |
2019-08-05
|
03 | (System) | New version approved |
2019-08-05
|
03 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-08-05
|
03 | James Gould | Uploaded new revision |
2019-07-21
|
02 | James Galvin | Added to session: IETF-105: regext Thu-1000 |
2019-06-25
|
02 | James Gould | New version available: draft-ietf-regext-login-security-02.txt |
2019-06-25
|
02 | (System) | New version approved |
2019-06-25
|
02 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-06-25
|
02 | James Gould | Uploaded new revision |
2019-06-21
|
01 | Antoin Verschuren | Changed consensus to Yes from Unknown |
2019-06-21
|
01 | Antoin Verschuren | Intended Status changed to Proposed Standard from None |
2019-06-21
|
01 | Antoin Verschuren | This document now replaces draft-gould-regext-login-security instead of None |
2019-04-09
|
01 | James Gould | New version available: draft-ietf-regext-login-security-01.txt |
2019-04-09
|
01 | (System) | New version approved |
2019-04-09
|
01 | (System) | Request for posting confirmation emailed to previous authors: Matthew Pozun , James Gould |
2019-04-09
|
01 | James Gould | Uploaded new revision |
2019-02-01
|
00 | James Gould | New version available: draft-ietf-regext-login-security-00.txt |
2019-02-01
|
00 | (System) | New version approved |
2019-02-01
|
00 | James Gould | Request for posting confirmation emailed to submitter and authors: Matthew Pozun , James Gould |
2019-02-01
|
00 | James Gould | Uploaded new revision |