Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax
draft-ietf-lamps-pkcs12-pbmac1-00

Internet Engineering Task Force                            H. Kario, Ed.
Internet-Draft                                             Red Hat, Inc.
Updates: 7292 (if approved)                               5 October 2022
Intended status: Informational                                          
Expires: 8 April 2023

Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12
                                 Syntax
                   draft-ietf-lamps-pkcs12-pbmac1-00

Abstract

   This document specifies additions and amendments to RFC 7292.  It
   defines a way to use the Password Based Message Authentication Code
   1, defined in RFC 8018, inside the PKCS #12 syntax.  The purpose of
   this specification is to permit use of more modern PBKDFs and allow
   for regulatory compliance.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Kario                     Expires 8 April 2023                  [Page 1]
Internet-Draft              PBMAC1 in PKCS#12               October 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   4.  Embedding PBMAC1 in PKCS #12  . . . . . . . . . . . . . . . .   3
   5.  Recommended parameters  . . . . . . . . . . . . . . . . . . .   3
   6.  Deprecated Algorithms . . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   The PKCS #12 [RFC7292] format is widely used for interoperable
   transfer of certificate, key, and other miscellaneous secrets between
   machines, applications, browsers, etc.  Unfortunately, the original
   specification mandates the use of a specific password based key
   derivation function, allowing only for change of the underlying
   message digest function.

2.  Rationale

   Due to security concerns with PBKDF1 and much higher extensibility of
   PBMAC1, we propose the use of PBMAC1 for integrity protection of PKCS
   #12 structures.  The new syntax is designed to allow legacy
   applications to still be able to decrypt the key material, even if
   they are unable to interpret the new integrity protection, provided
   that they can ignore failures in MAC verification.  Use of the
   extensible PBMAC1 mechanism also allows for greater flexibility and
   alignment to different government regulations.

Kario                     Expires 8 April 2023                  [Page 2]
Internet-Draft              PBMAC1 in PKCS#12               October 2022

   As recommended methods for key protection require both encryption and
   integrity protection, we've decided to amend the PKCS #12 format to
   support different key derivation functions rather than extending the
   PKCS #5 by a new field allowing integrity protection.

3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Embedding PBMAC1 in PKCS #12

   The MacData structure in the PFX object is changed as follows:

   1.  the id-PBMAC1 object identifier is permitted as a valid type for
       the DigestAlgorithmIdentifier inside the DigestInfo object.  If
       the algorithm field of the DigestAlgorithmIdentifier is id-
       PBMAC1, then the parameters field MUST be present and have the
       value consistent with PBMAC1-params

   2.  if the PBMAC1 algorithm is used, the digest value of the
       DigestInfo object MUST be the result of the PBMAC1 calculation
       over the authSafe field using the PBMAC1-params parameters

   3.  if the PBMAC1 algorithm is used, the macSalt value MUST be
       ignored, for backwards compatibility it SHOULD NOT be empty

   4.  if the PBMAC1 algorithm is used, the iteration value MUST be
       ignored, for backwards compatibility it SHOULD have a non-zero
       positive value

5.  Recommended parameters

   To provide interoperability between different implementations, all
   implementations of this specification MUST support the PBKDF2 key
   derivation function paired with SHA-256 HMAC.  It's RECOMMENDED for
   implementations to support other SHA-2 based HMACs.  Implementations
   MAY use other hash functions, like the SHA-3 famility of hash
   functions SHA-3 [SHA3].  Implementations MAY use other KDF methods,
   like the scrypt PBKDF RFC 7914 [RFC7914].

Kario                     Expires 8 April 2023                  [Page 3]
Internet-Draft              PBMAC1 in PKCS#12               October 2022

   The length of the key generated by the used KDF MUST be encoded
   explicitly in the parameters field and SHOULD be the same size as the
   HMAC function output size.  That means that PBMAC1-params specifying
   SHA-256 HMAC should also include KDF parameters that generate 32
   octet long key.  In particular, when using the PBKDF2, the
   implementations MUST include the keyLen field in the encoded
   PBKDF2-params.  Implementations MUST NOT accept PBKDF2 KDF with
   PBKDF2-params that omit the keyLen field.

6.  Deprecated Algorithms

   While attacks against SHA-1 HMACs are not considered practical
   [RFC6194] to limit the number of algorithms needed for
   interoperatbility, implementations of this specification SHOULD NOT
   use PBKDF2 with the SHA-1 HMAC.  Additionally the implementation MUST
   NOT use any other message digest functions with output of 160 bits or
   smaller.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   Except for use of different key derivation functions, this document
   doesn't change how the integrity protection on PKCS #12 objects is
   computed; therefore all the original security considerations from RFC
   7292 [RFC7292] apply.

   Use of PBMAC1 and PBKDF2 is unchanged from RFC 8018 [RFC8018];
   therefore all the original security considerations apply.

   The KDFs generally don't have a lower limit for the generated key
   size, allowing specifying very small key sizes (of 1 octet), which
   can facilitate brute-force attacks on the HMAC.  Since the KDF
   parameters are not cryptographically protected and HMACs accept
   arbitrary key sizes, implementations MAY refuse to process KDF
   paramters that specify small key output sizes or weak paramters.
   It's RECOMMENDED to reject any KDF parameters that specify key
   lengths below 20 octets.

9.  References

9.1.  Normative References

Kario                     Expires 8 April 2023                  [Page 4]
Internet-Draft              PBMAC1 in PKCS#12               October 2022

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
              Considerations for the SHA-0 and SHA-1 Message-Digest
              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
              <https://www.rfc-editor.org/info/rfc6194>.

   [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
              and M. Scott, "PKCS #12: Personal Information Exchange
              Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
              <https://www.rfc-editor.org/info/rfc7292>.

   [RFC8018]  Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
              Password-Based Cryptography Specification Version 2.1",
              RFC 8018, DOI 10.17487/RFC8018, January 2017,
              <https://www.rfc-editor.org/info/rfc8018>.

9.2.  Informative References

   [RFC7914]  Percival, C. and S. Josefsson, "The scrypt Password-Based
              Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
              August 2016, <https://www.rfc-editor.org/info/rfc7914>.

   [SHA3]     National Institute of Standards and Technology, "SHA-3
              Standard: Permutation-Based Hash and Extendable-Output
              Functions", August 2015,
              <https://doi.org/10.6028/NIST.FIPS.202>.

Appendix A.  Test Vectors

   TODO: Include few examples of PKCS#12 files with different
   parameters.

Author's Address

   Hubert Kario (editor)
   Red Hat, Inc.
   Purkynova 115
   61200 Brno
   Czech Republic
   Email: hkario@redhat.com

Kario                     Expires 8 April 2023                  [Page 5]