| blob | a860e8786ef8e039890f81aea7af5ac980240744 |
2 Network Working Group Babu Neelam
3 Internet-Draft Independent
4 Intended status: Standards Track August 19, 2007
5 Expires: February 15, 2008
8 TLS extension for Proxies to transfer Server certificate
9 draft-babu-serv-cert-trans-from-proxy-00
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on January 10, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2007).
40 Abstract
42 Intercepting transparent proxies splice the client-Server connection
43 into two connections: Client-Proxy connection, Proxy-server
44 connection. On Client-Proxy connection, proxy sends it's certificate
45 to the client. As client is generally (in such a scenario)
46 pre-configured to accept proxy's certificate, client accepts and
47 proceeds further with the connection. On Proxy-Server connection,
48 server sends its certificate to the proxy. Proxy typically doesn't
49 possess the information (like MX domain name in case of SMTP)
50 required to validate the certificate. The certificate validation is
51 at times very complex & hence it is better to offload this
52 reponsibility to the original client itself.
54 This document addresses this issue by extending TLS to let proxy
55 send server's certificate to the client for validation and suggests
56 how client can indicate certificate validation result to the proxy.
58 Requirements Language
60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
62 document are to be interpreted as described in RFC 2119 [RFC2119].
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
67 2. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 2
68 3. Need Server certificate extension. . . . . . . . . . . . . . . 2
69 4. Handshake message to transfer server certificate . . . . . . . 3
70 5. various scenarios. . . . . . . . . . . . . . . . . . . . . . . 4
71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
74 Intellectual Property and Copyright Statements . . . . . . . . . . 7
77 1. Introduction
79 Today, intercepting transparent proxies are very common in
80 applications (say SMTP, HTTP) using [TLS]. In SMTP, these
81 intercepting proxies may provide functionality like anti-virus
82 scanning, anti-spam scanning. HTTP intercepting proxies may provide
83 functionality like anti-virus scanning, URL filtering etc.
85 Client ---- Transparent Proxy -------- Server
87 This document defines a way for proxy to send original server's
88 certificate to the original client and suggests how client can
89 indicate certificate validation result to the proxy. The mechanism
90 makes use of TLS extension framework defined in [RFC4366] and defines
91 a new TLS handshake message type.
93 The clients supporting this extension receive certificates of
94 intercepting proxy (if interception happens) as well as the original
95 server. So clients should be capable of handling validations on both
96 the certificates.
98 2. Mechanism Overview
100 This extension defines
101 - A new extension type (need_server_certificate) for extended
102 client hellos defined in [RFC4366].
103 - A new handshake message (Orig_server_certificate)
105 3. Need Server certificate extension
107 Who should send this extension ?
108 - A client which is configured to request the original server
109 certificate for validation includes an extension of type
110 "need_server_certificate" in (extended) client hello.
111 - It is possible that there could be more than one proxy
112 between client and server:
114 Client --- P1 --- P2 ------ Server
116 In such a scenario, P1 also includes "need_server_certificate"
117 in (extended) client hello in its connection to P2, unless it
118 has the knowledge that it is the last proxy between client and
119 server. If a proxy is configured that it is the edge proxy in
120 client's trust domain, then it need not send this extension.
122 How should a receiver respond to this ?
123 - If a proxy intercepts the connection, it SHOULD respond back to
124 the client with "need_server_certificate" extension.
125 - When there are no intercepting proxies, a server receives this
126 extension. A server which understands this extension should
127 ignore this. It is not clear from [RFC4366] what a server does
128 when it receives an extension which it doesn't understand.
129 This item is TBD.
130 - If a proxy which doesn't have the capability to validate server
131 certificate or is configured to offload this responsibility to
132 the original client doesn't receive "need_server_certificate"
133 extension, it should return a fatal error like handshake failure
134 or insufficient security (TBD).
136 When a proxy responds with "need_server_certificate" extension to the
137 client, proxy MUST send the its certificate as well as the original
138 server certificate to the client (discussed in section 4).
141 How should client handle ServerHello?
142 - If the client receives "need server_certificate" extension in
143 ServerHello, it MUST expect the nexthop proxy certificate as
144 well as the original server certificate. Client MUST perform
145 validations on both proxy certificate as well as original server
146 certificate. If a client doesn't receive server certificate, it
147 MUST abort the connection.
148 - If the client doesn't receive "need_server_certificate"
149 extention in SerVerHello, client MUST assume that there is no
150 proxy in between and MUST perform server certificate validations
151 on the received certificate.
153 The "extension_data" field of this extension in both clientHello as
154 well as ServerHello SHALL be empty.
156 Note on backward compatibility: Suppose a client supports this
157 extension, but a intercepting proxy or the actual server doesn't
158 understand extended hello or "need_server_certificate", client
159 MUST proceed with the connection and MUST perform server certificate
160 validations on the received certificate. By validating this way,
161 clientcan deny connections from any proxies (because certificate
162 validation fails) which do not support this mechanism, but still
163 accept connections from server which do not support this.
165 4. Handshake message to transfer server certificate
167 This docuemnt suggests the use of a new handshake message,
168 "orig_server_certificate" to transfer the original server's
169 certificate to the client. The new handshake message structure
170 therefore becomes:
172 enum {
173 hello_request(0), client_hello(1), server_hello(2),
174 certificate(11), server_key_exchange (12),
175 certificate_request(13), server_hello_done(14),
176 certificate_verify(15), client_key_exchange(16),
177 finished(20), certificate_url(21), certificate_status(22),
178 orig_server_certificate(23),
179 (255)
180 } HandshakeType;
182 struct {
183 HandshakeType msg_type; /* handshake type */
184 uint24 length; /* bytes in message */
185 select (HandshakeType) {
186 case hello_request: HelloRequest;
187 case client_hello: ClientHello;
188 case server_hello: ServerHello;
189 case certificate: Certificate;
190 case server_key_exchange: ServerKeyExchange;
191 case certificate_request: CertificateRequest;
192 case server_hello_done: ServerHelloDone;
193 case certificate_verify: CertificateVerify;
194 case client_key_exchange: ClientKeyExchange;
195 case finished: Finished;
196 case certificate_url: CertificateURL;
197 case certificate_status: CertificateStatus;
198 case orig_server_certificate: Certificate; /*new*/
199 } body;
200 } Handshake;
202 The structure of Certificate is defined in [RFC4346].
204 If proxy responded to the client with "need_server_certificate"
205 extension, this message MUST be sent immediately after the
206 "Certificate" handshake message in Client-Proxy connection.
208 The client MUST perform validations on the received proxy
209 certificate as well as the server certificate. If either proxy or
210 server certificate is not valid, client should respond with
211 certificate related error messages defined in [RFC4346]. On
212 reception of such an error, proxy MUST close the Proxy-Server
213 connection.
215 It should be noted that proxy transparency is lost at TLS layer
216 due to the fact that client is sent both proxy as well as original
217 server certificate for validation. Though transparency is not
218 possible at TLS layer, application protocols can still remain
219 transparent to the proxy operation.
221 5. various scenarios
223 Client, Proxy understand this extension.
225 Client Proxy Server
227 ClientHelo
228 (with
229 "need_orig_server") -->
230 ClientHelo
231 (with
232 "need_orig_server")--->
233 ServerHelo
234 (without
235 "need_orig_server")
236 Certificate
237 ServerkeyExchange
238 <--- ServerhelloDone
239 ServerHelo
240 (with "need_orig_server")
241 Certificate
242 orig_server_certificate
243 ServerkeyExchange
244 <-- ServerHelloDone
245 ClientKeyExchange
246 CertificateVerify
247 [ChangeCipherSpec]
248 [Finished] -->
249 [ChangeCipherSpec]
250 <-- [Finished]
251 [ChangeCipherSpec]
252 [Finished] -->
253 [ChangeCipherSpec]
254 <-- [Finished]
258 Client understands this extension. Proxy doesn't. In this case,
259 certificate validation fails on the received proxy certificate.
262 Client Proxy Server
264 ClientHelo
265 (with
266 "need_orig_server") -->
267 ServerHelo
268 (without "need_orig_server")
269 Certificate
270 orig_server_certificate
271 ServerkeyExchange
272 <-- ServerHelloDone
273 Certificate error
277 Client doesn;t understand this extension, but proxy is configured
278 to offload original server certificate responsibility to the
279 original client:
281 Client Proxy Server
283 ClientHelo
284 (with
285 "need_orig_server") -->
286 Fatal Error
288 TBD: Two proxies between client and server. Client as well as two
289 proxies undertsand this extension.
291 6. IANA Considerations
293 This document (if approved) requests IANA to allocate
294 "need-server_certificate" TLS extension and
295 "Orig_server_certificate" handhsake message.
297 Note to RFC Editor: this section may be removed on publication as an
298 RFC.
300 7. Security Considerations
302 Though this extension equips clients with an ability to validate
303 original server certificate as well as it's nexthop, it doesn't
304 provide a mechanism to transmit certficates of any proxies between
305 the first proxy and the original server. It is assumed that client
306 trusts the first proxy to either not allow any other proxies in
307 between or to allow only a proxy which is in the trusted domain.
309 8. Normative References
311 [RFC4346] The Transport Layer Security (TLS) Protocol Version 1.1.
312 T.Dierks, E. Rescorla. April 2006.
313 [RFC4366] Transport Layer Security (TLS) Extensions.
314 S. Blake-Wilson, M.Nystrom, D. Hopwood, J. Mikkelsen,
315 T. Wright. April 2006.
316 [RFC2818] HTTP Over TLS. E. Rescorla. May 2000.
317 [RFC3207] SMTP Service Extension for Secure SMTP over Transport
318 Layer Security. P. Hoffman. February 2002.
320 Author's Address
322 Babu Neelam
323 Intoto Software India Private Ltd.
324 8-3-1111/2, kesava nagar colony,
325 sriniagar colony main road,
326 punjagutta,
327 Hyderabad,
328 India.
330 Email: babun@intoto.com
332 Comments are solicited and should be addressed to the working
333 group's mailing list at ietf-http-wg@w3.org and/or the author(s).
336 Full Copyright Statement
338 Copyright (C) The IETF Trust (2007).
340 This document is subject to the rights, licenses and restrictions
341 contained in BCP 78, and except as set forth therein, the authors
342 retain all their rights.
344 This document and the information contained herein are provided on an
345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
347 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
348 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
349 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
353 Intellectual Property
355 The IETF takes no position regarding the validity or scope of any
356 Intellectual Property Rights or other rights that might be claimed to
357 pertain to the implementation or use of the technology described in
358 this document or the extent to which any license under such rights
359 might or might not be available; nor does it represent that it has
360 made any independent effort to identify any such rights. Information
361 on the procedures with respect to rights in RFC documents can be
362 found in BCP 78 and BCP 79.
364 Copies of IPR disclosures made to the IETF Secretariat and any
365 assurances of licenses to be made available, or the result of an
366 attempt made to obtain a general license or permission for the use of
367 such proprietary rights by implementers or users of this
368 specification can be obtained from the IETF on-line IPR repository at
369 http://www.ietf.org/ipr.
371 The IETF invites any interested party to bring to its attention any
372 copyrights, patents or patent applications, or other proprietary
373 rights that may cover technology that may be required to implement
374 this standard. Please address the information to the IETF at
375 ietf-ipr@ietf.org.
378 Acknowledgment
380 Funding for the RFC Editor function is provided by the IETF
381 Administrative Support Activity (IASA).