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

[dsaucez <[e-mail]>]

Hello,

Sorry for my late answer, my affiliation is

  Damien Saucez
   Inria
   2004 route des Lucioles - BP 93
   Sophia Antipolis
   France

Thank you

Damien Saucez 

> On 21 Sep 2022, at 23:32, Alanna Paloma <[e-mail]> wrote:
> 
> Greetings,
> 
> Thank you for your reply.  We have updated as requested, as well as per Dino’s response to the cluster-wide queries. 
> 
> Please note that we are awaiting word from Vina and Damien regarding how they would like their affiliation information to appear across the documents in C381. 
> 
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9303.xml
> https://www.rfc-editor.org/authors/rfc9303.txt
> https://www.rfc-editor.org/authors/rfc9303.html
> https://www.rfc-editor.org/authors/rfc9303.pdf
> 
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9303-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9303-auth48diff.html (AUTH48 changes)
> 
> Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.
> 
> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9303
> 
> Thank you,
> RFC Editor/ap
> 
>> On Sep 20, 2022, at 5:47 PM, Fabio Maino (fmaino) <fmaino=[e-mail]> wrote:
>> 
>> 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
>