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
Hi,
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".
surely you mean Kerberos over EAP ? :-) alan
Hello Everyone, FreeRadius have some function to recconect clients after X days for example? I ask because yesterday many of my customers recconect without any action, at the same time. Looking in Acct-Status-Type I have "User-Request" Thanks Aurélio
On Apr 5, 2016, at 7:54 AM, Aurélio de Souza Ribeiro Neto <netolistas@mpc.com.br> wrote:
FreeRadius have some function to recconect clients after X days for example?
The RADIUS protocol doesn't allow for that.
I ask because yesterday many of my customers recconect without any action, at the same time.
That's normal. You have to design your systems to cope with that load.
Looking in Acct-Status-Type I have "User-Request"
And read the RFCs to see what it means. Alan DeKok.
On 4 Apr 2016, at 15:24, Rick van Rein <rick@openfortress.nl> wrote:
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).
I think EAP-Kerberos would be useful to bootstrap kerberos SSO during network login. I've been waiting for someone to come up with standard for this for 10 years :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Aurélio de Souza Ribeiro Neto -
Rick van Rein