Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-05 concern

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 16 Mar 2021 17:43:03 +0000

Nick

Many thanks for your feedback. 

> Von: Nick Lamb <[email-masked]>
>
> I noted with concern that the presenter suggests TLS 1.3's PSK modes are
> suitable for use with a password.
> 
> This is _explicitly_ not the case. To quote RFC 8446:
> 
> "Deriving a shared secret from a password or other low-entropy sources is not
> secure.  A low-entropy secret, or password, is subject to dictionary attacks
> based on the PSK binder.  The specified PSK authentication is not a strong
> password-based authenticated key exchange even when used with Diffie-
> Hellman key establishment."

I am aware that passwords with low entropy will only result in shared keys with low entropy.

> If CMP or LAMPS generally needs a way to use passwords to authenticate TLS
> it's worth reaching out to the TLS WG to ask them what you should do here, or
> contrariwise if this profile for CMP is to use PSKs it should likewise make explicit
> that you must not use passwords and similar human memorable low-entropy
> secrets.

Finally using shared secret information, e.g., OTPs or passwords is definitely not the main line for protection of CMP messages.
Also, TLS is not the only protection, but an additional layer for CMP, as CMP offers object level security.
When using shared secret information for protecting CMP message integrity we move from the old password-based MAC mechanism specified in RFC 4210 and RFC 4211 to PBMAC1 to improve the security here. Russ submitted the draft for updating RFC 4211 in this regard (draft-ietf-lamps-crmf-update-algs) and I did the same for RFC 4210  (draft-ietf-lamps-cmp-updates, draft-ietf-lamps-cmp-algorithms).

I struggled to provide some guidance on which cypher suites to use with shared secret information together with TLS in the Lightweight CMP Profile as presented during IETF 110.
One option is also to drop these recommendation, if there is no adequate cypher suite to be used with shared secret information and TLS 1.3, as TLS is not required for protecting CMP messages.

Any recommendations are welcome.

Hendrik

---

From: Nick Lamb <[email-masked]>
Date: Tue, 16 Mar 2021 16:19:32 +0000

Hi

I am not a LAMPS working group member, but I watched a video of the
presentation of this ID at IETF 110 on Youtube.

I noted with concern that the presenter suggests TLS 1.3's PSK modes
are suitable for use with a password.

"Deriving a shared secret from a password or other low-entropy
sources is not secure.  A low-entropy secret, or password, is subject
to dictionary attacks based on the PSK binder.  The specified PSK
authentication is not a strong password-based authenticated key
exchange even when used with Diffie-Hellman key establishment."

If CMP or LAMPS generally needs a way to use passwords to authenticate
TLS it's worth reaching out to the TLS WG to ask them what you should
do here, or contrariwise if this profile for CMP is to use PSKs it
should likewise make explicit that you must not use passwords and
similar human memorable low-entropy secrets.

Nick.

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 17 Mar 2021 15:42:40 +0000

Hi Nick,

That's what PAKEs are for, right? If I'm following the TLS WG properly, the TLS 1.3 PAKE draft (draft-barnes-tls-pake) expired in 2019 and PAKEs did not make it into 1.3. Is that right?

Looking at Hendrik's slides and I-D, I see proposals for specifying TLS 1.2 and 1.3 PSK cipher suites. I also see in the draft:

   *  The client MUST use its shared secret information for
      authentication.
   *  The server MUST use a suitable shared secret information for
      authentication.

Nowhere does it refer to this shared secret as a "password". I assume this shared secret will be some kind of registration code that a PKI operator distributes out-of-band to the end entity requesting the certificate? Seems a bit out of scope for a CMP RFC to put constraints on how that is generated.

So I suppose this email thread boils down to a request to add a "garbage-in, garbage-out" security consideration statement to the draft that a low entropy shared secret will result in a low entropy TLS session?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Nick Lamb
Sent: March 16, 2021 11:20 AM
To: [email-masked]; [email-masked]
Subject: [EXTERNAL] [lamps] draft-ietf-lamps-lightweight-cmp-profile-05 concern

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Hi

I am not a LAMPS working group member, but I watched a video of the presentation of this ID at IETF 110 on Youtube.

