[19287] in Kerberos_V5_Development
Re: Gss context refresh failure due to clock skew
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Oct 7 11:08:49 2015
To: "Adamson, Andy" <William.Adamson@netapp.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <56153576.1090209@mit.edu>
Date: Wed, 7 Oct 2015 11:08:38 -0400
MIME-Version: 1.0
In-Reply-To: <16B417DB-F019-4654-8B4E-7C4C3AF1487D@netapp.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
"krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 10/07/2015 11:00 AM, Adamson, Andy wrote:
> —— from the ticket: ——
>
> This unnecessarily strict check causes a particularly bad experience
> when (a) the client's clock is slightly ahead of the server's clock,
> and (b) the maximum service ticket lifetime is lower than the maximum
> TGT lifetime.
>
> —— ——
> I think both a) and b) are incorrect.
>
> for a) you got it backwards. this occurs when the server clock is ahead of the client clock.
Yes, I did write the wrong thing there; I will follow up on that.
> for b) the relationship between the TGT lifetime and the service ticket lifetime is irrelevant. Only the service ticket lifetime has any effect as the client will use a valid service ticket to construct an RPCSEC_GSS_INIT request irregardless of the TGT lifetime value.
I will try one more time to communicate what I mean:
* If the service ticket end time is less than the TGT end time, then
gss_init_sec_context() fails during the clock skew window, and starts
succeeding again afterwards.
* If the service ticket and TGT have both expired (according to the
server), then gss_init_sec_context() fails, and keeps failing
afterwards, unless there is some out-of-band agent refreshing expired TGTs.
Put another way: we expect authentications to start failing around the
time the TGT expires. We do not expect authentications to start failing
around the time a service ticket expires, if the TGT is still valid.
That is what I refer to as a "particularly" bad experience.
If that isn't clear, perhaps we should ignore this as a moot point; it
doesn't really affect how we plan to change the krb5 code.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
