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

[Benjamin Kaduk <[e-mail]>]

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