Subject: Re: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT))

From: Fabio Maino <[email-masked]>
Date: Wed, 6 Mar 2019 10:01:17 -0800

Hi Benjamin,
here is how we plan to update LISP-SEC to address this according to what 
anticipated in my previous email. Let me know if it fits what you were 
suggesting.

We add the ETR-Cant-Sign E-bit to the EID-AD:

   0 1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  ECM AD Type  |V|  Reserved   |        Requested HMAC ID |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
  |              OTK Length       |       OTK Encryption ID | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  |                       One-Time-Key Preamble ... | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD
  |                   ... One-Time-Key Preamble | |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  ~                      One-Time Key (128 bits) ~/
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
  |           EID-AD Length       |           KDF ID |     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
  | Record Count |E|  Reserved |         EID HMAC ID           |EID-AD
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
  |   Reserved    | EID mask-len  |           EID-AFI | |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
  ~                          EID-prefix ... ~ |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
  ~                            EID HMAC ~     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+

                      LISP-SEC ECM Authentication Data

  [...]

       E: ETR-Cant-Sign bit.  This bit is set to 1 to signal to the ITR
       that at least one of the ETRs authoritative for the EID prefixes
       of this Map-Reply has not enabled LISP-SEC.  This allows the ITR
       to securely downgrade to non LISP-SEC requests, as specified in
       Section 5.7, if so desired.

And then we update Map-Server processing accordingly in Section 5.7:

5.7.  Map-Server Processing

    Upon receiving an ECM encapsulated Map-Request with the S-bit set to
    1, the Map-Server process the Map-Request according to the value of
    the security-capable S-bit and of the proxy map-reply P-bit contained
    in the Map-Register sent by the ETRs authoritative for that prefix
    during registration.

    Processing of the Map-Request MUST proceed in the order described in
    the table below, applying the processing corresponding to the first
    rule that matches the conditions indicated in the first column:

+------------------+------------------------------------------------+
    | Matching         | Processing                                     |
    | Condition |                                                |
+------------------+------------------------------------------------+
    | 1. At least one  | The Map-Server MUST generate a LISP-SEC        |
    | of the ETRs      | protected Map-Reply as specified in Section    |
    | authoritative    | 5.7.2. The ETR-Cant-Sign E-bit in the EID      |
    | for the EID      | Authentication Data (EID-AD) MUST be set to 0. |
    | prefix included |                                                |
    | in the Map- |                                                |
    | Request |                                                |
    | registered with |                                                |
    | the P-bit set to |                                                |
    | 1 |                                                |
    | |                                                |
    | 2. At least one  | The Map-Server MUST generate a LISP-SEC        |
    | of the ETRs      | protected Encapsulated Map-Request (as         |
    | authoritative    | specified in Section 5.7.1), to be sent to one |
    | for the EID      | of the authoritative ETRs that registered with |
    | prefix included  | the S-bit set to 1 (and the P-bit set to 0).   |
    | in the Map-      | The ETR-Cant-Sign E-bit of the EID-AD MUST be  |
    | Request          | set to 1 to signal the ITR that a non LISP-SEC |
    | registered with  | Map-Request might reach additional ETRs that   |
    | the S-bit set to | have LISP-SEC disabled.                        |
    | 1 |                                                |
    | |                                                |
    | 3. All the ETRs  | The Map-Server MUST send a Negative Map-Reply  |
    | authoritative    | protected with LISP-SEC, as described in       |
    | for the EID      | Section 5.7.2. The ETR-Cant-Sign E-bit MUST be |
    | prefix included  | set to 1 to signal the ITR that a non LISP-SEC |
    | in the Map-      | Map-Request might reach additional ETRs that   |
    | Request          | have LISP-SEC disabled.                        |
    | registered with |                                                |
    | the S-bit set to |                                                |
    | 0 |                                                |
