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