Subject: Re: [lamps] draft-ietf-lamps-lightweight-cmp-profile-01, section 5.1.6.1

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 2 Apr 2020 10:48:40 +0000

Russ

Thank you for your feedback.
Together with Jim's question why I do not use PasswordRecipientInfo type I took some time to have a closer look at it.

In EnvelopedData there are only ktri, kari, and kekri mandatory and pwri is only optional. May be this is a reason why I did not look deeper into pwri. From its specification in RFC5652 pwri looks fairly what I tried to specify using PBMParameters. I was a bit confused that RFC5652 refers to RFC3211 for further specification of  PasswordRecipientInfo Type even thou RFC3211 is obsoleted by RFC3370. Should I use the PasswordRecipientInfo Type from RFC3211 and the keyDerivationAlgorithm PDKDF2 from RDC3370 then?

Below I updated my approach using KEKRecipientInfo  using an adapted AlgorithmID like I understood Russ's feedback.

@Jim, Russ, what would you recommend? Should I follow KEKRecipientInfo or swich to using PasswordRecipientInfo?

> Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
> Gesendet: Dienstag, 31. März 2020 20:04
> 
> I find this difficult.  Using id-PasswordBasedMac as a keyEncryptionAlgorithm
> algorithm identifier is a problem.  The OID tells the implementation how to
> parse the parameter structure, but it also tells the implementation what
> processing steps are needed.  It works for the structure, but I think it will be a
> big problem for the processing steps.  This is made worse by: "This key
> management technique can be applied in combination with the PKI
> management operation specified in Section 5.1.4 using MAC protected CMP
> messages."  This means that id-PasswordBasedMac would be used to indicate
> two different sets of processing steps in the same message.

If I understand this correctly, I can continue to use the concepts and general structure of PBMParameters.

This approach could look like this:
I would define a new OID/syntax containing the fields salt, owf, iterationCount, and keAkgorithm. It could be named KEParameters (KeyEncryptionParameters) to indicate that theses are the values to be used to derive and encrypt the contentEncryption for EnvelopedData. keAlgorithm shall be the AlgID for the key encryption algorithm.
To specify the processing I would copy the content of RFC4210 section 5.1.3.1 with a slightly adapted wording together with the new OID and ASN.1 to section 3.4 of Updates CMP and use it in Lightweight CMP Profile section 5.1.6.1.

     id-SymmetricKeyEncryption OBJECT IDENTIFIER ::= {xxx}
     KEParameter ::= SEQUENCE {
       salt                         OCTET STRING,
       owf                         AlgorithmIdentifier,
       iterationCount      INTEGER,
       keAlgorithm          AlgorithmIdentifier
     }

   In the above protectionAlg, the salt value is appended to the shared
   secret input.  The OWF is then applied iterationCount times, where
   the salted secret is the input to the first iteration and, for each
   successive iteration, the input is set to be the output of the
   previous iteration.  The output of the final iteration (called
   "BASEKEY" for ease of reference, with a size of "H") is what is used
   to form the symmetric key.  If the encryption algorithm requires a K-bit key
   and K <= H, then the most significant K bits of BASEKEY are used.  If
   K > H, then all of BASEKEY is used for the most significant H bits of
   the key, OWF("1" || BASEKEY) is used for the next most significant H
   bits of the key, OWF("2" || BASEKEY) is used for the next most
   significant H bits of the key, and so on, until all K bits have been
   derived.  [Here "N" is the ASCII byte encoding the number N and "||"
   represents concatenation.]

   Note: in case the message containing the EnvelopedData used PBMParameters
   it is RECOMMENDED that the salt field in KEParameter be different to the one
   used in PBMParameters. The fields owf and iterationCount MAY be the
   same than used in PBMParameters.

Did I understand Russ's approach correctly and would this fit?

Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 3 Apr 2020 17:09:05 +0000

