Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer

[Harlan Stenn <[e-mail]>]

Miroslav Lichvar writes:
> On Sun, Mar 06, 2016 at 09:53:23AM +0000, Harlan Stenn wrote:
> > Autokey was defined with the requirement that its extension field be
> > protected by a MAC.  The revising language in Errata 3627 does not
> > address this at all.  One immediate recommendation is that 3627 be
> > amended to say that a MAC SHOULD be present in any packet that includes
> > any extension fields.
> 
> Why? I think presence of MAC should be required by individual
> extension fields which implement some form of authentication, it
> shouldn't be a general suggestion. Hopefully in future we will have
> extension fields for other things than authentication, and they can be
> used without authentication.

Originally, the *only* extension field defined was for autokey, and the
RFCs that included autokey all *required* a MAC.

Tal's EXPERIMENTAL proposal for the next created extension field
*cannot* use a MAC because of the way it's implemented.

Therefore, I have recommended 2 things:

- clean up Tal's' errata so that it says a MAC SHOULD be provided.  That
means "Provide a MAC unless you really understand what's going on and
have a good reason for not using one."

- Use a flag bit in the Field Type that says "My extension field does
not require a following MAC."

There are 2 players here, and I'll call them "A" and "B".  It's one
thing for A to say "I think the extension field I am sending should be
covered by a MAC".  It's another thing for B to have the option to have
looser requirements.

With the proposals I've made, we've got that sort of flexibility.

The following extension fields are currently either available or in
various stages of proposal:

- Autokey
- MAC extension field
- NTS
- Checksum Complement
- Suggested REFID
- "I'm the last extension field"

>> If we're really that concerned about this problem, then all we need
>> to do is to create a new extension field, 8 bytes long, which
>> indicates "I am the last extension field", so any data after that
>> would be an old-style MAC.
> 
> What would prevent a server from misinterpreting a random MAC in a
> client packet that doesn't include this extension field as some
> extension field?

A bunch of things, which I may have covered in some earlier emails.

Off the top of my head:

- the only 2 implemented MACs we know about are 20 bytes for MD5 and 24
bytes for DES.  There's also a 28 byte MAC for SHA.  We have at least
partial support for longer digests, at least 256 bit and 512 bit.

- a MAC consists of a 4-byte keyid and a payload.  If there is no
autokey extension field, the keyid MUST be <65535, and we SHOULD have
that keyid in our chain.  If there is an autokey extension field, the
keyid MUST be >65535 and the key ID MUST (but at worst, SHOULD) be in
our chain.  As a secondary check, we could see if there is any way the
first two octets are a Field Type, and the second 2 octets would have to
be a longword-aligned length that was <= the remaining packet length,
and if you wanted to be really careful, if there was leftover data then
this fragment MUST be an extension field, or the next fragment MUST be
either an extension field or a MAC.  So it's pretty easy to validate
these things.

We can also see if it processes "both ways".  But more telling, if we're
dealing with an older/current server, there are limited options.  If
we're dealing with an "updated" server, we'll have enough information in
the packet to know what it contains.

I'm thinking the only other situation is somebody has an NTP network
where they need to send out both old and new style packets.  If they are
this "complicated" then I gotta believe they have the smarts to
understand their deployment, and if they *do* have problems they should
have the resources to configure their NTP network so that they send new
packets to new clients, and old packets to old clients.

But I also figure I could have missed something.
-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg