Benjamin,
Thanks again. My responses to your feedback is embedded below. — 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, 10:31 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote: 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? JG - The allocation token is not used to identify or authenticate a user, but it is associated with an object (e.g., domain name) as an extra credential needed to register (allocate) the object. Any client (registrar to registry) can pass a valid allocation token to authorize the allocation. RFC 5731 requires the passing of an auth info code at the time of registration (create) for use to authorize a later transfer request, but it is not used to authorize the registration itself. The allocation token is an explicit credential that is used to authorize the registration (or allocation). The allocation token itself it not defined in draft-ietf-regext-allocation-token, since draft-ietf-regext-allocation-token is a conduit for the allocation token. The allocation token can be a pre-generated random value that is stored with the domain name in the server or it could be digitally signed data that can be validated by the server for authorizing the allocation. Maybe it would help to describe in the Introduction the difference between an Allocation Token and the existing authorization information defined in RFC 5731 (and other EPP mappings), since they are both credentials used for different purposes. How about adding the following paragraph after the second Introduction paragraph or as a paragraph in the “Allocation Token” section 2.1? Authorization information, like what is defined in the EPP domain name mapping [RFC5731], is associated with objects to facilitate transfer operations. The authorization information is assigned when an object is created. The Allocation Token and the authorization information are both credentials, but used for different purposes and used in different ways. The Allocation Token is used to facilitate the allocation of an object instead of transferring the sponsorship of the object. The Allocation Token is not managed by the client, but is validated by the server to authorize assigning the initial sponsoring client of the object. > 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"). JG – Will do, thanks! > ---------------------------------------------------------------------- > 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. JG – The normative MUST may be too strong here, since the client is protocol compliant in passing a Allocation Token that the server may determine is invalid for the operation and / or object. How about just changing the first sentence to what you propose, so the end result is the following: Clients pass an Allocation Token to the server for validation, and the server determines if the supplied Allocation Token is one supported by the server. It is up to server policy which EPP transform commands and which objects require the Allocation Token. > 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. JG – Thanks your input is appreciated and noted. > 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! JG – There is no reason to distinguish between (1) and (2), since the purpose of the check is to “provide a hint that allows a client to anticipate the success or failure of provisioning an object using the <create> command” [RFC5731]. The check command is very lightweight and is meant to return availability as true (1) or false (0) based on the input provided with a human readable reason. In this case it’s a combination of the domain name and the Allocation Token. The client can attempt to execute the create to get a more detailed error based on the set of supported EPP result codes in RFC 5730, but I don’t believe the client will go any further. The use of the Allocation Token extension with the check command is to supply the second data element to determine the hint of the result of provisioning the object using the <create> command. > 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. JG – I don’t have an issue with your revised text, other than a few tweaks as defined below: Authorized clients MAY retrieve the Allocation Token (section 2.1) along with the other object information by supplying the <allocationToken:info> element in the command. > 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. JG – The set of transform operations that are applicable to allocation are defined in the Abstract and the Introduction (e.g., “…using one of the EPP transform commands including create and transfer”). In this case, the transfer query is a query command that is not associated with allocation. > 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? JG – I don’t want draft-ietf-regext-allocation-token to dictate the makeup of the token that is used via the XML schema. The guidance for the Allocation Token is provided in the Security Considerations section for the token designer to consider. -Benjamin
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
