Hi James, My apologies for the again-delayed response. Continuing inline and skipping points that are resolved...
On Mon, May 10, 2021 at 09:00:27PM +0000, Gould, James wrote: > Benjamin, > > I provide responses to your feedback embedded below. > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 4/30/21, 5:53 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > Hi James, > > Also inline. > > On Mon, Apr 26, 2021 at 09:08:29PM +0000, Gould, James wrote: > > Benjamin, > > > > Thank you for your review and feedback. I provides responses to your > feedback embedded below. Updates will be made to > draft-ietf-regext-secure-authinfo-transfer-07 that will include changes from > all of the feedback. > > > > -- > > > > JG > > > > > > > > James Gould > > Fellow Engineer > > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com > <http://secure-web.cisco.com/17qDpXuoUR_RViRldagQC1c4hbySMgaISf75YxoMh5RSacirr06cFESa5iUq-WYHWmSwoV_0gfiVQ3sJxyOTp2V7YfycAQc22A5jFUwf1tWe5BIVMw_DhfEoRMB714nZooUxfCgXZ0pqsFdHri7P64Ll3JJmluVVHHicUCEcEEBtWgv2EdVjlqSkz8ngYFLEZ__1ogASlc7hQjqDtsZBVJsieYqglrnve4Uavxi1_tQ6UDCSq1xdIywoHJsEW8iTy/http%3A%2F%2Fverisigninc.com%2F> > > > > On 4/21/21, 2:23 PM, "Benjamin Kaduk via Datatracker" > <nore...@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-regext-secure-authinfo-transfer-06: Discuss > > > > When responding, please keep the subject line intact and reply to > all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > > > Please refer to > https://secure-web.cisco.com/1x_mIFJ-zLPWFIDcykQFrXjxI71ZzFb_Wg7ZircyyhLW3CozdpwX3kNVg-mA5pDco5KEF8jHedG3kgX3Q9Xo2Net7Z5ohit0rRUUO1sjN0ZRmH-nKWURhgj3Iipq2JCdntBQ8pPbfJjvs4-xhVAysJ15K5B70hN2mLAmEhWFJLS1w_efP56Yn5-KMKtlrZbApoCRZf7rPXivpD0tFvZqUsCiaLJhRjezITS4nbdupjnrUei5o_FQWC5daBK4VUYj0/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > https://secure-web.cisco.com/1-l6dghkg8Lo7AiBGMYiae0h6FJhNsRSH26_rZNPQlWnaRgYK3kcZxY9W14m-dMM0khwg1IGtGRa8UhciRD20JvFL9P0TtgqnlBTwfsC-rxGTFVwOCtzkVhrRQGFF_Pi3vFSZPLTiJiPn1UhzOF_Qq0DxpjByXgIjKlBVR3SX6CxZg7ks5LXDTO9TuSSrXkvIlPQiQrQ-tuOvHqbxu2dJ_w4JbLhg9_aU-HVKpvcXM1W4CSEIcK2RYz7l2sGol9-1/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-secure-authinfo-transfer%2F > > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > (1) RFC 4086 does not state that "a high-security password must > have at > > least 49 bits of randomness or entropy" as is claimed in Section > 4.1 of > > this document. It merely says that so much entropy is needed to > have a > > one-in-a-billion chance of success for successfully guessing in the > > model laid out, and makes no statement about (absolute) "high" > security. > > I don't think we need to spend as much time on what RFC 4086 says > as we > > currently do, and could probably get to the "use at least 128 bits > of > > entropy" advice much sooner. > > > > JG - In section 8.1 of RFC 4086, it states "For a higher-security > password, ... To go to a one-in-10^9 change, 49 bits of randomness are > needed, ...". To be accurate with the language in RFC 4086, "high-security" > can be changed to "higher-security". Do you agree with making that change? > > I do not agree with that change. "Higher" is inherently relative to some > baseline; in the case of RFC 4086, "higher-security" is with respect to > the > baseline it has laid out of "an attacker has a 1-in-1000 chance of > guessing > correctly given [scenario]". The example given for "higher-security" just > moves the target from one in a thousand to one in a billion, but to be > strong in an absolute sense, we typically talk about a 1 in 2^64 or > 1 in 2^128 chance of success. > > Given that we go on to ignore the "49 bits" number and do the actual right > thing (128 bits of entropy) in the next paragraph, I don't really think we > need to reference this part of RFC 4086 at all. > > That could condense things down, for example via: > OLD: > For authorization information to be secure, it MUST be generated > using a secure random value. The authorization information is > treated as a password, where according to [RFC4086] a high-security > password must have at least 49 bits of randomness or entropy. The > required length L of a password, rounded up to the largest whole > number, is based on the set of characters N and the desired entropy > H, in the equation L = ROUNDUP(H / log2 N). Given a target entropy, > the required length can be calculated after deciding on the set of > characters that will be randomized. > > Considering the age of [RFC4086], the evolution of security > practices, and that the authorization information is a machine- > generated value, the implementation SHOULD use at least 128 bits of > entropy. The lengths are calculated below using that value. > > NEW: > For authorization information to be secure, it MUST be generated > using a secure random value. The authorization information is treated > as a password, and the required length L of a password, rounded up to > the > largest whole number, is based on the size N of the set of characters > and > the desired entropy H, in the equation L = ROUNDUP(H / log2 N). Given > a > target entropy, the required length can be calculated after deciding > on the > set of characters that will be randomized. In accordance with current > best practices and noting that the authorization information is a > machine-generated value, the implementation SHOULD use at least 128 > bits of > entropy as the value of H. The lengths below are calculated using that > value. > > JG - I'll make the change to your suggested language, thanks. > > > (2) There's also some text in Section 5.3 that I'd like to discuss > briefly: > > > > The registry MUST NOT return any indication of whether the > > authorization information is set or unset to the non-sponsoring > > registrar by not returning the authorization information element > in > > the response. The registry MAY return an indication to the > > sponsoring registrar that the authorization information is set by > > using an empty authorization information value. The registry MAY > > return an indication to the sponsoring registrar that the > > authorization information is unset by not returning the > authorization > > information element. > > > > This seems to be assigning semantics to both absent-authinfo and > > empty-authinfo in the <info> response, but is giving *different* > semantics > > to the response-to-sponsoring-registrar and > > response-to-non-sponsoring-registrar cases. Is there precedent for > > changing the semantics of the response based on the identity of the > > client like this (not just changing the content of the response)? > Can > > we come up with a scheme that provides consistent semantics to all > > clients, perhaps based on <domain:null> vs empty <domain:pw> for > > unset/set, leaving "element is absent" for the deliberately > ambiguous > > case? > > > > JG - Yes, draft-ietf-regext-secure-authinfo-transfer changes the > semantics of the RFC 5731 info response (section 3.1.2) based on the identity > of the client. The exact mechanism for signaling the existence or > non-existence of authorization information is an element of > draft-ietf-regext-secure-authinfo-transfer that needs to take into account > the data sponsored (owned) by the registrar. Non-sponsoring registrars don't > have a need to know and must not know of the existence or non-existence of > the authorization information. Only the sponsoring registrar has a need to > know. > > I agree with your assessment of who needs to know what information. > > I was trying to ask if we have a way to provide information (and not > provide information) in a way such that the semantics of the elements in a > given response do not depend on the identity of the client, since such > client-independence seems like it would result in a simpler implementation > and reduce the likelihood of security-relevant bugs. > > If there is not such a way, that seems perhaps tolerable, but I did not > see any > evidence that the WG had considered this topic and looked for a way to > provide those properties (giving the different parties the correct amount > of > information and having the semantics of response elements be independent > of > the client the response is sent to). If the WG has already considered > this > topic I'm happy to drop the discuss point; however, I think I provided a > sketch of a possible approach that could achieve these goals, and do not > see any argument presented that such a scheme is not workable. > > JG - This comes down to a question of authorization where the identity (or > sponsorship) of the client is used to determine the information to return to > the client. Other elements returned in the info response is based on the > client's identity, such as the language in RFC 5731 which states: Using the authorized identity to determine what *information* to return to the client is normal and expected. I don't think that's what is at question. What seems unusual to me is using the identity information to affect how to *interpret* a given *representation* of some information. > "An OPTIONAL <domain:authInfo> element that contains authorization > information associated with the domain object. This element MUST > only be returned if the querying client is the current sponsoring > client or if the client supplied valid authorization information > with the command." Okay, so the registry can't return the element to an unauthorized client, that's fine. This is consistent with what we say about "MUST NOT return any indication of whether the authorization information is set or unset". This is saying that for the unauthorized client case, we give "element not present" the semantics of "no information about the contents of the authorization information (if any is set) or whether or not the authorization information is set". The semantics of "element not present" would be different for the authoriezd client, though... > The client should know whether or not they sponsor the object, where the > semantics of an empty authorization information element (authorization > information is set) and a non-existent authorization information element > (authorization information is not set or non-sponsoring client) will be > clear. An empty authorization information (or a null element if the object > supports it) is only returned in the case of the sponsoring client, so the > semantics is clear for all clients. If there is any question related to > sponsorship, the identifier of the sponsoring client is returned using the > clID element of the existing EPP object RFCs (domain, host, and contact) for > the client to identify whether they do sponsor the object. The use of the > clID element is not guaranteed for EPP objects, but it's the existing > practice. The client ought to know whether or not they sponsor the object, sure. But maybe sometimes the client doesn't know, or has bad data, and there's an edge case. Part of my job as SEC AD is to look for edge cases and "pull on the string" to see whether anything bad could come from them. You've convinced me that the semantics of an empty authorization information element should always be clear, and thank you for that. However, I still don't think that the semantics of an *absent* authorization information element are clear, though, since it depends on this external information about whether the client is the authorized client for this object. Typically, in XML, the markup (and position in the hierarchy) determines the semantic content when a given element has a given value. The way this document is currently written introduces another factor, where information external to the local XML context ("is this the sponsoring client?") is required in order to decode the correct semantic content for a given (non)value of the XML element. This dependence on external contextual information seems like it makes the implementation more complicated and introduces risk of misinterpreting the semantics of the XML if the client has incorrect contextual data. I'm not saying that this risk is intrinsically unacceptable -- the contextual information is generally something the client should have and can otherwise typically get via the clID as you note, and the complication of implementation small compared to the overall complexity of a complete implementation -- but I do think that it's a risk that the WG should acknowledge it is taking on, if the WG chooses to do so. > > > > (3) We may also need to discuss the efficacy of the transition > plan, per > > my comments in Sections 6.1 and 6.3 -- my current understanding is > that > > the proposed plan will break some existing workflows. I am not > sure if > > that is intended, desirable, and/or tolerable, and welcome further > > insight. > > > > JG - I responded to your feedback on section 6.1 and 6.3 below. > Implementing the transition plan is up to server policy, which includes the > data used (e.g., % of registrars that signal support in login, % of > registrars not setting authorization information on create) to determine the > impact and best timing of the phases, the approach taken to notify the > registrars (e.g., maintenance notices and reaching out to impacted > registrars), and rollout plan (e.g., deploy to OT&E, deploy incrementally in > Production with monitors). Implementing non-backward compatible changes in > the registry is not new and in general needs to be handled with adequate > notification and in incremental steps. Deprecating and removing TLS > protocols and ciphers is a perfect example of rolling out a non-backward > compatible change that is up to registry policy to handle. The timing, > notification, and legal aspects of implementing the transition is based on > server policy. > > Okay, I will respond below as well. > > JG - I included updates for section 6.1 and section 6.3 embedded below that I > believe addresses your feedback. Let me know if anything was missed. > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > I think that the introduction would benefit from expanding on the > > high-level motivation for this work (which I assume to include): the > > current/original lifecycle for authorization information involves > > long-term storage of encrypted (not hashed) passwords, which > presents a > > significant latent risk of password compromise and is not consistent > > with current best practices. The mechanisms in this document > provide a > > way to avoid long-term password storage entirely, and to only > require > > the storage of hashed (not retrievable) passwords instead of > encrypted > > passwords. (Or, in a more colloquial language, "passwords suck, > and we > > want to get out of the business of handling them to the extent > > possible".) The third paragraph does talk about the "overall > goal", but > > doesn't say much about what we're moving *away* from (and why). > > > > JG - I will add the following second paragraph to the introduction > based on what you provided above: > > > > The current/original lifecycle for authorization information involves > > long-term storage of encrypted (not hashed) passwords, which presents a > > significant latent risk of password compromise and is not consistent > > with current best practices. The mechanisms in this document provide a > > way to avoid long-term password storage entirely, and to only require > > the storage of hashed (not retrievable) passwords instead of encrypted > > passwords. > > Thank you! > > > > > I think giving some explicit consideration of the lifecycle and > protocol > > interactions for the password 'salt' would be helpful. (That is, > that > > it's picked at random by the registry per password when a password > is > > set and never goes on the wire, but is stored alongside the hashed > > password.) > > > > JG - I'm not clear on the lifecycle and protocol interactions of the > authorization information 'salt'. The requirement is for the authorization > information to be hashed with a salt. Roman asked about guidance related to > the length of the salt. The purpose of the extension is to not cover the > details of creating a salted hashed authorization information. Some guidance > can be provided on the length and aspects of the salt. Do you have any > recommendations or relevant references that would be useful in providing the > guidance? > > My advice would be to pick a new random salt (128 bits is enough) each > time > a password hash is to be stored, and store that salt for the duration of > the TTL (i.e., alongside the hashed password). This is in contrast to > having a single salt per domain/object that is used for multiple > passwords, > or having only a single salt per registry. > > JG - How about changing the references of "with a random salt" to read "with > a per-authorization information random salt, with at list 128 bits"? The > "per-authorization information" addresses the sharing of salts concern, and > the ", with at least 128 bits" addresses the size concern. +1 > > > > The treatment in the introduction of "[use] the existing features > of the > > EPP RFCs" made me wonder why this needed to be on the > standards-track, > > as opposed to being an informational description of how to use > what's > > already there. The actual core of the spec, which includes changes > to > > the semantics of some XML elements (e.g., in the info response), is > > clearly protocol work, though, so perhaps the abstract/introduction > > could be revisited to clarify the scope of the work. > > > > JG - There is signaling of support of the practice by the client and > the server in section 3 and the behavior implemented in the existing EPP > commands in section 5, which are relevant to the protocol. We had discussed > the desired track of the draft in the working group which was captured in > section 1 " What type of RFC is being requested" of the shepherd writeup. > > To be clear, I'm happy with this document being a Proposed Standard; I am > less sure whether the Abstract/Introduction should be talking about > "defines an operational practice" vs "defines a protocol mechanism" > (etc.). > > JG - I'll stick with the language agreed to within the working group with > operational practice, since there was much discussion around the track used > and the approach taken. Okay. > > Section 1 > > > > "Strong Random Authorization Information": The EPP RFCs define > the > > password-based authorization information value using an XML > > schema "normalizedString" type, so they don't restrict what > can > > be used in any way. This operational practice defines the > > > > I suggest s/in any way/in any substantial way/ (not being able to > use > > CR/LF/TAB is in some sense a restriction). > > > > JG - Update will be made > > > > "Short-Lived Authorization Information": The EPP RFCs don't > > [...] > > upon a successful transfer. All of these features can be > > supported by the EPP RFCs. > > > > They can be supported, sure, but what about in practice? Can we > rely on > > such functionality being present? > > > > JG - There is a mix in practices based on the discussion in the working > group. > > Ah, interesting. Would it work to say "all of these features are > compatible with the EPP RFCs, though not mandatory to implement"? IMO > that > gives a clearer picture of what the reader can expect from an existing > implementation. > > JG - I went ahead and added the "All of these features are compatible with > the EPP RFCs, though not mandatory to implement." sentence as the second > sentence for the " Short-Lived Authorization Information" description. > > > Section 3 > > > > namespace URI in the login and greeting extension services. The > > namespace URI > "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer- > > 1.0" is used to signal support for the operational practice. The > > > > Written in this way this is codepoint squatting, assuming that the > > requested XML namespace value will be assigned. Given that Section > 8 > > implies this stuff is deployed already, there really should have > been an > > early allocation made. > > > > JG - Elements of the draft have been implemented and in the case of the > Verisign EPP SDK it has been implemented in Development. Given the context > and expected timing, conflict issues with the XML namespace > "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" registration would > seem unlikely as a practical matter. > > It does seem unlikely to cause issues as a practical matter, which is why > I > decided to not make a Discuss-level point about it. > > JG - Agreed > > > A client that receives the namespace URI in the server's Greeting > > extension services, can expect the following supported behavior > by > > the server: > > > > 1. Support an empty authorization information value with a > create > > command. > > [...] > > > > It's interesting to compare this to RFC 5731, that says > "Authorization > > information as described in Section 2.6 is REQUIRED to create a > domain > > object. [...] Failure to protect authorization information from > > inadvertent disclosure can result in unauthorized transfer > operations > > and unauthorized information release. [...]" In some sense we are > > introducing a rather significant philosophical change in the nature > of > > authorization information, that might be called out more > prominently. > > > > JG - The requirement for the authorization information at the time of > create is one of the drivers for the definition of the extension. How about > referencing the requirement defined section 2.6 of RFC 5731 in the > "Short-Lived Authorization Information" description of the Introduction: > > > > "The EPP RFCs don't explicitly support short-lived authorization > information or a time-to-live (TTL) for authorization information, but there > are EPP RFC features that can be leveraged to support short-lived > authorization information. In section 2.6 of [RFC5731] it states that > authorization information is assigned when a domain object is created, which > results in long-lived authorization information. This specification changes > the nature of the authorization information to be short-lived. If > authorization information is set only when...." > > > > Does this help? > > I like this text, though I'm not entirely sure where you are proposing to > put it. I guess it could fit near the start of the section (i.e., before > the "A client that receives [...]") > > JG - Sorry about the confusion. The plan was to place the clarification in > the description of "Short-Lived Authorization Information" of the > Introduction. After adding the sentence you recommended above, the start of > the description of the "Short-Lived Authorization Information" of the > Introduction would read below. I believe the significant philosophical > change needed to be addressed up front in the Introduction. > > The EPP RFCs don't explicitly support short-lived authorization information > or a time-to-live (TTL) for authorization information, but there are EPP RFC > features that can be leveraged to support short-lived authorization > information. All of these features are compatible with the EPP RFCs, though > not mandatory to implement. In section 2.6 of [RFC5731] it states that > authorization information is assigned when a domain object is created, which > results in long-lived authorization information. This specification changes > the nature of the authorization information to be short-lived. Assuming I'm understanding correctly, this (still) sounds good. > > > > 7. Support automatically unsetting the authorization information > > upon a successful completion of transfer. > > > > Just "support", or actually will in practice? > > (Probably applies to some of the other enumerated points as well, > for > > both client and server, though I think not to all of them.) > > > > JG - Support does mean will in this case. Perhaps clarified with this > proposed edit: "Automatically unset the authorization information upon a > successful completion of transfer.". Do you believe this edit is helpful? > > Yes, thank you. > > > > > Section 4 > > > > with the <contact:pw> element). Other EPP objects that support > > password-based authorization information for transfer can use the > > Secure Authorization Information defined in this document. For > the > > > > This is phrased just as "can use" (not "will use"), but we are > > supposedly defining an XML namespace used for capability > negotiation in > > the initial EPP exchange, which really ought to have well-specified > > semantics. *Must* the secure authorization information defined in > this > > document be used for any applicable transfer, when the XML > namespace we > > define is in effect for the capabilities to use? > > > > JG - In the base EPP RFC 5730 authorization information is required, > but the type of authorization information required is object-specific. There > is no requirement for all EPP objects to support password-based authorization > information, which is the reason for the "can use" language. The XML > namespace defines the capabilities to use when password-based authorization > information is used by the EPP object. Do you believe "can use" should be > changed to "MAY use"? > > I'm not entirely sure what effect we think changing "can use" to "MAY use" > will have. My new understanding in light of your reply above is that (1) > there > are not any other publicly defined EPP objects that support password-based > authorization information, and (2) we expect that any future EPP objects > that support password-based authorization information to specify their > interaction with the capabilities defined by the XML namespace created by > this document. In my opinion it's more important to talk about the > expectations on future specifications than what options are available to > them, so we might say something about "specifications that define other > EPP > objects" rather than the objects themselves. > > JG - To clarify the base EPP RFC 5730 does not require the use of > password-based authorization information, but includes the following > language: > > The type of authorization information required is object-specific; > passwords or more complex mechanisms based on public key cryptography > are typical. > > The EPP RFC objects (domain in RFC 5731 and contact in RFC 5733) support > password-based authorization information and supports other forms, with the > following language: > > This specification describes password-based authorization information, though > other mechanisms are possible. > > The draft only applies to password-based authorization information, which is > the only form that I'm aware of in practice. The "can use" is applied where > password-based authorization information is used. My recommendation is to > keep the "can use" language. The current "can use" language seems to be a local maximum, yes. It sounds like there's not appetite for a broader restructuring to address what/whether we expect future specifications of objects that use password-based authorization information to do in this space, and I'll let the topic rest. > > Section 4.1 > > > > The strength of the random authorization information is > dependent on > > the actual entropy of the underlying random number generator. > For > > the random number generator, the practices defined in [RFC4086] > and > > section 4.7.1 of the NIST Federal Information Processing > Standards > > (FIPS) Publication 140-2 [FIPS-140-2] SHOULD be followed to > produce > > random values that will be resistant to attack. A random number > > generator (RNG) is preferable over the use of a pseudorandom > number > > generator (PRNG) to reduce the predictability of the > authorization > > information. The more predictable the random number generator > is, > > the lower the true entropy, and the longer the required length > for > > the authorization information. > > > > This is not really the advice that I would be giving, myself. > > For one, using a true RNG is not necessarily better than a PRNG, > since a > > good PRNG will have a lot of well-thought-out "whitening" > functionality > > that makes the output fairly uniform. A true RNG can be a true RNG > > while still sampling from a non-uniform distribution and leaving > > patterns in the output. But more importantly, implementors of EPP > are > > highly unlikely to need to care about the entropy gathering > practices > > specified by NIST SP 140-2 and RFC 4086 -- they can and should just > use > > /dev/urandom! RFC 4086 was written in a time when /dev/urandom was > not > > as reliable as it is nowadays, but the advice of "to obtain randon > > numbers under Linux, Solaris, [...] all an application has to do is > open > > either /dev/random or /dev/urandom and read the desired number of > > bytes" is arguably the most important guidance in it. (There's > also a > > corresponding Windows API.) If we don't think people will want to > > implement a 94-character alphabet themselves, we can suggest the > widely > > available base64 encoding and say something like "read 18 bytes from > > /dev/random and base64 encode it, which will produce 24 characters > of > > encoded output" or give the ROUNDUP(128/log2 64) math. (I use 18 > bytes > > because that avoids base64 padding characters.) > > > > JG - I understand what you're saying, but I believe it's best to > reference publicly available documents and provide guidance based on them. > Do you have any revised references that you would recommend including? > > I think the RFC 4086 reference can work, if framed suitably. Something > like: > > The strength of the random authorization information is dependent on the > random number generator. Suitably strong random number generators are > available in a wide variety of implementation environments, including > the > interfaces listed in Sections 7.1.2 and 7.1.3 of [RFC4086]. > > If you think this doesn't provide enough guidance for situations in which > there is not a useeful API available, we could also add something like: > > In environments that do not provide interfaces to strong random number > generators, the practices defined in [RFC4086] and section 4.7.1 of the > NIST Federal Information Processing Standards (FIPS) Publication 140-2 > [FIPS-140-2] can be followed to produce random values that will be > resistant to attack. > > JG - Ok, I'll go with the combination of the two to provide the guidance > needed. The last paragraph of 4.1 will read: > > The strength of the random authorization information is dependent on the > random number generator. Suitably strong random number generators are > available in a wide variety of implementation environments, including > the > interfaces listed in Sections 7.1.2 and 7.1.3 of [RFC4086]. In > environments > that do not provide interfaces to strong random number > generators, the practices defined in [RFC4086] and section 4.7.1 of the > NIST Federal Information Processing Standards (FIPS) Publication 140-2 > [FIPS-140-2] can be followed to produce random values that will be > resistant to attack. Thank you! > > > > Section 4.2 > > > > I strongly suggest giving some guidance to registrars on how to set > the > > TTL (presumably a week or a few days is doable for common/generic > domain > > transfers?). The requirements in §4.3 are not really aligned with > > current best practices for password hashing for long term storage > > (which, admittedly, are designed for human-selected passwords and > not > > random ones), so clamping down the TTL is going to be helpful for > > putting bounds on some classes of attack. > > > > > > JG - The TTL is up to the registrar's business practices based on the > perceived importance of a domain. The guidance is that the authorization > information should only be set during the transfer process. This will be in > days and not weeks or months, which was the concern that Roman had. > > (I'm happy to keep this topic to Roman's thread.) > > > > > Section 4.3 > > > > I note that draft-ietf-kitten-password-storage is underway to write > > down best practices for password hashing and storage. It is > probably > > not mature enough to be used as a definitive reference yet, but > could be > > useful information. > > > > JG - Great, thank you for the reference. I'll give it a read. > > > > 1. The authorization information MUST be stored by the registry > > using a strong one-way cryptographic hash, with at least a > > 256-bit hash function such as SHA-256 [FIPS-180-4], and with > a > > random salt. > > > > Typical password-hashing recommendations these days are things like > > Argon2 (winner of https://www.password-hashing.net/) or PBKDF2 (for > > somewhat more legacy systems). The iteration count (and other > > parameters, for Argon2) can be tweaked depending on the systems in > > question and the esteimated strength of the password, but nobody is > > doing just a single-iteration of (salted) SHA256. I note that we > > recently approved draft-ietf-lamps-crmf-update-algs that leaves in > place > > a requirement that the iteration count MUST be at least 100 (and > adds > > "SHOULD be as large as server performance will allow, typically at > least > > 10,000"). If the intent is to take advantage of the special > > considerations here about the nature of the passwords in question, > in > > order to diverge from password-hashing best practice, we should be > > explicit about the intentional divergence. > > > > JG - The goal of the draft is for the registries to use a strong > one-way cryptographic hash. Inclusion of the "at least a 256-bit hash > function such as SHA-256 [FIPS-180-4], and with random salt" language was > added to provide some guidance, but it comes down to server policy and best > practices at the time in choosing the desired hashing function and attributes > (e.g., iteration count). Let me know if you have any relevant RFCs that can > be referenced for applicable hashing practices. > > (I think the kitten draft mentioned above may be the first RFC that's > really in this space. RFC 7617 mostly defers to > https://password-hashing.net, and for other IETF protocols we tend to > prefer to specify things that don't involve sending passwords around...) > > JG - Ok, I'll leave it as is with the exception of the update to the random > salt based on your other feedback. Okay. I can accept that I won't always get my preferred outcome. > > > > 5. The plain text version of the authorization information MUST > NOT > > be written to any logs by the registrar or the registry, nor > > > > nit: "the registrar" is perhaps ambiguous in this scenario where we > have > > both losing and gaining registrars. > > > > JG - References to "the registrar" applies to both the losing and > gaining registrar. How about making the edit : s/"the registrar or the > registry"/"a registrar or registry"? > > Sounds good. > > > Section 4.4 > > > > 1. Any input authorization information value MUST NOT match an > unset > > authorization information value. > > > > Does this only apply to non-empty input authorization information? > > > > JG - Yes, the WG wanted to ensure that an unset authorization > information value is never incorrectly matched with an input authorization > information value. > > I guess there are three potential cases that I had in mind for nailing > down > the specific semantics for the input authorization information: > > (1) <domain:authInfo><domain:null/></domain:authInfo> > (2) <domain:authInfo><domain:pw/></domain:authInfo> > (3) [there is no <domain:authInfo> element present] > > Which (if any) of these three cases fall under the umbrella of "any input > authorization information"? IMO, both (1) and (2) would be matched by the > language as written, but I don't think that the "MUST NOT match" is > supposed to apply to at least (1) and maybe not to (2) either. > > So, I think that a text change is likely in order so that we really nail > down what behavior is expected for these edge cases. > > JG - Actually, this text was meant to cover all cases of authorization > information input matching against an unset authorization information value, > which matches case 1 and 2 above along with case 4 > <domain:authInfo><domain:pw>2fooBAR</domain:pw></domain:authInfo>. > Obviously, passing a non-empty authorization information should never match > an unset authorization information, where the purpose of 4.4 rule #1 is to > cover any and all cases of authorization information input when the > authorization information value is unset. How about adding a second sentence > to rule #1 below. I believe referencing input authorization information > excludes case 3. > > "Any input authorization information value MUST NOT match an unset > authorization information value. This includes empty authorization > information, such as <domain:null/> or <domain:pw/> in [RFC5731], and > non-empty authorization information, such as <domain:pw>2fooBAR</domain:pw> > in [RFC5731]." > > Does this help? Yes, that helps a lot -- thanks! > > > 3. A non-empty input authorization information value MUST be > hashed > > and matched against the set authorization information value, > > which is stored using the same hash algorithm. > > > > It might be worth a few sentences (not necessarily here) about > > password-hashing-algorithm agility and what an algorithm transition > > would look like. > > > > JG - I believe the details of password-hashing-algorithm agility and > algorithm transition is implementation that is based on server policy. Let > me know whether you have any current best standard practices to reference for > guidance. > > I think BCP 201 is the go-to guidance for the need for algorithm agility. > That said, it's not terribly relevant for this specific text that I > quoted; > if we are going to reference it it would need to be somewhere else. > > JG - I reviewed BCP 201 and I agree that it doesn't really look relevant to > rule #3 in section 4.4. The focus on rule #3 is associated with ensuring > that the passed in authorization information properly matches the stored > authorization information, where the hash algorithms needs to match. I > prefer to leave it as is and keep algorithm agility up to server policy. > > > Section 5.2 > > > > Because of this, registries may validate the randomness of the > > authorization information based on the length and character set > > required by the registry. For example, validating an > authorization > > value contains a combination of upper-case, lower-case, and non- > > alphanumeric characters, in an attempt to assess the strength of > the > > value, and return an EPP error result of 2202 if the check fails. > > > > Such checks are, by their nature, heuristic and imperfect, and > may > > identify well-chosen authorization information values as being > not > > sufficiently strong. Registrars, therefore, must be prepared > for an > > error response of 2202, "Invalid authorization information", and > > respond by generating a new value and trying again, possibly more > > than once. > > > > I note for the record that we had an earlier conversation about this > > behavior, and I still believe that it does not reflect a best > practice > > for minimizing the use of weak passwords. That said, it is a > > non-normative example, and we basically already had our discussion > on > > this topic, so there is no need to rehash it again -- this is a > > non-blocking comment. > > > > Section 6 > > > > 3. Losing registrar retrieves the stored authorization > information > > locally or queries the registry for authorization information > > > > nit: I think s/retrieves the stored authorization information > > locally/retrieves the locally stored authorization information/ > helps > > readability. > > > > JG - Update will be made > > > > Section 6.1 > > > > How do these features interact with the presence (or absence) of the > > secure-authinfo-transfer XML namespace in the <login>/greeting > exchange? > > It sounds like the intent is for the server to just make these behavior > changes regardless of the capability negotiation, then? > > JG - Correct, the behavior change is independent of the client login > services. Everything is backward compatible and optional except for the Info > Response change, which you provided feedback about below. > > > It seems like at least the "don't return the authorization > information > > in the info response" change, if unilaterally implemented by the > > registry, would break the classic workflow for registrars that do > not > > store the authorization information locally and require retrieving > it > > from the registry. (Or are they required to implement the ability > to > > re-set the authorization information with an update, so that > recovery is > > possible?) > > > > JG - Correct, you picked up on the only non-backward compatible change > in the transition. Inclusion of not returning the authorization information > in an info response in Transition Phase 1 is important to enable Transition > Phase 2 to be done in the background without any direct impact to the > registrars. It's up to server policy, but generally registries would provide > notice to registrars ahead of deployment for the updated behavior. > > It seems like we should probably have some text in the document > acknowledging that there is potential for breakage if this change is made > in an uncoordinated manner, with either implicit or explicit > recommendation > for the registries to provide notice of the change via an out-of-band > policy channel. > > JG - How about updating the last sentence of Info Response feature > description to read as below, where the method for the notice does not need > to be prescribed here? There is an in-band mechanism being defined by the > working group with draft-ietf-regext-epp-registry-maintenance, which provides > for on-demand maintenance querying and maintenance notification via the EPP > poll queue. > > This feature is the only one that is not an optional change to the registrar > that has the potential of breaking the client, so it's recommended that the > registry provide notice of the change. That works for me, thanks. > > Section 6.2 > > > > Hash New Authorization Information Values: Change the create > command > > and the update command to hash instead of encyrpting the > > > > nit: s/encyrpting/encrypting/ > > > > JG - Update will be made > > > > Supporting Comparing Against Encrypted and Hashed Authorization > > Information: Change the info command and the transfer request > > command to be able to compare a passed authorization > information > > value with either a hashed or encyrpted authorization > information > > value. > > > > This seems to leave it implicit that the stored values in the > registry > > include an indication of whether they are encrypted or hashed. > This is > > probably trivial to ensure, just by virtue of being formatted > > differently, but is an important enough property that I would > suggest > > mentioning it specifically. > > > > JG - Yes, it will be trivial to identify a stored encrypted value > versus a stored hashed value. Do you have any suggested text to provide > clarity? > > "This requires that the stored values are self-identifying as being in > hashed or encrypted form" > > JG - I added that additional sentence. > > > Section 6.3 > > > > As for the case in Section 6.1, are these changes contingent on the > > negotiation of the use of secure-authinfo-transfer? Disallowing the > > creation of entries with non-empty authorization information values > > seems like it would break existing clients that do not implement > > secure-authinfo-transfer. Is there some mechanism in place that is > > going to make secure-authinfo-transfer (e.g., contractually) > required to > > implement for registrars? > > > > JG - It is up to server policy on the timing and approach taken to > notify the registrars with implementing the transition phases. > > As for §6.1, I'd suggest that we have explicit text mentioning the risk > (and expectation of out-of-band mitigation). > > JG - How about adding the similar recommendation to the "Disallow > Authorization Information on Create Command" element description as below. > As noted in the feedback for 6.1, the working group is working on an in-band > mechanism to maintenance notices with > draft-ietf-regext-epp-registry-maintenance. > > Change the create command to not allow for the passing of a non-empty > authorization information value that has the potential of breaking the > client, so it's recommended that the registry provide notice of the change. This sentence structure is a little hard to interpret. Maybe: Change the create command to not allow for the passing of a non-empty authorization information value. This behavior has the potential of breaking the client, so it's recommended that the registry provide notice of the change. ? > > > > Section 9 > > > > Section 4.1 defines the use a secure random value for the > generation > > of the authorization information. The server SHOULD define > policy > > related to the length and set of characters that are included in > the > > randomization to target the desired entropy level, with the > > recommendation of at least 128 bits for entropy. The > authorization > > information server policy is communicated to the client using an > out- > > of-band process. The client SHOULD choose a length and set of > > characters that results in entropy that meets or exceeds the > server > > policy. A random number generator (RNG) is preferable over the > use > > of a pseudorandom number generator (PRNG) when creating the > > authorization information value. > > > > [my comment from above about RNG vs PRNG applies here as well.] > > > > JG - Do you have any revised practices that you recommend referencing > when it comes to the use of RNG vs PRNG? > > My recommendation is to just omit the last sentence. > > JG - Ok, I'll removed it. > > > I am a little uneasy about the "SHOULD define policy", which may > just > > reflect a misundersanding of the text. If this is just an > > administrative policy that is written and read by humans, that is > > probably useful, but how it interacts with mechanical enforcement > (per > > my previous comments) could spill over into a regime of giving > normative > > recommendations to do things that I do not believe are best > practice. > > > > JG - Are you proposing to change the normative "SHOULD" with a > non-normative "should"? I believe it is important that the servers do > define a policy to meet the desired entropy level. > > I can't answer your question without knowing how you intend for this > policy > to be enforced. I think it's fine for the out-of-band communications from > registry to registrar to say "you need to use [strong random password, 128 > bits, etc.] with characters selected from a set including [whatever] and > length at least [computed value]" and be able to impose contractual > penalty > if audit discovers that the registrar failed to do so. I am not okay with > either "SHOULD" or "should"-level suggestion that the registry software > should require at least one character from multiple character classes for > each submitted password at runtime. (Checking the length at runtime is > fine.) > > JG - The policy defined by the server would be enforced by the registry > system. The security consideration is that the server SHOULD define a policy > to get the desired entropy level, which I believe is important. Do you > believe that recommendation should not be defined in the security > considerations? My concern is that at present, the most commonly used policies "related to the length and set of characters" used in a password-like thing are harmful policies that reject strong passwords with non-negligible probability and incentivize the selection of passwords that contain cursory representatives of each character class without adding unpredictability. So just saying "SHOULD define policy related to ..." with no further clarification is going to lead people into implementing those same harmful policies that are so prevalent today. What we want is that the client uses a large alphabet as the possible characters in its randomly selected password, and then independently picks an appropriately large number of characters each from the entire alphabet. We do *not* want a client to have an alphabet that's divided into categories, and then picks 2 letters, 4 numbers, 3 symbols, etc., since that's artificially reducing the entropy of the password. If the server policy is enforced as "must have at least one character from each set of: letters, numbers, symbols", then the latter strategy will be more reliable for the client, even though it is strictly worse from a cryptographic perspective than the former strategy. A good server policy in this space would be to specify a single alphabet that the client uses for password selection and the number of characters from that alphabet needed to meet the target entropy level ... but enforcement of that policy would be a bit more complicated. In particular, it would be based on modeling what input is extremely unlikely to have been produced by a client complying with the policy and rejecting (only) that input. So, for example, if the total number of unique characters in the password is less than a certain fraction of the password length (my intuition is that "half" would be safe, but I didn't check the statistics), that indicates a noncompliant client that should get rejected. Failing to include a symbol but having otherwise unique characters that are not in an clear order should not cause the password to be rejected. So, I remain pretty strongly opposed to leaving this "SHOULD define policy" in place without some guidance on what an effective policy and enforcement scheme, with only negligible false positives, would look like. That guidance could be in a separate document that is only an informational reference, and need not be included inline, but in the absence of concrete guidance I have high confidence that implementors will do the wrong things based only on this specification language. Stopping here, and thanks for your replies in the subsequent comments; they all look good so I have no further comments. -Ben > > Section 4.2 defines the use of an authorization information > Time-To- > > Live (TTL). The registrar SHOULD only set the authorization > > information during the transfer process by the server support for > > > > I guess I don't understand why this is only a SHOULD (and this same > > requirement seems to appear in Section 4.2 as well). Given that we > > propose for the registry to reject creation with non-empty > authorization > > information, it doesn't seem too big of a change to require that > > registrars also comply with this workflow. > > > > JG - The reason for the SHOULD is that authorization information can be > used for other purposes other than transfer, where the other purposes and the > applicable elements are out-of-scope as defined in the Introduction. In > practice authorization information is only used for transfer, but there may > be cases where authorization information can be used outside of the transfer > process. > > Okay, thanks for the extra explanation. > > > the end of the transfer process. The registry MUST store the > > authorization information using a one-way cryptographic hash of > at > > least 256 bits and with a random salt. All communication that > > > > [this text might have to change if the earlier comment about > password > > hashing techniques results in a textual change] > > > > JG - See my comment above. > > > > Section 11.1 > > > > (If my suggestion about RNG guidance is accepted, FIPS-140-2 will no > > longer need to be a normative reference.) > > > > JG - Do you have any revised practices that you recommend referencing > when it comes to the use of RNG vs PRNG? The reference can be updated, but > without another reference I would like to keep the normative reference to > FIPS-140-2. > > I think that I am unsure what you are intending the terms "RNG" and "PRNG" > to mean, so it's hard to have a productive conversation. > > For example, the term "PRNG" does not appear at all in FIPS 140-2, which > instead talks about "deterministic RNG"s and "nondeterministic RNG"s. > What it calls "deterministic RNGs" are inherently PRNGs, since they cease > to have random-like properties if the seed(s) (and algorithm) are > disclosed. > What it calls "nondeterministic RNGs" are things that "produce output that > is dependent on some unpredictable physical source that is outside human > control" (for example, this might be based on radioactive decay, > microphone > "shot noise", video of a laval lamp). These are what I refer to as (true) > RNGs, since there is no "pseudo" part that can be unmasked based on > disclosure of some separable information. Even FIPS 140-2, however, does > not want you to use nondeterministic RNG outputs directly for > keys/passwords -- they can only be used to produce seeds for deterministic > RNGs and to produce IVs. > > So I'd really like to hear what you think "RNG" means and why you think > FIPS 140-2 is supporting the use of RNGs over PRNGs. > > JG - The RNG and PRNG language was removed / replaced based on the other > feedback. I believe that the reference to FIPS-140-2 can now be made > informative instead of normative. > > > I don't really understand why RFC 3688 is listed as normative but > RFC > > 7451 is listed as informative -- on both cases they're only > referenced > > as the specification that created an IANA registry that we're > getting > > an allocation in. > > > > JG - The latest EPP RFC is RFC 8807, which lists RFC 3688 as normative. > The prior EPP RFC with RFC 8748 also lists RFC 3688 as normative. This > draft is following what was done in the prior two EPP RFCs. I don't have an > issue making it an informative reference if that is best. > > It doesn't really matter either way; there's basically no harm in listing > something as normative when it doesn't have to be. I just mentioned it > out > of a desire for consistency within the document; if you prefer to have > consistency across documents I won't argue with that. > > JG - Thanks > > Thanks, > > Ben > > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
