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