Projects/Python Kerberos for testing - Revision history

Ghudson at 16:00, 22 November 2013

2013-11-22T16:00:26Z

Ghudson: /* Stages */

2013-11-19T17:37:22Z

‎Stages

Ghudson: /* Stages */

2013-11-17T22:35:10Z

‎Stages

Ghudson: /* Stages */

2013-10-17T21:36:30Z

‎Stages

Ghudson: /* Stages */

2013-10-04T15:02:12Z

‎Stages

Ghudson: New page: {{project-early}} ==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 cann...

2013-10-04T15:01:39Z

New page: {{project-early}} ==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 cann...

New page

{{project-early}}

==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:
* {{rfcref|3961}} crypto operations using PyCrypto
* ASN.1 encoding of {{rfcref|4120}} using pyasn1
* KDC tests (TBD: what specifically can we test that we couldn't before?)

Stage 2:
* [[http://msdn.microsoft.com/en-us/library/cc246071(PROT.13).aspx 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.

@@ Line 39: / Line 39: @@
 * KDC tests:
 ** Non-FAST TGS requests
 ** Invalid KDC requests (e.g. a TGS request with no AP-REQ padata)
 ** Unusual TCP segmentation

@@ Line 40: / Line 40: @@
 ** Non-FAST TGS requests
 ** Invalid KDC requests (e.g. a TGS request with no AP-REQ padata)
 ** (TBD: what other KDC behavior can we exercise?)

@@ Line 37: / Line 37: @@
 * ASN.1 encoding of {{rfcref|4120}} protocol units using pyasn1
 * {{rfcref|4120}} client operations
 Stage 2:

@@ Line 44: / Line 44: @@
 Stage 3:
-* Alternate KDC using caller-provided DB and policy
+* Python KDC using caller-provided DB and policy
 * libkrb5 client tests (TBD: what specifically?)

@@ Line 35: / Line 35: @@
 Stage 1:
 * {{rfcref|3961}} crypto operations using PyCrypto
-* ASN.1 encoding of {{rfcref|4120}} using pyasn1
+* ASN.1 encoding of {{rfcref|4120}} protocol units using pyasn1
 * KDC tests (TBD: what specifically can we test that we couldn't before?)