Eric, I will include the agreed changes in draft-ietf-regext-allocation-token-10. The additional items are included below:
JG - RFC 5731 includes support for an authorization info (<domain:authInfo>) that is an existing credential stored in the server at the time of the create command, which can be updated with an update command, that is used by the gaining client (registrar) to authorize a transfer request. The registrant should have access to the authorization info from their sponsoring registrar to pass to the gaining registrar to authorize the transfer request. The Allocation Token is not meant to replace the RFC 5731 authorization info, but is meant as an additional credential to authorize the "allocation" of the domain name. A registry may hold premium domain names that have an authorization info value, and leverage the transfer command for use in allocation with the use of the additional allocation token. Let me know if you need any additional clarification on this. Why is this just true for transfer and not the other commands? JG - The only other command supported by draft-ietf-regext-allocation-token is create, and the authorization info in RFC 5731 is set on create and not used for authorization. JG - An unsigned code is a non-complex string that the server generates and stores with the domain name, which can be later validated during allocation. Where can I find a reference for this? JG - This is an implementation approach that has not been defined in a public Internet Draft or external resource that I’m aware of. Actually, the use of server-generated codes that is provided to auction providers for premium domain names, which then is provided to the winning registrant to be passed to the registrar and subsequently to the registry in a create command, with the unsigned code in the allocation token extension, was the original use case for draft-ietf-regext-allocation-token. The use of 3rd party signed tokens was used later to address additional use cases, such as pre-validating eligibility of domain names. The key is that draft-ietf-regext-allocation-token is a conduit that may be passed to satisfy different implementation use cases where the allocation token can contain a digital signed value or a simple code that the server can verify to authorize allocation. — JG [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Eric Rescorla <e...@rtfm.com> Date: Wednesday, August 15, 2018 at 11:23 AM To: James Gould <jgo...@verisign.com> Cc: The IESG <i...@ietf.org>, "regext-cha...@ietf.org" <regext-cha...@ietf.org>, Patrick Mevzek <patrick+i...@deepcore.org>, "p...@dotandco.com" <p...@dotandco.com>, "regext@ietf.org" <regext@ietf.org>, "draft-ietf-regext-allocation-to...@ietf.org" <draft-ietf-regext-allocation-to...@ietf.org> Subject: [EXTERNAL] Re: Eric Rescorla's Discuss on draft-ietf-regext-allocation-token-09: (with DISCUSS and COMMENT) On Wed, Aug 15, 2018 at 7:42 AM, Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Eric, Thank you for your review and feedback. I provide responses to your feedback 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:02 AM, "Eric Rescorla" <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: Eric Rescorla 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: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3061 These are bearer tokens and therefore I believe transport encryption needs to be required in S 7, not just listed as should (which isn't even normative in this context). JG - "An Allocation Token should be considered secret information by the client and should be protected at rest and in transit." can be changed to "An Allocation Token should be considered secret information by the client and SHOULD be protected at rest and MUST be protected in transit." Yes, this seems like the minimum. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 3.2.4. > like [RFC5731], the command MUST contain a child > <allocationToken:allocationToken> element for the client to be > authorized to transfer and allocate the object. The authorization > associated with the Allocation Token is in addition to and does not > replace the authorization mechanism defined for the object's > <transfer> request command. If the Allocation Token is invalid or I'm having trouble processing this statement. Can you explain in more detail what the two access control checks are here. JG - RFC 5731 includes support for an authorization info (<domain:authInfo>) that is an existing credential stored in the server at the time of the create command, which can be updated with an update command, that is used by the gaining client (registrar) to authorize a transfer request. The registrant should have access to the authorization info from their sponsoring registrar to pass to the gaining registrar to authorize the transfer request. The Allocation Token is not meant to replace the RFC 5731 authorization info, but is meant as an additional credential to authorize the "allocation" of the domain name. A registry may hold premium domain names that have an authorization info value, and leverage the transfer command for use in allocation with the use of the additional allocation token. Let me know if you need any additional clarification on this. Why is this just true for transfer and not the other commands? S 7. > specifications apply to this specification as well. > > The mapping acts as a conduit for the passing of Allocation Tokens > between a client and a server. The definition of the Allocation > Token is defined outside of this mapping. The following are security > considerations in the definition and use of an Allocation Token: Do you want to use normative language here? JG - Are you requesting normative language such as "The definition of the Allocation Token SHOULD be defined outside of this mapping". There are cases when the allocation token is a non-complex string value that does not require formal definition, so the normative SHOULD seems most appropriate here. Do you agree? I think you probably want this, yes. S 7. > 3. An Allocation Token should have a limited life with some form of > expiry in the Allocation Token if generated by a trusted 3rd > third party, or with a server-side expiry if generated by the > server. > 4. An Allocation Token should use a strong random value if it is > based on an unsigned code. What is an "unsigned code"? JG - An unsigned code is a non-complex string that the server generates and stores with the domain name, which can be later validated during allocation. Where can I find a reference for this? -Ekr
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
