Re: [lisp] Deriving Map-Register/Notify authentication key from PSK [Was: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT)]

[Benjamin Kaduk <[e-mail]>]

On Mon, Mar 18, 2019 at 03:01:07PM -0700, Fabio Maino wrote:
> Hi Ben,
> I'm starting this separated thread to discuss this point.

Thanks for splitting it off.

> 
> 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:

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?

> Map-Register Authentication Key = HKDF(Key ID + "Map-Register 
> Authentication" + PSK)   where "Map-Register Authentication" is a string 
> 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.

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

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.

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

That sounds reasonable.

> 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)

I think we can make it pretty general, yes.

-Benjamin

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