I noted with concern that the presenter suggests TLS 1.3's PSK modes are suitable for use with a password.

"Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder.  The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie-Hellman key establishment."

If CMP or LAMPS generally needs a way to use passwords to authenticate TLS it's worth reaching out to the TLS WG to ask them what you should do here, or contrariwise if this profile for CMP is to use PSKs it should likewise make explicit that you must not use passwords and similar human memorable low-entropy secrets.

Nick.

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!I5B4z3nBjk83j5emJqmOydz-dI4c_Lj4PXWDA4IItw2znDIALakjPklbFa0pKhZIf1rnybj-xQ$

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 17 Mar 2021 15:56:10 +0000

Actually, there is new work attempting to integrate Opaque (an augmented PAKE) into TLS - https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/

This was discussed in the TLS WG meeting; I believe they intend to integrate this into TLS at some point...

> From: Spasm <[email-masked]> On Behalf Of Mike Ounsworth
> Sent: Wednesday, March 17, 2021 11:43 AM
> To: Nick Lamb <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [lamps] [EXTERNAL] draft-ietf-lamps-lightweight-cmp-profile-05
> concern
> 
> Hi Nick,
> 
> That's what PAKEs are for, right? If I'm following the TLS WG properly, the TLS
> 1.3 PAKE draft (draft-barnes-tls-pake) expired in 2019 and PAKEs did not
> make it into 1.3. Is that right?
> 
> Looking at Hendrik's slides and I-D, I see proposals for specifying TLS 1.2 and
> 1.3 PSK cipher suites. I also see in the draft:
> 
> Nowhere does it refer to this shared secret as a "password". I assume this
> shared secret will be some kind of registration code that a PKI operator
> distributes out-of-band to the end entity requesting the certificate? Seems a
> bit out of scope for a CMP RFC to put constraints on how that is generated.
> 
> So I suppose this email thread boils down to a request to add a "garbage-in,
> garbage-out" security consideration statement to the draft that a low
> entropy shared secret will result in a low entropy TLS session?
> 
> ---
> Mike Ounsworth
> 
> "Deriving a shared secret from a password or other low-entropy sources is
> not secure.  A low-entropy secret, or password, is subject to dictionary
> attacks based on the PSK binder.  The specified PSK authentication is not a
> strong password-based authenticated key exchange even when used with
> Diffie-Hellman key establishment."
> 
> it's worth reaching out to the TLS WG to ask them what you should do here,
> or contrariwise if this profile for CMP is to use PSKs it should likewise make
> explicit that you must not use passwords and similar human memorable low-
> entropy secrets.
> 
> Nick.
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm
> __;!!FJ-Y8qCqXTj2!I5B4z3nBjk83j5emJqmOydz-
> dI4c_Lj4PXWDA4IItw2znDIALakjPklbFa0pKhZIf1rnybj-xQ$
> 
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Nick Lamb <[email-masked]>
Date: Wed, 17 Mar 2021 16:19:35 +0000

On Tue, 16 Mar 2021 17:43:03 +0000
"Brockhaus, Hendrik" <[email-masked]> wrote:

> I struggled to provide some guidance on which cypher suites to use
> with shared secret information together with TLS in the Lightweight
> CMP Profile as presented during IETF 110. One option is also to drop
> these recommendation, if there is no adequate cypher suite to be used
> with shared secret information and TLS 1.3, as TLS is not required
> for protecting CMP messages.

I can see several ways forward. One option would be as you say not to
suggest TLS for this purpose at all. One benefit here is that it
doesn't over-promise. TLS gives you confidentiality, but simple
password-based schemes aren't going to achieve that and so probably
shouldn't promise it.

It should I think be obvious that PBMAC1 does not protect against an
offline attack by an adversary guessing your password, but without
strong guidance it's unlikely to be obvious that using the password for
TLS PSK (which is an online protocol) also does not protect against such
offline attacks.

Another option would be to make clear that shared secrets for this
purpose MUST NOT be human memorable passwords.  Someone more familiar
with the deployed applications might have an insight into whether such
applications might actually use say 128-bit random secrets rather than
a short human memorable password or if this is never likely to be used
in the real world.

