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

[Vina Ermagan <[e-mail]>]

Hello,

Thank you for the updated affiliation.  I approve this RFC for publication.

Thank you,
Vina

On Fri, Sep 23, 2022 at 2:50 PM Alanna Paloma <[e-mail]> wrote:

> Hi Authors,
>
> Thank you for your replies. We have updated your affiliation information
> in the files accordingly.
>
> We will await approvals from all authors prior to moving this document
> forward in the publication process.
>
> 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)
>
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9303
>
> Thank you,
> RFC Editor/ap
>
> > On Sep 21, 2022, at 10:47 PM, dsaucez <[e-mail]> wrote:
> >
> > 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
> >>
> >
>
>