On Wed, Mar 20, 2019 at 02:10:19PM -0700, Fabio Maino wrote:
> 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.
I also think this should be okay.
> 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.
Seems reasonable.
-Benjamin
>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
