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 <ka...@mit.edu> 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
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