+------------------+------------------------------------------------+

    In this way the ITR that sent a LISP-SEC protected Map-Request always
    receives a LISP-SEC protected Map-Reply.  However, the ETR-Cant-Sign
    E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach
    additional ETRs that have LISP-SEC disabled.  This mechanism allows
    the ITR to securely downgrade to non LISP-SEC requests, if so
    desired.

5.7.1.  Generating a LISP-SEC Protected Encapsulated Map-Request

    The Map-Server decapsulates the ECM and generates a new ECM
    Authentication Data.  The Authentication Data includes the OTK-AD and
    the EID-AD, that contains EID-prefix authorization information, that
    are eventually received by the requesting ITR.

    The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from
    the ITR-OTK received with the Map-Request.  MS-OTK is derived
    applying the key derivation function specified in the KDF ID field.
    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.

    The Map-Server and the ETR MUST be configured with a pre-shared key
    for mapping registration according to [I-D.ietf-lisp-rfc6833bis].  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.

    The Map-Server includes in the EID-AD the longest match registered
    EID-prefix for the destination EID, and an HMAC of this EID-prefix.
    The HMAC is keyed with the ITR-OTK contained in the received ECM
    Authentication Data, and the HMAC algorithm is chosen according to
    the Requested HMAC ID field.  If The Map-Server does not support this
    algorithm, the Map-Server uses a different algorithm and specifies it
    in the EID HMAC ID field.  The scope of the HMAC operation covers the
    entire EID-AD, from the EID-AD Length field to the EID HMAC field,
    which must be set to 0 before the computation.

    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].

5.7.2.  Generating a Proxy Map-Reply

    LISP-SEC proxy Map-Reply are generated according to
    [I-D.ietf-lisp-rfc6833bis], with the Map-Replay S-bit set to 1.  The
    Map-Reply includes the Authentication Data that contains the EID-AD,
    computed as specified in Section 5.7.1, as well as the PKT-AD
    computed as specified in Section 5.8.

Thanks,
Fabio

