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

[Harlan Stenn <[e-mail]>]

Miroslav Lichvar writes:
> On Mon, Mar 07, 2016 at 10:21:15AM +0000, Harlan Stenn wrote:
>> 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."
> 
> I still don't follow here.

Please help me out.  I've written about this several times.

Originally, if there was an extension field there MUST be a MAC.

Tal wrrote Errata 3627 (or whatever) and removed that requirement.  I
didn't notice this.  I believe this was done because his experimental
checksum complement extension field, as written, *cannot* be done if
MAC protection is used.  In order to move his proposal forward, I've
delayed my proposal that provides similar functionality but allows the
first part of the packet to be protected by a MAC.

MAC protection is good.  NTS uses a 'single' Field Type, but the first
few packets have no MAC protection.  Therefore, the first few packets of
an NTS exchange arguably MUST have MAC protection outside the NTS
packet, and after the NTS packet begins to include MAC protection, one
MAY still want to have additional MAC protection outside of the NTS
packet.

We're getting ready to publish a "MAC in an Extension Field", and
arguably this is how it should have been originally done.  So in keeping
with the above logic, there are 2 pieces of information we want to see
for an extension field.  One is "SHOULD or MAY have MAC protection after
this field," and the other is "This extension field provides MAC
protection."

> > - Use a flag bit in the Field Type that says "My extension field does
> > not require a following MAC."
> 
> Meaning the field is not related to authentication?

Meaning "My extension field does not require a MAC after it".  This is
the "MAY" case as opposed to the "SHOULD" case.  An example of this is
Tal's checksum complement proposal, as currently written.  If ntpd sends
out an unauthenticated packet, the FPGA engine is free to rewrite the
transmit timestamp, but since the OS has already computed a UDP
checksum, if the transmit timestamp in the packet is changed it's almost
certain that a checksum complement will be needed to make sure the
existing UDP checksum will still be correct.  That's what Tal's proposal
is all about, and it's the first time we've seen a proposal for an
extension field where one MUST NOT have a MAC at the end of the packet.

This is for 2 reasons.  One is that changing the transmit timestamp will
invalidate the MAC.  The other is that the FPGA engine has no idea how
to calculate the MAC, so it can't generate one.

>> 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.
> 
> Can you give an example in which it would be useful to exchange that
> information in NTP packets?

I'll have to do this after I wake up.
 
> From the client's point of view, it either requires the server packets
> to be authenticated or not. If it does, it will send a field that
> enables some form of authentication and the server will have to
> process them in order to sent acceptable replies. When the association
> is initialized, the client will verify that MAC in the reply is good
> and covers all fields in the packet. There could be exceptions in the
> future like correction fields for NTP-aware networking devices, but
> that would a part of the specification that they are not covered by
> MAC and are placed in the packet after the extension field containing
> MAC.

I'll hvae to look at the above after I wake up.

>>> 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?
> 
>> - 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.
> 
> The SHA1 MAC is 24 octets, that's why there is a requirement for the
> last extension field to be at least 28 octets.

4 byte keyid plus 24 octets.  So 28 bytes is clearly potentially
ambiguous.

Extension fields of 4, 8, 12, or 16 bytes are also unambiguous.  Why
prohibit these lengths?

>> - 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
> 
> Isn't that restriction for keyid just for the autokey RFC? There are
> NTP implementations that allow any keyid with symmetric keys.

Originally:

- any extension field meant there MUST be a MAC.
- the only defined extention field as been autokey.
- if no extension field was present, then no autokey, and a MAC meant
  symmetric key was being used.  keyid < 65535.
- if an extension field was present, the autokey was being used, there
  MUST be a MAC, and  keyid > 65535.

>> 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.
> 
> I think a MAC could still pass all these tests and appear as an
> extension field. It wouldn't be a valid MAC, that would be extremely
> unlikely, but the expected digest would have to be calculated in order
> to detect that. The new restrictions on lengths of extension fields
> are supposed to prevent that if I understand it correctly.

Seems like false security to me.  It's easy enough to disambiguate.

Do you want to require *all* extension fields be at >68 bytes long
because somebody will want to use a 512 bit old-style MAC?  What if
somebody wants to use even longer digests?  What if somebody decides to
implement a MAC digest that uses some unexpected lengths?

Old (known) code will *never* do this.  New code will be using "MAC in
an extension field".
-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg