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)]
On Wed, Mar 20, 2019 at 03:27:26PM -0700, Dino Farinacci wrote: > 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? I'm not sure I understand the need for "use a different key for consecutive messages", but probably we should just talk about that on Tuesday. -Benjamin ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
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)]
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
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)]
> I'm not sure I understand the need for "use a different key for consecutive > messages", but probably we should just talk about that on Tuesday. Well in your last reply you felt it was okay if we used the nonce in each Map-Register for a new key per message. What this addition brings is use of a different PSK with nonce for a new authentication key, per message. If you think it’s not necessary, we can leave it out. But it is not clear to me if you support app-key per Fabio’s suggestion. Can you clarify that a nonce and PSK by themselves is sufficient? Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
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)]
On Sat, Mar 23, 2019 at 11:06:33AM -0700, Dino Farinacci wrote: > > I'm not sure I understand the need for "use a different key for consecutive > > messages", but probably we should just talk about that on Tuesday. > > Well in your last reply you felt it was okay if we used the nonce in each > Map-Register for a new key per message. > > What this addition brings is use of a different PSK with nonce for a new > authentication key, per message. > > If you think it’s not necessary, we can leave it out. > > But it is not clear to me if you support app-key per Fabio’s suggestion. Can > you clarify that a nonce and PSK by themselves is sufficient? My sense is that it's fine to have a single configured PSK (per pair of communicating entities, of course), provided that both a per-message nonce and a context string identifying the type of message that the derived key is used for are included as input to the key derivation. For HKDF specifically, we might consider that HKDF-Extract takes a public 'salt' (a "non-secret random value") and HKDF-Expand takes an optional 'info', but also that Section 3.4 mandates that the salt must not be chosen or manipulated by an attacker. Since I don't think the current LISP mechanisms can provide such a guarantee for any of the nonces (until after we use the derived key), it seems that both the nonce and message-type context would need to be introduced in 'info', with some length-prefix or zero separator to enforce separation between those components of the 'info' parameter. -Ben ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
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)]
On Sat, Mar 23, 2019 at 05:22:49PM -0500, Benjamin Kaduk wrote: > On Sat, Mar 23, 2019 at 11:06:33AM -0700, Dino Farinacci wrote: > > > I'm not sure I understand the need for "use a different key for > > > consecutive > > > messages", but probably we should just talk about that on Tuesday. > > > > Well in your last reply you felt it was okay if we used the nonce in each > > Map-Register for a new key per message. > > > > What this addition brings is use of a different PSK with nonce for a new > > authentication key, per message. > > > > If you think it’s not necessary, we can leave it out. > > > > But it is not clear to me if you support app-key per Fabio’s suggestion. > > Can you clarify that a nonce and PSK by themselves is sufficient? > > My sense is that it's fine to have a single configured PSK (per pair of > communicating entities, of course), provided that both a per-message nonce > and a context string identifying the type of message that the derived key > is used for are included as input to the key derivation. > > For HKDF specifically, we might consider that HKDF-Extract takes a public > 'salt' (a "non-secret random value") and HKDF-Expand takes an optional > 'info', but also that Section 3.4 mandates that the salt must not be chosen Sorry, that's Section 3.4 *of RFC 5869*, which didn't make it from my brain to the keyboard. > or manipulated by an attacker. Since I don't think the current LISP > mechanisms can provide such a guarantee for any of the nonces (until after > we use the derived key), it seems that both the nonce and message-type > context would need to be introduced in 'info', with some length-prefix or > zero separator to enforce separation between those components of the 'info' > parameter. > > -Ben ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
