Re: The usability of service ticket lifetimes

On Aug 21, 2012, at 6:35 PM, Jeffrey Hutzelman wrote:

> On Tue, 2012-08-21 at 15:22 -0700, Henry B. Hotz wrote:
>> On Aug 21, 2012, at 3:09 PM, Nico Williams wrote:
>> 
>>> On Tue, Aug 21, 2012 at 12:21 PM, Jeffrey Altman
>>> <[email protected]> wrote:
>>>> As part of any revision to RFC 4120, I would like to see this section
>>>> modified.
>>> 
>>> Note that some client libraries check that the KDC does not exceed the
>>> limits you quoted.  That means that relaxing them will require a KDC
>>> options flag in the request...  And it should only be used in KDC-REQs
>>> where the body of the request is protected (e.g., TGS-REQs and AS-REQs
>>> in a FAST tunnel).
>>> 
>>> Nico
>> 
>> IMO it's inappropriate (as in: a *bug*) for a client to unconditionally
>> enforce limits which are the KDCs responsibility to enforce.  If
>> nothing else, it makes it hard to support edge cases which may violate
>> some letters of the limits, but not the intent or the policy.  (I
>> suppose I'm a bit twitchy due to a PKINIT issue I ran into recently.)
> 
> Actually, no.  The protocol contains fields to allow a client to place
> limits on the lifetime and renew lifetime of tickets it requests, and
> the spec requires the KDC to obey those limits.  As a check that these
> fields have not been modified in transit, it is reasonable for a client
> to verify that the requested limits have not been exceeded.

Oh, yeah. . .  I remember a bug in that check.  Not really what I was talking about though.

Or, actually, it is.  In both cases the client was erroneously failing because it was not leaving checks/modifications to the discretion of the KDC when it should have.

> There is a mechanism for a client to indicate the KDC should use the
> maximum lifetime permitted by policy; when this is used, clients should
> not expect any particular values back.
> 
> -- Jeff
> 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email protected], or [email protected]

_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg