I-D for a new method: EAP-Kerberos

[Rick van Rein]

Hi,

> for ANY method that requires a password that goes through another system, the password
> is known for the server agent - thats just how things are. 

Sure, but it's rarely as devastating as in the case of Kerberos, where it also implies decryption capability of all private traffic.  Passing the Kerberos password through a 3rd party system is highly dis-advised within the Kerberos security model.  Also, I don't think we should take this undesirable situation as a fait accompli if there are straightforward manners of doing this in a way that raises less security concerns.  What is acceptable to some under a pragmatic attitude is unacceptable in other situations, e.g. when spreading functions over network partners.

> work is already done for EAP kerberos - along with some other reuqiremens such as 
> server security pinning - I would suggest that you read the ABFAB IETF stuff
> - 'Project Moonshot' was its original name - there is working software and FreeRADIUS 3
> does it, for example

I know ABFAB, and it is completely different from what I propose; it embeds EAP in GSS-API (making EAP an alternative to Kerberos5) while I'm proposing that EAP should carry Kerberos as one of its authentication methods (thereby following the line of thought underpinning EAP).  The only relation with ABFAB is that it would be possible in theory to choose between GSS-API / Kerberos5 and GSS-API / EAP / Kerberos layerings (the latter of which would be silly).

However, I did get a response from a similar piece of work by the Uni of Madrid, which does indeed implement EAP over Kerberos.  I have the related I-D work on my reading list now; it is not yet clear inhowfar their method can be called a "standard" or "working code".


Cheers,
 -Rick