Another option would be something like draft-sullivan-tls-opaque which
provides an actual password based AKE for TLS 1.3 but this is quite
complicated and may not meet your needs for a "Lightweight" profile, it
is also of course a draft, and so depending on it would delay
completion of the profile.

Nick.

---

From: Nick Lamb <[email-masked]>
Date: Wed, 17 Mar 2021 16:53:26 +0000

On Wed, 17 Mar 2021 15:42:40 +0000
Mike Ounsworth <[email-masked]> wrote:

> Hi Nick,
> 
> That's what PAKEs are for, right? If I'm following the TLS WG
> properly, the TLS 1.3 PAKE draft (draft-barnes-tls-pake) expired in
> 2019 and PAKEs did not make it into 1.3. Is that right?

I have replied (and I see someone else also replied) mentioning the
work to integrate OPAQUE. This may be too complicated for a
"lightweight" profile or it might delay publication unacceptably but
others will know better.

> Looking at Hendrik's slides and I-D, I see proposals for specifying
> TLS 1.2 and 1.3 PSK cipher suites. I also see in the draft:
> 
> Nowhere does it refer to this shared secret as a "password".

When I examine these slides
https://datatracker.ietf.org/meeting/110/materials/slides-110-lamps-lightweight-cmp-profile-updates-cmp-and-cmp-algorithms-00

Or I review the video on which I was commenting:
https://youtu.be/DQQ4h_M1XYM?t=4453

I see that page 9 explicitly refers to passwords - writing
"We would like to specify suitable TLS cipher suite for use with
pre-shared secret information, e.g., passwords"

So it seems to me that in fact it does exactly what you've said it does
not.

It is a problem that so often a value envisioned as a 128-bit PSK -
which would be safe for many purposes ends up implemented in real
systems as a human readable password - which is much too fragile; and
then actually used as a boilerplate value (ie users don't know why it's
supposed to be a high entropy secret so they write the name of the
company or something) and as a result a cast iron security
guarantee in the design becomes so flimsy as to have no value in real
usage.

Nick.

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 17 Mar 2021 16:54:18 +0000

Hi Nick,

TL;DR Unless I'm misunderstanding the draft, I don't believe that TLS is serving a security-critical purpose here as the inner CMP messages are already crypted. If I'm reading the draft correctly, you can send bare CMP messages, or you can wrap them in HTTP, or you can wrap them in HTTPS with client auth which is redundant with the crypto in the underlying CMP message. So this thread is debating an optional part (TLS) of an optional part (HTTP) of this draft.

The context here is important. We are talking about a mechanism for an end entity to bootstrap their first certificate from a PKI using a shared secret they were given out-of-band. In Hendrik's draft, we're talking about the following sections:

4.1.4.  Requesting a certificate from a PKI with MAC protection
4.1.6.  Generateing the key pair centrally at the PKI management entity
4.1.6.3.  Using password-based key management technique

It's important to note that the CMP message itself is already cryptographically protected using this shared secret. CMP has worked this way for decades.

Now, in section 6, they are proposing a new set of optional HTTP endpoints. Since the CMP messages are already crypted, the draft allows this over plaintext HTTP. And unless I'm missing something, there's no TLS in the non-HTTP parts of this draft anyway. If I'm understanding the draft properly, if you're using HTTPS, then you might as well do TLS client auth with the cert-based or PSK-based client keys that you're already using to crypt the underlying CMP message.

TLS is a freebie if you happen to use the HTTP version of this protocol, but TLS is not security-critical here. IMO, removing the HTTPS and only offering the HTTP neither adds nor removes any security from this draft. So why not leave it?

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Nick Lamb
Sent: March 17, 2021 11:20 AM
To: Brockhaus, Hendrik <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-05 concern

______________________________________________________________________
On Tue, 16 Mar 2021 17:43:03 +0000
"Brockhaus, Hendrik" <[email-masked]> wrote:

> with shared secret information and TLS 1.3, as TLS is not required for 
> protecting CMP messages.

