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

[Benjamin Kaduk <[e-mail]>]

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.