On Wed, Aug 15, 2018 at 09:09:00PM +0000, Gould, James wrote: > Benjamin, > > Thank you for the review and feedback. My responses to your feedback are > embedded below with a "JG - " prefix.
Thanks. Also inline... > > — > > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 8/15/18, 12:01 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-regext-allocation-token-09: 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://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (I agree with Ekr's DISCUSS about these being bearer tokens and am happy > to > see the discussion on improving the text there.) > > There are a couple of other things that I seek discussion on: > > The document itself does very little to motivate the addition of the > allocation token, from a security point of view. In what security model > is > there a security advantage from having this sort of single-use > authorization token as opposed to using existing authentication and > authorization methods? The use case of a premium domain-name auction that > came up in Ekr's ballot thread is actually quite enlightening, in that the > token allows for the authorization to be granted to the winner of an > auction even in the case where the winning bidder and the current > registration owner do not have any common authentication or authorization > infrastructure (other than for the auction and its payment itself). Some > generalization of these considerations into a model that matches the > generalized functionality in the draft would be a quite helpful addition. > This could also be leveraged in the discussion of why the allocation token > is not needed in the various commands for which its usage is not provided > (mentioned in my COMMENT). > > JG - There are many use cases where draft-ietf-regext-allocation-token > can be used to contain an allocation token to authorize allocation of a > domain name. There was similar feedback from the WG, which was addressed > by the addition of the second paragraph in the Introduction, which was to > list the known use cases for allocation via the Allocation Token. The > purpose of draft-ietf-regext-allocation-token is to be the conduit to > support the currently known allocation and yet to be defined allocation > use cases. We don't want to have the protocol overly prescribe a > specific use case, since it fills a critical role of enabling the tokens > to be passed over EPP in an explicit manner without attempting to > override the authorization info mechanism defined in RFC 5731. As noted > in my response to Eric's feedback, the initial auction use case was the > catalyst for draft-ietf-regext-allocation-token, but other use cases came > up where draft-ietf-regext-allocation-token met the need like > pre-eligibility validation and founders program registrations. Of course we don't want to unnecessarily lock in to a specific use case; I must have phrased my request poorly. I'm not asking for more description of the use cases (though, to be honest, I'm not sure I figured out the "founders Allocation Token" case yet), but rather an analysis of why they are needed at all. I'm not terribly well-versed with the EPP terminology, so my apologies if this reads a little strangely. Consider a degenerate case where there's one server (call it Bob) and one client (call it Alice). Alice has some credentials (password) it uses to authenticate to Bob, and Bob can say "yes, this is Alice and I know Alice; Alice is authorized to make the allocation she's requesting because it says so right here in my local authorization database". In this highly contrived, entirely local scenario, there is no need (that I can see) for an allocation token at all. It sounds like (but I can't quite tell), the need comes into play when there is another client (call it Charlie) in play, but maybe also when there is another server in play as well (call it Doug). Charlie may not have credentials with Bob (but does with Doug), and Bob can issue an allocation token (E.g., based on the say-so of Alice), that Charlie can use, in addition to his normal authentication with Doug, to make a specific allocation. What about the case when Alice and Charlie are both clients and Bob is the only server involved? Do I need an allocation token then, or can Bob continue to store the authorization information locally? In a general sense, how many and what types protocol actors are needed for the existing solution to break down and this new solution to become needed? Not as a question of specific use cases, but as a question of what protocol flows and authorization decisions are not possible without this new technology? > I also request changes to the examples (or the discussion surrounding > them). > Using "abc123" as the example allocation token is probably unwise, as that > value provides none of the properties we desire from allocation tokens. > If you don't want to use an actual random-looking (e.g., self-encrypted > server-generated) or signed value because it makes the examples too long, > at least provide some text indicating that "abc123" is a placeholder and > real tokens should have a different structure. > Similarly, the passwords used in the examples hardly have enough entropy > to > be considered secure by modern standards. > > JG - I can add a paragraph to the "Conventions Used in This Document" section > that indicates that the "abc123" token value is used as a placeholder value > in the examples. The server MUST support token values that follow the > Security Considerations. That would be great, thanks! (There does seem some pedagogical merit in having this easily recognized value used in the examples, to distinguish it from any other random data that might be present.) Please also make a note about the password as well ("2fooBAR"). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (section-by-section) > > Section 1 > > A client MUST pass an Allocation Token known to the server to be > authorized to use one of the supported EPP transform commands. It is > up to server policy which EPP transform commands and which objects > require the Allocation Token. > > The language could probably be tightened up for greater clarity about when > the MUST applies, and perhaps be consistent about "supported" vs. > "require" > between sentences. > > JG - This pretty much says that the client MUST pass an Allocation Token > to the server that the server supports and can validate. The "to be > authorized..." portion of the sentence can be removed, since that is > covered by the second sentence. Does it tighten it up by stating "A > client MUST pass an Allocation Token to the server that the server > supports and can validate" in the first sentence? That helps some, yes. But it's not clear that we need that MUST at all -- a literal reading is that this document should be Updating 5730 so that all clients trying to use transform commands must always pass an allocation token, and existing deployments not implementing this spec are suddenly broken by fiat. So maybe: Clients pass an Allocation Token to the server for validation, and the server determines if the supplied token is one supported by the server. Server policy dictates which EPP transform commands and objects require the use of an Allocation Token, and which Allocation Tokens provide authorization for which command/object pairings. > Section 1.1 > > represents lines returned by a protocol server. Indentation and > white space in examples are provided only to illustrate element > relationships and are not a REQUIRED feature of this protocol. > > It would be nice to rephrase this so that "NOT REQUIRED" could be > together/majuscule. Maybe, "to illustrate element relationships and > implementations are NOT REQUIRED to adhere to such whitespace and > formatting"? > > JG - How about "Indentation and white space in the examples are provided only > to illustrate element relationships and are NOT REQUIRED in the protocol."? Sure. > The XML namespace prefix "allocationToken" is used for the namespace > "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations > MUST NOT depend on it and instead employ a proper namespace-aware XML > parser and serializer to interpret and output the XML documents. > > Maybe I'm misunderstanding, but isn't this kind-of inviting sloppy > implementations that don't check? Sometimes we say things like "this > prefix is used in the examples for concision but actual usage is expected > to vary between fully scoped and shortened versions". > > JG - I believe this disallows sloppy implementations by using the > normative MUST NOT depend on the "allocationToken" prefix. If an > implementation is dependent on the use of the "allocationToken" XML > namespace prefix, it would not be compliant with the protocol, which > mitigates a sloppy implementation. I used the word "inviting" instead of "allowing" for a reason, along the lines of the "attractive nuisance" doctrine of liability. It's like saying "yes, there's this incredibly convenient thing that you could do and will work most of the time, but you need to have self control and do a big scarey complicated thing instead of this easy thing I just mentioned". Phrasing as something like "this document uses the bare namespace prefix "allocationToken" to aid readability of examples, but real-world deployments will encounter fully qualified namespaces as well as implicitly qualified ones" doesn't even require normative language, and conveys the impression of "of course you need to handle robust input; it's all over the place". Do note, of course, that this is a non-blocking comment and (normative language aside) probably subject to your editorial discretion. > Section 3.1.1 > > 2. If an object requires an Allocation Token and the Allocation > Token does not apply to the object or an object does not require > an Allocation Token, then the server SHOULD return the > availability status as unavailable (e.g., "avail" attribute is > "0" or "false"). > It's really unclear why these two cases are not distinguished in a > machine-readable way (i.e., not the text of the reason). (Also in 3.2.4, > etc.) > > JG - I don't understand what you mean by "in a machine-readable way". > The cases for the check response cover the expected value of the "avail" > flag in the check response in RFC 5731, when applying the Allocation > Token in the check command, which is the key machine-readable attribute > returned to the client. The <domain:reason> is human-readable and not > discussed in the two cases, since it should not drive client-side logic. You are overloading avail=false to mean two different things: (1) the supplied allocation token is no good here, and (2) this object didn't need an allocation token at all. Am I supposed to do the same thing in response to both of those cases? Intuitively it seems that (1) get a fresh token and (2) try again without supplying a token would be natural responses, and those are quite different. I agree that <domain:reason> is human readable and should not drive client-side logic -- give me something usable to disginguish cases (1) and (2) so that I can drive my client-side logic! > Section 3.1.2 > > [...] Authorized clients MAY retrieve > the Allocation Token (Section 2.1) along with the other object > information using the <allocationToken:info> element. [...] > > The causality here is a bit weird; it seems like the client is requesting > to retrieve the token by including <allocationToken:info> in its request > so > that the server knows to include it in the response (where it is retrieved > from an <allocationToken:allocationToken> element). > > JG - That is correct, querying for the allocation token is explicit by > the inclusion of the empty <allocationToken:info> element in the info > command. There is no need for the server to return it if the client does > not need it. "retrive X using the Y element" has a simple reading that information X is contained within Y. That simple reading of this text is incorrect and finding the correct interpretation requires a decent amount of mental effort. Can we save the reader that effort and instead say something like: Authorized clients MAY retrieve the Allocation Token (Section 2.1) alongside other object information by supplying the <allocationToken:info> element in the request. > If the query was successful, the server replies with an > <allocationToken:allocationToken> element, as described in > Section 2.1. > > Section 2.1 describes the contents of the element, not how the server > replies with it. Maybe, "interpreted as described in" would be better? > > JG - Maybe this can be rephrased similar to the info response description in > RFC 8334 as "If the query was successful, the server replies with an > <allocationToken:allocationToken> element along with the regular EPP > <resData>. The <allocationToken:allocationToken> element is described in > section 2.1." Is this better? Much better, thanks! > Section 3.1.3 > > It would probably be good to have some discussion of why the <transfer> > query command (as opposed to transform command) does not benefit from > having this additional authorization-checking mechanism. > > JG - This is consistent language to other EPP extensions, where the extension > defines explicitly what commands don't apply and doesn't attempt to cover why > they don't apply. See section 3.6 and 3.7 in RFC 8334, or section 5.1.1, > 5.1.3, 5.2.2, and 5.2.3 in RFC 5910. I guess so. RFC 8334 has a pretty clear overview that it only covers initial registrations in a greenfield namespace, though (so renewals and transfers don't make sense yet), and though I'm less clear on RFC 5910, it seems like it's allowing the client to specify additional metadata to be stored, and so the presence of that additional metadata doesn't have relevance for checking if creation is possible or deleting things. As discussed above, this document doesn't really give me a clear picture of the overarching (authorization) goals and why some operations do not benefit from additional authorization. Keeping parallelism with other EPP extension specifications does seem to imply keeping this section (and the below-mentioned ones) as-is, but also providing a clearer version of the bigger picture. > Section 3.2.1 > > The EPP <create> command provides a transform operation that allows a > client to create an instance of an object. In addition to the EPP > command elements described in an object mapping like [RFC5731], the > command MUST contain a child <allocationToken:allocationToken> > > This MUST is only for the cases when an allocation token is to be used, > right? (Similarly in 3.2.4, etc.) > > JG - Yes, that is correct. This is consistent with other EPP extensions, > where the normative language applies to when the extension is needed or used. > OK. > element for the client to be authorized to create and allocate the > object. If the Allocation Token does not apply to the object, the > server MUST return an EPP error result code of 2201. > > nit: Maybe "supplied Allocation Token"? > > JG - Ok, I can change "If the Allocation Token does not apply..." to "If the > supplied Allocation Token does not apply...". > > > Section 3.2.2, 3.2.3, 3.2.5 > > Similarly to for Section 3.1.3, some text on why the additional > authorization is not useful would be helpful. > > JG - This is consistent language to other EPP extensions, where the extension > defines explicitly what commands don't apply and doesn't attempt to cover why > they don't apply. See section 3.6 and 3.7 in RFC 8334, or section 5.1.1, > 5.1.3, 5.2.2, and 5.2.3 in RFC 5910. > > Section 4.1 > > <annotation> > <documentation> > Extensible Provisioning Protocol v1.0 > Allocation > Token Extension. > </documentation> > </annotation> > > nit: are this many line breaks needed? > > JG - This can be fixed. > > I also question the minLength of 1 for an allocation token value. > Why couldn't it be more like 16 or even 32? I would put this in the > DISCUSS section but maybe there are mitgating circumstances I'm unaware > of. > > JG - The makeup of the token itself it not defined by > draft-ietf-regext-allocation-token, so the only requirement that > draft-ietf-regext-allocation-token needs to apply is that the > <allocationToken:allocationToken> element is not empty. I can sympathize with this argument somewhat, but (e.g.) in RFC 8446 we set a lower bound of 32 bytes on the size of a PSKBinderEntry even though the protocol data structure just needed something non-empty -- in order to provide the needed cryptographic property (binding a key to the current ClientHello) at least that many bytes were needed. Since there is no statement in this document about what properties the token value needs to provide, we're in something of a grey area. But, if section 7 is suggesting that we use digital signatures or strong random values, we can provide implementors incentive to use the recommended techniques by denying them the ability to use a simple counter that starts at one. Again, this is a non-blocking comment, but what is the harm in requiring a longer value, compared against the benefit of encouraging cryptographic best practices? -Benjamin _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
