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

[Mike Ounsworth <[e-mail]>]

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 <[e-mail]> On Behalf Of Nick Lamb
Sent: March 17, 2021 11:20 AM
To: Brockhaus, Hendrik <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: [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.

______________________________________________________________________
On Tue, 16 Mar 2021 17:43:03 +0000
"Brockhaus, Hendrik" <[e-mail]> 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.

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