Re: [regext] New Version Notification for draft-gould-regext-secure-authinfo-transfer-00.txt

Gavin, 

Thank you for your review and support.  I posted draft-gould-regext-secure-authinfo-transfer-01 (https://tools.ietf.org/html/draft-gould-regext-secure-authinfo-transfer-01) with the revised Implementation Status section along with small corrections based on private review feedback.  

Any additional review and feedback of the draft is appreciated.

Thanks,

—

JG

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 6/25/19, 1:12 PM, "Gavin Brown" <gavin.brown@centralnic.com> wrote:

    Hi Jim,

    I have reviewed the draft and I think it's a good piece of work. CentralNic actually already implements some of the practices in it: the <authInfo> code is "write only" in that registrars can set it, but not see it. Feel free to include that in the "Implementation Status" section.

    I would support the WG's adoption of this draft if it were put forward.

    G.

    > On 25 Jun 2019, at 13:29, Gould, James <jgould=40verisign.com@dmarc.ietf.org> wrote:
    > 
    > The Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer (draft-gould-regext-secure-authinfo-transfer) was posted to define a BCP for securing the authorization information using the existing EPP RFCs.  The overall goal is to have strong, random authorization information values, that are short-lived, and that are either not stored or stored as cryptographic hash values.  Review and feedback is appreciated.  
    > 
    > Antoin and Jim, I would like to have 10 minutes to introduce and discuss this draft at the REGEXT meeting at IETF-105.  
    > 
    > Thanks, 
    > 
    > —
    > 
    > JG
    > 
    > 
    > 
    > James Gould
    > Distinguished Engineer
    > jgould@Verisign.com
    > 
    > 703-948-3271
    > 12061 Bluemont Way
    > Reston, VA 20190
    > 
    > Verisign.com <http://verisigninc.com/> 
    > 
    > On 6/25/19, 8:23 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:
    > 
    > 
    >    A new version of I-D, draft-gould-regext-secure-authinfo-transfer-00.txt
    >    has been successfully submitted by James Gould and posted to the
    >    IETF repository.
    > 
    >    Name:		draft-gould-regext-secure-authinfo-transfer
    >    Revision:	00
    >    Title:		Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer
    >    Document date:	2019-06-25
    >    Group:		Individual Submission
    >    Pages:		17
    >    URL:            https://www.ietf.org/internet-drafts/draft-gould-regext-secure-authinfo-transfer-00.txt
    >    Status:         https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/
    >    Htmlized:       https://tools.ietf.org/html/draft-gould-regext-secure-authinfo-transfer-00
    >    Htmlized:       https://datatracker.ietf.org/doc/html/draft-gould-regext-secure-authinfo-transfer
    > 
    > 
    >    Abstract:
    >       The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
    >       use of authorization information to authorize a transfer.  The
    >       authorization information is object-specific and has been defined in
    >       the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
    >       Mapping, in RFC 5733, as password-based authorization information.
    >       Other authorization mechanisms can be used, but in practice the
    >       password-based authorization information has been used by the
    >       authorization information being set at the time of object create,
    >       managed with the object update, and used to authorize an object
    >       transfer request.  What has not been fully considered is the security
    >       of the authorization information that includes the complexity of the
    >       authorization information, the time-to-live (TTL) of the
    >       authorization information, and where and how the authorization
    >       information is stored.  This document defines an operational
    >       practice, using the EPP RFCs, that leverages the use of strong random
    >       authorization information values that are short-lived, that are not
    >       stored by the client, and that are stored using a cryptographic hash
    >       by the server to provide for secure authorization information used
    >       for transfers.
    > 
    > 
    > 
    > 
    >    Please note that it may take a couple of minutes from the time of submission
    >    until the htmlized version and diff are available at tools.ietf.org.
    > 
    >    The IETF Secretariat
    > 
    > 
    > 
    > _______________________________________________
    > regext mailing list
    > regext@ietf.org
    > https://www.ietf.org/mailman/listinfo/regext

    --
    Gavin Brown
    Chief Innovation Officer
    CentralNic Group plc (LSE:CNIC)
    https://www.centralnicgroup.com/
    +44.7548243029

    CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6AE.