On 2/28/19 3:46 PM, Fabio Maino wrote:
> Hi Benjamin,
> thanks for bringing this up.
>
> I think it makes  sense to have a mechanism for secure downgrade, and 
> it should indeed simplify adoption and transition to LISP-SEC.
>
> I discussed what you proposed here with the LISP-SEC authors and with 
> Dino and Alberto. We agree to the principles of what you are proposing.
>
> I'll send detailed text, but here is a brief description of what we 
> plan to do.
>
> The Map-Register has already the capability to encode ETR's support 
> for  LISP-SEC. We will change the behavior of the MS to signal to the 
> ITR when the ETR is not LISP-SEC capable.
>
> This will happen when
> - the ITR is sending a LISP-SEC Map-Request, AND
> - the corresponding ETR has not registered as LISP-SEC capable, AND
> - the ETR is in "non-proxy mode" (that is the mode in which the 
> Map-reply should be originated at the ETR. (MS/ITR behavior won't 
> change if the ETR is in "proxy mode")
>
> In this case the MS will send a Negative Map-Reply, protected by 
> LISP-SEC, that includes an ETR-Cant-Sign bit that informs the ITR that 
> the ETR doesn't support LISP-SEC. The integrity of the ECS bit is 
> protected by LISP-SEC, as the rest of the Map-Reply. This will work 
> without changes to the ETR.
>
> In this way the ITR has the option to choose to downgrade to non 
> LISP-SEC if it wants to favor reachability.
>
> Thanks,
> Fabio
>
>
>
> On 2/9/19 2:14 PM, Benjamin Kaduk wrote:
>> Splitting off a sub-thread for one fairly narrow point that AFAICT needs
>> further discussion to clarify the path forward:
>>
>> On Thu, Feb 07, 2019 at 05:50:39AM -0800, Benjamin Kaduk wrote:
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>> [...]
>>>     3.  LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented.  Network
>>>         operartors should carefully weight how the LISP-SEC threat 
>>> model
>>>         applies to their particular use case or deployment. If they
>>>         decide to ignore a particular recommendation, they should make
>>>         sure the risk associated with the corresponding threats is well
>>>         understood.
>>>
>>> I'm concerned enough about the risk of having a "ITR requests 
>>> lisp-sec but
>>> ETR didn't use it" case that causes complete breakage, that I want 
>>> to talk
>>> about this a bit more.  We currently in this document say that 
>>> lisp-sec is
>>> mandatory to implement (which presumably covers at least ITRs, ETRs,
>>> Map-Resolvers, and Map-Servers).  LISP-SEC itself says that "and ETR 
>>> that
>>> supports LISP-SEC MUST set the S bit in its Map-Register messages".  
>>> Is it
>>> possible that an ETR might "implement" but then not "support" 
>>> LISP-SEC?  If
>>> so, then we should consider the possibility that we need an 
>>> authenticated
>>> signal (from the mapping system to the ITR) that downgrading from 
>>> lisp-sec
>>> is allowed.  There seem to be several possibilities for how one might
>>> construct such a signal; two that came to mind to me would be (1) to 
>>> define a
>>> new ACT value for "repeat without lisp-sec" that could be returned as a
>>> negative Map-Response directly from the mapping system wherever the 
>>> mapping
>>> system is able to discern that the ETR in question does not support
>>> lisp-sec (I don't actually know if this could happen at Map-Resolver or
>>> would need to be delayed until the final Map-Server) and (2) to have an
>>> optional Map-Request field that the ETR is required to copy 
>>> unchanged to
>>> the Map-Reply; this could then include a message HMAC'd in the 
>>> ITR-OTK that
>>> indicates lisp-sec non-support and binds to the nonce in the request.
>>> Whether these are workable ideas seems to depend on aspects of the 
>>> mapping
>>> system to which I cannot speak.
>> In terms of some background assumptions I've been making (that of course
>> could be false, so I'm trying to make them explicit), I am assuming that
>> many or most current LISP deployments do not utilize LISP-SEC at 
>> runtime.
>> It's less clear to me how many deployments/implementations simply do not
>> have LISP-SEC capabilities at all, or how easy it is to get
>> software/firmware updates to the needed devices.  Regardless, if there
>> are existing RFC 6833 deployments that want to migrate to 6833bis 
>> when it
>> is finalized, we should consider what steps would be needed to safely
>> deploy LISP-SEC without disruption.  In particular, it seems a useful 
>> goal
>> to try to get the security benefit of LISP-SEC for those machines/sites
>> that have LISP-SEC capability without waiting for the entire 
>> administrative
>> domain's deployment to get updated software/firmware, which I assume 
>> is at
>> least a 5-year lead time in many sites.
>>
>> Given that at this point my analyses are mostly treating the mapping 
>> system
>> as something of a closed "magic box" that takes Map-Requests as input 
>> and
>> emits them to the appropriate ETRs (or internal proxy function), I'm 
>> forced
>> to conclude that any incremental update to using LISP-SEC will 
>> inherently
>> require the entire mapping system to upgrade first, before any concrete
>> usage of LISP-SEC should be expected.  Hopefully that's less of a burden
>> than upgrading entire deployments, since the mapping system is a more
>> contained set of devices and does not need to handle data-plane 
>> levels of
>> traffic.
>>
>> Once that's done, though, we still have the question of "which ETRs are
>> updated to be registering themselves as LISP-SEC-capable?".  For any 
>> given
>> ITR/ETR pair, if both are LISP-SEC capable, we want them to be using
>> LISP-SEC, while still allowing traffic if one or both are not LISP-SEC
>> capable.  If the ITR is not capable, this is easy, as the Map-Request 
>> will
>> never attempt to use LISP-SEC.  But if the ITR is capable and the ETR is
>> not, the ITR is going to either attempt to use LISP-SEC for all
>> Map-Requests or need some out-of-band knowledge of whether the target 
>> ETR
>> is capabable.  Now, the whole point of the mapping system is that the 
>> ITR
>> doesn't know what ETR it's going to talk to when it sends the 
>> Map-Request,
>> so this "out-of-band" setup seems pretty hard to fulfil.  My current 
>> best
>> thought (not expected to be perfect) in this scenario is that the ITR 
>> that
>> is LISP-SEC capable (and configured to use it, I suppose) will always 
>> try
>> to use LISP-SEC, but needs an authenticated signal from the mapping 
>> system
>> that the ETR it's being mapped to is not LISP-SEC-capable, and it should
>> try again without LISP-SEC.  This signal needs to be authenticated 
>> not just
>> for security reasons (though an insecure downgrade would render LISP-SEC
>> useless against an active attacker until the entire deployment disabled
>> non-LISP-SEC exchanges), but also for performance concerns.  As 
>> currently
>> specified, the Map-Server that gets a LISP-SEC Map-Request but is 
>> going to
>> forward it to an ETR that did not register as LISP-SEC capable is 
>> going to
>> repackage the Map-Request into a non-LISP-SEC Map-Request to send to the
>> ETR in question.  That ETR will produce a normal Map-Reply, that the ITR
>> will proceed to drop without processing, since it does not use LISP-SEC.
>> IIUC, that leaves the ITR in "wait to timeout" territory, which is a 
>> pretty
>> lousy situation to be in.
>>
>> I know there are only a couple values left for ACT values, but it seems
>> that this may be a big enough issue to justify allocating one for "retry
>> with downgrade", so that the final Map-Server can send a negative 
>> Map-Reply
>> that does use LISP-SEC, and the ITR can have this authenticated 
>> signal that
>> the destination ETR is not LISP-SEC capable at the moment. There are of
>> course other ways to generate an authenticated downgrade signal, but the
>> only other ones I've been able to come up with seem less architecturally
>> pleasing (and may not in fact work when the destination ETR is running
>> original RFC 6833 code).
>>
>> I'm interested in hearing what other people think about this scenario 
>> and
>> proposed remediation.
>>
>> -Benjamin
>>
>> _______________________________________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lisp
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Fabio Maino <[email-masked]>
Date: Mon, 18 Mar 2019 15:01:07 -0700

Hi Ben,
I'm starting this separated thread to discuss this point.

On 2/7/19 5:50 AM, Benjamin Kaduk wrote:
> This document includes a mechansism to use HMAC keyed by a pre-shared key
> to authenticate messages (Map-Register and Map-Notify*); it is directly
> using the long-term PSK as the HMAC key.  This is not really consistent
> with current IETF best practices (e.g,. BCP 107), which tend to not use the
> long-term key directly for keying messages, but rather to incorporate some
> form of key derivation step, to protect the long-term key from
> cryptanalysis and reduce the need to track long-term per-key data usage
> limits.  It is probably not feasible to directly require all LISP
> implementations to switch keying strategy, but it seems quite advisable to
> define new algorithm ID types that include a key derivation step before the
> HMAC, and to begin efforts to convert the ecosystem to the more sustainable
> cryptographic usage.  I would like to discuss what actions are reasonable
> to take at this time, on this front.

We plan to proceed as follows.

Currently the Map-Register/Map-Notify protocols messages are 
authenticated using a Pre-Shared Key (PSK) identified by the Key ID 
field in the Map-Register/Notify message (I'll refer to Map-Register 
only from now on, but everything applies to both protocols). The Key ID 
field allows rotation of the PSK.

The Algorithm ID identifies the algorithm used. Currently the values 
defined are : (0) None, (1) HMAC-SHA1-96, and (2) HMAC-SHA-256-128

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Key ID     | Algorithm ID  |  Authentication Data Length   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ~                     Authentication Data                       ~
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We plan to introduce a simple key hierarchy that starting from the PSK 
derives per "application" specific keys (applications being 
Map-Register/Map-Notify Authentication, LISP-SEC OTK key wrapping, ... 
). We will use the most significant bits of the Key ID as actual 
identifier of the PSK, and the least significant ones to rotate through 
application specific keys for a given PSK.

PSK [identified by Key ID-MSb]

     +--> Map-Register/Notification Key [identified by Key ID-LSb]

     +--> LISP-SEC OTK Wrapping Key [identified by Key ID-LSb]

     +--> ...

For example, if we use the 4 Most Significant bits in the Key ID to 
identify the PSK and the 4 Least Significant bits to rotate per 
application keys the ETR/MS will use an HKDF (RFC 5869) for 
per-application key derivation. Something like:

Map-Register Authentication Key = HKDF(Key ID + "Map-Register 
Authentication" + PSK)   where "Map-Register Authentication" is a string 
that identifies the Map-Register application.

As an example a Map-Register that has the Key ID field set to 0xd0 
refers to Map-Register Key 0x0 generated using PSK 0xd. If the ETR wants 
to rotate to a new Map-Register Authentication Key (without changing 
PSK) it will set the Key-ID field to 0xd1. A new PSK will be provisioned 
before all the 16 Map-register Authentication Keys associated with PSK 
0xd are used.

We will use the Algorithm ID to encode the particular KDF used. As an 
example the Algorithm ID defined for the Map-Register authentication 
protocol would be:

HMAC-SHA-256-128-HKDF-SHA1-128 that include HMAC-SHA-256-128 as 
Map-register authentication Algorithm, and HKDF-SHA1-128 as Key 
Derivation Algorithm.

This is compatible with the existing Algorithm IDs defined up to now 
(encoded with values 0,1 and 2) that will be deprecated.

This seems general enough that we can extend it to other security 
services used with the various LISP messages (e,g, to derive a wrapping 
key to transport the OTK in LISP-SEC)

Please let us know if you have comments or suggestions.

We will post the text to describe this in more details as soon as it's 
ready.

Thanks,

Fabio

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Mar 2019 10:05:45 -0500

> I'm starting this separated thread to discuss this point.

Thanks for splitting it off.

> defined are : (0) None, (1) HMAC-SHA1-96, and (2) HMAC-SHA-256-128

It's not clear to me that we need to use explicit identifier space to
indicate what type of key we derived -- shouldn't that be implicit from the
context in which we're processing a mesage?

> that identifies the Map-Register application.

It's good and important to include an identifier like this ("Map-Register
Authentication") to produce different keys for performing different types
of operations, but I think I may have been too brief when I introduced the
topic of key derivation.  The general risk is that if we have a single key that
gets used over and over for the same class of operation over a long period
of time, an attacker can collect lots of ciphertexts produced by the same
key, and do some forms of cryptanalysis that benefit from having more
ciphertexts.  Whether this reused key is the original PSK explicitly shared
between parties, or one deterministically derived from it for just
map-register authentication or map-notify protection doesn't make much
difference to the attacker -- there's still a lot of ciphertexts produced
using the same key.  (That key just happens to have been the output of a
KDF instead of directly shared).  The main goal of the KDF is to stop
presenting many ciphertexts over time produced with the same key, by
generating a fresh derived key for each exchange.  So, in addition to that
context label for what type of key it is, we want something fresh per
message, perhaps that binds the derived key to the specific message at
hand.  I haven't thought very hard about the details yet, but it seems
likely that we'd want to include the nonce as KDF input.  In some protocols
we end up putting almost the entire message being protected in as
additional input, but that's not always necessary or even helpful.

> before all the 16 Map-register Authentication Keys associated with PSK 

I'm not sure there's a need to be able to rotate these intermediate derived
keys separately from the main PSK (or, really, to have them at all, if
there ends up being per-message input to the final KDF).  I guess
technically it might end up letting you prolong the extent of "safe" PSK
usage for the original PSK (along the lines of draft-irtf-cfrg-re-keying
but not exactly the same); it's just not clear to me that we'd end up
anywhere close to the computed limit, here.

> Map-register authentication Algorithm, and HKDF-SHA1-128 as Key 

That sounds reasonable.

> key to transport the OTK in LISP-SEC)

I think we can make it pretty general, yes.

-Benjamin

---

From: Fabio Maino <[email-masked]>
Date: Wed, 20 Mar 2019 14:10:19 -0700

> additional input, but that's not always necessary or even helpful.

This sounds reasonable.

We could use the 64-bit nonce contained in the map-register/notify so we 
have a fresh key every time.  This would require a KDF operation for 
each Map-Register/Notify, but I think that will be ok.

Only caveat is that the nonce in the map-request now is a sequence 
number, because we use it for anti-replay protection. Do you think 
having a monotonically increasing nonce will change the security 
properties you wanted to achieve? The generated key will still be 
different per each map-register, so it should be ok.

The other application we will need to secure, OTK wrapping in LISPsec, 
could use a similar approach using the 64-bit nonce included in the 
map-register (that is an actual random nonce).

> anywhere close to the computed limit, here.

Agree, especially if we use the nonce as you suggest.

Consider also that we typically send a Map-register per minute, so we 
are not generating TBs of ciphertext... Similar considerations would 
apply to OTK wrapping for Map-Request/Reply in LISPsec.

We would be back to having 256 PSKs, each with a relatively long 
lifetime, that makes the operation of PSK rotation manageable. The most 
cryptographic intense application will determine the frequency of PSK 
rotation, that is a decision that can be taken autonomously by each 
individual xTR.

Thanks,

Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Mar 2019 15:27:26 -0700

Ben regarding using PSKs for Map-Registers. How about we do this:

(1) The ETR and map-server can be provisioned with up to 256 keys.
(2) Each Map-Register uses one of the 256 keys buy doing a random number modulo 256.
(3) Each consecutive Map-Register will use a different key.
(4) The Map-Server would do the same for Map-Notify messages.

A key could only be used once very 4 hours.

And then a new 256 set of keys can be re-configured via a provisioning system.

How does that sound?

Dino

> On Mar 20, 2019, at 8:05 AM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Mar 2019 08:06:43 -0500

> different per each map-register, so it should be ok.

I also think this should be okay.

> rotation, that is a decision that can be taken autonomously by each 

Seems reasonable.

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Mar 2019 08:08:34 -0500

> And then a new 256 set of keys can be re-configured via a provisioning system.

I'm not sure I understand the need for "use a different key for consecutive
messages", but probably we should just talk about that on Tuesday.

-Benjamin

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 23 Mar 2019 11:06:33 -0700

> messages", but probably we should just talk about that on Tuesday.

Well in your last reply you felt it was okay if we used the nonce in each Map-Register for a new key per message. 

What this addition brings is use of a different PSK with nonce for a new authentication key, per message. 

If you think it’s not necessary, we can leave it out. 

But it is not clear to me if you support app-key per Fabio’s suggestion. Can you clarify that a nonce and PSK by themselves is sufficient?

Dino

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Mar 2019 17:22:49 -0500

> But it is not clear to me if you support app-key per Fabio’s suggestion. Can you clarify that a nonce and PSK by themselves is sufficient?

My sense is that it's fine to have a single configured PSK (per pair of
communicating entities, of course), provided that both a per-message nonce
and a context string identifying the type of message that the derived key
is used for are included as input to the key derivation.

For HKDF specifically, we might consider that HKDF-Extract takes a public
'salt' (a "non-secret random value") and HKDF-Expand takes an optional
'info', but also that Section 3.4 mandates that the salt must not be chosen
or manipulated by an attacker.  Since I don't think the current LISP
mechanisms can provide such a guarantee for any of the nonces (until after
we use the derived key), it seems that both the nonce and message-type
context would need to be introduced in 'info', with some length-prefix or
zero separator to enforce separation between those components of the 'info'
parameter.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Mar 2019 17:23:43 -0500

> 'info', but also that Section 3.4 mandates that the salt must not be chosen

Sorry, that's Section 3.4 *of RFC 5869*, which didn't make it from my brain
to the keyboard.