I can see several ways forward. One option would be as you say not to suggest TLS for this purpose at all. One benefit here is that it doesn't over-promise. TLS gives you confidentiality, but simple password-based schemes aren't going to achieve that and so probably shouldn't promise it.

It should I think be obvious that PBMAC1 does not protect against an offline attack by an adversary guessing your password, but without strong guidance it's unlikely to be obvious that using the password for TLS PSK (which is an online protocol) also does not protect against such offline attacks.

Another option would be to make clear that shared secrets for this purpose MUST NOT be human memorable passwords.  Someone more familiar with the deployed applications might have an insight into whether such applications might actually use say 128-bit random secrets rather than a short human memorable password or if this is never likely to be used in the real world.

Another option would be something like draft-sullivan-tls-opaque which provides an actual password based AKE for TLS 1.3 but this is quite complicated and may not meet your needs for a "Lightweight" profile, it is also of course a draft, and so depending on it would delay completion of the profile.

Nick.

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!PMS5xx0mkPb9vTOeWxYEoqY7liGb9xicnP_ZALAQnD1KM_g_JyupnHVcYhqe31wdPfJLJnN3MA$

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 17 Mar 2021 17:01:45 +0000

> I see that page 9 explicitly refers to passwords - writing "We would like to specify suitable TLS cipher suite for use with pre-shared secret information, e.g., passwords"

> So it seems to me that in fact it does exactly what you've said it does not.

OOO, yeah, fair point. I missed that. 

See my last email: This seems like a lot of fuss over an optional TLS wrapper of an optional HTTP wrapper of a message that's already crypted using this shared secret / password / whatever.

If you want to challenge how this shared secret is generated and argue that it's in-scope for the CMP spec to put constraints on that, then that would be a fair discussion to have. Note that the original CMP (RFC 4210) just assumes the existence of this shared secret:

    5.1.3.1.  Shared Secret Information

   In this case, the sender and recipient share secret information
   (established via out-of-band means or from a previous PKI management
   operation).

    5.2.2 Encrypted Values
    
    Typically,
   this will mean that the sender and recipient have, or are able to
   generate, a shared secret key.

    Etc

Like, if you're gonna object to this shared secret, then you should object to it throughout the CMP protocol; only objecting to it in the optional TLS wrapper seems a bit bizarre.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Nick Lamb
Sent: March 17, 2021 11:53 AM
To: Mike Ounsworth <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [lamps] [EXTERNAL] draft-ietf-lamps-lightweight-cmp-profile-05 concern

> 2019 and PAKEs did not make it into 1.3. Is that right?

I have replied (and I see someone else also replied) mentioning the work to integrate OPAQUE. This may be too complicated for a "lightweight" profile or it might delay publication unacceptably but others will know better.

When I examine these slides
https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/110/materials/slides-110-lamps-lightweight-cmp-profile-updates-cmp-and-cmp-algorithms-00__;!!FJ-Y8qCqXTj2!M0SWNuT7Bi0EOo4JbSCfPLAyoFmNCsXICueBA0V_-eoDHDc42seJKkO31CRdsfhQnJTuPzCV1g$ 

Or I review the video on which I was commenting:
https://urldefense.com/v3/__https://youtu.be/DQQ4h_M1XYM?t=4453__;!!FJ-Y8qCqXTj2!M0SWNuT7Bi0EOo4JbSCfPLAyoFmNCsXICueBA0V_-eoDHDc42seJKkO31CRdsfhQnJStX5zA1A$ 

I see that page 9 explicitly refers to passwords - writing "We would like to specify suitable TLS cipher suite for use with pre-shared secret information, e.g., passwords"

So it seems to me that in fact it does exactly what you've said it does not.

It is a problem that so often a value envisioned as a 128-bit PSK - which would be safe for many purposes ends up implemented in real systems as a human readable password - which is much too fragile; and then actually used as a boilerplate value (ie users don't know why it's supposed to be a high entropy secret so they write the name of the company or something) and as a result a cast iron security guarantee in the design becomes so flimsy as to have no value in real usage.

Nick.

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!M0SWNuT7Bi0EOo4JbSCfPLAyoFmNCsXICueBA0V_-eoDHDc42seJKkO31CRdsfhQnJQFmFXU6g$