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

[Dino Farinacci <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp