<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://k5wiki.test.kerberos.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Rharwood</id>
		<title>K5Wiki - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://k5wiki.test.kerberos.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Rharwood"/>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki/Special:Contributions/Rharwood"/>
		<updated>2026-05-14T20:07:36Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.27.4</generator>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/KDC_Discovery&amp;diff=5811</id>
		<title>Projects/KDC Discovery</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/KDC_Discovery&amp;diff=5811"/>
				<updated>2017-04-26T15:59:58Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: /* Examples */ krb5kdc -&amp;gt; kerberos&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-rel|1.15}}&lt;br /&gt;
&lt;br /&gt;
This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type.&lt;br /&gt;
&lt;br /&gt;
The current method of KDC discovery using DNS SRV records has the following drawbacks:&lt;br /&gt;
&lt;br /&gt;
* Only UDP and TCP protocols can be specified&lt;br /&gt;
* Multiple queries are needed to discover both protocol records&lt;br /&gt;
* The DNS administrator has no influence on client protocol use&lt;br /&gt;
&lt;br /&gt;
==Design==&lt;br /&gt;
&lt;br /&gt;
The client performs a DNS lookup for one or more of the following URI records:&lt;br /&gt;
* _kerberos-adm.REALM (Admin service)&lt;br /&gt;
* &amp;lt;strike&amp;gt;_krb5kdc.REALM (KDC)&amp;lt;/strike&amp;gt; Changed to: _kerberos.REALM (KDC) in code and draft&lt;br /&gt;
* _kpasswd.REALM (Password service)&lt;br /&gt;
&lt;br /&gt;
The URI record includes a priority and weight, and contains a URI string of the krb5srv scheme name, flags, transport, and target (containing optional port and path) fields, separated by colons. &lt;br /&gt;
&lt;br /&gt;
* krb5srv:[flags]:transport:host[:port][/path]&lt;br /&gt;
&lt;br /&gt;
The priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.&lt;br /&gt;
&lt;br /&gt;
The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.&lt;br /&gt;
&lt;br /&gt;
The transport field indicates the transport type for the given host address. It can be either &amp;quot;tcp&amp;quot;, &amp;quot;udp&amp;quot;, or &amp;quot;kkdcp&amp;quot; for MS-KKDCP.&lt;br /&gt;
&lt;br /&gt;
The host field in the udp and tcp transport cases can be a hostname, IPv4 address, or bracket-enclosed IPv6 address, and can be followed by a port extension. A host for the MS-KKDCP transport type uses a https:// URL, and can include a port and/or path extension. &lt;br /&gt;
&lt;br /&gt;
Discovery using this new method should be attempted before searching SRV records.&lt;br /&gt;
&lt;br /&gt;
==Examples==&lt;br /&gt;
&lt;br /&gt;
* _kerberos IN URI 10 1 &amp;lt;nowiki&amp;gt;&amp;quot;krb5srv:M:kkdcp:https://kdc.example.com/path&amp;quot;&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
* _kerberos IN URI 20 1 &amp;lt;nowiki&amp;gt;&amp;quot;krb5srv::kkdcp:https://kdc2.example.com&amp;quot;&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
* _kerberos-adm IN URI 10 1 &amp;quot;krb5srv::tcp:192.168.1.20:1333&amp;quot;&lt;br /&gt;
&lt;br /&gt;
==Implementation==&lt;br /&gt;
&lt;br /&gt;
src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format. &lt;br /&gt;
&lt;br /&gt;
==Resources==&lt;br /&gt;
&lt;br /&gt;
* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02&lt;br /&gt;
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html&lt;br /&gt;
&lt;br /&gt;
* KDC Discovery may fail with URI entries served by RHEL7 bind: https://bugzilla.redhat.com/show_bug.cgi?id=1388534&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/KDC_Discovery&amp;diff=5810</id>
		<title>Projects/KDC Discovery</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/KDC_Discovery&amp;diff=5810"/>
				<updated>2017-04-26T15:57:56Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: /* Design */ update kdc record format&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-rel|1.15}}&lt;br /&gt;
