RFC 4557

Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)

📅 published June 2006, from ietf

RFC 4557: Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) ✨

okay so bestie, this one is from the Network Working Group 🎀. It was written by Larry Zhu (Microsoft Corporation), Karthik Jaganathan (Microsoft Corporation), and Nicolas Williams (Sun Microsystems) in June 2006. Its category is Standards Track 🔥, and the header doesn't list any RFCs that it obsoletes or updates, so it's not replacing or patching anything 💅.

Status of This Memo 🌸

This document is a standards track spec for the whole Internet community, and it's asking for discussion and suggestions. To check where the protocol stands, look at the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2006).

Abstract 🧚

This document adds a way to send Online Certificate Status Protocol (OCSP) responses in-band inside Kerberos 🍓. Those responses help verify the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension for public key cryptography. Main character energy, honestly 👑.

Table of Contents 📚

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. Message Definition ..............................................2
   4. Security Considerations .........................................3
   5. Acknowledgements ................................................4
   6. References ......................................................4
      6.1. Normative References .......................................4
      6.2. Informative References .....................................4

1. Introduction ✨

okay so OCSP [RFC2560] lets applications find out, in a timely way, whether a certificate has been revoked 🫶. OCSP responses are small and well bounded, so constrained clients can use OCSP to check the certificates of the Kerberos Key Distribution Center (KDC). That means they don't have to download huge Certificate Revocation Lists (CRLs), which saves bandwidth on constrained networks 🌈 [OCSP-PROFILE].

This document defines a pre-authentication type [RFC4120]. The client and the KDC MAY piggyback OCSP responses for certificates used in authentication exchanges, as described in [RFC4556] 💖.

Using this OPTIONAL extension lets PKINIT clients and the KDC get the most out of cached OCSP responses 🔥.

2. Conventions Used in This Document 🎀

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

3. Message Definition 🧚

A pre-authentication type identifier is defined for this mechanism 🦋:

           PA-PK-OCSP-RESPONSE              18

The matching padata-value field [RFC4120] holds the DER [X60] encoding of the following ASN.1 type 💜:

       PKOcspData ::= SEQUENCE OF OcspResponse
                      -- If more than one OcspResponse is
                      -- included, the first OcspResponse
                      -- MUST contain the OCSP response
                      -- for the signer's certificate.
                      -- The signer refers to the client for
                      -- AS-REQ, and the KDC for the AS-REP,
                      -- respectively.

       OcspResponse ::= OCTET STRING
                      -- Contains a complete OCSP response,
                      -- as defined in [RFC2560].

The client MAY send OCSP responses for certificates used in PA-PK-AS-REQ [RFC4556] through a PA-PK-OCSP-RESPONSE 🌸.

When the KDC gets a PA-PK-OCSP-RESPONSE, it SHOULD send back a PA-PK-OCSP-RESPONSE with OCSP responses for the certificates used in the KDC's PA-PK-AS-REP 🫶. To ask for one, the client can send a PKOcspData that contains an empty sequence 🙈.

The KDC MAY send a PA-PK-OCSP-RESPONSE even when it didn't get one from the client 🌈.

The PA-PK-OCSP-RESPONSE that the KDC sends contains OCSP responses for the certificates used in PA-PK-AS-REP [RFC4556] ✨.

Heads up: an empty or missing OCSP response has no integrity protection. So if the client doesn't get the OCSP response it expects from the KDC for the KDC's certificates, the client SHOULD treat that as an error, unless it's configured to do something else 🙈💀.

When OCSP is in use, the OCSP server signs the response, and the receiver trusts that server 🔥. Depending on local policy, the receiver may need to check the validity of the OCSP servers further

The client and the KDC SHOULD ignore invalid OCSP responses received through this mechanism 💅. They MAY also implement CRL processing as a fallback, if the OCSP responses received through this mechanism alone aren't enough to verify certificate validity 👑. The client and/or the KDC MAY ignore a valid OCSP response and do its own revocation status check on its own 🦋.

4. Security Considerations 💀

This is the part where I need you to pay attention, bestie 🚨. The pre-authentication data in this document doesn't actually authenticate any principals. It's designed to be used together with PKINIT 🎀.

There's no binding between PA-PK-OCSP-RESPONSE pre-authentication data and PKINIT pre-authentication data, except that an OCSP response corresponds to a certificate used in a PKINIT pre-authentication data element 😭. Attacks that remove or replace PA-PK-OCSP-RESPONSE pre-authentication data elements are, at worst, downgrade attacks. In those, a PKINIT client or KDC goes ahead without using CRLs or OCSP to validate certificates 💀. They can also be denial-of-service attacks, where a PKINIT client or KDC that can't validate the other's certificate without an accompanying OCSP response rejects the AS exchange, or has to download very large CRLs to keep going 🥺. Kerberos V doesn't protect against denial-of-service attacks, so the denial-of-service side of these attacks is considered acceptable 🫠.

If a PKINIT client or KDC can't validate certificates without a valid PA-PK-OCSP-RESPONSE, it SHOULD fail the AS exchange, depending on local configuration 🔥.

5. Acknowledgements 🫶

This document came out of conversations among the authors, Jeffrey Altman, Sam Hartman, Martin Rex, and other members of the Kerberos working group 💖.

6. References 📚

6.1. Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2560]      Myers, M., Ankney, R., Malpani, A., Galperin, S., and
                  C. Adams, "X.509 Internet Public Key Infrastructure
                  Online Certificate Status Protocol - OCSP", RFC 2560,
                  June 1999.

   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
                  Kerberos Network Authentication Service (V5)", RFC
                  4120, July 2005.

   [RFC4556]      Zhu, L. and B. Tung, "Public Key Cryptography for
                  Initial Authentication in Kerberos (PKINIT)", RFC
                  4556, June 2006.

   [X690]         ASN.1 encoding rules: Specification of Basic Encoding
                  Rules (BER), Canonical Encoding Rules (CER) and
                  Distinguished Encoding Rules (DER), ITU-T
                  Recommendation X.690 (1997) | ISO/IEC International
                  Standard 8825-1:1998.

6.2. Informative References

   [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
                  High Volume Environments", Work in Progress, May 2006.

Authors' Addresses 💌

   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   EMail: lzhu@microsoft.com


   Karthik Jaganathan
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   EMail: karthikj@microsoft.com


   Nicolas Williams
   Sun Microsystems
   5300 Riata Trace Ct
   Austin, TX  78727
   US

   EMail: Nicolas.Williams@sun.com

Copyright (C) The Internet Society (2006).

This document falls under the rights, licenses, and restrictions in BCP 78. Except as BCP 78 says otherwise, the authors keep all their rights 💜.

The document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose 🙈.

Intellectual Property 🦋

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone claims apply to the technology in this document are valid or in scope. It also doesn't say whether licenses under those rights are or aren't available, and it hasn't checked for such rights itself ✨. Information about rights in RFC documents is in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF online IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites anyone who knows of copyrights, patents, patent applications, or other proprietary rights that could cover technology needed to implement this standard to tell it about them. Send that information to ietf-ipr@ietf.org 💅.

Acknowledgement 💖

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶.

📦 where this page comes from