Creating a new pre-authentication plugin

[Alejandro Perez Mendez]

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:
>
> http://k5wiki.kerberos.org/wiki/Contributing_code
> http://k5wiki.kerberos.org/wiki/Coding_style

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". 
Isn't it?

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 
proposal.

Other solution could be just forbidding specific mech OIDs from being 
selected for pre-authentication.

Regards,
Alejandro