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

[Fabio Maino <[e-mail]>]

On 3/20/19 8:05 AM, Benjamin Kaduk 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.

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


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


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


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