Creating a new pre-authentication plugin
Alejandro Perez Mendez
alex at um.es
Wed Aug 1 13:45:14 EDT 2012
El 01/08/12 17:16, Greg Hudson escribió:
> On 08/01/2012 04:06 AM, Alejandro Perez Mendez wrote:
>> Is there any coding
>> guidelines available for pre-authentication plugin developers, or for
>> MIT Kerberos developers in general (i.e. how to format the code, how to
>> comment the code...)?
> Please see:
Thank you, I will.
> For a project like this, I would strongly suggest beginning with a
> project proposal, so you can get design review before you put a lot of
> effort into code. To do that, you'll need to get a wiki account, which
> for spam-related reasons isn't automatic. Send your preferred account
> name to tlyu at mit.edu and he should be able to set that up.
Seems reasonable. I already starting coding, but I can upload there my
design and thoughts about this.
> Some issues I would expect to see for this project include:
> * I don't believe our current preauth plugin framework supports multiple
> hops; it would need to be extended.
Indeed it does not. But I already patched it locally in my working copy.
It just needed a couple of lines to be modified (I will include the
patch into the wiki).
> * KDC statelessness is a serious concern for us, just as it was within
> the IETF working group. The draft argues that the KDC should not be
> considered "stateful" because the state lies within the GSSAPI objects,
> but that position does not resolve the practical issues which give rise
> to the statelessness requirement.
That's something still under discussion into the IETF, though in the
last discussion we more or less agreed that it would be something
depending on how the GSS-API is implemented. From a specification point
of view, the state is GSSAPI's responsibility.
If we assume the GSS-API is linked statically and locally with the KDC
process, meaning that when the KDC process stops, all the GSS-API is
lost, I can only think on two problematic situations:
1) The client tries to continue the pre-authentication with a different
KDC: I haven't checked it yet, but seems reasonable that try_again()
function uses the existing socket to send the subsequent AS_REQ
messages, thus resulting into the client going to the exact same KDC.
Thus this situation would be avoided in MIT KRB.
2) The KDC process is killed and restarted at the middle of a
pre-authentication process. Two possible reasons:
a) The KDC is stopped from time to time due to administrative
reasons, system failure... In this case, the client tries to
continue the pre-authentication process resulting into an error
because the GSS Context no longer exists. Thus the client starts the
pre-authenticaiton process again, resulting SUCCESSFUL.
b) The KDC is stopped after generating every response (not optimized
xinitd). This situation may be the most problematic. But, again, as
is a matter on how it is implemented, I think that including an
indication that GSS-Preauth is not compatible with such deployments
would be ok.
> * How can we test this with good code coverage as part of "make check"?
I don't know anything about your test suite yet. That's one of the
things I wanted to learn.
> * How do we prevent loops where the client attempts to use gss-krb5 to
> satisfy the preauth mechanism and that devolves into another AS request?
I thought gss-krb5 never resulted into AS_REQ message sent to the KDC,
just into TGS_REQ requests. In the tests I have performed, when you
don't have a TGT and try to use gss-krb5 (e.g. ssh user at host), it does
not results into AS_REQ/AS_REP, but into a "credentials not found".
As a matter of fact, I think one may want to use a KRB ticket from KDC1
to be authenticated with KDC2, using GSS-preauth (though this is kind of
weird solution to bypass cross-real). Anyway, that's not a goal of this
Other solution could be just forbidding specific mech OIDs from being
selected for pre-authentication.
More information about the krbdev