Hi Ben,
I'm starting this separated thread to discuss this point.
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:
Map-Register Authentication Key = HKDF(Key ID + "Map-Register
Authentication" + PSK) where "Map-Register Authentication" is a string
that identifies the Map-Register application.
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.
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.
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)
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.
Thanks,
Fabio
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
