Internet-Draft PBMAC1 in PKCS#12 June 2022
Kario Expires 23 December 2022 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-kario-pkcs12-pbmac1-00
Updates:
RFC7292 (if approved)
Published:
Intended Status:
Informational
Expires:
Author:
H. Kario, Ed.
Red Hat, Inc.

Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax

Abstract

This document specifies additions and amendments to RFC 7292 [RFC7292]. It defines a way to use the Password Based Message Authentication Code 1, defined in RFC 8018 [RFC8018], 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 23 December 2022.

▲

Table of Contents

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.

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

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 KDF methods, like the scrypt PBKDF RFC 7914 [RFC7914].

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.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7914>.

Appendix A. Additional Stuff

This becomes an Appendix.

Author's Address

Hubert Kario (editor)
Red Hat, Inc.
Purkynova 115
61200 Brno
Czech Republic