Projects/HTTP Transport
Contents
Overview
This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 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-KKDCP, 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, as Microsoft's implementation does not work over plain HTTP.
Implementation Process
An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.
Implementation Design
- We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:
kdc = https://<proxy.addr>[:<port>][/<page>]
Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.
- We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).
- In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll be ignoring the system-wide default trust store and adding `http_anchor', `http_revoke', and `http_require_crl_checking' options to krb5.conf. These will function similarly to the similarly-named counterparts which were added for PKINIT:
- Each will be read first from the realm-specific subsection of the `realms' section. If no value for a setting is found, the library will look for a key of the same name in the `libdefaults' section of krb5.conf. Unlike with PKINIT, it will not be looking at a realm-specific subsection of `libdefaults'.
- As with PKINIT, both anchor and CRL information can be specified using `FILE:', `DIR:', or `ENV:' prefixes to describe locations.
- As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting. Whether this requires an `http_hostname' option which works similarly to the `pkinit_kdc_hostname' option, when most HTTPS clients merely check for the name they extract from the URL they were given, is not yet determined.
Test Plan
The self-tests will be expanded to make use of a locally-installed copy of kdcproxy to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy.
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}}.
Approvals
Discussion
The first version had comments from mail from ghudson, which we attempted to address.
