[18795] in Kerberos_V5_Development
Re: Automatic FAST via Anonymous PKINIT
daemon@ATHENA.MIT.EDU (Dmitri Pal)
Mon Jun 2 20:11:02 2014
Message-ID: <538D128C.7060905@redhat.com>
Date: Mon, 02 Jun 2014 20:10:52 -0400
From: Dmitri Pal <dpal@redhat.com>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <1401744267.4161.1.camel@ipa.example.com>
Reply-To: dpal@redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 06/02/2014 05:24 PM, Nathaniel McCallum wrote:
> On Mon, 2014-06-02 at 14:52 -0500, Nico Williams wrote:
>> On Mon, Jun 2, 2014 at 2:26 PM, Nathaniel McCallum
>> <npmccallum@redhat.com> wrote:
>>> Even if we use FAST to encrypt all traffic, the temporary anonymous
>>> ticket will only be used for ASReq requests. #4 provides no benefit to
>>> "FAST all the time" apart from ASReqs. The only case where it does make
>>> sense is in a login system. And the login system should (generally) be a
>>> Kerberos service in its own right. This is precisely how SSSD works. No
>>> anonymous ticket is needed because the service has its own ticket which
>>> is managed in the SSSD ticket ccache.
>> Mobile devices might not be keyed, or if they are they might not have
>> stable hostnames (so don't insist on host-based client credentials for
>> them, or on their matching the client's IP address).
> I don't think there is any plan to do this.
Actually we started poking at this area in attempt to bring FAST to
mobile devices. For initial case a key would be a prerequisite but a
good solution for a general case would be nice to have in a long run.
>
>> I agree that a per-session/user FAST armor ticket for protecting AS
>> _and_ TGS requests would be nice. Greg's #4 is not incompatible with
>> that: a PAM / whatever can make sure to obtain such a ticket for the
>> user, and if none is available, then kinit/krb5_get_init_creds*() can
>> do it (though in the last case it'd be an anon PKINIT ticket).
> Of course not. I'm only trying to point out that #1 is independent of
> #4. #4 is a nice feature, but I don't think it should hold back #1 from
> being implemented.
>
> Nathaniel
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