&lt;br /&gt;
This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type.&lt;br /&gt;
&lt;br /&gt;
The current method of KDC discovery using DNS SRV records has the following drawbacks:&lt;br /&gt;
&lt;br /&gt;
* Only UDP and TCP protocols can be specified&lt;br /&gt;
* Multiple queries are needed to discover both protocol records&lt;br /&gt;
* The DNS administrator has no influence on client protocol use&lt;br /&gt;
&lt;br /&gt;
==Design==&lt;br /&gt;
&lt;br /&gt;
The client performs a DNS lookup for one or more of the following URI records:&lt;br /&gt;
* _kerberos-adm.REALM (Admin service)&lt;br /&gt;
* &amp;lt;strike&amp;gt;_krb5kdc.REALM (KDC)&amp;lt;/strike&amp;gt; Changed to: _kerberos.REALM (KDC) in code and draft&lt;br /&gt;
* _kpasswd.REALM (Password service)&lt;br /&gt;
&lt;br /&gt;
The URI record includes a priority and weight, and contains a URI string of the krb5srv scheme name, flags, transport, and target (containing optional port and path) fields, separated by colons. &lt;br /&gt;
&lt;br /&gt;
* krb5srv:[flags]:transport:host[:port][/path]&lt;br /&gt;
&lt;br /&gt;
The priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.&lt;br /&gt;
&lt;br /&gt;
The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.&lt;br /&gt;
&lt;br /&gt;
The transport field indicates the transport type for the given host address. It can be either &amp;quot;tcp&amp;quot;, &amp;quot;udp&amp;quot;, or &amp;quot;kkdcp&amp;quot; for MS-KKDCP.&lt;br /&gt;
&lt;br /&gt;
The host field in the udp and tcp transport cases can be a hostname, IPv4 address, or bracket-enclosed IPv6 address, and can be followed by a port extension. A host for the MS-KKDCP transport type uses a https:// URL, and can include a port and/or path extension. &lt;br /&gt;
&lt;br /&gt;
Discovery using this new method should be attempted before searching SRV records.&lt;br /&gt;
&lt;br /&gt;
==Examples==&lt;br /&gt;
&lt;br /&gt;
* _krb5kdc IN URI 10 1 &amp;lt;nowiki&amp;gt;&amp;quot;krb5srv:M:kkdcp:https://kdc.example.com/path&amp;quot;&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
* _krb5kdc IN URI 20 1 &amp;lt;nowiki&amp;gt;&amp;quot;krb5srv::kkdcp:https://kdc2.example.com&amp;quot;&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
* _kerberos-adm IN URI 10 1 &amp;quot;krb5srv::tcp:192.168.1.20:1333&amp;quot;&lt;br /&gt;
&lt;br /&gt;
==Implementation==&lt;br /&gt;
&lt;br /&gt;
src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format. &lt;br /&gt;
&lt;br /&gt;
==Resources==&lt;br /&gt;
&lt;br /&gt;
* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02&lt;br /&gt;
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html&lt;br /&gt;
&lt;br /&gt;
* KDC Discovery may fail with URI entries served by RHEL7 bind: https://bugzilla.redhat.com/show_bug.cgi?id=1388534&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5209</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5209"/>
				<updated>2013-08-23T17:28:17Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: /* Microsoft */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-early}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though Microsoft's implementation does not work over plain HTTP.  The tag used for a &amp;quot;KERB-REALM&amp;quot; is 0x1B.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTPS transport will be implemented first, followed optionally by HTTP transport.  We will implement HTTPS transport that corresponds to Microsoft's specification.  We will implement OpenSSL support initially and optionally may add NSS support at a later date.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;br /&gt;
The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5208</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5208"/>
				<updated>2013-08-23T17:27:10Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: Address current state of MSFT.&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-early}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though Microsoft's implementation does not work over plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTPS transport will be implemented first, followed optionally by HTTP transport.  We will implement HTTPS transport that corresponds to Microsoft's specification.  We will implement OpenSSL support initially and optionally may add NSS support at a later date.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;br /&gt;
