[SSSD] On FAST support in SSSD

Dmitri Pal dpal at redhat.com
Mon Feb 1 23:42:19 UTC 2010


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 at redhat.com>
> Organization: Red Hat, Inc.
> To: Stephen Gallagher <sgallagh at 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 at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list