Subject: [TLS] OCSP Stapling in RFC 6066

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 11 Feb 2015 12:26:12 +0000

Hi all,

I've got a question to the OCSP stapling approach described in RFC 6066 using the Certificate Status Request extension. It seems that this extension has been defined in a way to allow only a client to request the OCSP response from a server during the ClientHello message. From my understanding, it does not support the other way around to let the client also sent OCSP response for his  certificates, when doing a client side authentication. So my question is simply if this is the right observation and if there is a (standard compliant) way to also let the client sent his OCSP response (maybe through the generic extension mechanism?)?

The background of this question is that in energy automation or smart grid standards like IEC 62351 require mutual authentication based on certificates as part of the TLS handshake. Moreover, the server application often resides on field devices and the connecting application is control center. Hence, the TLS client side may be more powerful and may have better connectivity to OCSP server.

Any ideas?

Regards
Steffen

Steffen Fries
Siemens AG
Corporate Technology
Research & Technology Center
CT RTC ITS
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Tel.: +49 89 636-633604
Fax: +49 89 636-48000
mailto:[email-masked]

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 11 Feb 2015 15:09:59 +0000

You are correct; there is no way for a client to include its OCSP status.   Defining a new extension that the client could put in its hello message would be interesting; it might even work.

--
Principal Security Engineer, Akamai Technologies
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 12 Feb 2015 07:55:52 +0000

Hi Rich,

thank you for the feedback. Yes, putting it into the ServerHello would probably be the most easy approach, as it allows extensions. It could probably also be put into the CertificateRequest direcly, but certainly requires more specification.

Regards
Steffen

From: Salz, Rich [mailto:[email-masked]]
Sent: Mittwoch, 11. Februar 2015 16:10
To: Fries, Steffen; [email-masked]
Subject: RE: OCSP Stapling in RFC 6066

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 12 Feb 2015 11:57:39 +0000

On 11/02/15 12:26, Fries, Steffen wrote:
> I've got a question to the OCSP stapling approach described in RFC 6066

Why not jump directly to an RFC 6961 analogue?
-- 
Cheers,
  Jeremy

---

From: [email-masked] (Martin Rex)
Date: Thu, 12 Feb 2015 19:51:23 +0100 (CET)

Jeremy Harris wrote:
> Fries, Steffen wrote:

Your observation is correct that the rfc6066 OCSP extension is limited
to a single OCSP response for the server certificate, whereas the
TLS extension defined in rfc6961 allows for multiple OCSP responses,
including OCSP responses for CA certificates in the certificate
chain of the server.

But there are a number of differences in the server and client
authentication that make these two TLS extensions (or their approach)
a bad fit for client certificate authentication.

For the server certificate, the Server's decision/choice for a specific
server certificate happens (or at least can happen) while the server
evaluates the TLS protocol options proposed in ClientHello and
composed the ServerHello response _after_ making the selections of
TLS protocol options.  So when the server composes the ServerHelloExtensions
it knows which server certificate it is going to use and can insert
the respective OCSP responses into ServerHello.

The situation is substantially different for the client, who has to
include all TLS protocol options that are up for negotation upfront
in ClientHello(Extensions).  At this point, the client does not know
whether the server is going to request a client certificate at all,
nor does the client know, which list of trusted certification_authorities
or which algorithms the server supports and is going to select/request.

So the approach for conveying OCSP responses for the client certificate
from the client to the server should probably be on the second batch
of handshake messages from client to server in a full TLS handshake,
such as using a "TLS Handshake Message for Supplemental Data" (rfc4680).
I agree that the rfc4680 approach is more code to implement, but
such an approach would not break when the client has more than one
client certificates or additional client certificates other than X.509.

-Martin

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 13 Feb 2015 09:58:05 +0000

Martin, Jeremy,

to be frank, I checked RC 6961 before but did not mention it in my initial request. I did not see the option to also use the extension to transmit the OCSP information for the client certificate. Hence the question regarding applying the extension via the generic extensions mechanism. 

I see Martins point with the order of information sent, as when applied to the single TLS handshake, the client would have to know he has to authenticated using his certificate before getting the request from the server side for client authentication. This would be probably not such a problem for the target environment as here mutual authentication is always required. But for the generic approach your proposal using RFC 4680 looks promising, as in the second round the client could attach his OCSP responses to the ClientHello. But as you said, it comes with the burden of a second run of the handshake. 
There is some asymmetry, as the server basically sends his certificate and also the OCSP response(s) in his ServerHello message, while the client sends his certificate with the second handshake message, while extensions are defined for the ClientHello. But I would not see an easier way for now. 

Steffen

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Donnerstag, 12. Februar 2015 19:51
To: Jeremy Harris
Cc: [email-masked]
Subject: Re: [TLS] OCSP Stapling in RFC 6066

> Why not jump directly to an RFC 6961 analogue?

Your observation is correct that the rfc6066 OCSP extension is limited to a single OCSP response for the server certificate, whereas the TLS extension defined in rfc6961 allows for multiple OCSP responses, including OCSP responses for CA certificates in the certificate chain of the server.

But there are a number of differences in the server and client authentication that make these two TLS extensions (or their approach) a bad fit for client certificate authentication.

For the server certificate, the Server's decision/choice for a specific server certificate happens (or at least can happen) while the server evaluates the TLS protocol options proposed in ClientHello and composed the ServerHello response _after_ making the selections of TLS protocol options.  So when the server composes the ServerHelloExtensions it knows which server certificate it is going to use and can insert the respective OCSP responses into ServerHello.

The situation is substantially different for the client, who has to include all TLS protocol options that are up for negotation upfront in ClientHello(Extensions).  At this point, the client does not know whether the server is going to request a client certificate at all, nor does the client know, which list of trusted certification_authorities or which algorithms the server supports and is going to select/request.

So the approach for conveying OCSP responses for the client certificate from the client to the server should probably be on the second batch of handshake messages from client to server in a full TLS handshake, such as using a "TLS Handshake Message for Supplemental Data" (rfc4680).
I agree that the rfc4680 approach is more code to implement, but such an approach would not break when the client has more than one client certificates or additional client certificates other than X.509.

-Martin

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 13 Feb 2015 10:44:15 +0000

> to be frank, I checked RC 6961 before but did not mention it in my initial request. I did not see the option to also use the extension to transmit the OCSP information for the client certificate. H…

Indeed; it's just the support for status on the entire chain I'm
suggesting, not the mechanism.
-- 
Cheers,
  Jeremy