The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5207</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5207"/>
				<updated>2013-08-23T17:22:47Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-early}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;br /&gt;
From [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson]:&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Should remove the tcp: and udp: specifiers from the `kdc` configuration line and write a separate case for http: and https: instead of trying to integrate them&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Switch to non-portable socket enumerator to portable protocol enumerator&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Remove cut-and-paste between service_tcp_fd and service_http_fd in favor of more careful design&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5194</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5194"/>
				<updated>2013-08-12T21:05:03Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: /* Discussion */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;br /&gt;
From [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson]:&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Should remove the tcp: and udp: specifiers from the `kdc` configuration line and write a separate case for http: and https: instead of trying to integrate them&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Switch to non-portable socket enumerator to portable protocol enumerator&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Remove cut-and-paste between service_tcp_fd and service_http_fd in favor of more careful design&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5193</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5193"/>
				<updated>2013-08-12T21:04:46Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: /* Discussion */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;br /&gt;
From [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson]:&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Should remove the tcp: and udp: specifiers from the `kdc` configuration line and write a separate case for http: and https: instead of trying to integrate them (-ghudson)&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Switch to non-portable socket enumerator to portable protocol enumerator (-ghudson)&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Remove cut-and-paste between service_tcp_fd and service_http_fd in favor of more careful design (-ghudson)&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5192</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5192"/>
				<updated>2013-08-12T20:54:37Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: /* Review */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;br /&gt;
From [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson]:&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Should document which Kerberos-over-HTTP protocol it implements (-ghudson)&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Should remove the tcp: and udp: specifiers from the `kdc` configuration line and write a separate case for http: and https: instead of trying to integrate them (-ghudson)&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Switch to non-portable socket enumerator to portable protocol enumerator (-ghudson)&lt;br /&gt;
&lt;br /&gt;
* {{project-block}} Remove cut-and-paste between service_tcp_fd and service_http_fd in favor of more careful design (-ghudson)&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5191</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5191"/>
				<updated>2013-08-12T20:42:09Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5190</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5190"/>
				<updated>2013-08-12T20:41:08Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;] | (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;])&lt;br /&gt;
that is, a separate portion of the parser to handle HTTP/HTTPS with the rest of the parser unchanged.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5189</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5189"/>
				<updated>2013-08-12T20:36:06Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;] | (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;])&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5188</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5188"/>
				<updated>2013-08-12T20:35:49Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = (&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;] | (http|https)://&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5187</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5187"/>
				<updated>2013-08-12T20:33:22Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in active deployment.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, though it is not known whether it will respond to plain HTTP.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = [(tcp|udp|http|https)://]&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5186</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5186"/>
				<updated>2013-08-12T20:25:40Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = [(tcp|udp|http|https)://]&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5185</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5185"/>
				<updated>2013-08-12T20:24:28Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
Microsoft has documented their mechanism, which they have dubbed MS-KKDCPP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = [(tcp|udp|http|https)://]&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5184</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5184"/>
				<updated>2013-08-12T20:16:03Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
The existence of Microsoft's mechanism can be seen [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = [(tcp|udp|http|https)://]&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current working protocol for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.  Preliminary testing suggests that this is not what Microsoft uses, but the server isn't particularly chatty about errors.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5183</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5183"/>
				<updated>2013-08-12T20:07:48Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: open review&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-review|2013-08-22}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
The existence of Microsoft's mechanism can be seen [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = [(tcp|udp|http|https)://]&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current belief is that the specification for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;br /&gt;
&lt;br /&gt;
==Review==&lt;br /&gt;
&lt;br /&gt;
This section documents the review of the project according to [[Project policy]].&lt;br /&gt;
It  is divided into multiple sections.  First, approvals should be listed.  To list an approval type&lt;br /&gt;
:&amp;lt;nowiki&amp;gt;#~~~~&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
(hash mark followed by four tilde characters) on its own line.&lt;br /&gt;
The next section is for summarizing discussion, which should take place on krbdev@mit.edu.  Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate.  Blocking objections can be noted with &amp;lt;nowiki&amp;gt;{{project-block}}&amp;lt;/nowiki&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
===Approvals===&lt;br /&gt;
&lt;br /&gt;
===Discussion===&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5182</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5182"/>
				<updated>2013-08-12T20:05:38Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-early}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
The existence of Microsoft's mechanism can be seen [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;br /&gt;
&lt;br /&gt;
==Implementation Process==&lt;br /&gt;
&lt;br /&gt;
HTTP transport will be implemented first, followed by HTTPS transport.  We prefer Microsoft interoperability to Heimdal interoperability because despite the added complexity we feel it to be more in keeping with the HTTP specification.  We will implement HTTP and HTTPS transports that correspond to our interpretation of Microsoft's specification.  Parallel to implementation, we will attempt to set up a Microsoft KDC with proxying enabled so that we can test our implementation.  For HTTPS transportation, we will first implement OpenSSL support, with NSS support to follow.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
* 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:&lt;br /&gt;
  kdc = [(tcp|udp|http|https)://]&amp;lt;kdc.addr&amp;gt;[:&amp;lt;port&amp;gt;][/&amp;lt;page&amp;gt;]&lt;br /&gt;
where &amp;lt;page&amp;gt; is meaningless when the protocol is not TCP or UDP.  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.&lt;br /&gt;
&lt;br /&gt;
* 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).&lt;br /&gt;
&lt;br /&gt;
As we have not yet been able to examine traffic from a Microsoft KDC with proxy enabled, our current belief is that the specification for traffic is: POST request to /KdcProxy with body consisting of the base64-encoded version of the Kerberos request, with response from the MS-KKDCP consisting of the base64-encoding of the KDC's reply.&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  Instead, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5181</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5181"/>
				<updated>2013-08-12T19:37:26Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-early}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
The existence of Microsoft's mechanism can be seen [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;br /&gt;
&lt;br /&gt;
==Implementation Design==&lt;br /&gt;
&lt;br /&gt;
==Test Plan==&lt;br /&gt;
&lt;br /&gt;
Due to the nature of the changes, it will be extremely difficult to write test cases for the new code.  To combat this, code has been written to implement the &amp;quot;other side&amp;quot; (on the KDC-end) of HTTP/HTTPS transport as a reference implementation.  That code, including its implementation of the client-end of the HTTP/HTTPS pipe, can be found [https://github.com/frozencemetery/krb-proxies here].&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	<entry>
		<id>https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5180</id>
		<title>Projects/HTTP Transport</title>
		<link rel="alternate" type="text/html" href="https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&amp;diff=5180"/>
				<updated>2013-08-12T19:33:58Z</updated>
		
		<summary type="html">&lt;p&gt;Rharwood: New page: {{project-early}}  ==Overview==  This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic ...&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{project-early}}&lt;br /&gt;
&lt;br /&gt;
==Overview==&lt;br /&gt;
&lt;br /&gt;
This project intends to add HTTP and HTTPS transport to Kerberos traffic.  This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.&lt;br /&gt;
&lt;br /&gt;
==Precedent==&lt;br /&gt;
&lt;br /&gt;
Both Heimdal and Microsoft Kerberos have such a technology.&lt;br /&gt;
&lt;br /&gt;
===Heimdal===&lt;br /&gt;
&lt;br /&gt;
Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here].  It uses a GET request with a base64-encoded version of the UDP traffic.  This is not particularly in keeping with the HTTP specification, since a GET request should not incur change to the server.  Additionally, Apache has a URL length for GET of about 4000 characters, and requests of this nature come too close to that length limit for comfort.  It uses a separate field in krb5.conf for specification of the http_proxy to be used.  There is almost no evidence of this in use in the wild.&lt;br /&gt;
&lt;br /&gt;
===Microsoft===&lt;br /&gt;
&lt;br /&gt;
The existence of Microsoft's mechanism can be seen [http://msdn.microsoft.com/en-us/library/hh553774.aspx here].  It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also uses HTTPS, though it is not known whether this is required.&lt;/div&gt;</summary>
		<author><name>Rharwood</name></author>	</entry>

	</feed>