On Sat, Jan 11, 2020, at 1:03 AM Hal Murray <hmur...@megapathdsl.net> wrote:
> > The current symmetric auth scheme requires a not-an-extension which is
> > (formerly 10) 20 or 24 bytes of an essentially unidentifiable binary blob.
> > to
> > check for it, you either need a length for the authenticated stream or walk
> > backward in the packet to see if the text matches a symmetric authenticator.
>
> That's not quite the right description. You don't walk backwards. You go
> forwards until you get to a reasonable stopping place, then check the length
> of what is left. 20 or 24 bytes are grandfathered (ugly hack) as
> non-extension authentication.
The backward walking was an anti-pattern I picked up somewhere. For
regular time packets, the method is now to read until you get to a
type 0 non-extension. Then ask if it is a valid authenticator.
> > My former proposed scheme requires something which is
> > not-properly-an-extensio
> > n. it has a six-byte header which should be regex searchable in mode 6 and
> > unlikely to occur (no number though) in a regular text stream.
>
> "regex searchable" doesn't sound like the right approach.
I was thinking wrongly that it would have been fewer than eight null
bytes, two bytes of known value for the extension type, two bytes in
a list of known values the former of which is probably 0, four bytes
for key/salt id which has two (or three) 0 bytes. so something like [1].
> Is Eric's mode 6 writeup accurate? docs/mode6.adoc
> (I haven't checked the code, but it looks good.)
>
> Assuming yes, then the current hack authentication will work and we can switch
> to using real extensions at any time.
It seems reasonably accurate AFAICT. I am only looking at small
pieces of it and there seems to be some an inconsistent use of
payload/extension in section 4 and I have not recently seen nor
attempted the use of a non-128bit key/salt for anything contrary
to section 7.
> My previous comments about using NTS were bogus. That lets the client know
> the response came from the correct server (or at least one with the correct
> certificate). We need the other direction: the server needs to know the
> client is authorized to do restricted operations. NTS doesn't support that.
Network Time Security could work for that but it would require scope
creep. Thinking back, I now think that would not be not a good thing.
It would not work well with the unlinkability goal of NTS.
[1] /\0{0,7}\x05\x04(\0.)(\0\0..)(.{16,64})$/
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
