Kerberos authentication for IMAP?

[Donn Cave]

Quoth martin at v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=):
| Alan Hoyle <alanh at unc.edu> writes:
|...
|> Which seems a bit more promising than the how can I set this up to use
|> my Kerberos tokens or TGT? 
|
| The tricky part is, perhaps, to fetch the token from the ticket
| cache. This would normally require wrappig the Kerberos library as a
| Python module, which hasn't been done for Kerberos 4; perhaps you
| could adapt
|
| http://starship.python.net/crew/fdrake/manuals/krb5py/
| http://pygss.sourceforge.net/

I'm sure it will take a Kerberos 4 module.  If 4 is anything like 5,
there are API functions to create and negotiate the authentication data
and you'd want to use them.  The Python imaplib part is there just to
get the data across the network through the IMAP protocol.  I've never
heard of a krb4 module, but I could imagine the author of such a thing
failing to appreciate that others would be interested (as I suppose
few would be - your IMAP server supports Kerberos 4 and not SSL?
Have you been borrowing Guido's time machine?)  

| Alternatively, you could try invoking command line utilities, and try
| to generate an authenticator from that.

Hm, I believe it would be much easier to write the IMAP component
of this email tool in some language (C) that can call the krb4 API.
Like fetchmail, which for all I know may already support krb4.
The shell script that invokes it could also invoke the spam filter,
assuming that's an external component.

Anyway, supposing that the krb4 module is ready to go ... The imaplib
authenticate function deals with the AUTHENTICATE command, 6.2.2 in
the IMAP4 RFC 3501, which is more generically a SASL implementation.
The authentication object is your responsibility to write, as the
author of a Kerberos 4 IMAP authentication plugin for imaplib.  It will
have to figure out who you are, and the name of the remote service, in
terms of Kerberos principals, and do whatever initial processing the
krb4 API calls for.  This can happen when the object is initialized,
and may create some initial data for the SASL exchange.

When the object is invoked (cf. __call__ standard special method),
its parameter is decoded data from the SASL exchange.  Feed that
into the negotiation, and return the result data.  Maybe there will
be no data from the server to start with, and if that's what you expect
then you may just ignore the input parameter at that point.  I doubt
you can know how to write this without looking at the source of the
IMAP service implementation, unless it's better documented than usual.
There may very likely be more to it than just plain krb4 authentication -
the server may need some additional data identifying the to-be-authorized
remote user, as opposed to the to-be-authenticated Kerberos principal,
for example.

	Donn Cave, donn at u.washington.edu