Difference between revisions of "Projects/Python Kerberos for testing"

Revision as of 10:02, 4 October 2013

Description

The automated test suite for MIT krb5 has significantly improved in coverage over the past few years. Still, there are many code branches which we cannot easily test because they depend on specific behaviors from a counterparty which we do not manifest--either protocol violations which must cause graceful failures, or behaviors of other implementations with which we must interoperate.

The goal of this project is to create a highly malleable Python-based implementation of the Kerberos protocol which can be used to augment our test suite. This project has no user-visible footprint apart from the potential for a higher-quality product; there is no intention to create a new supported implementation of Kerberos.

Scope

In scope:

• Malleability: interfaces should be available at all abstraction levels. A caller should be able to request unusual or invalid behavior when creating a protocol data unit. A caller should be able to create a lower-level unit and use it within a higher-level operation--for instance, a caller should be able to create a krb5 GSSAPI initiator request using an AP-REQ it created earlier.

• Internal documentation: this must be documented well enough for MIT krb5 developers to be able to use it for test scripts.

Out of scope:

• Stable interfaces: we retain the freedom to modify interfaces in incompatible ways.

• Compatibility: the Python implementation has no requirement to conform to any existing interfaces.

• Configuration: all behavior decisions will be driven by the caller, not by any kind of configuration file.

• Performance: the implementation must only have acceptable performance for the automated test suite, not for any kind of production scenario.

• Testing: the Python implementation will be used to test the MIT krb5 C implementation, but does not itself need to be tested.

• End-user documentation: no end users are not intended to use the Python implementation, so it does not need to be documented for anyone but internal developers.

Stages

This project is broken down into stages to make it more manageable. The first stage is the minimal core of this project; other stages can be shuffled around.

Stage 1:

• RFC 3961 crypto operations using PyCrypto
• ASN.1 encoding of RFC 4120 protocol units using pyasn1
• RFC 4120 client operations
• KDC tests (TBD: what specifically can we test that we couldn't before?)

Stage 2:

• [MS-S4U] encoders and client operations
• S4U tests (TBD: what specifically?)

Stage 3:

• Alternate KDC using caller-provided DB and policy
• libkrb5 client tests (TBD: what specifically?)

Stage 4:

• GSSAPI krb5
• GSSAPI SPNEGO with krb5 as a supported mech
• GSSAPI IAKERB
• GSSAPI initiator and acceptor tests (TBD: what specifically?)

Stage 5:

• GSSRPC using xdrlib
• kadmin client and server tests (TBD: what specifically?)

Stage 6:

• Writing ccache, keytab, and rcache files
• ccache/keytab/rcache tests (TBD: what specifically?)

Issues

If this project is used widely by the test suite, then large portions of the test suite will rely on pycrypto and pyasn1 being installed. We may need to pay more attention to the problem of documenting optional test suite dependencies and prominently calling out what optional dependencies are missing when "make check" is run.

Mailing list discussions

Commits

Release notes

This project has no user-visible footprint and therefore no release notes.