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