Re: [auth48] [C381] Re: AUTH48: RFC-to-be 9303 <draft-ietf-lisp-sec-29> for your review

["Fabio Maino (fmaino)" <[e-mail]>]

Please see in-line...

On 9/16/22, 3:59 PM, "[e-mail]" <[e-mail]> wrote:

    Authors,

    While reviewing this document during AUTH48, please resolve (as necessary) 
    the following questions, which are also in the XML file.

    1) <!--[rfced] It appears that text may be missing in this sentence
    after "defined in".  Should this refer to RFC 7835?  Please review and 
    let us know how to update.

    Original:
       LISP-SEC builds on top of the security mechanisms defined in to
       address the threats described in Section 4 by leveraging the trust
       relationships existing among the LISP entities
       ([I-D.ietf-lisp-rfc6833bis]) participating in the exchange of the
       Map-Request/Map-Reply messages.
    -->   

Section 5 

OLD: 
LISP-SEC builds on top of the security mechanisms defined in

NEW:
LISP-SEC builds on top of the security mechanisms defined in [I-D.ietf-lisp-rfc6833bis]


    2) <!-- [rfced] HMAC is expanded in this document as "Keyed-Hashing for Message 
    Authentication (HMAC)".  While the title of RFC 2104 matches this expansion, 
    we have changed it to "Hashed Message Authentication Code (HMAC)" as that is 
    more common.  Please let us know if you strongly prefer that this be reverted.

       o  The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for
          Message Authentication (HMAC) [RFC2104] that protects the
          integrity of the mapping data known to the Map-Server to prevent
          overclaiming attacks.
    -->

Ok


    3) <!-- [rfced] Should instances of "ECM message" be updated to read simply
    "ECM" to avoid redundancy (if expanded, "ECM message" would read
    "Encapsulated Control Message message"). Please review and let us know
    if we may update the text. 

    Example from Section 5 (original):
       2.  The Map-Resolver decapsulates the ECM message, decrypts the ITR-
           OTK, if needed, and forwards through the Mapping System the
           received Map-Request and the ITR-OTK, as part of a new ECM
           message.
    -->   

Ok.

Global

OLD:
ECM message

NEW: 
ECM


    4) <!-- [rfced] We note that RFC 3394 does not include any mention of
    "msg-key" or "per-msg-key". Please review and let us know how to update the
    citation.    

    Original:
       According to [RFC3394] the per-msg-key is used to wrap the OTK
       with AES-KEY-WRAP-128.
    -->   

The per-msg-key is defined in this doc, and wrapped using the OTK defined in this doc using AES-KEY-WRAP-128 that is specified in RFC3394. The following should be more clear:

Section 6.5

OLD:
According to [RFC3394] the per-msg-key is used to wrap the OTK with AES-KEY-WRAP-128.

NEW:
The per-msg-key is then used to wrap the OTK with AES-KEY-WRAP-128, as specified in section 2.2.1 of {RFC3394]


    5) <!-- [rfced] Should "128 less significant bits" be "128 least significant 
    bits"?  Please review.

    Original:
           The most significant
           64-bit are copied in the One-Time Key Preamble field, while the
           128 less significant bits are copied in the One-Time Key field of
           the LISP-SEC Authentication Data.

    Perhaps:
           The most significant 64 bits
           are copied in the 'One-Time Key Preamble' field, while the 128
           least significant bits are copied in the 'One-Time Key' field of
           the LISP-SEC Authentication Data.
    -->

Ok

    6) <!--[rfced] It is unclear if "will be discarded" is referring to
    "a replayed Map-Reply" or "the incoming Map-Reply". Please review
    and let us know how this sentence should be updated.

    Original:
       If a replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK>
       that matches the incoming Map-Reply and will be discarded.

    Perhaps (referring "a replayed Map-Reply": 
       If a replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK>
       that matches the incoming Map-Reply and the replayed Map-Reply will be
       discarded.
    -->

Ok

    7) <!--[rfced] Throughout the text, the following term appears to be used 
    inconsistently: 

    key wrap vs. Key Wrap vs. key wrapping

    Please review these occurrences and let us know
    if/how this may be made consistent.
    -->

Please, change ONLY the following instances: 

Section 6.5
OLD: 
as well as the AES-KEY-WRAP-128 Key Wrap algorithm
NEW: 
as well as the AES-KEY-WRAP-128 key wrap algorithm

OLD: 
1.  The KDF and Key Wrap algorithms
NEW: 
1.  The KDF and key wrap algorithms

OLD: 
The output of the AES Key Wrap operation is 192-bit long.
NEW:
The output of the AES key wrap operation is 192-bit long.

OLD: 
AES Key Wrap decryption operation
NEW: 
AES key wrap decryption operation


    8) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
    Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 
    and let us know if any changes are needed. Note that our script did not flag
    any words in particular, but this should still be reviewed as a best practice.
    -->  

I don’t see any occurrence of non-inclusive language. 



