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 <na...@redhat.com> > Organization: Red Hat, Inc. > To: Stephen Gallagher <sgall...@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 -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
