draft-ietf-krb-wg-ocsp-for-pkinit-02.txt   draft-ietf-krb-wg-ocsp-for-pkinit-03.txt 
NETWORK WORKING GROUP L. Zhu NETWORK WORKING GROUP L. Zhu
Internet-Draft K. Jaganathan Internet-Draft K. Jaganathan
Expires: May 21, 2005 Microsoft Corporation Expires: June 3, 2005 Microsoft Corporation
N. Williams N. Williams
Sun Microsystems Sun Microsystems
November 20, 2004 December 3, 2004
OCSP Support for PKINIT OCSP Support for PKINIT
draft-ietf-krb-wg-ocsp-for-pkinit-02 draft-ietf-krb-wg-ocsp-for-pkinit-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2005. This Internet-Draft will expire on June 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines a mechanism to enable in-band transmission of This document defines a mechanism to enable in-band transmission of
OCSP responses. These responses are used to verify the validity of Online Certificate Status Protocol (OCSP) responses in the Kerberos
the certificates used in PKINIT - the Kerberos Version 5 extension network authentication protocol. These responses are used to verify
that provides for the use of public key cryptography. the validity of the certificates used in PKINIT - the Kerberos
Version 5 extension that provides for the use of public key
cryptography.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Message Definition . . . . . . . . . . . . . . . . . . . . . 5 3. Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10 7.2 Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11
1. Introduction 1. Introduction
Online Certificate Status Protocol (OCSP) [RFC2560] enables Online Certificate Status Protocol (OCSP) [RFC2560] enables
applications to obtain timely information regarding the revocation applications to obtain timely information regarding the revocation
status of a certificate. Because OCSP responses are well-bounded and status of a certificate. Because OCSP responses are well-bounded and
small in size, constrained clients may wish to use OCSP to check the small in size, constrained clients may wish to use OCSP to check the
validity of KDC certificates in order to avoid transmission of large validity of the certificates for Kerberos Key Distribution Center
Certificate Revocation Lists (CRLs) and therefore save bandwidth on (KDC) in order to avoid transmission of large Certificate Revocation
constrained networks [OCSP-PROFILE]. Lists (CRLs) and therefore save bandwidth on constrained networks
[OCSP-PROFILE].
This document defines a pre-authentication type [CLARIFICATIONS], This document defines a pre-authentication type [CLARIFICATIONS],
where the client and the KDC MAY piggyback OCSP responses for where the client and the KDC MAY piggyback OCSP responses for
certificates used in authentication exchanges, as defined in certificates used in authentication exchanges, as defined in
[PKINIT]. [PKINIT].
By using this OPTIONAL extension, PKINIT clients and the KDC can By using this OPTIONAL extension, PKINIT clients and the KDC can
maximize the reuse of cached OCSP responses. maximize the reuse of cached OCSP responses.
2. Conventions Used in This Document 2. Conventions Used in This Document
skipping to change at page 5, line 11 skipping to change at page 5, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Message Definition 3. Message Definition
A pre-authentication type identifier is defined for this mechanism: A pre-authentication type identifier is defined for this mechanism:
PA-PK-OCSP-RESPONSE 16 PA-PK-OCSP-RESPONSE 16
The corresponding pre-authentication field contains OCSP data as The corresponding padata-value field [CLARIFICATIONS] contains the
follows: DER [X60] encoding of the following ASN.1 type:
PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse PKOcspData ::= SEQUENCE OF OcspResponse
OcspResponse ::= OCTET STRING OcspResponse ::= OCTET STRING
-- contains a complete OCSP response, -- contains a complete OCSP response,
-- defined in [RFC2560] -- defined in [RFC2560]
The client MAY send OCSP responses for certificates used in The client MAY send OCSP responses for certificates used in
PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE. PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a
PA-PK-OCSP-RESPONSE in response. The client can request a PA-PK-OCSP-RESPONSE containing OCSP responses for certificates used
PA-PK-OCSP-RESPONSE by using an empty sequence in its request. in the KDC's PA-PK-AS-REP. The client can request a
PA-PK-OCSP-RESPONSE by using a PKOcspData containing an empty
sequence.
The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
PA-PK-OCSP-RESPONSE from the client. PA-PK-OCSP-RESPONSE from the client.
The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
certificates used in PA-PK-AS-REP [PKINIT]. certificates used in PA-PK-AS-REP [PKINIT].
Note the lack of integrity protection for the empty or missing OCSP Note the lack of integrity protection for the empty or missing OCSP
response; lack of an expected OCSP response from the KDC for the response; lack of an expected OCSP response from the KDC for the
KDC's certificates SHOULD be treated as an error by the client, KDC's certificates SHOULD be treated as an error by the client,
unless it is configured otherwise. unless it is configured otherwise.
When using OCSP, the response is signed by the OCSP server, which is When using OCSP, the response is signed by the OCSP server, which is
trusted by the receiver. Depending on local policy, further trusted by the receiver. Depending on local policy, further
verification of the validity of the OCSP servers MAY need to be done. verification of the validity of the OCSP servers may be needed
The client and the KDC SHOULD ignore invalid OCSP responses received The client and the KDC SHOULD ignore invalid OCSP responses received
via this mechanism, and they MAY implement CRL processing logic as a via this mechanism, and they MAY implement CRL processing logic as a
fall-back position, if the OCSP responses received via this mechanism fall-back position, if the OCSP responses received via this mechanism
alone are not sufficient for the verification of certificate alone are not sufficient for the verification of certificate
validity. The client and/or the KDC MAY ignore a valid OCSP response validity. The client and/or the KDC MAY ignore a valid OCSP response
and perform their own revocation status verification independently. and perform their own revocation status verification independently.
4. Security Considerations 4. Security Considerations
The pre-authentication data in this document do not actually The pre-authentication data in this document do not actually
authenticate any principals, and MUST be used in conjunction with authenticate any principals, and it is designed to be used in
PKINIT. conjunction with PKINIT.
There is a downgrade attack against clients which want OCSP responses There is a downgrade attack against clients which want OCSP responses
from the KDC for the KDC's certificates. The clients, however, can from the KDC for the KDC's certificates. The clients, however, can
treat the absence of valid OCSP responses as an error, based on their treat the absence of valid OCSP responses as an error, based on their
local configuration. local configuration.
5. IANA Considerations 5. IANA Considerations
This document defines a new pre-authentication type for use with No IANA actions are required for this document.
PKINIT to encode OCSP responses. The official value for this padata
identifier need to be acquired from IANA.
6. Acknowledgements 6. Acknowledgements
This document was based on conversations among the authors, Jeffrey This document was based on conversations among the authors, Jeffrey
Altman, Sam Hartman, Martin Rex and other members of the Kerberos Altman, Sam Hartman, Martin Rex and other members of the Kerberos
working group. working group.
7 References 7. References
7.1 Normative References
[CLARIFICATIONS] [CLARIFICATIONS]
Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", Kerberos Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications, Work in draft-ietf-krb-wg-kerberos-clarifications, work in
progress.
[OCSP-PROFILE]
Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
High Volume Environments",
draft-ietf-pkix-lightweight-ocsp-profile, Work in
progress. progress.
[PKINIT] Tung, B., Neuman, B. and S. Medvinsky, "Public Key [PKINIT] Tung, B., Neuman, B. and S. Medvinsky, "Public Key
Cryptography for Initial Authentication in Kerberos", Cryptography for Initial Authentication in Kerberos",
draft-ietf-cat-kerberos-pk-init, Work in progress. draft-ietf-cat-kerberos-pk-init, work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[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.
7.2 Informative References
[OCSP-PROFILE]
Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
High Volume Environments", August 2004.
Authors' Addresses Authors' Addresses
Larry Zhu Larry Zhu
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
EMail: lzhu@microsoft.com EMail: lzhu@microsoft.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/