Thanks for another great review! 
Fabio



    Thank you.

    RFC Editor


    On Sep 16, 2022, at 3:56 PM, [e-mail] wrote:

    *****IMPORTANT*****

    Updated 2022/09/16

    RFC Author(s):
    --------------

    Instructions for Completing AUTH48

    Your document has now entered AUTH48.  Once it has been reviewed and 
    approved by you and all coauthors, it will be published as an RFC.  
    If an author is no longer available, there are several remedies 
    available as listed in the FAQ (https://www.rfc-editor.org/faq/).

    You and you coauthors are responsible for engaging other parties 
    (e.g., Contributors or Working Group) as necessary before providing 
    your approval.

    Planning your review 
    ---------------------

    Please review the following aspects of your document:

    *  RFC Editor questions

       Please review and resolve any questions raised by the RFC Editor 
       that have been included in the XML file as comments marked as 
       follows:

       <!-- [rfced] ... -->

       These questions will also be sent in a subsequent email.

    *  Changes submitted by coauthors 

       Please ensure that you review any changes submitted by your 
       coauthors.  We assume that if you do not speak up that you 
       agree to changes submitted by your coauthors.

    *  Content 

       Please review the full content of the document, as this cannot 
       change once the RFC is published.  Please pay particular attention to:
       - IANA considerations updates (if applicable)
       - contact information
       - references

    *  Copyright notices and legends

       Please review the copyright notice and legends as defined in
       RFC 5378 and the Trust Legal Provisions 
       (TLP – https://trustee.ietf.org/license-info/).

    *  Semantic markup

       Please review the markup in the XML file to ensure that elements of  
       content are correctly tagged.  For example, ensure that <sourcecode> 
       and <artwork> are set correctly.  See details at 
       <https://authors.ietf.org/rfcxml-vocabulary>.

    *  Formatted output

       Please review the PDF, HTML, and TXT files to ensure that the 
       formatted output, as generated from the markup in the XML file, is 
       reasonable.  Please note that the TXT will have formatting 
       limitations compared to the PDF and HTML.


    Submitting changes
    ------------------

    To submit changes, please reply to this email using ‘REPLY ALL’ as all 
    the parties CCed on this message need to see your changes. The parties 
    include:

       *  your coauthors

       *  [e-mail] (the RPC team)

       *  other document participants, depending on the stream (e.g., 
          IETF Stream participants are your working group chairs, the 
          responsible ADs, and the document shepherd).

       *  [e-mail], which is a new archival mailing list 
          to preserve AUTH48 conversations; it is not an active discussion 
          list:

         *  More info:
            https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

         *  The archive itself:
            https://mailarchive.ietf.org/arch/browse/auth48archive/

         *  Note: If only absolutely necessary, you may temporarily opt out 
            of the archiving of messages (e.g., to discuss a sensitive matter).
            If needed, please add a note at the top of the message that you 
            have dropped the address. When the discussion is concluded, 
            [e-mail] will be re-added to the CC list and 
            its addition will be noted at the top of the message. 

    You may submit your changes in one of two ways:

    An update to the provided XML file
     — OR —
    An explicit list of changes in this format

    Section # (or indicate Global)

    OLD:
    old text

    NEW:
    new text

    You do not need to reply with both an updated XML file and an explicit 
    list of changes, as either form is sufficient.

    We will ask a stream manager to review and approve any changes that seem
    beyond editorial in nature, e.g., addition of new text, deletion of text, 
    and technical changes.  Information about stream managers can be found in 
    the FAQ.  Editorial changes do not require approval from a stream manager.


    Approving for publication
    --------------------------

    To approve your RFC for publication, please reply to this email stating
    that you approve this RFC for publication.  Please use ‘REPLY ALL’,
    as all the parties CCed on this message need to see your approval.


    Files 
    -----

    The files are available here:
       https://www.rfc-editor.org/authors/rfc9303.xml
       https://www.rfc-editor.org/authors/rfc9303.html
       https://www.rfc-editor.org/authors/rfc9303.pdf
       https://www.rfc-editor.org/authors/rfc9303.txt

    Diff file of the text:
       https://www.rfc-editor.org/authors/rfc9303-diff.html
       https://www.rfc-editor.org/authors/rfc9303-rfcdiff.html (side by side)

    Diff of the XML: 
       https://www.rfc-editor.org/authors/rfc9303-xmldiff1.html

    The following files are provided to facilitate creation of your own 
    diff files of the XML.  

    Initial XMLv3 created using XMLv2 as input:
       https://www.rfc-editor.org/authors/rfc9303.original.v2v3.xml 

    XMLv3 file that is a best effort to capture v3-related format updates 
    only: 
       https://www.rfc-editor.org/authors/rfc9303.form.xml


    Tracking progress
    -----------------

    The details of the AUTH48 status of your document are here:
       https://www.rfc-editor.org/auth48/rfc9303

    Please let us know if you have any questions.  

    Thank you for your cooperation,

    RFC Editor

    --------------------------------------
    RFC9303 (draft-ietf-lisp-sec-29)

    Title            : LISP-Security (LISP-SEC)
    Author(s)        : F. Maino, V. Ermagan, A. Cabellos, D. Saucez
    WG Chair(s)      : Joel M. Halpern, Luigi Iannone
    Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston