Projects/HTTP Transport - Revision history

Ghudson: /* Commits */

2014-08-12T17:54:19Z

‎Commits

Ghudson at 17:46, 12 August 2014

2014-08-12T17:46:17Z

Ghudson at 23:12, 2 June 2014

2014-06-02T23:12:14Z

Nalin: /* Implementation Design */

2014-06-02T18:36:27Z

‎Implementation Design

Nalin: /* Test Plan */

2014-04-21T23:00:25Z

‎Test Plan

Nalin: /* Test Plan */

2014-04-21T22:26:12Z

‎Test Plan

Nalin: /* Implementation Design */

2014-04-21T21:47:21Z

‎Implementation Design

Nalin: /* Test Plan */

2014-04-21T21:33:42Z

‎Test Plan

Nalin: /* Implementation Design */

2014-04-21T21:30:15Z

‎Implementation Design

Nalin: /* Implementation Process */

2014-04-21T21:25:58Z

‎Implementation Process

@@ Line 49: / Line 49: @@
 ==Commits==
-* 42b3c2ed11c1e62c1691f868a6796983f93c3beb Simplify sendto_kdc.c
+b3c2ed11c1e62c1691f868a6796983f93c3beb Simplify sendto_kdc.c
-* f4b1a7e7b80ce68e57912edcd48c39ea62c73e43 Add helper to determine if a KDC is the master
+    f4b1a7e7b80ce68e57912edcd48c39ea62c73e43 Add helper to determine if a KDC is the master
-* 9c6be00daca0b80aed94ec9680724f95e6be92e1 Use k5_transport(_strategy) enums for k5_sendto
+c6be00daca0b80aed94ec9680724f95e6be92e1 Use k5_transport(_strategy) enums for k5_sendto
-* d0be57ac45ea639baa3cff0dd2108c34e834bfa7 Build support for TLS used by HTTPS proxy support
+    d0be57ac45ea639baa3cff0dd2108c34e834bfa7 Build support for TLS used by HTTPS proxy support
-* bb89afd7c59deea855d2818fe36ef7472b4abf2e Add ASN.1 codec for KKDCP's KDC-PROXY-MESSAGE
+    bb89afd7c59deea855d2818fe36ef7472b4abf2e Add ASN.1 codec for KKDCP's KDC-PROXY-MESSAGE
-* 606e2ccc0a2546a23761f910482a55c5bf0f98ac Dispatch-style protocol switching for transport
+e2ccc0a2546a23761f910482a55c5bf0f98ac Dispatch-style protocol switching for transport
-* d950809ff49e3e7603594186d77135a09ab6b1b2 HTTPS transport (Microsoft KKDCPP implementation)
+    d950809ff49e3e7603594186d77135a09ab6b1b2 HTTPS transport (Microsoft KKDCPP implementation)
-* f220067c2969aab107bd1300ad1cb8d4855389a7 Load custom anchors when using KKDCP
+    f220067c2969aab107bd1300ad1cb8d4855389a7 Load custom anchors when using KKDCP
-* f7825e81b1ebf533c1dba9f84ae9ad36073a89cf Check names in the server's cert when using KKDCP
+    f7825e81b1ebf533c1dba9f84ae9ad36073a89cf Check names in the server's cert when using KKDCP
-* b52acabf478e8d1aa19f7823aade81eed1553143 Add some longer-form docs for HTTPS
+    b52acabf478e8d1aa19f7823aade81eed1553143 Add some longer-form docs for HTTPS
-* f78f8b1a46534db3a4547323ba952c1fa1b41fe9 Have k5test.py provide 'runenv' to python tests
+    f78f8b1a46534db3a4547323ba952c1fa1b41fe9 Have k5test.py provide 'runenv' to python tests
-* 142255ba9af4ce1016a8eadf147e599ee490f1f7 Add a simple KDC proxy test server
+ba9af4ce1016a8eadf147e599ee490f1f7 Add a simple KDC proxy test server
-* 3e2c7cc557048faac3400ae41b0228bd37a82a4c Add tests for MS-KKDCP client support
+e2c7cc557048faac3400ae41b0228bd37a82a4c Add tests for MS-KKDCP client support
 ==Release notes==

@@ Line 42: / Line 42: @@
 The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy.  Tests should include cases which succeed and cases in which the client rejects the server's certificate.
