Re: [secdir] Secdir last call review of draft-ietf-regext-epp-eai-12

["Gould, James" <[e-mail]>]

Chris,

Based on the feedback that you provided, we did add the proposed language below to the security considerations section of draft-ietf-regext-epp-eai-13:

When the EAI functional extension is negotiated by both the client and the server, the client and server obligations defined in Section 5.3.1 MUST be satisfied.  If the obligations are not satisfied by either the client or server, the EAI address may be mishandled in processing or storage and be unusable.

If this addresses your feedback, can you clear the SECDIR "Has Issues" status, or let us know what else needs to be addressed?

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

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

On 6/13/22, 11:35 AM, "Gould, James" <[e-mail]> wrote:

    Chris,

    Thank you for the review, feedback, and recommended text.  You mention an interesting use case of a client or server that signals the support EAI, but that can't meet the obligations defined in section 5.3.1 "EAI Functional Extension Negotiated".  The negotiation is handled when the EPP session is established via the list of services provided by the server in the greeting and the client in the login command.  In EPP there is no functional capability to not accept the service URI at the time of EPP session establishment based on determining compliance with a service / extension obligation.  For EAI, the negotiated services will imply the normative language in section 5.3.2 "EAI Functional Extension Negotiated" for the server and the client, respectively.  We could add the following to the security considerations section to cover the risk of negotiating EAI support without fully complying with the obligations defined in section 5.3.1:

    When the EAI functional extension is negotiated by both the client and the server, the client and server obligations defined in Section 5.3.1 MUST be satisfied.  If the obligations are not satisfied by either the client or server, the EAI address may be mishandled in processing or storage and be unusable.   

    Any thoughts on the language is appreciated.

    Thanks,
    -- 

    JG



    James Gould
    Fellow Engineer
    [e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

    Verisign.com <http://secure-web.cisco.com/175AUUsbJVaoxOezz1lqoGtSJG2fku7o0Lg9ShgFtnC4wowW2VYMrmIqsxvdw93PUXc2zhu3Qf0z8or4QFqBqV1mTbQMn9lQnbIOAVMsXaB1uY4hTJABd3GehICkvskowKXshb5UzeTUstLXIGspyEsa0X6-Tx3uhSauMW2UVMuMhcZSFxqATxnzJeBBNJ7EXOc99PT8z9_eFVgLD81xEbKtqiBqwX6PeIRQUx8qZCVCNK9JzfpLNjQjii2fyx5TI/http%3A%2F%2Fverisigninc.com%2F>

    On 6/12/22, 8:48 PM, "Chris Lonvick via Datatracker" <[e-mail]> wrote:


        Reviewer: Chris Lonvick
        Review result: Has Issues

        Hello,

        I have reviewed this document as part of the security directorate's ongoing
        effort to review all IETF documents being processed by the  IESG.  These
        comments were written primarily for the benefit of the  security area
        directors.  Document editors and WG chairs should treat  these comments just
        like any other last call comments.

        The summary of the review is that it has issues.

        The document is well written and the Security Considerations seems appropriate.
        However, there is insufficient guidance given regarding when the EAI functional
        extension is negotiated, but when the server cannot satisfy the required
        obligations. The specification says that when the client and server negotiate
        the EAI functional specification that, "implies the possibility to process the
        EAI address". The draft needs to specify what happens if the client and server
        negotiate the EAI functional extension, but when the server cannot fulfill its
        obligations to provide the required information, or when the client cannot
        process the received information.

        This may be easily fixed by saying in the specification that the server will
        only accept the negotiation if it can (MUST) provide the required information
        specified in section 5.3.1 and that the client can (MUST) accept and act upon
        that received information. The specification should also go on to say what MUST
        happen if those conditions are not met.

        Best regards,
        Chris