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

[Miroslav Lichvar <[e-mail]>]

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.

> - 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?

> 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?

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.

> > 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.

> - 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.

> 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.

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg