Difference between revisions of "Projects/HTTP Transport"
| Line 16: | Line 16: | ||
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. |
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. |
||
| + | |||
| + | ==Implementation Process== |
||
| + | |||
| + | 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. |
||
==Implementation Design== |
==Implementation Design== |
||
| + | |||
| + | * We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this: |
||
| + | kdc = [(tcp|udp|http|https)://]<kdc.addr>[:<port>][/<page>] |
||
| + | where <page> 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. |
||
| + | |||
| + | * 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). |
||
| + | |||
| + | 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. |
||
==Test Plan== |
==Test Plan== |
||
| − | Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. |
+ | 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 "other side" (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]. |
Revision as of 15:05, 12 August 2013
Contents
Overview
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.
Precedent
Both Heimdal and Microsoft Kerberos have such a technology.
Heimdal
Heimdal has such a mechanism 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.
Microsoft
The existence of Microsoft's mechanism can be seen 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.
Implementation Process
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.
Implementation Design
- We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:
kdc = [(tcp|udp|http|https)://]<kdc.addr>[:<port>][/<page>]
where <page> 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.
- 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).
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.
Test Plan
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 "other side" (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 here.