> Von: Spasm <[email-masked]> Im Auftrag von [ext] Brockhaus,
> Hendrik
> 
> In EnvelopedData there are only ktri, kari, and kekri mandatory and pwri is only
> optional. May be this is a reason why I did not look deeper into pwri.. From its
> specification in RFC5652 pwri looks fairly what I tried to specify using
> PBMParameters. I was a bit confused that RFC5652 refers to RFC3211 for
> further specification of  PasswordRecipientInfo Type even thou RFC3211 is
> obsoleted by RFC3370. Should I use the PasswordRecipientInfo Type from
> RFC3211 and the keyDerivationAlgorithm PDKDF2 from RDC3370 then?
> 
> Below I updated my approach using KEKRecipientInfo  using an adapted
> AlgorithmID like I understood Russ's feedback.
> 

After checking some libraries it looks like pwri is well supported.
What do you recommend? 

Hendrik

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Apr 2020 11:32:16 -0700

If there is good support, and perhaps even if there is not, for password
recipient info I think you are going to be better off using that.  The
reason for this is that it is likely that the existing PRI will already
implement the password based KDF that you want to use, even if that changes
in the future, while the KEK version would need to be added as part of every
new algorithm update.

Jim

-----Original Message-----
From: Brockhaus, Hendrik <[email-masked]> 
Sent: Friday, April 3, 2020 10:09 AM
To: Russ Housley <[email-masked]>; Jim Schaad <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: AW: [lamps] draft-ietf-lamps-lightweight-cmp-profile-01, section
5.1.6.1

> In EnvelopedData there are only ktri, kari, and kekri mandatory and 
> pwri is only optional. May be this is a reason why I did not look 
> deeper into pwri.. From its specification in RFC5652 pwri looks fairly 
> what I tried to specify using PBMParameters. I was a bit confused that 
> RFC5652 refers to RFC3211 for further specification of  
> PasswordRecipientInfo Type even thou RFC3211 is obsoleted by RFC3370. 
> Should I use the PasswordRecipientInfo Type from

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Apr 2020 15:09:52 -0400

Yes, I think that pwri is a better fit.

Russ

> On Apr 3, 2020, at 2:32 PM, Jim Schaad <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 3 Apr 2020 19:16:33 +0000

> Von: Russ Housley <[email-masked]>
> 
> > If there is good support, and perhaps even if there is not, for
> > password recipient info I think you are going to be better off using
> > that.  The reason for this is that it is likely that the existing PRI
> > will already implement the password based KDF that you want to use,
> > even if that changes in the future, while the KEK version would need
> > to be added as part of every new algorithm update.
> >
> > Jim

Thanks! 
I will update the draft accordingly.

> >> RFC3211 and the keyDerivationAlgorithm PDKDF2 from RFC3370 then?

Is this the way forward to use pwri?

Hendrik

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Apr 2020 12:40:57 -0700

-----Original Message-----
From: Brockhaus, Hendrik <[email-masked]> 
Sent: Friday, April 3, 2020 12:17 PM
To: Russ Housley <[email-masked]>; Jim Schaad <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: AW: [lamps] draft-ietf-lamps-lightweight-cmp-profile-01, section
5.1.6.1

> > that.  The reason for this is that it is likely that the existing 
> > PRI will already implement the password based KDF that you want to 
> > use, even if that changes in the future, while the KEK version would 
> > need to be added as part of every new algorithm update.
> >
> > Jim

Thanks! 

[JLS] The structure is the same in both 3211 and 5652. I don't think it
matters from that point which you refer to.  If you want to refer to
implementation details then 3211 is correct.  Yes 3370 for PDKDF2 makes
sense.  You may also want to look at Argon2 as well even though I don't know
if it has been fully specified yet.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Apr 2020 15:49:57 -0400

> On Apr 3, 2020, at 3:16 PM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
>>>> PDKDF2

You mean PBKDF2, right?

Look at RFC 8018.  If specifies the algorithm identifiers for PBKDF2 with SHA-256, SHA-384, SHA-512, ...

Russ

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 3 Apr 2020 19:53:27 +0000

Thanks, I will have a look at RFC 8018 and Argon2.
Hendrik