Re: [lisp] comments on draft-ietf-lisp-sec-17

Thanks Ben,
we will indeed be looking at these comments with the perspective of the 
RFCbis in mind.

Fabio

On 2/19/19 8:07 AM, Benjamin Kaduk wrote:
> Hi folks,
>
> Since this document is still sort-of in WGLC, I'm sending my notes on it.
> They were originally written as notes to myself during my review of
> 6833bis, so my apologies for the parts that are inscrutable.  I can try to
> clarify as needed.
>
> -Ben
>
>
> Section 3
>
>     authoritative.  In this way the ETR can maliciously redirect traffic
>     directed to a large number of hosts.
>
> needs clarification
>
> Section 4
>
>     LISP-SEC builds on top of the security mechanisms defined in
>     [I-D.ietf-lisp-rfc6833bis] to address the threats described in
>     Section 3 by leveraging the trust relationships existing among the
>     LISP entities participating to the exchange of the Map-Request/Map-
>     Reply messages.  [...]
>
> I think this may be better as "participating in" (or maybe "party to").
>
>     o  The ITR, upon needing to transmit a Map-Request message, generates
>        and stores an OTK (ITR-OTK).  This ITR-OTK is included into the
>        Encapsulated Control Message (ECM) that contains the Map-Request
>        sent to the Map-Resolver.  To provide confidentiality to the ITR-
>        OTK over the path between the ITR and its Map-Resolver, the ITR-
>        OTK SHOULD be encrypted using a preconfigured key shared between
>        the ITR and the Map-Resolver, similar to the key shared between
>        the ETR and the Map-Server in order to secure ETR registration
>        [I-D.ietf-lisp-rfc6833bis].
>
> I think this is "MUST be protected; SHOULD encrypt using the preconfigured
> key".
>
>     o  The Map-Server derives a new OTK, the MS-OTK, by applying a Key
>        Derivation Function (KDF) to the ITR-OTK.  This MS-OTK is included
>        in the Encapsulated Control Message that the Map-Server uses to
>        forward the Map-Request to the ETR.  To provide MS-OTK
>        confidentiality over the path between the Map-Server and the ETR,
>        the MS-OTK SHOULD be encrypted using the key shared between the
>        ETR and the Map-Server in order to secure ETR registration
>        [I-D.ietf-lisp-rfc6833bis].
>
> and likewise this would be "MUST be protected; SHOULD encrypt using the key
> used for registration".
>
>     o  If the Map-Server is acting in proxy mode, as specified in
>        [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the
>        generation of the Map-Reply.  In this case the Map-Server
>        generates the Map-Reply on behalf of the ETR as described below.
>
> nit: is what's "described below" the normal ETR procedure (as opposed to
> the "on behalf of" behavior)?  Perhaps "using the same procedure the ETR
> would use, as described below".
>
>     o  The ETR, upon receiving the ECM encapsulated Map-Request from the
>        Map-Server, decrypts the MS-OTK, if needed, and originates a
>        standard Map-Reply that contains the EID-to-RLOC mapping
>        information as specified in [I-D.ietf-lisp-rfc6833bis].
>
> nit: is this really "originates" (vs. "constructs") if we're going to add
> the HMAC AD before sending, per the next step?
>
>     o  The ITR, upon receiving the Map-Reply, uses the locally stored
>        ITR-OTK to verify the integrity of the EID-prefix authorization
>        data included in the Map-Reply by the Map-Server.  The ITR
>        computes the MS-OTK by applying the same KDF used by the Map-
>        Server, and verifies the integrity of the Map-Reply.  If the
>        integrity checks fail, the Map-Reply MUST be discarded.  [...]
>
> A typical crypto workflow would be to verify the outer message first before
> inspecting the inner contents.  Because this flow is using OTKs, I don't
> see an actual attack (and perhaps the EID-prefix authorization is still
> useful), but it's unclear that there's any reason to deviate from the
> normal practice (which would put the MS-OTK computation and Map-Reply
> verification first, then the EID-prefix authorization data integrity
> verification).
>
> Section 5.1
>
>        OTK Length: The length (in bytes) of the OTK Authentication Data
>        (OTK-AD), that contains the OTK Preamble and the OTK.
>
> nit: it also contains the "OTK length" and "OTK encryption ID" fields, if
> the figure is to be believed about the definition of "OTK-AD".
>
>        EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server.
>        Before computing the HMAC operation the EID HMAC field MUST be set
>        to 0.  The HMAC covers the entire EID-AD.
>
> nit: could note that the length of the HMAC depends on the algorithms used.
>
> Section 5.2
>
> There's a bit of churn between the EID-AD field descriptions in Section 5.1
> and the ones here.  The Section 5.1 text does have to cover the
> ITR-to-Map-Server version that is somewhat abbreviated, so it's unclear if
> the best choice is to do a full consolidation and have Section 5.2 just say
> "The EID-AD fields are copied unchanged from the Map-Request received at
> the ETR".  Perhaps there's a middle ground of "the X, Y, and Z fields have
> the same content and interpretation as in Section 5.1; the A, B, and C
> fields are similar to those in Section 5.1 but correspond to Map-Reply
> instead of Map-Request messages.  More detail on Map-Reply (as opposed to
> Map-Request) is in Section 5.7."
>
>        PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP-
>        SEC Authentication Data.  The scope of the authentication goes
>        from the Map-Reply Type field to the PKT HMAC field included. [...]
>
> I could see clarifying that this is the top-level "Type=2, Map-Reply" as
> opposed to the "MR AD Type" field in the figure in this section.
>
> Section 5.4
>
>     The Map-Request MUST be encapsulated in an ECM, with the S-bit set to
>     1, to indicate the presence of Authentication Data.  If the ITR and
>     the Map-Resolver are configured with a shared key, the ITR-OTK
>     confidentiality SHOULD be protected by wrapping the ITR-OTK with the
>
> This seems to duplicate the normative requirement from Section 4.
>
>     algorithm specified by the OTK Encryption ID field.  See Section 5.5
>     for further details on OTK encryption.
>
> nit: this text implies that you could specify an algorithm in the OTK
> Encryption ID field and then not use it for key wrapping.  Maybe "by
> wrapping the ITR-OTK; the algorithm used for wrapping is specified in the
> OTK Encryption ID field".
> not-nit: we need some text about how the Map-Resolver knows what KEK was
> used for key wrapping.  Presumably we assume it is the configured shared
> key unless otherwise specified by manual configuration, but this needs to
> be explicitly stated.
>
>     The Requested HMAC ID field contains the suggested HMAC algorithm to
>     be used by the Map-Server and the ETR to protect the integrity of the
>     ECM Authentication data and of the Map-Reply.
>
> To be clear: the Map-Server and ETR can use different HMAC algorithms if
> local configuration requires it, right?  The (lack of) negotiation story
> and downgrade protection for this algorithm selection is not very good, but
> I guess most of the protection here relies on keeping the OTKs secret via
> the mapping system and it would be hard for an attacker to spoof an HMAC
> without the OTK.
>
>     The KDF ID field specifies the suggested key derivation function to
>     be used by the Map-Server to derive the MS-OTK.  A KDF Value of NONE
>     (0), MAY be used to specify that the ITR has no preferred KDF ID.
>
> This also doesn't have much of a negotiation story; attempts at protocol
> agility (viz. BCP 201) will probably involve some amount of connection
> failures.
>
>     In response to an encapsulated Map-Request that has the S-bit set, an
>     ITR MUST receive a Map-Reply with the S-bit set, that includes an
>     EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
>     ITR MUST discard it.  [...]
>
> This seems to be necessary behavior for security, but also seems to be a
> deployability nightmare -- all Map-Servers and ETRs must get software
> upgrades to support LISP-SEC before any ITR can safely start setting the S
> bit, if I understand correctly.  (And of course the presence of xTRs makes
> the needed configuration a bit more exciting.)
>
>     Upon receiving a Map-Reply, the ITR must verify the integrity of both
>     the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of
>     the integrity checks fails.  After processing the Map-Reply, the ITR
>     must discard the <nonce,ITK-OTK> pair associated to the Map-Reply
>
> nit: "one or both of the integrity checks".
> not-nit: it's not entirely clear whether discarding <nonce,ITK-OTK> after
> *any* reply is appropriate, or only one which has at least one HMAC
> validate.  That is, discard-after-any-reply opens up a DoS attack where an
> attacker can cause the ITR to fail to accept valid responses, if the
> attacker is faster than the valid response.
>
>     The integrity of the EID-AD is verified using the locally stored ITR-
>     OTK to re-compute the HMAC of the EID-AD using the algorithm
>     specified in the EID HMAC ID field.  If the EID HMAC ID field does
>     not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply
>     and send, at the first opportunity it needs to, a new Map-Request
>     with a different Requested HMAC ID field, according to ITR's local
>     policy.  [...]
>
> I'm a bit confused by this procedure for HMAC ID mismatch.  If the ITR
> supports the returned algorithm and the returned algorithm is secure, there
> should be no problem with validating the HMAC and using the data (if it
> validates).  So "SHOULD discard" doesn't seem to make sense in that case.
> I can sort-of see some desire to start a new mapping transaction that will
> result in the requested HMAC ID being used, but this guidance ("according
> to local policy", "different Requested HMAC ID field" does not seem to be
> sufficient to get a high likelihood of HMAC ID agreement.
>
> I also note that BCP 201 says that the algorithm negotiation/selection
> SHOULD be integrity protected; I don't think that the current procedure
> meets that threshold.
>
>                        If the KDF ID in the Map-Reply does not match the
>     KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
>     Reply and send, at the first opportunity it needs to, a new Map-
>     Request with a different KDF ID, according to ITR's local policy.
>
> (ditto)
>
>     The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD
>     using the Algorithm specified in the PKT HMAC ID field.  If the PKT
>     HMAC ID field does not match the Requested HMAC ID the ITR SHOULD
>     discard the Map-Reply and send, at the first opportunity it needs to,
>     a new Map-Request with a different Requested HMAC ID according to
>     ITR's local policy or until all HMAC IDs supported by the ITR have
>     been attempted.
>
> (and here)
>
>     Each individual Map-Reply EID-record is considered valid only if: (1)
>     both EID-AD and PKT-AD are valid, and (2) the intersection of the
>     EID-prefix in the Map-Reply EID-record with one of the EID-prefixes
>     contained in the EID-AD is not empty.  [...]
>
> nit: from a terminology sense, the "intersection" is inferred to be set
> intersection, which acts on a pair of sets.  "One of" the EID-prefixes is
> perhaps not the intended set.
> Do I understand correctly that we require an exact match of prefix-length
> and value, or is it okay to have more of a subset relation?
>
>     The ITR SHOULD send SMR triggered Map-Requests over the mapping
>
> We don't seem to expand Solicit-Map-Request in this document, and only use
> it once, so maybe we could just expand it out here and not rely on the
> reader also having 6833bis up, ...
>
>     system in order to receive a secure Map-Reply.  If an ITR accepts
>     piggybacked Map-Replies, it SHOULD also send a Map-Request over the
>     mapping system in order to verify the piggybacked Map-Reply with a
>     secure Map-Reply.
>
> though it's actually not entirely clear to me why this guidance needs to be
> in LISP-SEC (and, actually, is not already covered by 6833bis as-is).
>
> Section 5.4.1
>
> We talk a bit more about the "intersection" and "empty set" here; similar
> comments as above apply.
>
> Section 5.4.2
>
>     System such as LISP+ALT [RFC6836], the PITR performs the functions of
>     both the ITR and the Map-Resolver forwarding the Map-Request
>     encapsulated in an ECM header that includes the Authentication Data
>     fields as described in Section 5.6.
>
> editorial: could you mention that it is forwarded to the Map-Server, for
> clarity?
>
> Section 5.5
>
> For both the ITR/Map-Resolver and Map-Server/ETR exchanges, if it is no
> mandatory to use the preconfigured shared key, we need some text about how
> to know what other key might be used.
>
>     MS-OTK confidentiality is required in the path between the Map-Server
>     and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured
>     key shared between the Map-Server and the ETR for the purpose of
>     securing ETR registration [I-D.ietf-lisp-rfc6833bis].  Similarly, if
>
> This duplicates noramtive requirements from Section 4.  (Also, it's a comma
> splice.)
>
>     ITR-OTK confidentiality is required in the path between the ITR and
>     the Map-Resolver, the ITR-OTK SHOULD be encrypted with a key shared
>     between the ITR and the Map-Resolver.
>
> This one's not a comma splice, but still duplicates Section 4.
>
> Section 5.5
>
>     The OTK is encrypted using the algorithm specified in the OTK
>     Encryption ID field.  When the AES Key Wrap algorithm is used to
>     encrypt a 128-bit OTK, according to [RFC3394], the AES Key Wrap
>     Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits).
>     The output of the AES Key Wrap operation is 192-bit long.  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.
>
> Limiting to 128-bit keys is a bit risky given the threat of quantum
> computers and Grover's algorithm; systems that are targetting post-quantum
> security with symmetric crypto are ensuring that they can use 256-bit
> symmetric keys to retain the desired safety margin.
> Note also that BCP 201 tells us to expect the MTI key size to increase over
> time.
>
> Also, it is generally a more useful mindset to think of the key wrapping
> (or any crypto algorithm, really) as an operation from byte array to byte
> array, with the input and output sizes not necessarily being the same.  So
> here we would just have a 192-bit wrapped key and not try to assign any
> internal structure.  The rhetorical gymnastics to retain the current
> encoding and possibility of unencrypted keys would then be to define a
> "null wrapping" algorithm that just prepends 64 bits of zeroes to the key
> being wrapped.
>
>     When decrypting an encrypted OTK the receiver MUST verify that the
>     Initialization Value resulting from the AES Key Wrap decryption
>     operation is equal to 0xA6A6A6A6A6A6A6A6.  [...]
>
> nit: we could mention that this is the default IV (from RFC 3394 section
> 2.2.3.1), since we only need an integrity check for the duration that the
> key is wrapped.
>
> Section 5.6
>
>     Protecting the confidentiality of the ITR-OTK and, in general, the
>     security of how the Map-Request is handed by the Map-Resolver to the
>     Map-Server, is specific to the particular Mapping System used, and
>     outside of the scope of this memo.
>
> It may be appropriate to reiterate the need for confidentiality protection
> of the ITR-OTK, here.
>
>     In Mapping Systems where the Map-Server is compliant with
>     [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM
>     header with the S-bit set, that contains the unencrypted ITR-OTK, as
>     specified in Section 5.5, and the other data derived from the ECM
>     Authentication Data of the received encapsulated Map-Request.
>
> I don't really understand what this is trying to say.  Why is 6833bis
> compliance important?  Do we need to phrase it as "with the S bit set"
> instead of (or in addition to?) "the security mechanism specified in this
> document?"  The part about copying the contents into the new encapuslated
> Map-Request does seem straightforward, though.
>
>     The Map-Resolver then forwards to the Map-Server the received Map-
>     Request, encapsulated in the new ECM header that includes the newly
>     computed Authentication Data fields.
>
> I would suggest not using the term "forwards" when the authentication data
> has been recomputed.
>
> Section 5.7
>
>     If the S-bit contained in the Map-Register was clear the Map-Server
>     decapsulates the ECM and generates a new ECM encapsulated Map-Request
>     that does not contain an ECM Authentication Data, as specified in
>     [I-D.ietf-lisp-rfc6833bis].  The Map-Server does not perform any
>     further LISP-SEC processing, and the Map-Reply will not be protected.
>
> This doesn't make sense -- such an unprotected Map-Reply will be rejected
> by the ITR, per Section 5.4.
>
>     If the algorithm specified in the KDF ID field is not supported, the
>     Map-Server uses a different algorithm to derive the key and updates
>     the KDF ID field accordingly.
>
> Do we need to give any guidance on how this "different algorithm" is
> selected?
>
>                                                                    If MS-
>     OTK confidentiality is required, then the MS-OTK SHOULD be encrypted,
>     by wrapping the MS-OTK with the algorithm specified by the OTK
>     Encryption ID field as specified in Section 5.5.
>
> Similarly to my previous comments, I'd expect this language to be more of a
> "the MS-OTK MUST have confidentiality protection for transit, which SHOULD
> be provided by encryption using the shared key from mapping registration".
> Also, the way to know what KEK should be used to unwrap the key needs to be
> talked about.  It's fine to assume the share key for mapping registration
> unless otherwise indicated by configuration, but if we do not mandate the
> use of that key, we need to say how an other key would be used.
>
>     The Map-Server then forwards the updated ECM encapsulated Map-
>     Request, that contains the OTK-AD, the EID-AD, and the received Map-
>     Request to an authoritative ETR as specified in
>     [I-D.ietf-lisp-rfc6833bis].
>
> As above, I would suggest a different word than "forwards" here.
>
> Section 5.8
>
>     If the ETR does not support the Requested HMAC ID, it uses a
>     different algorithm and updates the PKT HMAC ID field accordingly.
>
> (as above) "how does it pick the different algorithm?"
>
> Section 6.1
>
> We also assume that the mapping system globally supports lisp-sec; there is
> no provision for incremnetal deployment as specified.
>
> Section 6.4
>
> With a title like "Deploying LISP-SEC" I expected something like
> "deployment considerations", i.e., guidance on what steps to do in what
> order.  Does this feel more like an applicability statement to you?
>
>     As an example, in certain closed and controlled deployments, it is
>     possible that the threat associated with a MiTM between the xTR and
>     the Mapping System is very low, and after carfeul consideration it
>     may be decided to allow a NULL key wrapping algorithm while carrying
>     the OTKs between the xTR and the Mapping System.
>
> I would be more comfortable if this included phrasing similar to "the
> physical and network security of the closed environment is deemed to be
> sufficient to provide confidentiality protection to the OTKs".
>
> Section 6.6
>
>                                                                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.
>
> I think it is more relevant to just say that there is no matching nonce;
> the ITR-OTK is not used in the lookup process.
>
>     In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR
>     will have to do a LISP-SEC computation.  This is equivalent to a
>     valid LISP-SEC computation and an attacker does not obtain any
>     benefit.
>
> Perhaps, "does not obtain any benefit from the replay as compared to
> generating a new Map-Request".
>
> Section 6.8
>
> We say that we protect from attacks, but from a rhetoric point of view, we
> should probably say what those attacks would be targetting, i.e., what
> systems/protocol exchanges we are protecting.
>
> Section 7.1, 7.2
>
> It's surprising to see the registry creation in this document, given that
> 6833bis defines the fields that carry the AD type values.  (That is, I'd
> expect 6833bis to create the registries as empty registries and this
> document to just make registrations.)
>
> Section 7.3
>
> I don't really think that SHA1-96 is considered to provide an adequate
> level of security anymore, so I'd suggest making SHA256-128 the MUST and
> demoting SHA1-96 to a "SHOULD (for legacy compatibility)".
>
> BTW, BCP 201 suggests to break the MTI algorithm list into a separate
> document to make it easier to update without revving the base spec.
>
> Also, these HMAC algorithm IDs seem to be exactly duplicating the "LISP
> Algorithm ID Numbers" from rfc6833bis; do they somehow offer different
> functionality such that a common registry could not be used?
>
> Section 7.4
>
> The currently defined AD type formats only admit 196 bits of (wrapped) key
> material; it seems prudent to mention that values allocated here need to
> produce wrapped keys that fit within that space, or that they will need to
> define corresponding new AD types to hold the wrapped keys.
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp