-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think this discussion deserves wider exposure, so I'm forwarding it to the sssd-devel list.
This pertains to https://fedorahosted.org/sssd/ticket/237 - Kerberos client functionality should be able to use FAST if available
- -------- Original Message -------- Subject: On FAST support in SSSD Date: Thu, 28 Jan 2010 17:19:09 -0500 From: Nalin Dahyabhai nalin@redhat.com Organization: Red Hat, Inc. To: Stephen Gallagher sgallagh@redhat.com
Stephen, I took a closer look at it, and here's what I can tell you:
FAST uses a previously-obtained ticket, and an authenticator that's built using it, to encrypt AS requests and replies traded between the client and the KDC. This yields a few useful benefits: * The entire AS exchange is encrypted: eavesdroppers have to crack the armor ticket's key to even figure out who the client of the AS request is. Additionally, as the ticket's key is usually random rather than password-based, so dictionary attacks should be harder. * If the armor ticket was issued by a KDC whose identity was verified, then the AS reply is also verified (for example, the armor ticket could have been obtained using PKINIT, in which the client can verify the KDC's identity using the KDC's certificate). * The client and KDC can jointly select a key which is not based on the client's long-term password. * The authentication can be performed with a mechanism that doesn't yield a key, for example with an OTP token (in the current draft, the key used for encrypting the TGT is based on the armor key, possibly in combination with the OTP token).
In the implementation we use, when the client software calls krb5_get_init_creds_opt_set_fast_ccache_name() to set the location of a ccache containing a suitable ticket, before calling krb5_get_init_creds_password(), the client uses FAST. If the client tries to use FAST and the server doesn't support it, then the client will treat that as an error and fail to obtain a TGT.
If SSSD already has a credential cache when it goes to obtain a TGT for a user, this is probably a trivial addition, but I'd suggest it not be turned on by default. Hopefully it'd be available as an option for situations where it's already known that the KDC supports FAST (either beforehand or out-of-band, most likely).
HTH,
Nalin
Stephen Gallagher wrote:
I think this discussion deserves wider exposure, so I'm forwarding it to the sssd-devel list.
This pertains to https://fedorahosted.org/sssd/ticket/237 - Kerberos client functionality should be able to use FAST if available
-------- Original Message -------- Subject: On FAST support in SSSD Date: Thu, 28 Jan 2010 17:19:09 -0500 From: Nalin Dahyabhai nalin@redhat.com Organization: Red Hat, Inc. To: Stephen Gallagher sgallagh@redhat.com
Stephen, I took a closer look at it, and here's what I can tell you:
FAST uses a previously-obtained ticket, and an authenticator that's built using it, to encrypt AS requests and replies traded between the client and the KDC. This yields a few useful benefits:
- The entire AS exchange is encrypted: eavesdroppers have to crack the
armor ticket's key to even figure out who the client of the AS request is. Additionally, as the ticket's key is usually random rather than password-based, so dictionary attacks should be harder.
- If the armor ticket was issued by a KDC whose identity was
verified, then the AS reply is also verified (for example, the armor ticket could have been obtained using PKINIT, in which the client can verify the KDC's identity using the KDC's certificate).
- The client and KDC can jointly select a key which is not based on
the client's long-term password.
- The authentication can be performed with a mechanism that doesn't
yield a key, for example with an OTP token (in the current draft, the key used for encrypting the TGT is based on the armor key, possibly in combination with the OTP token).
In the implementation we use, when the client software calls krb5_get_init_creds_opt_set_fast_ccache_name() to set the location of a ccache containing a suitable ticket, before calling krb5_get_init_creds_password(), the client uses FAST. If the client tries to use FAST and the server doesn't support it, then the client will treat that as an error and fail to obtain a TGT.
If SSSD already has a credential cache when it goes to obtain a TGT for a user, this is probably a trivial addition, but I'd suggest it not be turned on by default. Hopefully it'd be available as an option for situations where it's already known that the KDC supports FAST (either beforehand or out-of-band, most likely).
HTH,
Nalin
I think we should do it for Fedora 14.
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, Feb 01, 2010 at 01:28:09PM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think this discussion deserves wider exposure, so I'm forwarding it to the sssd-devel list.
This pertains to https://fedorahosted.org/sssd/ticket/237 - Kerberos client functionality should be able to use FAST if available
- -------- Original Message --------
Subject: On FAST support in SSSD Date: Thu, 28 Jan 2010 17:19:09 -0500 From: Nalin Dahyabhai nalin@redhat.com Organization: Red Hat, Inc. To: Stephen Gallagher sgallagh@redhat.com
Stephen, I took a closer look at it, and here's what I can tell you:
FAST uses a previously-obtained ticket, and an authenticator that's built using it, to encrypt AS requests and replies traded between the client and the KDC. This yields a few useful benefits:
- The entire AS exchange is encrypted: eavesdroppers have to crack the armor ticket's key to even figure out who the client of the AS request is. Additionally, as the ticket's key is usually random rather than password-based, so dictionary attacks should be harder.
- If the armor ticket was issued by a KDC whose identity was verified, then the AS reply is also verified (for example, the armor ticket could have been obtained using PKINIT, in which the client can verify the KDC's identity using the KDC's certificate).
- The client and KDC can jointly select a key which is not based on the client's long-term password.
- The authentication can be performed with a mechanism that doesn't yield a key, for example with an OTP token (in the current draft, the key used for encrypting the TGT is based on the armor key, possibly in combination with the OTP token).
In the implementation we use, when the client software calls krb5_get_init_creds_opt_set_fast_ccache_name() to set the location of a ccache containing a suitable ticket, before calling krb5_get_init_creds_password(), the client uses FAST. If the client tries to use FAST and the server doesn't support it, then the client will treat that as an error and fail to obtain a TGT.
If SSSD already has a credential cache when it goes to obtain a TGT for a user, this is probably a trivial addition, but I'd suggest it not be turned on by default. Hopefully it'd be available as an option for situations where it's already known that the KDC supports FAST (either beforehand or out-of-band, most likely).
If I understand this correctly we have to create a new boolean option, say krb5_use_fast, and if this option is set to true check if the user has a valid ticket no matter what kind of ticket in his credential cache. If we find a ticket we call krb5_get_init_creds_opt_set_fast_ccache_name() if not we do not call it and continue with krb5_get_init_creds_password(). If this understanding is correct it would be a fairly simple patch.
It looks that FAST is a new security feature of MIT Kerberos 1.8 which can make the general AS requests more secure even if there are no new authentication methods like OTP tokens. If the above description is correct I would vote for adding #237 back to the list for 1.1 (btw I think I'm mostly done the my 1.1 tasks).
bye, Sumit
HTH,
Nalin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAktnHTkACgkQeiVVYja6o6MNUgCeKWkk2Oh5m0DIMmxa21qPHcMJ yqAAnixWTbRG2sMxb3wI4hOtoWWZir6j =FMRt -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Stephen Gallagher -
Sumit Bose