FAST - enable by default?

[Zhanna Tsitkova]

Hmm... this brings us to the conversation about code modularity.

Thinking Kerberos Lite Client I'm coming from the opposite direction  
as one should have as small code/functionality footprint on the mobile  
device as possible. It would not be enough to identify just client vs  
server code - because some clients may need "server" functionality  
(U2U scenario)  , but also allow customers pick up the functionality  
they desire for their client-to-be. So, I suggest to restrict the  
functionality of the library during build time with such flags as  
NO_DES, NO_PKINIT, NO_RCACHE etc.




On Apr 6, 2009, at 6:22 PM, Sam Hartman wrote:

>>>>>> "Stephen" == Stephen C Buckley <sbuckley at MIT.EDU> writes:
>
>    Stephen> On Apr 6, 2009, at 5:35 PM, Zhanna Tsitkova wrote:
>
>> adding Sam.
>>>
>
> I'm certainly no expert, but isn't this a krbcore type question?
>
> I would actually think krbdev.
>
> So, there are two aspects to this.  1) compile-time.  Do we enable
> FAST at compile time.  Our policy has typically been to minimize the
> number of compile-time options, preferring to turn everything on and
> to the extent we provide configuration to do so at run-time.  The
> justification here is that many vendors ship our code as binaries as
> part of their operating systems.  When we provide a compile time
> option we provide vendors with a way to confuse their users by making
> functionality unavailable.  At best, the vendors will turn everything
> on.  At worst, they will turn some things off, and then the question
> of what is available on my operating system that ships MIT Kerberos
> 1.6.3 becomes more confusing than it should be.  Marshall was really
> strict about this; I was a bit less so, but certainly agreed with the
> general principle.
>
> Under this principle, FAST should definitely be enabled by default.
>
> Discussions of this principle should probably be on krbdev.

Hmm... this brings us to the code modularity.

Thinking Kerberos Lite Client I'm coming from the opposite direction  
as one should have as small code/functionality footprint on the mobile  
device as possible. It would not be enough - although one of the steps  
- to identify just client vs server code - because some clients may  
need "server" functionality (U2U scenario)  , but also allow customers  
to pick up the functionality they desire for their client-to-be. So, I  
suggest to restrict the functionality of the library during build time  
with such flags as NO_3DES, NO_PKINIT, NO_RCACHE, well... NO_FAST,  etc.

>
>
> 2) Runtime.  I don't see a need to disable FAST at the KDC layer.  We
> have typically not been concerned about KDC performance.  It's my
> understanding that Redhat has been a bit concerned about database
> performance, but I don't think anyone has brought up KDC crypto
> performance.
>
> Everything currently on the trunk requires explicit client
> configuration to enable.  I do have changes for client TGS support
> that would be on by default.  If we were going to ship Larry's
> negotiation stuff, I'd actually think  that was a really good idea.
> However given where things stand it's less clear to me that we want to
> turn on FAST all the time on the client for TGS.
>
> My concern is more about making a change this close to the release
> than about performance.
>


> From: Greg Hudson <ghudson at MIT.EDU>
> Date: April 6, 2009 4:39:09 PM EDT
> To: Zhanna Tsitkova <tsitkova at mit.edu>
> Cc: Tom Yu <tlyu at mit.edu>, "Stephen C. Buckley" <sbuckley at mit.edu>,  
> Thomas Hardjono <hardjono at mit.edu>
> Subject: Re: FAST - enable by default?
>
> The expensive part of FAST is the extra encryptions performed by the
> client and KDC when FAST is used via a ticket-based armor request.  I
> don't believe this will happen serendipitously; as currently  
> implemented
> it requires specific configuration.  Sam would know more about this.
> Actively preventing FAST from being used against a KDC should be as
> simple as removing the plugin, and perhaps simpler.
>
> In cases where FAST is not used, I believe the only performance impact
> is scanning the padata for a FAST request, and that's probably not
> measurable.
>
> On Mon, 2009-04-06 at 12:26 -0400, Zhanna Tsitkova wrote:
>> Hi!
>> FAST introduces the additional performance drawback and it is  
>> possible
>> that not all appl would want it for one or another reason.
>> Don't you think that one should have an option to disable it during
>> build or run time?
>>
>> Thanks,
>> Zhanna
>