[17549] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: clock skew and preauth

daemon@ATHENA.MIT.EDU (Stef Walter)
Thu Apr 5 16:21:18 2012

Message-ID: <4F7DFEB3.7040004@gnome.org>
Date: Thu, 05 Apr 2012 22:21:07 +0200
From: Stef Walter <stefw@gnome.org>
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <CAK3OfOgMfMZ92GvC6zSKAT+6nz2fnTb4KvYA9T0Q0V5PMUwC3Q@mail.gmail.com>
Cc: tlyu@mit.edu, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

On 2012-04-05 20:44, Nico Williams wrote:
> On Thu, Apr 5, 2012 at 12:51 PM, Stef Walter <stefw@gnome.org> wrote:
>> On 2012-04-05 19:48, Nico Williams wrote:
>>> If we're going to go this far, why not associate a realm name with
>>> each offset?  That way a multi-client-principal application can cope
>>> with each client realm having the wrong time.
>>
>> Yes, I was going to look at that next ;)
>>
>> But this preauth stuff is (and should be) conceptually separate. The
>> preauth server timestamp is untrusted, and so we shouldn't store it
>> anywhere. It's just to be used in the next encrypted timestamp preauth
>> reply. Essentially it becomes a challenge that we receive from the
>> server, which we respond to by encrypting it and sending it back.
> 
> Ah, fair enough.  But what about the per-ccache time offset?  It
> normally gets stored in the krb5_context.

Will look at that next week sometime. Haven't yet played with the
multi-realm stuff that much.

Cheers,

Stef
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post