-==Review==
+==Discussions==
-===Approvals===
+==Commits==

← Older revision		Revision as of 23:12, 2 June 2014
Line 1:		Line 1:
−	{{project-~~early~~}}	+	{{project-rel\|1.13}}
−	{{project-target\|1.13}}

	==Overview==		==Overview==

@@ Line 30: / Line 30: @@
 * We will need to build against a cryptography library, and to add options to the build system for such.  We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).
-* In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll be ignoring the system-wide default trust store and adding `http_anchor', `http_revoke', and `http_require_crl_checking' options to krb5.conf.  These will function similarly to the similarly-named counterparts which were added for PKINIT:
+* In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll default to using the system-wide default trust store and adding an `http_anchor' option to krb5.conf to allow the location to be overridden.
-** Each will be read first from the realm-specific subsection of the `realms' section.  If no value for a setting is found, the library will look for a key of the same name in the `libdefaults' section of krb5.conf.  Unlike with PKINIT, it will not be looking at a realm-specific subsection of `libdefaults'.
+** The setting will be read from the realm-specific subsection of the `realms' section.
-** As with PKINIT, both anchor and CRL information can be specified using `FILE:', `DIR:', or `ENV:' prefixes to describe locations.
+** As with PKINIT, we can be describe  locations using `FILE:', `DIR:', or `ENV:' prefixes.
-* As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting.  Whether this requires an `http_hostname' option which works similarly to the `pkinit_kdc_hostname' option, when most HTTPS clients merely check for the name they extract from the URL they were given, is not yet determined.
+* As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting.
 ==Test Plan==

@@ Line 38: / Line 38: @@
 ==Test Plan==
-The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy.
+The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy.  Tests should include cases which succeed and cases in which the client rejects the server's certificate.
 ==Review==

← Older revision		Revision as of 21:47, 21 April 2014
Line 29:		Line 29:

	* We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).		* We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).
		+
		+	* In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll be ignoring the system-wide default trust store and adding `http_anchor', `http_revoke', and `http_require_crl_checking' options to krb5.conf. These will function similarly to the similarly-named counterparts which were added for PKINIT:
		+	** Each will be read first from the realm-specific subsection of the `realms' section. If no value for a setting is found, the library will look for a key of the same name in the `libdefaults' section of krb5.conf. Unlike with PKINIT, it will not be looking at a realm-specific subsection of `libdefaults'.
		+	** As with PKINIT, both anchor and CRL information can be specified using `FILE:', `DIR:', or `ENV:' prefixes to describe locations.
		+
		+	* As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting. Whether this requires an `http_hostname' option which works similarly to the `pkinit_kdc_hostname' option, when most HTTPS clients merely check for the name they extract from the URL they were given, is not yet determined.

	==Test Plan==		==Test Plan==

← Older revision		Revision as of 21:33, 21 April 2014
Line 32:		Line 32:
	==Test Plan==		==Test Plan==

−	Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.
		+	The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to test's KDC via the test's proxy.

	==Review==		==Review==

@@ Line 24: / Line 24: @@
 ==Implementation Design==
-* We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport.  The new syntax will look like this:
+* We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport.  The new syntax will look like this:
-  kdc = (http|https)://<kdc.addr>[:<port>][/<page>]
+  kdc = https://<proxy.addr>[:<port>][/<page>]
-Note that the syntax (and parser) does not change in the non-HTTP{,S} cases.  In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.
+Note that the syntax (and parser) does not change in the non-HTTPS cases.  In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport.  Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.
-* We will need to build against a cryptography library, and to add options to the build system for such.  We will include an option to disable HTTPS support (i.e., build against no cryptographic library).
+* We will need to build against a cryptography library, and to add options to the build system for such.  We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).
 ==Test Plan==

@@ Line 20: / Line 20: @@
 ==Implementation Process==
-An HTTPS transport will be implemented.  Some of the client library's internal send-to-kdc logic will be refactored to make adding new transports (such as a possible HTTP transport to be added later) less disruptive.  The HTTPS transport will follow Microsoft's specification.  We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.
+An HTTPS transport will be implemented.  Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward.  The HTTPS transport implementation will follow Microsoft's specification.  We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.
 ==Implementation Design==