Projects/HTTP Transport

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

This project is targeted at release 1.13.

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. 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.

Microsoft

Microsoft has documented their mechanism, MS-KKDCPP, 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 "KERB-REALM" is 0x1B.

Implementation Process

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.

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 = (http|https)://<kdc.addr>[:<port>][/<page>]

Note that the syntax (and parser) does not change in the non-HTTP{,S} cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.

• 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).

Test Plan

Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

(hash mark followed by four tilde characters) on its own line. 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 {{project-block}}.

Discussion

The first version had comments from mail from ghudson, which we attempted to address.